October 2004 - U-Boot

RE: [U-Boot-Users] PPC as host
by VanBaren, Gerald (AGRE) 25 Oct '04

25 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Richard Klingler > Sent: Monday, October 25, 2004 11:02 AM > To: u-boot-users > Subject: [U-Boot-Users] PPC as host > > Evening (o; > > > Apparently no one uses Linux PPC as host? > So no one ever had problems cross-compiling u-boot for > another target then (o; > > > In the top Makefile we have: > > ifndef CROSS_COMPILE > ifeq ($(HOSTARCH),ppc) > CROSS_COMPILE = > else > .... > > which always picks up the host ppc compiler regardless what > ARCH you have defined for your board... > > > Since I don't use PPC as target someone might come up with a > better idea then: > > ifeq ($(HOSTARCH,$(ARCH)) > CROSS_COMPILE = > else > ... > > > In my case it is YDL-3.0.1 PPC Linux running on G4. > This doesn't happen on OSX since it is solved in the top > config.mk file. > > > best regards > rick The Makefile makes its best guess about cross compilers given very limited information. It may guess wrong, as you are seeing. For more information, see: http://www.denx.de/twiki/bin/view/DULG/ELDKUsage <blockquote> * After the installation utility completes, export the CROSS_COMPILE variable: bash$ export CROSS_COMPILE=ppc_8xx- TIP The trailing '-' character in the CROSS_COMPILE variable value is optional and has no effect on the cross tools behavior. </blockquote> A related hint (if you don't like the export hint) is in http://www.denx.de/twiki/bin/view/DULG/LinuxConfiguration <blockquote> If your host computer is not the same architecture as the target system, and if you got your kernel tree from kernel.org or other "official" sources, then you may have to supply an architecture override and a cross compiler definition. The most reliable way to do this is to specify them on the make command line as part of the make command. If this is the case, use for example: bash$ make ARCH=ppc CROSS_COMPILE=ppc_8xx- </blockquote> gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

3 2

[U-Boot-Users] Ebony (440GP) fails to bootp in Linux after U-Boot...
by Rani Glaser 25 Oct '04

25 Oct '04

Hi, I've been using the the IBM booter that comes with the Ebony and successfully booted my Linux kernel (2.6.8.1 based) on the Ebony. This includes the IBM booter doing tftp, then the kernel running bootp/dhcp and mounting the nfs smoothly. Lately I've been trying to move to u-boot. Although installation of u-boot to the flash and booting u-boot went quite fine, I'm unable to finish the kernel boot process. First I generated a kernel for the IBM booter using the make and tftp-loaded zImage.ebony. Everything works fine. Then switched to the u-boot flash (using U46 SW1). Then I generated the linux kernel using "make uImage", using "tftpbootm 0x500000 /somewhere/uImage ; bootm 0x50000". (IBM booter used same 0x500000 address). It loads nicely then just keeps trying to "BOOTP". Configuring the IP by hand just moves the problem later to the NFS mounting process since no ethernet traffic exists. I did notice that the kernel doesn't automatically load the u-boot MAC address correctly (kernel originally showed MAC is ff:ff:ff:ff:ff:ff on u-boot), so for the time being I patched the source of the MAC and inserted it by hand into the kernel code (now the kernel shows the correct MAC when booting). Again, this runs fine on the IBM booter. However, after I boot using u-boot, there doesn't seem to be any traffic coming from the kernel (monitored using ethereal). I turned on some debugging features in the 440GP EMAC driver, and it seems that the EMAC driver gets request to transmit the BOOTP request, but nothing comes in or out. Anyone have any solutions for this?!? Please help me out. Many thanks, Rani Glaser ranig <at> go-wlan.com

2 1

RE: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET
by VanBaren, Gerald (AGRE) 25 Oct '04

25 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Steven Scholz > Sent: Monday, October 25, 2004 10:28 AM > To: u-boot-users > Subject: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET > > Hi there, > > as mentioned on list before some boards/cpus might need some > extra code to be executed _before_ rebooting. E.g. the i.MX > hangs when doing "reset" while the LCD controller is still enabled. > > That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and > board_pre_reset(). > The attached does exactly that. But only for cpu/arm920t. > If wished I'll add the appropriate code to all cpu/$(CPU)/cpu.c files. > > * Patch by Steven Scholz, 25 Oct 2004: > - Introducing CONFIG_BOARD_PRE_RESET and board_pre_reset() to allow > code to be executed before actually rebooting > > -- > Steven Scholz Hi Steven, I like your suggestion a lot, but I would suggest a "#ifdef" around the common.h kind of like I hand-pasted in below (probably incorrectly, but you get my meaning). gvb Index: include/common.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/common.h,v retrieving revision 1.46 diff -p -u -r1.46 common.h --- include/common.h 10 Oct 2004 18:41:14 -0000 1.46 +++ include/common.h 25 Oct 2004 13:32:15 -0000 @@ -318,6 +318,9 @@ int board_late_init (void); int board_postclk_init (void); /* after clocks/timebase, before env/serial */ int board_early_init_r (void); void board_poweroff (void); +#ifdef CONFIG_BOARD_PRE_RESET +void board_pre_reset (void); +#endif #if defined(CFG_DRAM_TEST) int testdram(void); ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

2 1

[U-Boot-Users] Compile problem for ARM / LPD7A400
by Devraj Mukherjee 25 Oct '04

25 Oct '04

Hi everyone, I am using arm-linux GCC 3.3 with GlibC 2.3.2. I have managed to compile a Linux version 2.6 kernel with this setup and patches for Logic PD card engine LPD7A400. I am trying to get a version of U-Boot with working with the same. I have applied all available patches, that I gathered for the board from this list serve. I get the following errors when I am trying to compile UBoot. Is there anyone who can encoutnered this problem and if so any lead? Thanks in advance. Dump from compile time: In file included from cfi_flash.c:48: /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:52: parse error before `1' /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:52: warning: no semicolon at end of struct or union /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:54: parse error before `}' /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:58: field `insn' has incomplete type make[1]: *** [cfi_flash.o] Error 1 make[1]: Leaving directory `/home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/drivers' make: *** [drivers/libdrivers.a] Error 2 Regards, Devraj

2 1

Re: [U-Boot-Users] question about net/net.c
by Robin Getz 25 Oct '04

25 Oct '04

Wolfgang requested: >Can you please re-send this question in form of a (suggested / >potential) patch? That would be much more readable. Sorry for the delay - traveling over the weekend... ============================================= --- ../cvs/u-boot_1.1.1/net/net.c 2004-07-02 04:45:14.000000000 -0700 +++ ./u-boot_1.1.1/net/net.c 2004-10-25 05:59:54.000000000 -0700 @@ -1241,7 +1241,7 @@ case ARPOP_REPLY: /* arp reply */ /* are we waiting for a reply */ if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC) - break; + return; #ifdef ET_DEBUG printf("Got ARP REPLY, set server/gtwy eth addr (%02x:%02x:%02x:%02x:%02x:%02x)\n", arp->ar_data[0], arp->ar_data[1], @@ -1276,7 +1276,7 @@ #endif return; } - + break; case PROT_RARP: #ifdef ET_DEBUG puts ("Got RARP\n"); ======================================================= This will fix the issue described previously, where: 1. u-boot initiates a tftp transfer 2. u-boot sets a flag "NetArpWaitPacketMAC = 1" 3. u-boot sends ARP Request on network to find the MAC address of tftp server 4. server is a little slow, and u-boot has not yet received the ARP so, u-boot sends ARP Request on network to find the MAC address of tftp server 5. tftp server responds back to first request with it's MAC address, and u-boot sees this, and accepts it. 6. u-boot sets the flag "NetArpWaitPacketMAC = 0" as it got the ARP reply 7. tftp server responds back to second request with it's MAC address, and u-boot sees this, and accepts it. At this point as u-boot is not waiting (NetArpWaitPacketMAC is 0) for ARP reply breaks out of the switch that handles ARP reply. But this break is not to return from the complete handler and thus falls into RARP handler code. 8. u-boot prints out "invalid RARP header".

1 0

[U-Boot-Users] Testing of Ethernet.
by Prathima_Kolar 25 Oct '04

25 Oct '04

Hello All, Can anyone please tell me how i can test Read and Write to registers on LXT971A if it is not memory mapped. Thanks & Regards, Prathima Kolar. ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **************************************************************************

3 2

[U-Boot-Users] U-boot for Malta
by calvin 24 Oct '04

24 Oct '04

Hi, I am trying to port u-boot for MALTA(mips) board. The code downloads properly at the appropriate Flash address (0xBFC0000) but then loops back at some point due to memory problems. here is the dump file - > ffffffffbfc00300: 10000090 b ffffffffbfc00544 <romExcHandle> > ffffffffbfc00304: 241a0300 li $k0,768 ffffffffbfc00544 <romExcHandle>: ffffffffbfc00544: 1000ffff b ffffffffbfc00544 <romExcHandle> Other boot loaders works ok. that means hardware is working perfectly fine. Any pointers would be helpful. Thanks and regards, Pooja

2 1

[U-Boot-Users] Switching of LCD controller before reboot?
by Steven Scholz 22 Oct '04

22 Oct '04

Hi there, my i.MX based board does not reboot but hangs when doing "reset" (on u-boot) or "reboot" (on linux) when the internal LCD contoller is enabled. Thus I have to disable the LCD contoller before doing that. Something else: The AT91RM9200DK needs to "shutdown the console to avoid strange chars during reset". So my question is: Where would be the appropriate place for stuff like that? Should we clobber cpu/arm920t/cpu.c with all the processor or board specific reset related stuff? Or would it be better to have something like cpu_init, /* basic cpu dependent setup */ board_init, /* basic board dependent setup */ ... cpu_reset, /* basic cpu dependent reset */ board_reset, /* basic board dependent reset */ or prepare_reset based on defines like CONFIG_BOARD_PRE_RESET or something? Thanks. -- Steven Scholz

3 8

[U-Boot-Users] PATCH: Support for Motorola HiddenDragon board
by Santoso, Yusdi 22 Oct '04

22 Oct '04

Patch to add support fo Motorola HiddenDragon board. Thanks, Yusdi

1 0

[U-Boot-Users] [patch][CVS] Updating for RPXlite_DW
by Sam Song 22 Oct '04

22 Oct '04

Hi list, I found sth was broken on my previous patch which I did on Oct. 11 because there were some conflicts in it. I don't know why cvs diff did it like that. So I redid the patch against CVS and test it on RPXlite DW board fully. Pls apply this patch. Wolfgang, if I confuse you again with my patch, pls forgive me again. To make RPXlite DW board close to system deployment, PREBOOT and AUTOBOOT function was added. CHANGELOG: * Patch by Sam Song, 22 October 2004: - Add PREBOOT/AUTOBOOT support for RPXlite_DW board ===== Best regards, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_… Index: board/RPXlite_dw/README =================================================================== RCS file: /cvsroot/u-boot/u-boot/board/RPXlite_dw/README,v retrieving revision 1.1 diff -p -u -r1.1 README --- board/RPXlite_dw/README 9 Jun 2004 21:04:49 -0000 1.1 +++ board/RPXlite_dw/README 22 Oct 2004 01:17:22 -0000 @@ -2,11 +2,11 @@ After following the step of Yoo. Jonghoon and Wolfgang Denk, I ported u-boot on RPXlite DW version board: RPXlite_DW or LITE_DW. -There are three differences between the Yoo-ported RPXlite and the RPXlite_DW. +There are at least three differences between the Yoo-ported RPXlite and the RPXlite_DW. -Board(in U-BOOT) version(in EmbeddedPlanet) CPU SDRAM FLASH +Board(in U-Boot) version(in EmbeddedPlanet) CPU SDRAM FLASH RPXlite RPXlite CW 850 16MB 4MB -RPXlite_DW RPXlite DW 823e 64MB 16MB +RPXlite_DW RPXlite DW(EP 823 H1 DW) 823e 64MB 16MB This fireware is specially coded for EmbeddedPlanet Co. Software Development Platform(RPXlite DW),which has a NEC NL6448BC20-08 LCD panel. @@ -17,6 +17,7 @@ It has the following three features: The default setting is 48MHz.To get a 64MHz u-boot,just add '64' in make command,like +make distclean make RPXlite_DW_64_config make all @@ -28,19 +29,21 @@ didn't use EEPROM for ENV is that Planet home.Because of the possibility of using two firewares on this board,I didn't 'disturb' EEPROM.To get NVRAM support,you may use the following build command: +make distclean make RPXlite_DW_NVRAM_config make all 3. LCD panel support -To support the Platform better,I added LCD panel(NL6448BC20-08) function.But bewear of -the fact that once you build this support and program it to FLASH,you should make sure -you put workable kernel and ramdisk at the right place in FLASH or through NFS. -Otherwise, you must erase this fireware manually via BDI2000 or ICE tools.So this -function is used for deployment and demo only.Pls look before you leap. +To support the Platform better,I added LCD panel(NL6448BC20-08) function. +For the convenience of debug, CONFIG_PERBOOT was supported. So you just +perss ENTER if you want to get a serial console in boot downcounting. +Then you can switch to LCD and serial console freely just typing +'run lcd' or 'run ser'. They are only vaild when CONFIG_LCD was enabled. To get a LCD support u-boot,you can do the following: +make distclean make RPXlite_DW_LCD_config make all @@ -68,7 +71,7 @@ make RPXlite_DW_64_LCD_config The boot process by "make RPXlite_DW_config" could be: -U-Boot 1.1.1 (Jun 8 2004 - 11:16:30) +U-Boot 1.1.2 (Oct 22 2004 - 08:15:50) CPU: PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB D-Cache Board: RPXlite_DW @@ -80,10 +83,72 @@ In: serial Out: serial Err: serial Net: SCC ETHERNET +Hit any key to stop autoboot: 6 + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A word on the U-Boot enviroment variable setting and usage : + +In the beginning, you could just need very simple defult environment variable setting, +like[include/configs/RPXlite.h] : + +#define CONFIG_BOOTCOMMAND \ + "bootp; " \ + "setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) " \ + "ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off; " \ + "bootm" + +This is enough for kernel NFS test. But as debug process goes on, you would expect +to save some time on environment variable setting and u-boot/kernel updating. +So the default environment variable setting would become more complicated. Just like +the one I did in include/configs/RPXlite_DW.h. + +Two u-boot commands, ku and uu, should be careful to use. They were designed to update +kernel and u-boot image file respectively. You must tftp your image to default address +'100000' and then use them correctly. Yeah, you can create your own command to do this +job. :-) The example u-boot image updating process could be : + +u-boot>t 100000 RPXlite_DW_LCD.bin +Using SCC ETHERNET device +TFTP from server 172.16.115.6; our IP address is 172.16.115.7 +Filename 'RPXlite_DW_LCD.bin'. +Load address: 0x100000 +Loading: ############################# +done +Bytes transferred = 144700 (2353c hex) +u-boot>run uu +Un-Protect Flash Sectors 0-4 in Bank # 1 +Erase Flash Sectors 0-4 in Bank # 1 +.... done +Copy to Flash... done +ff000000: 27051956 552d426f 6f742031 2e312e32 '..VU-Boot 1.1.2 +ff000010: 20284175 67203239 20323030 34202d20 (Aug 29 2004 - +ff000020: 31353a32 303a3238 29000000 00000000 15:20:28)....... +ff000030: 00000000 00000000 00000000 00000000 ................ +ff000040: 00000000 00000000 00000000 00000000 ................ +ff000050: 00000000 00000000 00000000 00000000 ................ +ff000060: 00000000 00000000 00000000 00000000 ................ +ff000070: 00000000 00000000 00000000 00000000 ................ +ff000080: 00000000 00000000 00000000 00000000 ................ +ff000090: 00000000 00000000 00000000 00000000 ................ +ff0000a0: 00000000 00000000 00000000 00000000 ................ +ff0000b0: 00000000 00000000 00000000 00000000 ................ +ff0000c0: 00000000 00000000 00000000 00000000 ................ +ff0000d0: 00000000 00000000 00000000 00000000 ................ +ff0000e0: 00000000 00000000 00000000 00000000 ................ +ff0000f0: 00000000 00000000 00000000 00000000 ................ +u-boot updating finished u-boot> +Also for environment updating, 'run eu' could let you erase OLD default environment variable +and then use the working u-boot environment setting. + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Finally, if you want to keep the serial port to possible debug on spot for deployment, you +just need to enable 'DEPLOYMENT' in RPXlite_DW.h as 'DEBUG' does. Only the special string +defined by CONFIG_AUTOBOOT_STOP_STR like 'st' can stop the autoboot. + I'd like to extend my heartfelt gratitute to kind people for helping me work it out. I would particually thank Wolfgang Denk for his nice help. @@ -93,4 +158,4 @@ Sam Song, samsongshu(a)yahoo.com.cn Institute of Electrical Machinery and Controls Shanghai University -June 8,2004 +October 22, 2004 Index: include/configs/RPXlite_DW.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/RPXlite_DW.h,v retrieving revision 1.3 diff -p -u -r1.3 RPXlite_DW.h --- include/configs/RPXlite_DW.h 9 Oct 2004 22:45:00 -0000 1.3 +++ include/configs/RPXlite_DW.h 22 Oct 2004 01:17:35 -0000 @@ -45,6 +45,7 @@ */ /* #define DEBUG 1 */ +/* #define DEPLOYMENT 1 */ #undef CONFIG_MPC860 #define CONFIG_MPC823 1 /* This is a MPC823e CPU. */ @@ -59,19 +60,32 @@ #undef CONFIG_8xx_CONS_NONE #define CONFIG_BAUDRATE 9600 /* console default baudrate = 9600bps */ -#ifdef CONFIG_LCD -#define CONFIG_BOOTDELAY 12 /* autoboot after 12 seconds */ +#ifdef DEBUG +#define CONFIG_BOOTDELAY -1 /* autoboot disabled */ #else -#define CONFIG_BOOTDELAY -1 /* autoboot disabled */ +#define CONFIG_BOOTDELAY 6 /* autoboot after 6 seconds */ +#define CONFIG_BOOTDELAY 6 /* autoboot after 6 seconds */ + +#ifdef DEPLOYMENT +#define CONFIG_BOOT_RETRY_TIME -1 +#define CONFIG_AUTOBOOT_KEYED +#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (stop with 'st')...\n" +#define CONFIG_AUTOBOOT_STOP_STR "st" +#define CONFIG_ZERO_BOOTDELAY_CHECK +#define CONFIG_RESET_TO_RETRY 1 +#define CONFIG_BOOT_RETRY_MIN 1 +#endif #endif +/* pre-boot commands */ +#define CONFIG_PREBOOT "setenv stdout serial;setenv stdin serial" + #undef CONFIG_BOOTARGS #define CONFIG_EXTRA_ENV_SETTINGS \ "netdev=eth0\0" \ - "nfsargs=setenv bootargs console=ttyS0,9600 root=/dev/nfs rw " \ - "nfsroot=$(serverip):$(rootpath)\0" \ - "ramargs=setenv bootargs console=tty0 console=ttyS0,9600 " \ - "root=/dev/ram rw\0" \ + "nfsargs=setenv bootargs console=tty0 console=ttyS0,9600 " \ + "root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)\0" \ + "ramargs=setenv bootargs console=tty0 root=/dev/ram rw\0" \ "addip=setenv bootargs $(bootargs) " \ "ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask)" \ ":$(hostname):$(netdev):off panic=1\0" \ @@ -82,8 +96,18 @@ "net_nfs=tftp 200000 $(bootfile);run nfsargs addip;bootm\0" \ "gatewayip=172.16.115.254\0" \ "netmask=255.255.255.0\0" \ - "kernel_addr=ff080000\0" \ + "kernel_addr=ff040000\0" \ "ramdisk_addr=ff200000\0" \ + "ku=era $(kernel_addr) ff1fffff;cp.b 100000 $(kernel_addr) " \ + "$(filesize);md $(kernel_addr);" \ + "echo kernel updating finished\0" \ + "uu=protect off 1:0-5;era 1:0-5;cp.b 100000 ff000000 " \ + "$(filesize);md ff000000;" \ + "echo u-boot updating finished\0" \ + "eu=protect off 1:6;era 1:6;reset\0" \ + "lcd=setenv stdout lcd;setenv stdin lcd\0" \ + "ser=setenv stdout serial;setenv stdin serial\0" \ + "verify=no" \ "" #define CONFIG_BOOTCOMMAND "run flash_self"

1 0

[U-Boot-Users] question about net/net.c
by Robin Getz 22 Oct '04

22 Oct '04

I had a question about the latest version of net/net.c scenario is as follows. 1. u-boot initiates a tftp transfer 2. u-boot sets a flag "NetArpWaitPacketMAC = 1" 3. u-boot sends ARP Request on network to find the MAC address of tftp server 4. server is a little slow, and u-boot has not yet received the ARP so, u-boot sends ARP Request on network to find the MAC address of tftp server 5. tftp server responds back to first request with it's MAC address, and u-boot sees this, and accepts it. 6. u-boot sets the flag "NetArpWaitPacketMAC = 0" as it got the ARP reply 7. tftp server responds back to second request with it's MAC address, and u-boot sees this, and accepts it. At this point as u-boot is not waiting (NetArpWaitPacketMAC is 0) for ARP reply breaks out of the switch that handles ARP reply. But this break is not to return from the complete handler and thus falls into RARP handler code. 8. u-boot prints out "invalid RARP header". This can be observed in net\net.c "NetReceive" function. =============================================== void NetReceive(volatile uchar * inpkt, int len) { [snip/snip] switch (x) { case PROT_ARP: switch (ntohs(arp->ar_op)) { case ARPOP_REQUEST: /* reply with our IP address */ return; case ARPOP_REPLY: /* arp reply */ /* are we waiting for a reply */ if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC) break; return; default: return; } case PROT_RARP: break; ================================================== am I missing something or shouldn't there be a break; above the 'case PROT_RARP:' to handle this? Thanks -Robin

3 2

[U-Boot-Users] Sending patch
by Santoso, Yusdi 21 Oct '04

21 Oct '04

Hi all, I'm planning to send a patch to add Motorola HiddenDragon board support, but I do not have access to CVS in my work place. Can I send a patch agains the latest stable (1.1.1) version? Or the latest snapshot in the FTP (2004-08-18) ? Thanks, Yusdi

2 1

[U-Boot-Users] Debugging u-boot using an EPI Majic JTAG
by Christian Kapeller 21 Oct '04

21 Oct '04

Hi! I'm trying to debug u-boot 1.1.1 using a EPI Majic JTAG probe for arm processors on an PXA255. I load the compiled elf-binary down using the JTAG, and try to run it. I get immediately a "Hardware instruction breakpoint" message. Other binaries run without problems using the JTAG. Also when i flash u-boot it works. Has anyone of you used a EPI Majic to debug u-boot successfully? Here are the logs: --snip-- EPI Symbolic Assembly Level Debug Monitor, version V6.9.7 - Linux(x86) Copyright (c) 1987-2000 by Embedded Performance Inc. - All Rights Reserved. Processing register file: /home/chrkap/tinylinux/edta21/bin/arm/spaces.rd Processing register file: /home/chrkap/tinylinux/edta21/bin/arm/pxa250.rd Processing register file: /home/chrkap/tinylinux/edta21/bin/arm/80200.rd Processing register file: /home/chrkap/tinylinux/edta21/bin/arm/majic.rd Reading command history from: '/home/chrkap/tinylinux/edta21/bin/startedb.hst' Establishing communications with remote target via 192.168.0.2... Connection verified Target System: EPI Majic Probe, Version: 3.2.6, S/N 0310H016 Hardware Rev: a0:3:3:10 Target CPU: PXA21x/PXA25x/PXA26x Ethernet: at address 00:80:CF:00:17:FA IP address: 192.168.0.2, Subnet mask: 255.255.255.0 Trace Buffer: 0 frames Profiler: Not Installed Connected via: Ethernet UDP/IP Device name: 192.168.0.2 Target Endian: little Start Address: 00000000: EPI-OS (HIF): on Reset Mode: capture Reading commands from /home/chrkap/tinylinux/edta21/bin/startice.cmd MON> +q // Enter quiet mode Reading startice.cmd file Notification from the target: Target power detected on VREF Auto JTAG detection process detected 1 TAP JTAG connection established Reading dbpxa250.cmd Executing One Time Setup Commands Executing Target Init Commands 48000008: 26F226F2 4800000c: 3FF4A441 48000010: 00007FF0 48000004: 00010018 a0000000: 00000000 00000000 00000000 00000000 a0000010: 00000000 00000000 00000000 00000000 a0000020: 00000000 00000000 00000000 00000000 a0000030: 00000000 00000000 00000000 00000000 a0000040: 00000000 00000000 00000000 00000000 a0000050: 00000000 00000000 00000000 00000000 a0000060: 00000000 00000000 00000000 00000000 a0000070: 00000000 00000000 00000000 00000000 a0000080: 00000000 00000000 00000000 00000000 a0000090: 00000000 00000000 00000000 00000000 a00000a0: 00000000 00000000 00000000 00000000 a00000b0: 00000000 00000000 00000000 00000000 a00000c0: 00000000 00000000 00000000 00000000 a00000d0: 00000000 00000000 00000000 00000000 a00000e0: 00000000 00000000 00000000 00000000 a00000f0: 00000000 00000000 00000000 00000000 Finished reading dbpxa250.cmd Finished reading startice.cmd MON> l /home/chrkap/u-boot/u-boot loading /home/chrkap/u-boot/u-boot section .text from a3f80000 to a3f93cd7 section .rodata from a3f93cd8 to a3f941cb section .rodata. from a3f941cc to a3f9840a section .data from a3f9840c to a3f98d17 section .u_boot_ from a3f98d18 to a3f991c7 section .bss from a3f991c8 to a3f9d70b Entry address set (pc): a3f80000 $a: a3f80000: ea000012 B 0xA3F80050 ; $a MON> g Hardware instruction breakpoint 0000000c: e59ff014 LDR pc,0x28 MON> --snap--

1 0

Re: [U-Boot-Users] CFI driver
by Sam Song 21 Oct '04

21 Oct '04

Wed, 20 Oct 2004 14:26:11 York Sun <yorksun(a)freescale.com> wrote: > Another issue is the CFI driver might not work for > all CFI compatible flash. For example, Micro > MT28F640J3. Micro uses status register instead > of DQ# polling. Somehow, we still need board > specific driver. Yeah. CFI driver still need to fix to support more cfi flash. In my experience, CFI driver support Intel FLASH better than AMD ones. I also use special flash driver for AMD flash on RPXlite_DW. I once tested it for Brad Kemp but no success. ===== Best regards, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 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] CFI driver
by Sam Song 21 Oct '04

21 Oct '04

Wed, 20 Oct 2004 14:26:11 York Sun <yorksun(a)freescale.com> wrote: > Another issue is the CFI driver might not work for > all CFI compatible flash. For example, Micro > MT28F640J3. Micro uses status register instead > of DQ# polling. Somehow, we still need board > specific driver. Yeah. CFI driver still need to fix to support more cfi flash. In my experience, CFI driver support Intel FLASH better than AMD ones. I also use special flash driver for AMD flash on RPXlite_DW. I once tested it for Brad Kemp but no success. ===== Best regards, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

1 0

[U-Boot-Users] CFI driver
by York Sun 20 Oct '04

20 Oct '04

I am debugging flash driver for MPC8555CDS board. The driver is drivers/cfi_flash.c. I have two boards. One is rev 1.0, with AM29LV641D. The other is rev 1.1, with AM29LV641M. The problem is polling DQ6 after programming. The current driver in U-boot 1.1.2 works well for AM29LV641M. As for AM29LV641D, the programming hangs after writing about 13KB. I track it down to "flash_is_busy()" function. When the problem occurs, the DQ6 keeps toggling. If I change the algorithm to polling DQ7, no problem occurs. Shawn has a similar problem http://lists.infradead.org/pipermail/linux-mtd/2004-March/009402.html. Maybe we should use DQ7 rather than DQ6. Another issue is the CFI driver might not work for all CFI compatible flash. For example, Micro MT28F640J3. Micro uses status register instead of DQ# polling. Somehow, we still need board specific driver. -- Best regards, York Sun, Ph.D Metrowerks Freescale Semiconductor Inc. Phone: (512) 996-5252 Email: yorksun(a)freescale.com This email, and any associated attachments have been classified as: [x] Freescale Semiconductor General Business [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary

2 4

RE: [U-Boot-Users] BDI2000 flashing problem
by VanBaren, Gerald (AGRE) 20 Oct '04

20 Oct '04

> -----Original Message----- > From: Santoso, Yusdi [mailto:Yusdi_Santoso@adaptec.com] > Sent: Tuesday, October 19, 2004 8:33 PM > To: VanBaren, Gerald (AGRE); u-boot-users(a)lists.sourceforge.net > Subject: RE: [U-Boot-Users] BDI2000 flashing problem > > Hi gvb, > > Thanks for the reply. What you said make sense but somehow I > managed to get it work after tinkering with the BDI config > file. I removed the "WORKSPACE" option in the [FLASH] section > and the "prog" command worked well albeit much slower. > Not sure why it is so...anybody can explain why? > > My RAM is working properly because I can read/write to the > address space perfectly, although I have not done a checker > pattern test. > > Thanks, > > > Yusdi The "workspace" command tells the BDI2000 to load a helper program into RAM. The BDI2000 can then load the to-be-programmed data into a RAM buffer (which is fast) and run the helper program to program the RAM buffer data into flash. This obviously is the faster method, but requires more things to be operational on the board and with the processor. Without the "workspace" command, the BDI2000 programs the data into flash directly which is considerably slower since bit-shifting the commands to do the write and poll for completion, etc. are much less efficient than the workspace method. This is slow but sure and only requires CPU and flash functionality to work. You apparently have a problem with the RAM set up in your config file or a hardware problem with your RAM (in that order of likelyhood). I forgot which processor you have, but most or all of the 8xx/8xxx processors have dual port RAM that you can also use for a workspace. Using this is much less complicated than getting SDRAM configured properly in the BDI2000 config file. Trivia: WD recommends (wisely!) that you do _not_ do the SDRAM initialization in the BDI2000 config file. The problem people have with initializing SDRAM in the config file is that they will do the bulk of their development with the BDI2000 attached and never realize their program's SDRAM initialization is stuffed... then at time (ship_date - 1), they unplug the BDI2000 and find their board is dead without a heart-lung machine and they are in a world of hurt. gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] RE: Another RTL8139 problem
by Santoso, Yusdi 20 Oct '04

20 Oct '04

Nevermind....fixed it myself... Apparently another one of those infamous PPC endianness problem. Just need to swap the MAC address read from EEPROM before storing it to MAC0 register. Thanks, Yusdi

1 0

[U-Boot-Users] Another RTL8139 problem
by Santoso, Yusdi 20 Oct '04

20 Oct '04

Hi all, I have a strange problem with RTL8139 driver on my dev board (hidden dragon-MPC 8241). Some of you might remember my question regarding setting _IO_BASE for the RTL8139. I have that one solved by setting it to (believe it or not) 0x00000000. Seems like the dev->iobase is set correctly to the device memory space without needing extra _IO_BASE. I verified this by doing memory dump with BDI2000 at the iobase address. To test my settings, I enabled the PING command. The network module was able to detect the presence of the link and to send packet out (I used ethereal on the other end to sniff the packets). My development machine also replied with the appropriate packet as reported by ethereal. Now the problem is that the RTL8139 did not recieve any packet (ChipCmd & RxEmptyBuf != 0) at any time. What could be the problem? Is anybody else using RTL8139 in u-boot? What is your experience? Thanks, Yusdi

1 0

AW: [U-Boot-Users] u-boot 1.1.1 and USB mass storage devices
by Martin Krause 20 Oct '04

20 Oct '04

Hi Shannon, Shannon Holland wrotes on Mittwoch, 20. Oktober 2004 00:25: > On Oct 19, 2004, at 2:38 PM, Wolfgang Denk wrote: > > > There are many, many USB devices out there which are out of spec, > > or where controller/firmware problems get fixed in the windows > > drivers provided by the vendor (either directly or through M$). > > Does anyone have recommendations as to devices that are known > to work? We had similar Problems on a Samsung S3C2400 CPU. The following Sticks are working with our board. - Transcend JetFlash TS32MJFLASH OT; Vendor=0ea0 ProdID=6803 Rev= 1.00 - Transcend JetFlash TS32MJF2B; Vendor=0ea0 ProdID=2168 Rev= 2.00 - Sharkoon 64 MB; Vendor=0d7d ProdID=110e Rev= 2.00 - USB007 BIU32MB; Vendor=0ea0 ProdID=6803 Rev= 1.00 - Sharkoon USB 2.0 FLEXI-DRIVE 64 MB; Vendor=0ea0 ProdID=2168 Rev= 2.00 - Belkin F5U026ea16MB; Vendor=0ea0 ProdID=6803 Rev= 1.00 - Yakumo Quicksave 2.0; Vendor=0ea0 ProdID=2168 Rev= 2.00 But be warned. Many USB-Stick manufacturers often change the internally used usb controller - without changing the name of the stick or even the order number. This happens two times for us. In both cases the new usb controller did not work, so we had to search for another usb stick. USB007 seems to provide some manufacturers of embedded devices with huge unit numbers. So this is perhaps a good address to start searching for sticks with a long availability. Regards, Martin

1 0

RE: [U-Boot-Users] BDI2000 flashing problem
by Santoso, Yusdi 20 Oct '04

20 Oct '04

Hi gvb, Thanks for the reply. What you said make sense but somehow I managed to get it work after tinkering with the BDI config file. I removed the "WORKSPACE" option in the [FLASH] section and the "prog" command worked well albeit much slower. Not sure why it is so...anybody can explain why? My RAM is working properly because I can read/write to the address space perfectly, although I have not done a checker pattern test. Thanks, Yusdi

1 0

[U-Boot-Users] U-Boot, hush and pipes
by Robin Gilks 20 Oct '04

20 Oct '04

Greetings I've been digging into the hush parser and finding, what appear to be, odd things. Obviously masses of the hush functionality has been removed using the __U_BOOT__ #define but some bits that are left seem to be not relevant to the bootloader environment. I'm particularly confused by the pipe operators '&' and '|' and how they are used in u-boot. Is this just a mistake? or am I (as usual) missing something... A quick pass with gcc -E -D__U_BOOT__ is most revealing :-)) -- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks(a)tait.co.nz New Zealand ======================================================================= This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. =======================================================================

1 0

[U-Boot-Users] Query: Flash remapping
by Charles J Gillan 19 Oct '04

19 Oct '04

Folks, While reading through the source code for the TQM860L board, I have found some comment cards (and related functional details) that are puzzling me. I can't find anything about this in the archive, so I am raising it here as a question. >From TQM860L.h: lines 323to 328 (u-boot-1.1.1 source) /* used to re-map FLASH both when starting from SRAM or FLASH: * restrict access enough to keep SRAM working (if any) * but not too much to meddle with FLASH accesses */ #define CFG_REMAP_OR_AM 0x80000000 /* OR addr mask */ #define CFG_PRELIM_OR_AM 0xE0000000 /* OR addr mask */ I can see the above hash-defines being used in file ./cpu/mpc8xx/cpu_init.c as follows (lines 176 to 178). /* now restrict to preliminary range */ memctl->memc_br0 = CFG_BR0_PRELIM; memctl->memc_or0 = CFG_OR0_PRELIM; where CFG_PRELIM_OR_AM is used in the definition of CFG_OR0_PRELIM, also in TQML860L.h (line 337). I read Table 15.4 of the Motorola MPC860 Family Users Manual which explains the format of the OR registers. If I understand it correctly, the definition of CFG_PRELIM_OR_AM limits the size of the Flash address range by masking out bits 0,1 and 2. Why are only three bits removed ? Also, what puzzles me is the comment: restrict access enough to keep SRAM working (if any) but not too much to meddle with FLASH accesses Why do we have to restrict access to keep SRAM working ? Any explanations would be appreciated. Thanks, Charles. Dr Charles J Gillan The Institute of Electronics, Communications and Information Technology (ECIT), Queen's University Belfast, Titanic Quarter Queens Road, Queens Island, Belfast, BT3 9DT Northern Ireland, UK Tel: +44 (0) 2890 971847

2 1

[U-Boot-Users] U-Boot not working on TQM860L
by Rami Segal 19 Oct '04

19 Oct '04

Hi, I'm am trying to bring up U-Boot on my TQM860L (8M flash), and have some difficulties. The instructions are simple and straight forward (I compile with the TQM860_config parameter). The burning of the u-boot.bin file is successful (address 0x40000000). However, when turning on the power, the system does not respond! The terminal is dead. I know that the system is functional, because other bootstrap programs, such as the TQC monitor, work fine. Are there any configurations that should be changed in the TQM860L.h configuration file? Any other ideas that might help? Thanks, Rami.

2 1

[U-Boot-Users] Re: U-Boot-Users -- confirmation of subscription -- request 357367
by Paul Wujek 19 Oct '04

19 Oct '04

> U-Boot-Users -- confirmation of subscription -- request 357367 > > We have received a request from 216.8.140.170 for subscription of your > email address, <pwujek(a)xp2telecom.com>, to the > u-boot-users(a)lists.sourceforge.net mailing list. To confirm the > request, please send a message to > u-boot-users-request(a)lists.sourceforge.net, and either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 357367 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to > u-boot-users-admin(a)lists.sourceforge.net. > > -- Paul Wujek, Director Network Software, Xp2 Telecom Inc.

1 0