August 2003 - U-Boot

Re: [U-Boot-Users] hang up after start_here
by S. Hebbar 18 Aug '03

18 Aug '03

Hello, I am having the exact same problem. It doesn't return to start_here label after executing RFI instruction. (linux-2.4.20) linux-2.4.20/arch/ppc/kernel/start.S ==> turn_on_mmu: mfmsr r0 ori r0,r0,MSR_DR|MSR_IR mtspr SRR1,r0 lis r0,start_here@h ori r0,r0,start_here@l mtspr SRR0,r0 SYNC RFI /* enables MMU */ I have 128Meg or SDRAM on a MPC8260 board. The initialization sequence in U-BOOT is as follows. void initdram() { #define CFG_SDRAM_BASE 0x0 #define CFG_IMMR 0x60000000 int i; int size; int cpu_type=0; volatile immap_t *immap = (immap_t *)CFG_IMMR; volatile memctl8260_t *memctl = &immap->im_memctl; volatile uchar c = 0; volatile uchar *ramaddr = (uchar *)(CFG_SDRAM_BASE) + 0x110; /* Set OR1 and OR2 values */ memctl->memc_or1 = 0xf8002940; memctl->memc_br1 = 0x00000041; /* * Quote from 8260 UM (10.4.2 SDRAM Power-On Initialization, 10-35): * * "At system reset, initialization software must set up the * programmable parameters in the memory controller banks registers * (ORx, BRx, P/LSDMR). After all memory parameters are configured, * system software should execute the following initialization sequence * for each SDRAM device. * * 1. Issue a PRECHARGE-ALL-BANKS command * 2. Issue eight CBR REFRESH commands * 3. Issue a MODE-SET command to initialize the mode register * * The initial commands are executed by setting P/LSDMR[OP] and * accessing the SDRAM with a single-byte transaction." * * The appropriate BRx/ORx registers have already been set when we * get here. The SDRAM can be accessed at the address CFG_SDRAM_BASE. */ memctl->memc_psrt = psrt; memctl->memc_mptpr = mptpr;; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_PREA; *ramaddr = c; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_CBRR; for (i = 0; i < 8; i++) *ramaddr = c; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_MRW; *ramaddr = c; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_NORM | PSDMR_RFEN; *ramaddr = c; I have turned off Data cache in U-BOOT. If I enabel D-CACHE, the code hangs in U-BOOT itself. Any help is very much appreciated. Regards, Hebbar. \ <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3(a)se.wavetek.com> you wrote: > > I've debugged and found that the board hangs in start_here function and > doesn't reach the early_init function. > > Because the problem appears on only one of my boards out of 16, I suspect > a hardware problem, and because it occurs just after mmu initialisation > and caches enabling, I suspect more especially sdram accesses. > > I want to know if anybody has encountered a similar problem and if the > diagnostic was the same. This is a standard problem, which can show up in many forms. My bet is that your SDRAM initialization sequence is incomplete / broken. Remember that it is NOT sufficient to set up the mmeory controller, you must also intialize the SDRAM chips themself. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de "What is wanted is not the will to believe, but the will to find out, which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_, 1928 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

1 0

RE: [U-Boot-Users] what is wrong when calloc return bogus?
by Woodruff, Richard 18 Aug '03

18 Aug '03

The heap area is not being setup properly. It appears that all of the ARM boards cpu.c and start.S were from the same root. In cpu.c _armboot_real_end is set up such that the malloc init in lib_arm/board.c's should work... It appears that the pxa's start.S diverged from the way the other ARMs did the relocation and ended up breaking this aspect of the init. So, the PXA and could change to be like the other ARM boards or ... I recall that part of a patch to board.c someone posted should result in this working for PXA. Having malloc work is important beyond getting the device_init structure up and running. Either should fairly straight forward to do. Regards, Richard W. > -----Original Message----- > From: Holger Schurig [mailto:h.schurig@mn-logistik.de] > Sent: Friday, August 15, 2003 11:39 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] what is wrong when calloc return bogus? > > > I recently updated from u-boot 0.3.2 to CVS (0.4.5). Now blob > stopped working. > I tracked this down from device_init() to ListCreate() or NewHandle(). > > My debug output is: > > U-Boot 0.4.5 (Aug 15 2003 - 18:26:38) > > U-Boot code: A3000000 -> A300D4E0 BSS: -> A3024000 > DRAM Configuration: > Bank #0: a0000000 128 MB > Flash: 32 MB > 1 > 2 > 4 > 6 > 7 > 9 > 10 > d1 > d3 > l1 > n1 > n2 memPtr=0badc0e8 > n3 hanPtr=0badc108 > n4 > l2 > l3 0badc108 > > list_t ListCreate (int elementSize) > { > list_t list; > printf("l1\n"); > list = (list_t) (NewHandle (sizeof (ListStruct))); > /* create empty > list */ > printf("l2\n"); > if (list) { > printf("l3 %08x\n", list); > (*list)->signature = LIST_SIGNATURE; > (*list)->numItems = 0; > (*list)->listSize = 0; > (*list)->itemSize = elementSize; > (*list)->percentIncrease = > kDefaultAllocationPercentIncrease; > (*list)->minNumItemsIncrease = > kDefaultAllocationminNumItemsIncrease; > } > printf("l4\n"); > > return list; > } > > > Target is an Intel PXA255 > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites > including Data Reports, E-commerce, Portals, and Forums are > available now. Download today and enter to win an XBOX or > Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet _072303_01/01 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

4 3

[U-Boot-Users] [PATCH] get rid of bi_env
by Holger Schurig 18 Aug '03

18 Aug '03

The attached patch removes bi_env, bi_env_data and bi_env_crc. According to "grep -r" were nowhere used.

1 0

[U-Boot-Users] hang up after start_here
by Laurent Mohin 18 Aug '03

18 Aug '03

Hello all, I'm designing a custom board build around a 405GPr processor. I'm in my third prototype phase, and I've problem with one board which hang during Linux booting. I've debugged and found that the board hangs in start_here function and doesn't reach the early_init function. Because the problem appears on only one of my boards out of 16, I suspect a hardware problem, and because it occurs just after mmu initialisation and caches enabling, I suspect more especially sdram accesses. I want to know if anybody has encountered a similar problem and if the diagnostic was the same. Kernel version is 2.4.18 from Montavista. Thanks for help, Laurent

2 1

RE: [U-Boot-Users] what is wrong when calloc return bogus?
by Woodruff, Richard 15 Aug '03

15 Aug '03

This has come up a couple times recently. I'll agree that from a consistency standpoint it would be nice if this were same for all architectures, and it will probably end up this way, but is it really "broken", what is not currently functioning, other than a proper mapping from the documentation to reality. Regards, Richard W. > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > Sent: Friday, August 15, 2003 2:51 PM > To: Woodruff, Richard > Cc: 'Holger Schurig'; u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] what is wrong when calloc return bogus? > > > In message >> If the PXA is broken, then it should be fixed, but NOT by > making it like the other ARM boards which are (IMHO) > broken by design. [It's just that we didn't have enough free > resources (or volunteers???) to fix the ARM memory layout.] > > ARM still suffers from the many things ARMBoot did differently. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: > wd(a)denx.de "In Christianity neither morality nor religion > come into contact with > reality at any point." - Friedrich Nietzsche >

2 1

[U-Boot-Users] Patches
by Jonas Larsson 15 Aug '03

15 Aug '03

I have a question regarding submitting patches. Should I send them to the mailing list or to the patch tracking system at sourceforge? I've submitted a patch to sourcforge already. The patch adds support for an environment variable 'arch' which is passed as the ARM machine number to the kernel if set. The u-boot behaviour is unchanged if 'arch' is not defined. / Jonas

3 6

[U-Boot-Users] u-boot's own boot process
by Seb James 15 Aug '03

15 Aug '03

Hi, I've got some hardware which has a problem somewhere. It's a board with a tqm823l on it and the tqm should happily boot u-boot. The module plugged into another board works fine, but in our new hardware the code hangs. I've checked out u-boot from cvs today, making it 0.4.5, and I applied a tqm8xx specific patch to boards/tqm8xx/flash.c which Wolfgang Denk posted in reply to a message a couple of days ago. I enabled debugging in config.mk and recompiled with no problems. Running the code (using gdb through an Abatron BDI2000): The problem occurs at program re-location. I set a breakpoint in cpu/mpc8xx/start.S thus: (gdb) break start.S:575 Breakpoint 2 at 0x4000231c: file /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S, line 575. (gdb) c Continuing. Breakpoint 2, relocate_code () at /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S:575 575 addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET (gdb) s 576 mtlr r0 (gdb) s 577 blr (gdb) s Program received signal SIGSTOP, Stopped (signal). 0x3ffffffc in ?? () (gdb) And you can see where the trouble occurs (console output given below). It's just at the point in start.S where u-boot is relocated from flash to RAM (correct me if that's wrong). Where's the code going from and to? In start.S I read that the code starts executing from flash, with the program counter starting at 0x100. What is boardinit? From start.S: "board_init lies at a quite high address and when the cpu has jumped there, everything is ok." Anyone have any ideas as to what might be wrong in the hardware to cause this behaviour? regards, Seb James Here's the output at the terminal: U-Boot 0.4.5 (Aug 15 2003 - 13:18:07) CPU: PPC823EZTnnB2 at 50 MHz: 16 kB I-Cache 8 kB D-Cache Board: ### No HW ID - assuming TQM8xxL DRAM: 16 MB Top of RAM usable for U-Boot at: 01000000 Reserving 204k for U-Boot at: 00fcc000 Reserving 128k for malloc() at: 00fac000 Reserving 60 Bytes for Board Info at: 00fabfc4 Reserving 52 Bytes for Global Data at: 00fabf90 Stack Pointer at: 00fabf78 New Stack Pointer is: 00fabf78 N?wr?ni?gi? A? " ?-&o?t*a?:.%?82x?F?A?H? ?e?h?d?r?i?a?d? ?#?G?t?f?a?h?b?n? ? ?i?e?@?0?%?8? #? e? (Then some more garbage is output until things stop).

1 2

RE: [U-Boot-Users] Start up problem with PPCboot 1.2.0
by Matias Sundman (TB/EAB) 15 Aug '03

15 Aug '03

Hi again, I solved the problem by flashing the two other boards with PPCboot 1.1.6 , now everything works fine. After 1.1.6 I will go for the u-boot distribution. Thanks // Matias ------------------------------------------------------- -----Original Message----- From: Matias Sundman (TB/EAB) Sent: den 14 augusti 2003 13:58 To: u-boot-users Cc: 'matias.sundman(a)sundmangroup.com' Subject: [U-Boot-Users] Start up problem with PPCboot 1.2.0 Comrades, I have three BMW (WhiteKnight) boards from Broadcom. In one of them PPCboot 1.1.6 is used and everything works fine, but on one of the others I have PPCboot 1.2.0 and I never get passed the , IP-Config: Incomplete network configuration information.... I thought the bootargs parameter should supply the Linux kernel with it's parameters, bootargs=root=/dev/nfs rw nfsroot=130.100.50.56:/tftpboot/130.100.50.55 ip=130.1 00.50.55:130.100.50.56::255.255.255.0:::off It seems to work on the 1.1.6 version though, can someone advice me what to try next? Below you can see the start-up attempt and all the environment variables used/set. Regards // Matias ---------------------------------------------------------------------------------- PPCBoot 1.2.0 (Feb 5 2003 - 17:02:59) CPU: MPC8245 Revision 16.20 at 198 MHz: 16 kB I-Cache 16 kB D-Cache Board: BMW MPC8245/KAHLUA2 - CHRP (MAP B) Built: Feb 27 2003 at 14:29:08 Local Bus at 100 MHz DRAM: 64 MB FLASH: 1 MB DiskOnChip(TM): 32MB found at address 0xff000000 In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 Broadcom BCM5703 1000Base-T: bus 0, device 13, function 0: MBAR=0x80100000 BCM570x PCI Memory base address @0x80100000 eth0: Broadcom BCM5703 1000Base-T @0x80100000,node addr 0010188201a1 eth0: BCM5700 with Broadcom BCM5703 Integrated Copper transceiver found eth0: 32-bit PCI 33MHz, MTU: 1500,Rx Checksum ON ARP broadcast 1 eth0:Broadcom BCM5703 1000Base-T: 10 Mbps half duplex link up, flow control OFF TFTP from server 130.100.50.56; our IP address is 130.100.50.55 Filename 'pSystem'. Load address: 0x400000 Loading: ################################################################# ################################################## done Bytes transferred = 584472 (8eb18 hex) eth0:Broadcom BCM5703 1000Base-T,HALT,POWER DOWN,done - offline. ## Booting image at 00400000 ... Image Name: Linux-2.4.18_mvl30-lvl7 Created: 2003-07-18 9:29:45 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 584408 Bytes = 570 kB = 0 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb Linux version 2.4.18_mvl30-lvl7 (uabtrg@RedHatServer) (gcc version 3.2.1 2002093 0 (MontaVista)) #1 Fri Jul 18 11:24:13 CEST 2003 Broadcom BMW Fast Ethernet Routing Switch BMW port (C) 2003 LVL7 Systems, Inc. (linville(a)lvl7.com) On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: OpenPIC Version 1.2 (1 CPUs and 139 IRQ sources) at fc040000 time_init: decrementer frequency = 24.750000 MHz Calibrating delay loop... 131.89 BogoMIPS Memory: 63088k available (1008k kernel code, 328k data, 72k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Disabling the Out Of Memory Killer Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0xfc004500 (irq = 137) is a ST16650 ttyS01 at 0xfc004600 (irq = 138) is a ST16650 block: 128 slots per queue, batch=32 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Universal TUN/TAP device driver 1.4 (C)1999-2001 Maxim Krasnyansky MTD driver for BMW. Written by John W. Linville <linville(a)lvl7.com> bmw: Probing for BMW flash configuration... bmw: Found no BMW compatible flash configuration... Macintosh non-volatile memory driver v1.0 Broadcom Gigabit Ethernet Driver bcm5700 ver. 3.0.7 (07/17/02) eth0: Broadcom BCM5703 1000Base-T found at mem bfff0000, IRQ 17, node addr 00101 88201a1 eth0: Broadcom BCM5703 Integrated Copper transceiver found eth0: Scatter-gather OFF, 64-bit DMA OFF, Tx Checksum ON, Rx Checksum ON NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) IP-Config: Incomplete network configuration information. NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 =>printenv baudrate=9600 clocks_in_mhz=1 ethaddr=00:10:18:82:01:A1 lan_ifname=bcm0 lan_ifnames= lan_hwnames= lan_hwaddr= wan_ifname=eth0 wan_hwname= timer_interval=3600 ntp_server= log_level=0 time_zone=PST8PDT upnp_enable=0 os_server=http://router:kilroy@64.162.141.122 stats_server=http://router:kilroy@64.162.141.122/cgi-bin/stats.pl console_loglevel=7 lan_proto=dhcp lan_ipaddr=192.168.1.1 lan_netmask=255.255.255.0 lan_stp=0 wan_hostname= wan_domain= static_route= filter_ip= filter_tcp= filter_udp= filter_mac= forward_tcp= forward_udp= dmz_ipaddr= http_username=router http_passwd=kilroy http_wanport=8080 http_lanport=80 pppoe_ifname= pppoe_username= pppoe_passwd= pppoe_idletime=60 pppoe_keepalive=0 pppoe_demand=0 pppoe_mru=1500 pppoe_mtu=1500 wl_ssid=Broadcom wl_country=USA wl_closed=0 wl_wep=off wl_auth=0 wl_key=1 wl_key1= wl_key2= wl_key3= wl_key4= wl_mac= wl_macmode=allow d11b_channel=11 d11b_rate=0 d11b_rateset=default d11b_frag=2346 d11b_rts=2347 d11b_dtim=3 d11b_bcn=100 d11b_plcphdr=long d11a_channel=64 d11a_rate=0 d11a_rateset=default d11a_frag=2346 d11a_rts=2347 d11a_dtim=3 d11a_bcn=100 d11g_channel=11 d11g_rate=0 d11g_rateset=default d11g_frag=2346 d11g_rts=2347 d11g_dtim=3 d11g_bcn=100 restore_defaults=0 wan_dns=130.100.241.150 130.100.76.22 130.100.76.32 wan_wins=147.214.112.67 153.88.193.201 wan_lease=604800 wan_ipaddr=0.0.0.0 wan_netmask=0.0.0.0 wan_gateway=0.0.0.0 os_name=linux os_version=2.4.19-rc3 filesize=25994a dhcp_start=130.100.50.56 dhcp_end=130.100.50.56 gw=255.255.255.255 nfsroot=130.100.50.56:/tftpboot/130.100.50.55 root=/dev/nfs rw bootdelay=5 bootfile=pSystem netmask=255.255.255.0 ipaddr=130.100.50.55 serverip=130.100.50.56 rootpath=/tftpboot/130.100.50.55 bootcmd=tftpboot 00400000 ; bootm bootargs=root=/dev/nfs rw nfsroot=130.100.50.56:/tftpboot/130.100.50.55 ip=130.1 00.50.55:130.100.50.56::255.255.255.0:::off stdin=serial stdout=serial stderr=serial Environment size: 1903/8172 bytes => ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

RE: [U-Boot-Users] examples programs
by Dave.Stoddart＠aculab.com 15 Aug '03

15 Aug '03

Hi Wolfgang, Thanks for the comments. OK, found the section on Memory Management, do remember seeing it a while ago. But it doesn't explain my problem. I have also built the code into u-boot, and it runs just fine. The only thing I can think that is out of the ordinary is a large static array of short values, (2-3K) which get downloaded to an attached DSP. Its not the end of the world if it doesn't work, but its been bugging me (sorry!!) for a week or two. Thanks David

1 0

[U-Boot-Users] examples programs
by Dave.Stoddart＠aculab.com 15 Aug '03

15 Aug '03

Hi Folks, I am using U-Boot 0.4.0 with an MPC8245 processor with 64MBytes of SDRAM. The hardware appears to work fine, as we can load / run U-Boot and then run Embedded Linux without a problem. I have written some simple hardware test programs, again without a problem, using the examples/hello_world.c as a starting point. However, as they get more complex, i.e. more variables and larger, the program crashes, with odd messages coming out of mon_printf commands. It looks to me as though the stack is crashing. If I make the LOAD_ADDR in the Makefile 0x03000000, originally the default location 0x00040004, i.e. much higher up than the original, the test program works fine and returns to U-Boot without error. Has anybody else seen anything like this? Or can anybody tell me where the stack is? I have looked at the documentation, and cannot see anywhere that describes the memory layout when U-Boot is running. Regards David Stoddart Aculab PLC

2 1