July 2006 - U-Boot

Re: [U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module
by Joao, Nuno (ext) 06 Jul '06

06 Jul '06

> It seems > that a prolonged sequence of accesses is required to cause the problem. Heating problem? It can cause strange problems. > The following is the DRAM initialization data from Uboot: > > DRAM: Initializing > DDR: number of banks = 2 > DDR: DDR I bank density = 0x20000000 > Number of Row Address Bits - 13 > Number of Col Address Bits - 11 > > DDR: cs0_bnds = 0x0000001f > DDR: cs0_config = 0x80000103 > (...) > DDR: err_sbe = 0x00ff0000 > DDR: sdram_cfg_2 = 0x00000000 The configuration of the DDR is rather complex, specially the timming parameters and, of course, it depends a bit on the DDR in question. This is usually done by the hardware team, they have to give the parameters. Where I work I have a hardware collegue specialized in this kind of configuration and it took him some time to fully analyse and optimize this parameters for a MPC8541E based custom board. Best Regards

2 1

Re: [U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module
by Joao, Nuno (ext) 06 Jul '06

06 Jul '06

> ... > > Are you missing "sync" instructions in your UART handling? Sounds > like > > the UART register operations are not being forced to run by the > > processor... when you hit the LED register, you are forcing the > >instructions to run as a side effect and all becomes well. > > The UART code that I am using is plain vanilla U-boot 1.1.4, > drivers/ns16550.c. I dropped an asm("sync;isync;msync") in > front of the > loop which polls the LSR and the behavior didn't change. I dropped an > asm("sync;isync;msync") inside the loop which polls the LSR and the > behavior didn't change. I just want to mention that those instructions will only "sync" from the processor core's point of view. However, PQIII has this coeherency module between the processor core and the rest of the system, which adds another level of "asynchronism". For a "real sync" in this chip, specially when there are dependencies between different subsystems, you need to do a read after a write; that will force the processor to really sync with the device and it is the only way for you to make sure that a value has been written to the sub-system. Best Regards

1 0

[U-Boot-Users] slow boot
by Takács Áron 06 Jul '06

06 Jul '06

Hi, I am using a PXA270-based board with u-boot-1.1.2. I wonder if I could make the bootup process faster. I have measured the following times (with a stopper watch ...): -Time to the first output on the serial console (baudrate: 115200): ~3 sec -Time to "Hit any key to stop autoboot (boot delay: 1s): ~5 sec -Time to "Starting kernel...": ~8.7sec So I have delays after the messages: "Err: serial" and "Entry Point: a0008000". I have set "verify=no" in the environment. Any ideas how to make the boot faster? Thank you for your help! Áron Takács

3 2

[U-Boot-Users] MAC address setting
by Jevgeni Zolotarjov 06 Jul '06

06 Jul '06

Hi all! I have custom designed ARM board, based on AT91RM9200EK reference design. Hardware works fine. And I have following problem: When U-boot loads Kernel image from tftp, everything fine. When U-Boot starts kernel from flash, then Linux cannot communicate to ethernet device. I understand, that this is because MAC address was not set by U-Boot. But I could not find a command to initialise Ethernet. Please advice, how to act. Best regards, Jevgeni

6 8

[U-Boot-Users] STE100p PHY
by Madhu Saravana Sibi Govindan 06 Jul '06

06 Jul '06

Hello all, Has anyone used the STE100p (ST Microelectronics part) PHY device on any board? I have a custom board based on 440GP and STE100p. I'm currently at the U-boot prompt and have configured all the required environmental variables. However, I'm not able to ping external hosts from the board. I see these messages: sending ARP for c0a80101 ARP broadcast 1 ARP broadcast 2 ping failed; host 192.168.1.1 is not alive I'm not sure what is happening wrong. I'm trying to use the MII PHY mode for the 440GP's EMAC-ZMII bridge. I also tried installing ethereal on the host machine, but it does not receive any ARP packets from the board. I'm not able to ping the board from the host too. I suspect that the PHY device has not been initialized properly. Also, I'm using the ebony board'd code as a base for this custom board (with whatever modifications I could think of). When I type "mii info" at u-boot prompt, I see these messages: PHY 0x00: OUI = 0x70100, Model = 0x01, Rev = 0x01, 100baseT, FDX Error reading info from the PHY (repeated lot of times) PHY 0x1F: OUI = 0x70100, Model = 0x01, Rev = 0x01, 100baseT, FDX Also, how does CONFIG_PHY_ADDR work? Is it determined by the jumpers on the board? I'd appreciate it if someone gives some pointers to proceed with the debugging. Thanks a ton, G.Sibi

1 0

Re: [U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module
by Scott Coulter 05 Jul '06

05 Jul '06

Hi Jerry, > OK, what is the system trying to send out the UART when the hang occurs? > Since you only send characters out the UART "when the test is done" > either the test has been successfully completed or it is sending a > failure message. The two cases would cause different guesses. I suspect that the "hang" is caused by a completion message since I can also make the processor "hang" by only reading large chunks of memory in a loop. > Are you missing "sync" instructions in your UART handling? Sounds like > the UART register operations are not being forced to run by the > processor... when you hit the LED register, you are forcing the >instructions to run as a side effect and all becomes well. The UART code that I am using is plain vanilla U-boot 1.1.4, drivers/ns16550.c. I dropped an asm("sync;isync;msync") in front of the loop which polls the LSR and the behavior didn't change. I dropped an asm("sync;isync;msync") inside the loop which polls the LSR and the behavior didn't change. Scott ___________________________________________________________________ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coulter(a)cyclone.com U.S.A. Web: http://www.cyclone.com ___________________________________________________________________ -----Original Message----- From: u-boot-users-bounces(a)lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Jerry Van Baren Sent: Wednesday, July 05, 2006 12:39 PM To: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module Scott Coulter wrote: > Hi everyone, > > I have a custom MPC8540-based board running U-boot 1.1.4. The processor > core runs at 833MHz and the memory is DDR 333MHz with ECC. With a > single banked SoDIMM memory module, 256 or 512Mbyte, the board can run a > memory test and boot/run linux 2.6.15. With a multiple banked (2) > 1Gbyte memory module, the board can boot/run linux 2.6.15, but, the > memory test hangs in the vicinity of the bank (512Mbyte) boundary. The > uboot fill command also hangs. We can also generate a hang condition by > doing a sequence of reads of a memory range that crosses the bank > boundary. Individual peeks and pokes of memory work fine. It seems > that a prolonged sequence of accesses is required to cause the problem. > > If I run 'mtest 1fff0000 20010000' (over the 512MB boundary on a 1GB > module), the test hangs in seconds. > > If I use a 512MB SoDIMM module which use two Chip Selects (2 banks). I > can run 'mtest fff0000 10010000' from U-boot for hours without a > problem. > > Investigation with a JTAG emulator shows that the processor is not hung, > but rather the code is stuck in a loop trying to output characters to > the serial port (polling the LSR in the DUART for the transmitter to be > empty). According to the JTAG emulator, the data being read in the loop > during the "hang" condition was 0. However, if I read the register > manually using the emulator, the value returned is 0x60 which should > have caused the loop to exit and the character to be written. OK, what is the system trying to send out the UART when the hang occurs? Since you only send characters out the UART "when the test is done" either the test has been successfully completed or it is sending a failure message. The two cases would cause different guesses. > On the board, we have an LED register connected to the local bus. If I > write to the LEDs prior to the DUART LSR polling loop the memory test > runs fine. What effect should the local bus access have on the DUART > polling loop? According to the code and the emulator, the DUART > registers do not show up in the data cache. Are you missing "sync" instructions in your UART handling? Sounds like the UART register operations are not being forced to run by the processor... when you hit the LED register, you are forcing the instructions to run as a side effect and all becomes well. [snip] > Thanks in advance, > Scott You are welcome in advance, ;-) gvb Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] 440GP and the MII mode
by Madhu Saravana Sibi Govindan 05 Jul '06

05 Jul '06

Hello all, I understand that the ebony board is set to RMII mode (for the ethernet PHY device) and U-boot also configures the ZMII0_FER to the RMII mode. I have a custom 440-GP based board, which should operate in the MII mode. Is it enough if I configure the ZMII0_FER register to the MII mode (in the file: cpu/ppc4xx/4xx_enet.c)? Are there other places in the U-boot code that might need change? I'm currently reading through the source code to figure this out, but I wanted to get a heads-up from others. Thanks, G.Sibi

1 0

[U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module
by Scott Coulter 05 Jul '06

05 Jul '06

Hi everyone, I have a custom MPC8540-based board running U-boot 1.1.4. The processor core runs at 833MHz and the memory is DDR 333MHz with ECC. With a single banked SoDIMM memory module, 256 or 512Mbyte, the board can run a memory test and boot/run linux 2.6.15. With a multiple banked (2) 1Gbyte memory module, the board can boot/run linux 2.6.15, but, the memory test hangs in the vicinity of the bank (512Mbyte) boundary. The uboot fill command also hangs. We can also generate a hang condition by doing a sequence of reads of a memory range that crosses the bank boundary. Individual peeks and pokes of memory work fine. It seems that a prolonged sequence of accesses is required to cause the problem. If I run 'mtest 1fff0000 20010000' (over the 512MB boundary on a 1GB module), the test hangs in seconds. If I use a 512MB SoDIMM module which use two Chip Selects (2 banks). I can run 'mtest fff0000 10010000' from U-boot for hours without a problem. Investigation with a JTAG emulator shows that the processor is not hung, but rather the code is stuck in a loop trying to output characters to the serial port (polling the LSR in the DUART for the transmitter to be empty). According to the JTAG emulator, the data being read in the loop during the "hang" condition was 0. However, if I read the register manually using the emulator, the value returned is 0x60 which should have caused the loop to exit and the character to be written. On the board, we have an LED register connected to the local bus. If I write to the LEDs prior to the DUART LSR polling loop the memory test runs fine. What effect should the local bus access have on the DUART polling loop? According to the code and the emulator, the DUART registers do not show up in the data cache. Since we are testing over a nearly 1Gbyte memory range (the exception table and the u-boot area are excluded), and the code only writes to the serial port before and after the memory fill operation and then before and after the read/verify operation, I cannot see that the led register write is having any significant impact on the DRAM access timing. The following is the DRAM initialization data from Uboot: DRAM: Initializing DDR: number of banks = 2 DDR: DDR I bank density = 0x20000000 Number of Row Address Bits - 13 Number of Col Address Bits - 11 DDR: cs0_bnds = 0x0000001f DDR: cs0_config = 0x80000103 DDR: cs1_bnds = 0x0020003f DDR: cs1_config = 0x80000103 DDR: caslat SPD bit is 3 DDR: tCKmin = 6000 ps DDR: Module max data rate = 333 Mhz DDR: effective data rate is 333 MHz DDR: caslat SPD bit is 3, controller field is 0x4 DDR: ext_refrec = 0x00000000 DDR: timing_cfg_1 = 0x37344321 DDR: timing_cfg_2 = 0x00000c00 DDR: sdram_mode = 0x00000062 DDR: sdram_mode_2 = 0x00000000 DDR: sdram_interval = 0x05130100 DDR: err_disable = 0x0000000d DDR: err_sbe = 0x00ff0000 DDR: sdram_cfg_2 = 0x00000000 ECC enabled DDR: sdram_cfg = 0xe2008000 Setup for 256MB pagesize Setup TLB index #8 for address 0x00000000 DDR: MAS0=0x10080000 DDR: MAS1=0xc0000900 DDR: MAS2=0x00000000 DDR: MAS3=0x00000015 Setup TLB index #9 for address 0x10000000 DDR: MAS0=0x10090000 DDR: MAS1=0xc0000900 DDR: MAS2=0x10000000 DDR: MAS3=0x10000015 Setup TLB index #10 for address 0x20000000 DDR: MAS0=0x100a0000 DDR: MAS1=0xc0000900 DDR: MAS2=0x20000000 DDR: MAS3=0x20000015 Setup TLB index #11 for address 0x30000000 DDR: MAS0=0x100b0000 DDR: MAS1=0xc0000900 DDR: MAS2=0x30000000 DDR: MAS3=0x30000015 DDR: LAWBAR1=0x00000000 DDR: LARAR1=0x80f0001d DMA DDR: err_disable = 0x0000000d DMA DDR: err_disable = 0x00000000 DDR: 1024 MB This is the uboot serial routine with the led writes: void NS16550_putc (NS16550_t com_port, char c) { /* snc - debug */ volatile unsigned char *led = (volatile unsigned char *)0xffb00000; *led = 0xa; while ((com_port->lsr & LSR_THRE) == 0); com_port->thr = c; } I am pretty sure that the memory design is OK since even with a 2 bank, 1GB memory module will, the board will boot and run linux, mount its root filesystem over NFS, be able to mount an NFS partition containing the linux 2.6.15 kernel source, and be able to repeatedly compile the kernel over NFS overnight. Anyone have any thoughts? Thanks in advance, Scott ___________________________________________________________________ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coulter(a)cyclone.com U.S.A. Web: http://www.cyclone.com ___________________________________________________________________

2 1

[U-Boot-Users] Wrong map addresses
by Mitsy Tsuchiya 05 Jul '06

05 Jul '06

I'm trying to port u-boot to run on a custom board. The CPU is AMD au1550. I'm a newbie on this and I'd like to get some help. When I look at the map file after compilation, I noticed the addresses has extra 0's in front of it. I haven't been able to successfully run the u-boot and believe this is one of the problems. Where do I specify the size so that the start address will be 0xbfc0 0000 and not 0x0000 0000 bfc0 0000? Memory Configuration Name Origin Length Attributes *default* 0x0000000000000000 0xffffffffffffffff Linker script and memory map 0x0000000000000000 . = 0x0 0x0000000000000000 . = ALIGN (0x4) .text 0x00000000bfc00000 0x1b210 *(.text) .text 0x00000000bfc00000 0x550 cpu/mips/start.o 0x00000000bfc00488 relocate_code 0x00000000bfc00000 _start Thanks in advance!

3 2

[U-Boot-Users] Error message from gdb during hook_stop
by mitsy 05 Jul '06

05 Jul '06

I'm trying to debug U-boot using gdb via BDI2000. However, I get the following error when I connect to the target machine. I can't figure out what I'm missing here. Could anyone give me some suggestions on what I'm not doing right? Thank you, Mitsy $ mipsel-gdb u-boot GNU gdb 6.2.1 Copyright 2004 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=i686-pc-linux-gnu --target=mipsel-linux"... gdb> target remote bdi2000:2001 Error while running hook_stop: Invalid type combination in ordering comparison. _start () at ~/u-boot/cpu/mips/start.S:43 43 RVECENT(reset,0) /* U-boot entry point */ gdb>

1 0