June 2005 - U-Boot

[U-Boot-Users] SoM ftp password change
by NZG 01 Jun '05

01 Jun '05

Somebody was bombing our ftp site with some kind of recursive attack and eating up all the servers cpu time, so I'm afraid the public ftp thing is going to have to go down for now. Sigh, I supposed it was a matter of time.... In the mean time, we've modified the login, but will only be able to give it out to customers and trusted developers for the moment. If you would like to request access please send an email to coldfirertai(a)emacinc.com, and we will try to grant all reasonable requests. We will work on getting up a decent repository structure that's a bit more secure, but the netadmin say's I'll have to give him some time on it. Sorry for any inconvenience. P.S. Rev 3 of the SoM-5282EM board has just been released, which is a cleaner build that uses Minix busybox and supports the MMC. NZG.

1 0

[U-Boot-Users] RTL8138DL EEPROM contents.
by Herb Radford 01 Jun '05

01 Jun '05

We're using an RTL8139DL chip on our board and I need to fill the EEPROM on the 8139 with a default set of values. The "twister" parameters (TW_PARM_U/T) and Phy parameters (PHY1/2_PARM_T) are particularly problematic and worrisome. I've sent off a request to Realtek but I'm not holding my breath for a quick response. Does anyone perhaps have a default set (preferably a reliable set, not just a guess) that they would be willing to share? We did dump the contents from an 8139 NIC EEPROM, but there's no assurance that they are even close. Regards, Herb -- hradford(a)symbium.com

1 0

Re: [U-Boot-Users] pci_hose_read_config_byte() definition puzzles
by Sam Song 01 Jun '05

01 Jun '05

--- Wolfgang Denk <wd(a)denx.de> wrote: > The code is where it is to be expected - in > "drivers/pci.c": > > #define PCI_HOSE_OP(rw, size, type) > \ > int pci_hose_##rw##_config_##size(struct > pci_controller *hose, \ > pci_dev_t dev, > \ > int offset, type > value) \ > { > \ > return hose->rw##_##size(hose, dev, offset, > value); \ > } > > PCI_HOSE_OP(read, byte, u8 *) > PCI_HOSE_OP(read, word, u16 *) > PCI_HOSE_OP(read, dword, u32 *) > PCI_HOSE_OP(write, byte, u8) > PCI_HOSE_OP(write, word, u16) > PCI_HOSE_OP(write, dword, u32) > > Sometimes even "grep" cannot save you from actually > RTFS ;-) Lessons learned:-) Really appreciate your hints! Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

1 0

Re: [U-Boot-Users] pci_hose_read_config_byte() definition puzzles
by Sam Song 01 Jun '05

01 Jun '05

Wolfgang Denk <wd(a)denx.de> wrote: > > ./include/pci.h:extern int > pci_hose_read_config_byte(struct pci_controller > *hose, > > This looks very much like a prototype definition to > me. OK. It defines perfectly BUT where is the function pci_hose_read_config_byte() body? Only declaration is not enought to use it...... Thanks, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

2 1

[U-Boot-Users] pci_hose_read_config_byte() definition puzzles
by Sam Song 01 Jun '05

01 Jun '05

Hi all, I met a PCI init problem and happened to find several PCI functions like pci_hose_read_config_byte() defined and used but no function prototype. It made me really surprised. I hope I was in an unclear mind to report it:-) Attached is the grep result of u-boot-1.1.3 included in ELDK3.1.1. Any thoughts? Thanks in advance! Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_… [root@sam u-boot-1.1.3]# grep -r pci_hose_read_config_byte ./ ./board/MAI/AmigaOneG3SE/articiaS_pci.c: pci_hose_read_config_byte(hose, dev, PCI_HEADER_TYPE, &header_type); ./board/MAI/AmigaOneG3SE/articiaS_pci.c: pci_hose_read_config_byte(hose, dev, 0x0B, &c1); ./board/MAI/AmigaOneG3SE/articiaS_pci.c: pci_hose_read_config_byte(hose, dev, 0x0A, &c2); ./board/MAI/AmigaOneG3SE/articiaS_pci.c: pci_hose_read_config_byte(hose, dev, PCI_HEADER_TYPE, &header_type); ./board/MAI/AmigaOneG3SE/articiaS_pci.c: pci_hose_read_config_byte(hose, dev, PCI_SECONDARY_BUS, &secondary_bus); ./board/MAI/AmigaOneG3SE/articiaS_pci.c: pci_hose_read_config_byte(&articiaS_hose, bridge, 0x3E, &agp_control_0); ./board/Marvell/db64360/pci.c: pci_hose_read_config_byte_via_dword, ./board/Marvell/db64360/pci.c: pci_hose_read_config_byte_via_dword, ./board/Marvell/db64460/pci.c: pci_hose_read_config_byte_via_dword, ./board/Marvell/db64460/pci.c: pci_hose_read_config_byte_via_dword, ./board/dave/common/pci.c: pci_hose_read_config_byte_via_dword, ./board/esd/common/pci.c: pci_hose_read_config_byte_via_dword, ./board/esd/cpci750/pci.c: pci_hose_read_config_byte_via_dword, ./board/esd/cpci750/pci.c: pci_hose_read_config_byte_via_dword, ./board/evb64260/pci.c: pci_hose_read_config_byte_via_dword, ./board/evb64260/pci.c: pci_hose_read_config_byte_via_dword, ./board/mpl/common/pci.c: pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_PIN, &pin); ./board/mvblue/mvblue.c: pci_hose_read_config_byte (hose, bridge, PCI_SECONDARY_BUS, &bus); ./board/sc520_cdp/sc520_cdp.c: pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_PIN, &tmp_pin); ./board/sc520_spunk/sc520_spunk.c: pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_PIN, &tmp_pin); ./cpu/mpc5xxx/pci_mpc5200.c: pci_hose_read_config_byte_via_dword, ./cpu/mpc85xx/pci.c: pci_hose_read_config_byte(hose, ./drivers/pci.c: pci_hose_read_config_byte (hose, dev, PCI_INTERRUPT_PIN, &pin); ./drivers/pci.c: pci_hose_read_config_byte(hose, dev, PCI_HEADER_TYPE, &header_type); ./drivers/pci.c: pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_LINE, ./drivers/pci_auto.c: pci_hose_read_config_byte(hose, dev, PCI_CLASS_PROG, &prg_iface); ./include/pci.h:extern int pci_hose_read_config_byte(struct pci_controller *hose, ./include/pci.h:extern int pci_hose_read_config_byte_via_dword(struct pci_controller *hose, [root@sam u-boot-1.1.3]#

2 1

[U-Boot-Users] PATCH for drivers/cfi_flash.c
by Tolunay Orkun 01 Jun '05

01 Jun '05

This patch is prepared against current CVS: * Patch by Tolunay Orkun, 06 May 2005: Fixes for drivers/cfi_flash.c: - Fix wrong timeout value usage in flash_status_check() - Fix incorrect if condition in flash_full_status_check() - Remove clearing flash status at the end of flash_write_cfibuffer() which set Intel 28F640J3 flash back to command mode on CSB472 ~~~~ Verbose description of fixes: Fix #1: flash_status_check() receives the timeout as a parameter. Existing code is using erase_blk_tout which is too conservative for some operations but insufficient for others (like buffered writes) Fix #2: flash_full_status_check() does not combine conditions properly in the if statement. This fix was suggested by "Peter Pearse" <Peter.Pearse(a)arm.com> but a patch was never submitted as far as I can tell. Refer to: http://sourceforge.net/mailarchive/message.php?msg_id=10546157 Fix #3: flash_write_cfibuffer() would leave the flash in command mode. I had mentioned this problem on the list a couple of times but never had time to investigate until now. * Intel 28F640J3 flash on CSB472 board reverts to command mode if the removed line is present. Thus immediately after cp to flash operation, imls, boot etc would not work properly. md to flash displays 0x0080 (repeated) which is the value of status register of the flash. * When this line is present and executed the flash is already in Array Read mode (flash_full_status_check issues a reset command in the end). So clearing the status is unnecessary at best. Best regards, Tolunay Orkun Index: drivers/cfi_flash.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/drivers/cfi_flash.c,v retrieving revision 1.17 diff -p -u -r1.17 cfi_flash.c --- drivers/cfi_flash.c 13 Apr 2005 10:02:47 -0000 1.17 +++ drivers/cfi_flash.c 6 May 2005 07:06:04 -0000 @@ -676,7 +676,7 @@ static int flash_status_check (flash_inf /* Wait for command completion */ start = get_timer (0); while (flash_is_busy (info, sector)) { - if (get_timer (start) > info->erase_blk_tout * CFG_HZ) { + if (get_timer (start) > tout * CFG_HZ) { printf ("Flash %s timeout at address %lx data %lx\n", prompt, info->start[sector], flash_read_long (info, sector, 0)); @@ -701,7 +701,7 @@ static int flash_full_status_check (flas case CFI_CMDSET_INTEL_EXTENDED: case CFI_CMDSET_INTEL_STANDARD: if ((retcode != ERR_OK) - && !flash_isequal (info, sector, 0, FLASH_STATUS_DONE)) { + || !flash_isequal (info, sector, 0, FLASH_STATUS_DONE)) { retcode = ERR_INVAL; printf ("Flash %s error at address %lx\n", prompt, info->start[sector]); @@ -1263,7 +1263,6 @@ static int flash_write_cfibuffer (flash_ info->buffer_write_tout, "buffer write"); } - flash_write_cmd (info, sector, 0, FLASH_CMD_CLEAR_STATUS); return retcode; } #endif /* CFG_FLASH_USE_BUFFER_WRITE */

3 8

Re: [U-Boot-Users] PATCH for drivers/cfi_flash.c
by Peter Pearse 01 Jun '05

01 Jun '05

Tolkay Orkun wrote: > I do not have access to the patch file mentioned in that messages to compare I have sent him a copy Peter ------------------------------------------------------------------------- Peter Pearse ARM Ltd ------------------------ Peter.Pearse(a)arm.com -------------------------

1 0

Re: [U-Boot-Users] compile u-boot with recent toolchain : symbols problem
by Cedric VINCENT 01 Jun '05

01 Jun '05

---------- Forwarded message (without attachement) ---------- On 5/30/05, Wolfgang Denk <wd(a)denx.de> wrote: > In message <c8f10050526062372e8a833(a)mail.gmail.com> you wrote: > > > > I used to compile U-Boot with ELDK, but I currently need to work with > > newer toolchain : > > - binutils-2.16 > > - gcc-3.4.3 > > This looks line a binutils problem, then. May I ask why you have to > use binutils-2.16 ? We want to test recent toolchain, to see if we should migrate or not (our policy is to keep tools up-to-date, assuming fixes and new features are more important than new bugs). > > And which exact board are we talking about? We're talking about "ADS Virtex-II Pro Development board", I use ML300 port (and some parts of ML2 and MicroBlaze ports). > > > The "__u_boot_cmd_start" symbol value, generated with this new > > toolchain, is wrong (U-Boot crashes when relocating the command > > table). > > Can you please provide exact data, like the differences between the > System.map and the u-boot.map files when using binutils-2.16 and > another, working version of binutils? [Please use the _same_ version > of GCC for this comparison.] The problem doesn't appear using binutils-2.16 with GCC provided by ELDK... So it seems to be a GCC problem. > > > There are two new sections between "__u_boot_cmd_start" and > > ".u_boot_cmd" address : > > - .data.rel.local > > - .data.rel > > Can you please show exactly what happens? I attached 3 binaries : - u-boot_ELDK, which is compiled with binutils-2.11.93.0.2 (20020207) and gcc-2.95.4 - u-boot_binutils-2.16, which is compiled with binutils-2.16 and gcc-2.95.4 - u-boot_new_toolchain, which is compiled with binutils-2.16 and gcc-3.4.3 As you can see with this command, "__u_boot_cmd_start" is not at the right place : bash# powerpc-405-linux-gnu-nm u-boot_new_toolchain | sort [...] 0002ab8c A __u_boot_cmd_start 0002ab8c D init_sequence 0002abb8 d failed 0002abbc D op_table 0002ac24 D stdio_names 0002ac30 d av_ 0002b038 D z_errmsg 0002b058 D __u_boot_cmd_autoscr 0002b070 D __u_boot_cmd_bdinfo 0002b088 D __u_boot_cmd_reset 0002b0a0 D __u_boot_cmd_go [...] Since U-Boot uses the address of "__u_boot_cmd_start" to point to the first entry of the command table, U-Boot crashes when relocating this table. Here, the address of "__u_boot_cmd_start" should be 0x0002b058. I noticed that symbol "init_sequence" belongs to section ".data.rel" and symbols "failed", "op_table", "stdio_names", "av_" and "z_errmsg" belong to section ".data.rel.local". As you can see with this command, these new sections are above the ".u_boot_cmd" section : bash# powerpc-405-linux-gnu-readelf -S u-boot_new_toolchain [...] [ 1] .text PROGBITS 00010000 000094 016684 00 AX 0 0 4 [ 2] .resetvec PROGBITS 00026684 016718 000004 00 AX 0 0 1 [ 3] .rodata PROGBITS 00026688 01671c 003500 00 A 0 0 4 [ 4] .reloc PROGBITS 00029c00 019c94 000ab8 00 WA 0 0 1 [ 5] .data PROGBITS 0002a6b8 01a74c 0004d4 00 WA 0 0 4 [ 6] .data.rel PROGBITS 0002ab8c 01ac20 00002c 00 WA 0 0 4 [ 7] .data.rel.local PROGBITS 0002abb8 01ac4c 0004a0 00 WA 0 0 4 [ 8] .u_boot_cmd PROGBITS 0002b058 01b0ec 000348 00 WA 0 0 4 [...] So "__u_boot_cmd_start" points to the start of the ".data.rel" section instead of the start of ".u_boot_cmd" section. These new sections are disassembled in attached files "section_.data.rel.local_dump" and "section_.data.rel_dump". Thanks. Best regards, Cedric VINCENT. > > > > I don't know what these (new) sections are, but the problem can be > > solved in "u-boot.lds" : > > - __u_boot_cmd_start = .; > > .u_boot_cmd : { *(.u_boot_cmd) } > > __u_boot_cmd_end = .; > > + __u_boot_cmd_start = ADDR(.u_boot_cmd); > > I would like to understand this problem first before deciding about > any fixes or patches. > > Thanks. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > "The computer programmer is a creator of universes for which he alone > is responsible. Universes of virtually unlimited complexity can be > created in the form of computer programs." - Joseph Weizenbaum, > _Computer Power and Human Reason_ >

1 0

RE: [U-Boot-Users] tftpboot question
by Bharath G - CTD , Chennai 01 Jun '05

01 Jun '05

Hi, >Hi all, and sorry for disturbing you again. >I'm trying to load an image from a tftp server using tftpboot. >Server is reachable, and running. Address of image is correct. >U-boot contacts the right IP, then tries to load the image and intead >of printing "#" as documented, prints "T" (it means timeout I >suppose). >But I continue getting an error message: "Retry count exceeded" >Then the procedure starts again. >What this behaviour can depend from? >I excluded tftp configuration problems and network problems. Are you running tftpd on a linux box? Try turning off your firewall ! Sometimes UDP packets are blocked .... Try Tftping small files 1K and see if they work ... And If by chance you are using montavista binaries for tftpd , in all probability they wont work with u-boot.It did not work with a PQ2FADS-ZU board for me (even for their customer support here in INDIA). Cheers, .Bharath. EGO iS NotHinG wIthOuT ArrOgAncE tO BaCk iT uP..." DISCLAIMER This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer

1 0

Re: [U-Boot-Users] Support for Samsung 1Giga bit NAND device
by Laurent Mohin 01 Jun '05

01 Jun '05

Andy, U-boot 1.1.0 doesn't provide support for NAND flash with a page size of 2K-byte instead of 512 byte (and you're right, theses devices require special handling). Pantelis Antoniou submitted a patch on 2004-04-30 which seems to manage these new chips, but I don't think it has been added to the latest CVS tree. By the way, Samsung also offer 1 Giga bit devices with a 512 byte page size (K9K1G08UOM - Manufacturer ID : 0xEC, Chip ID: 0x79). Hope this helps, Laurent Andy Hawkins <a.hawkins(a)cabletime.com> Sent by: u-boot-users-admin(a)lists.sourceforge.net 14/06/04 13:40 To: u-boot-users(a)lists.sourceforge.net cc: Subject: [U-Boot-Users] Support for Samsung 1Giga bit NAND device Hi, Can anyone tell me if U-Boot has support for the Samsung 1 Giga Bit NAND devices (Manufacturer ID: 0xec, Chip ID: 0xf1)? I understand these devices have an unusually large block size, that needs special handling. Is this correct? Thanks. Andy ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

4 8

[U-Boot-Users] NS9360 / NS 9750 config file
by Terence Soh 01 Jun '05

01 Jun '05

Hi, I apologize if this is somewhat offline but I requesting for the BDI2000 config file for NetSilicon NS9360/9750 evaluation board. I am currently having problem trying to program/erase the flash on the board so that I can get u-boot to boot. Thanks, Terence.

1 0

[U-Boot-Users] DENX SELF, a more current version?
by jds 01 Jun '05

01 Jun '05

folks, is there a more current version of the DENX SELF somewhere? i am referring to ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/ following "how to build SELF" in the readme ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/README i see that the paths in ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/URL are either out of date or completely out of commission. if someone has a pointer to a more current SELF recipe it would be appreciated. otherwise i'll have a go at updating the current recipe. OR if someone has a pointer to a ppc rootfs build script that would be appreciated as well. thanks, jim

1 0