August 2003 - U-Boot

[U-Boot-Users] error while compilation in u-boot-0.4.5
by Gupta, Kshitij 08 Aug '03

08 Aug '03

hi, we downloaded u-boot-0.4.5.tar.bz2 ftp://ftp.denx.de/pub/u-boot. When we try to compile this for our board (omap1510inn) it gives me error like this. The same error is reported even for smdk2410 also. ----------------------------------------------------------- make[1]: Entering directory `/home/a0875451/mwd/u-boot/release-1510/u-boot-0.4.5/tools' /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for dir in ; do make HOSTOS=linux HOSTARCH=i386 HOST_CFLAGS="-Wall -pedantic" HOST_LDFLAGS="" -C $dir || exit 1 ; done' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/a0875451/mwd/u-boot/release-1510/u-boot-0.4.5/tools' make: *** [subdirs] Error 1 ---------------------------------------------------------------------- regards -kshitij

1 0

[U-Boot-Users] Patch for MPC852T ( AdderII )
by Krishnaprasad, Raghunandan 08 Aug '03

08 Aug '03

Hello, I had submitted a pre - patch for AdderII. I have got the FEC up and running on the AdderII card. I am attaching the patch for the same. This is a complete patch that will apply on u-boot.0.4.0 Warm Regards, Raghu D K Raghunandan Force Computers Pvt Ltd. No: 60, Kormangala Ring road Bangalore - 560 071 Phone No: 91 + 80 + 535 6060 Ext: 324 e-mail: raghu.krishnaprasad(a)fci.com

1 0

[U-Boot-Users] Preparing a KEV7a400 patch
by Marc Singer 07 Aug '03

07 Aug '03

I've successfully ported u-boot to the Sharp KEV7A400 board. It can program flash, boot from the network, and it runs from flash. Before I submit a patch, I believe there are a couple of outstanding issues that you, Wolfgang, want resolved. 1) Dependency on Perl Are you OK with an initial patch that checks for the presence of a Perl interpreter? Since this is the only board using the mkocnfigx script, such a method will be backward compatible. I agree that a shell script of the Perl script must be written. 2) #undef arm It looks like the arm macro may be defined by the compiler. The GCC info pages suggest that this macro may be defined unless -ansi is passed to the compiler. There are a few of ways to resolve this problem. I could change the structure that is broken by the #define. I could leave the #undef intact. I could find a way to remove the #define by passing an switch to the compiler. My preference, of course, is to leave the #undef intact. 3) Trailing whitespace You found some lines in a previous patch to have trailing whitespace. What do you use to detect this?

2 6

[U-Boot-Users] 857T scc init
by Brian Rasmussen 07 Aug '03

07 Aug '03

Hi, I�m almost done porting U-boot to a custom HW platform but I have a problem getting the Ethernet port to work correctly. I�m using a 857T with a Realtek 8201BL transceiver. If I run U-boot and press a key so I get to the prompt and then type tftp I see the following behavior. 5 ARP requests are sent but no response is received and it times out and tries again. An ARP response is never received. If I stop U-boot with the BDM and changes RINV in GSMR_L and start again I receive an ARP request and tftp gets called but the transfer stops. To get the tftp transfer to continue I need to change RINV back to normal and run again. The tftp transfer then completes. I can now issue a tftp transfer over and over without making any changes through the BDM. Even the ARP request works every time. This behavior is consistent every time I reboot the system. The only modifications made to the code are the pin-configurations. Has anybody seen this behavior before or have any ideas. Thanks, Brian Rasmussen

1 0

[U-Boot-Users] 857T scc init
by Brian Rasmussen 07 Aug '03

07 Aug '03

Hi, I�m almost done porting U-boot to a custom HW platform but I have a problem getting the Ethernet port to work correctly. I�m using a 857T with a Realtek 8201BL transceiver. If I run U-boot and press a key so I get to the prompt and then type tftp I see the following behavior. 5 ARP requests are sent but no response is received and it times out and tries again. An ARP response is never received. If I stop U-boot with the BDM and changes RINV in GSMR_L and start again I receive an ARP request and tftp gets called but the transfer stops. To get the tftp transfer to continue I need to change RINV back to normal and run again. The tftp transfer then completes. I can now issue a tftp transfer over and over without making any changes through the BDM. Even the ARP request works every time. This behavior is consistent every time I reboot the system. The only modifications made to the code are the pin-configurations. Has anybody seen this behavior before or have any ideas. Thanks, Brian Rasmussen

1 0

RE: [U-Boot-Users] Using the abatron to debug an image in flash
by Mark Doherty 07 Aug '03

07 Aug '03

Dear Wolfgang, > Accessing normal static variables should be no problem. It's just > initialized data pointers which need manual relocation. I try to > avoid this data type whenever possible, or we need to relocate it. If > you find unrelocated initialized pointers please let me know. > > But accessing the variables itself should work just fine - if they > are pointers, they will just contain unrelocated addresses. > I have loaded the symbol file as mentioned previously, however to my unexperienced eye it appears that some of the symbols for the static variables have not been loaded where I would have expected ... $ ppc-linux-gdb GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux". (gdb) bdi 0xff000100 in ?? () (gdb) ram add symbol table from file "u-boot" at .text_addr = 0x7fc0000 (gdb) info address rtx Symbol "rtx" is static storage at address 0xff0312d8. (gdb) In the unlikely case you are not aware rtx is defined in cpu/mpc8260/ether_fcc.c as ... <snip> /* * FCC Ethernet Tx and Rx buffer descriptors. * Provide for Double Buffering * Note: PKTBUFSRX is defined in net.h */ typedef volatile struct rtxbd { cbd_t rxbd[PKTBUFSRX]; cbd_t txbd[TX_BUF_CNT]; } RTXBD; /* Good news: the FCC supports external BDs! */ #ifdef __GNUC__ static RTXBD rtx __attribute__ ((aligned(8))); #else #error "rtx must be 64-bit aligned" #endif <snip> Is this what you would normally expect? When I scan the assembler the code uses the correct address, it appears that the gdb however is a bit lost. Best wishes, Mark.

2 1

[U-Boot-Users] Announcement of new DENX U-Boot and Linux Guide
by Detlev Zundel 07 Aug '03

07 Aug '03

Hi, as the URL has leaked onto this list by now anyway, I am somewhat late to officially announce the all-new, ultra-shiny and wonderfully interactive "DENX U-Boot and Linux Guide"[1] (DULG for short). The DULG is the successor of the DPLG previously available in different formats and specialized for different boards from the DENX website[2]. The new DULG in contrast is a Wiki collaboration area (TWiki to be precise) allowing direct editing of its contents. If you never heard of "Wikis" before, [3] should be a good starting point for finding out. In addition to the advantages inherent in a Wiki based site, the DULG web is designed to provide board-specific documentation through the ease of a webform for choosing the target board[4]. Right now there are only two boards to choose from, _but_ one is PowerPC based (TQM8xxL), while the other is MIPS based (INCA-IP). The ELDK[5] sections will of course show the correct information for the selected platform... Disclaimer: If things don't work as you expect them to, remember that this baby is _very_ young, but don't hesitate to ask. There's even a place in the Wiki itself for discussing it[6]. Ok, now its official, so all thats left for me to say is: Browse, enjoy and last but not least _improve_ it by contributing! Cheers Detlev PS: Before making major changes, it is a good idea to get familiar with the peculiarities of the DULG web explained in links from the main web[1]. [1] http://www.denx.de/twiki/bin/view/DULG [2] http://www.denx.de/ [3] http://www.denx.de/twiki/bin/view/TWiki/TWikiSite [4] http://www.denx.de/twiki/bin/view/DULG/BoardSelect [5] http://www.denx.de/twiki/bin/view/DULG/ELDK [6] http://www.denx.de/twiki/bin/view/DULG/DULGFaq -- 14474011154664524427946373126085988481573677491474835889066354349131199152128 If you know why this number is perfect - you're probably a mathematician...

1 0

RE: [U-Boot-Users] Using the abatron to debug an image in flash
by Mark Doherty 07 Aug '03

07 Aug '03

Hello Detlev, Wolfgang, Thanks for your replies, you are completely correct, I should have realised! I had some problems compiling with -O0, however building with -O1 was just as good. Now I have another problem, one which I hope you may have come across before, my debugger is failing to keep track of the updated addresses of static variables after relocation, which makes displaying variables kinda hard :) Any ideas? Mark.

3 2

[U-Boot-Users] Re: Are there any users of tools/gdb/astest.c?
by Murray Jensen 07 Aug '03

07 Aug '03

On 05 Aug 2003 18:33:54 +0200, Detlev Zundel <dzu(a)denx.de> writes: >If anyone wants to keep the file then please speak up, otherwise I'd >like to ask Wolfgang to remove it so there is one less obstacle for >new users of U-Boot. I was responsible for the gdb directory being there - long time ago early in the ppcboot days - when the board I was using had no ethernet and no flash (really!). I would burn ppcboot into an EPROM, then use gdb to download a linux kernel over the serial line and debug it the same way if it crashed (with kgdb). Wasn't too bad at 230400 baud. But I stopped using these tools many years ago. astest was just a little hack that printed some info I needed - it could definitely go. In fact, the whole gdb directory could probably go, although I suppose it might be useful to someone/somewhere/sometime. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

3 3

[U-Boot-Users] Using the abatron to debug an image in flash
by Mark Doherty 07 Aug '03

07 Aug '03

Hi, Apologies for asking what I suspect is a very simple problem, I am attempting to debug u-boot after relocation and have followed the simple instructions previously posted on this mailing-list, however I am having difficulty in getting the abatron to do as it is told! First up is the target section of the bdi2000 config file : [TARGET] CPUTYPE 8260 BDIMODE AGENT STARTUP RESET JTAGCLOCK 0 BOOTADDR 0x00000100 ;WORKSPACE 0x00000000 BREAKMODE HARD STEPMODE HWBP ;VECTOR CATCH ;DCACHE NOFLUSH ;MMU XLAT 0xC0000000 ;PTBASE 0x000000F0 I'd like to be able to step through the eth_init routine and I am invoking it through a tftpboot command on the console. A trace from gdb illustrates my problem, (note that I have some shortcuts programmed into my .gdbinit routine to set the $pc and to load the symbol file). When the program has loaded into RAM I stop the debugger (hence the SIGSTOP) to insert my breakpoint, for some reason I have problems if I attempt to insert the breakpoint before the code is in RAM (?). $ ppc-linux-gdb GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux". (gdb) bdi 0x00000100 in ?? () (gdb) resethi (gdb) ram add symbol table from file "u-boot" at .text_addr = 0x7fc0000 (gdb) c Continuing. Program received signal SIGSTOP, Stopped (signal). 0x07fdbb18 in serial_getc () at serial_scc.c:242 242 while (rbdf->cbd_sc & BD_SC_EMPTY) (gdb) b eth_init Breakpoint 1 at 0x7fdc278: file ether_fcc.c, line 201. (gdb) c Continuing. Breakpoint 1, eth_init (bis=0x7fa0220) at ether_fcc.c:201 201 volatile cpm8260_t *cp = &(immr->im_cpm); (gdb) step 227 rxIdx = 0; (gdb) step 198 { (gdb) step 212 immr->im_cpmux.cmx_uar = 0; (gdb) step 228 txIdx = 0; (gdb) step 212 immr->im_cpmux.cmx_uar = 0; (gdb) step 221 immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | FCC_PSMR_ENCRC; (gdb) step 213 immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & ~CFG_CMXFCR_MASK) | (gdb) step 221 immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | FCC_PSMR_ENCRC; (gdb) step 227 rxIdx = 0; (gdb) step 201 volatile cpm8260_t *cp = &(immr->im_cpm); (gdb) step 213 immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & ~CFG_CMXFCR_MASK) | (gdb) step 228 txIdx = 0; (gdb) step 213 immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & ~CFG_CMXFCR_MASK) | (gdb) As you can see the code appears to jump around aimlessly, though the program still appears to run ok. Just to finish off I am able to configure the ram such that I can debug the application in ram up to the point where relocation occurs so I am fairly confident in my SDRAM setup. Any thoughts or comments welcome, thanks Mark.

3 2