May 2005 - U-Boot

[U-Boot-Users] mkimage parameters for cramfs.img
by Wayne Lee 06 May '05

06 May '05

Hi, u-boot users, I use uClinux with cramfs filesystem. The uClinux works when zImage is put at 0x8000 and cramfs.img is put at 0x02000000. For uClinux kernel, I create linux.bin.gz and make uImage by mkimage. mkimage -A arm -O linux -T kernel -C gzip -a 0x8000 -e 0x8000 -n "uClinux 2.6.5 Kernel Image" -d linux.bin.gz uImage Image Name: uClinux 2.6.5 Kernel Image Created: Fri May 6 12:30:15 2005 Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 547132 Bytes = 534.31 kB = 0.52 MB Load Address: 0x00008000 Entry Point: 0x00008000 uClinux filesystem is encapsulated with mkimage. mkimage -A arm -O linux -T ramdisk -C none -n "Cramfs Image" -a 0x02000000 -d cramfs.img ucramfs Image Name: Cramfs Image Created: Fri May 6 12:31:51 2005 Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 655360 Bytes = 640.00 kB = 0.62 MB Load Address: 0x02000000 Entry Point: 0x02000000 I copy uImage and ucramfs to 0x00400000 and 0x00500000. After bootm 0x00400000 and 0x00500000, the uClinux kernel is launched. However, the uClinux kernel cannot find the filesystem to mount. The message is as follows, RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Couldn't find valid RAM disk image starting at 0. Kernel panic: VFS: Unable to mount root fs on ram0 What is the correct mkimage parameters for cramfs.img ? Thanks. Wayne

2 4

[U-Boot-Users] Passing IP address to kernel
by JobHunts02＠aol.com 06 May '05

06 May '05

Should U-Boot be able to pass the board's IP address to the kernel? Immediately after logging in, I cannot ping. ifconfig shows the correct hardware address that was set in U-Boot, but not the IP address, which was similarly set in U-Boot. Also, many of the statistical fields have garbage data in them (see below). If I then set the IP address, ifconfig returns the IP address and the other fields are correct. Then, I can ping. Is this the expected behavior? Thank you. (none) login: root login[44]: root login on `ttyS0' # ping 10.174.100.14 PING 10.174.100.14 (10.174.100.14): 56 data bytes ping: sendto: Network is unreachable # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 1A:34:01:9C:69:15 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:4039443 errors:1743791573 dropped:0 overruns:0 frame:1156359170 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:4144766653 txqueuelen:1000 RX bytes:1290872887 (1231.0 MiB) TX bytes:0 (0.0 iB) # ifconfig eth0 address 10.174.100.211 eth0: OPEN BD rings initialised, RBASE=3D8160, TBASE=3D8360 # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 1A:34:01:9C:69:15 inet addr:10.174.100.211 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB) # ping 10.174.100.14 PING 10.174.100.14 (10.174.100.14): 56 data bytes 64 bytes from 10.174.100.14: icmp_seq=0 ttl=64 time=1.1 ms 64 bytes from 10.174.100.14: icmp_seq=1 ttl=64 time=0.5 ms 64 bytes from 10.174.100.14: icmp_seq=2 ttl=64 time=0.5 ms 64 bytes from 10.174.100.14: icmp_seq=3 ttl=64 time=0.5 ms 64 bytes from 10.174.100.14: icmp_seq=4 ttl=64 time=0.5 ms 64 bytes from 10.174.100.14: icmp_seq=5 ttl=64 time=0.5 ms 64 bytes from 10.174.100.14: icmp_seq=6 ttl=64 time=0.5 ms 64 bytes from 10.174.100.14: icmp_seq=7 ttl=64 time=0.6 ms 64 bytes from 10.174.100.14: icmp_seq=8 ttl=64 time=0.5 ms --- 10.174.100.14 ping statistics --- 9 packets transmitted, 9 packets received, 0% packet loss round-trip min/avg/max = 0.5/0.5/1.1 ms #

2 1

[U-Boot-Users] booting out of NAND for s3c2410
by Tehn-Yit Chin 06 May '05

06 May '05

Hi folks, We have a Samsung s3c2410 based plaform which we want to boot out of NAND. Our development board is the smdk2410. When I uncommented out CFG_CMD_NAND and did a compile, a whole bunch error messages pops up. The errors mostly deals with NAND parameters. Before I head-on into this code, can anyone tell me how complete the NAND support is s3c2410? Also does anyone know if u-boot is able to be boot from NAND on the s3c2410? Many thanks, Tehn Yit Chin Software Engineer, Grey Innovation Pty. Ltd.

1 0

RE: [U-Boot-Users] A&M Rattler8248 ethernet config
by tony.ford＠quadrics.com 05 May '05

05 May '05

Hi guys, I've managed to get to the bottom of my problem. It would seem that when I compile the sources out of CVS the resulting u-boot.bin file is 197320 bytes big, (192K + 712bytes). This is greater than the 192K reserved for the monitor in include/configs/Rattler.h When I saveenv the environment vars after initial boot this starts writing at CFG_MONITOR_BASE + CFG_MONITOR_LEN, scribbling over the last 712 bytes of the monitor. Once I up the monitor length to 256 bytes it all just works. Many thanks for your speedy feedback. -- > -----Original Message----- > From: Yuli Barcohen [mailto:yuli@arabellasw.com] > Sent: 03 May 2005 20:08 > To: Tony Ford > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] A&M Rattler8248 ethernet config > > > >>>>> Tony Ford writes: > > Tony> Hi, I've got a basic u-boot port going on this card > and am now > Tony> looking at getting ethernet working. > > What's wrong with the U-Boot port for to this board which > already is in > CVS? > > -- > ============================================================== > ========== > Yuli Barcohen | Phone +972-9-765-1788 | Software > Project Leader > yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella > Software, Israel > ============================================================== > ========== > >

2 1

[U-Boot-Users] Returned mail: see transcript for details
by Mail Delivery Subsystem 05 May '05

05 May '05

The original message was received at Thu, 5 May 2005 01:41:31 -0600 (MDT) from duel.boulder.nist.gov [132.163.6.1] ----- The following addresses had permanent fatal errors ----- <roberts(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <scoops(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <jwong(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <parker(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <jeffxie(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <3dwenshuhong(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <bear_hu1(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <culinary(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <miltonj(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <bmaster(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <xx(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRnanovball(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRli(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRwangdz(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRlitoni(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRpeterandpeter(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <imADDRpeterandpeter(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRhhannover(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRchizhang(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRqzhang(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRcustomerservice(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <idlemandeal(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <ADDRwenshuhong(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <reply(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <licensing(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <Matthew_Baird(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <david(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <vintagediva(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <recruitment(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <youningzhu(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <enrichers(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <agnesm(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <homeownertips(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <LSI-service(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <jiagao_suny(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <endoftransaction(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <endofitem(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <outbidnotice(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <hotmail.com(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <mercury866(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <literature(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <richard(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <myron.plichota(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <tomsmith(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <tonymantoan(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <pier(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <DO85(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <D3(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <r0a4(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <chernaev(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <jes(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) <Matt_Domsch(a)boulder.nist.gov> (reason: 550 5.1.1 User unknown) ----- Transcript of session follows ----- ... while talking to localhost: >>> RCPT To:<Matt_Domsch(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <Matt_Domsch(a)boulder.nist.gov>... User unknown >>> RCPT To:<jes(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <jes(a)boulder.nist.gov>... User unknown >>> RCPT To:<chernaev(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <chernaev(a)boulder.nist.gov>... User unknown >>> RCPT To:<r0a4(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <r0a4(a)boulder.nist.gov>... User unknown >>> RCPT To:<D3(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <D3(a)boulder.nist.gov>... User unknown >>> RCPT To:<DO85(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <DO85(a)boulder.nist.gov>... User unknown >>> RCPT To:<pier(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <pier(a)boulder.nist.gov>... User unknown >>> RCPT To:<tonymantoan(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <tonymantoan(a)boulder.nist.gov>... User unknown >>> RCPT To:<tomsmith(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <tomsmith(a)boulder.nist.gov>... User unknown >>> RCPT To:<myron.plichota(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <myron.plichota(a)boulder.nist.gov>... User unknown >>> RCPT To:<richard(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <richard(a)boulder.nist.gov>... User unknown >>> RCPT To:<literature(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <literature(a)boulder.nist.gov>... User unknown >>> RCPT To:<mercury866(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <mercury866(a)boulder.nist.gov>... User unknown >>> RCPT To:<hotmail.com(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <hotmail.com(a)boulder.nist.gov>... User unknown >>> RCPT To:<outbidnotice(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <outbidnotice(a)boulder.nist.gov>... User unknown >>> RCPT To:<endofitem(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <endofitem(a)boulder.nist.gov>... User unknown >>> RCPT To:<endoftransaction(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <endoftransaction(a)boulder.nist.gov>... User unknown >>> RCPT To:<jiagao_suny(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <jiagao_suny(a)boulder.nist.gov>... User unknown >>> RCPT To:<LSI-service(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <LSI-service(a)boulder.nist.gov>... User unknown >>> RCPT To:<homeownertips(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <homeownertips(a)boulder.nist.gov>... User unknown >>> RCPT To:<agnesm(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <agnesm(a)boulder.nist.gov>... User unknown >>> RCPT To:<enrichers(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <enrichers(a)boulder.nist.gov>... User unknown >>> RCPT To:<youningzhu(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <youningzhu(a)boulder.nist.gov>... User unknown >>> RCPT To:<recruitment(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <recruitment(a)boulder.nist.gov>... User unknown >>> RCPT To:<vintagediva(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <vintagediva(a)boulder.nist.gov>... User unknown >>> RCPT To:<david(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <david(a)boulder.nist.gov>... User unknown >>> RCPT To:<Matthew_Baird(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <Matthew_Baird(a)boulder.nist.gov>... User unknown >>> RCPT To:<licensing(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <licensing(a)boulder.nist.gov>... User unknown >>> RCPT To:<reply(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <reply(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRwenshuhong(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRwenshuhong(a)boulder.nist.gov>... User unknown >>> RCPT To:<idlemandeal(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <idlemandeal(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRcustomerservice(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRcustomerservice(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRqzhang(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRqzhang(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRchizhang(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRchizhang(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRhhannover(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRhhannover(a)boulder.nist.gov>... User unknown >>> RCPT To:<imADDRpeterandpeter(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <imADDRpeterandpeter(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRpeterandpeter(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRpeterandpeter(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRlitoni(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRlitoni(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRwangdz(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRwangdz(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRli(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRli(a)boulder.nist.gov>... User unknown >>> RCPT To:<ADDRnanovball(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <ADDRnanovball(a)boulder.nist.gov>... User unknown >>> RCPT To:<xx(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <xx(a)boulder.nist.gov>... User unknown >>> RCPT To:<bmaster(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <bmaster(a)boulder.nist.gov>... User unknown >>> RCPT To:<miltonj(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <miltonj(a)boulder.nist.gov>... User unknown >>> RCPT To:<culinary(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <culinary(a)boulder.nist.gov>... User unknown >>> RCPT To:<bear_hu1(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <bear_hu1(a)boulder.nist.gov>... User unknown >>> RCPT To:<3dwenshuhong(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <3dwenshuhong(a)boulder.nist.gov>... User unknown >>> RCPT To:<jeffxie(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <jeffxie(a)boulder.nist.gov>... User unknown >>> RCPT To:<parker(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <parker(a)boulder.nist.gov>... User unknown >>> RCPT To:<jwong(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <jwong(a)boulder.nist.gov>... User unknown >>> RCPT To:<scoops(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <scoops(a)boulder.nist.gov>... User unknown >>> RCPT To:<roberts(a)boulder.nist.gov> <<< 550 5.1.1 User unknown 550 5.1.1 <roberts(a)boulder.nist.gov>... User unknown

1 0

[U-Boot-Users] register init
by Hinko Kocevar 05 May '05

05 May '05

Hello @LL, i've ported u-boot to trizeps2 cpu module. It can boot and use tftp when running under BDI debugger, so I guess basic parts are ported fine. When I try to run board standalone it kind of hangs there... no output on serial console. After few days of debugging I established that lowlevel_init() won't set the GAFR0_x register(s) to defined value set in u-boot board config. Under BDI I can see that at this point PC jumps to some random address - or throws an exception that BDI intercepts, if I set 'VECTOR CATCH 0xde' directive in BDI config. After exception caught by the BDI I can set PC back few instrucions and board would boot, console lives! I've added few nop instructions* after ldr and str invocations that are setting GAFRx registers, but that just delays the data abort seen before (eg. it would happen when setting MSCx registers). * As xscale manual suggests for imprecise data aborts. Further, it is not always the same exception that occurs, it is data abort, undefined instruction, and sometimes prefetch aborts are seen also. And more, when the board boots by itself, which happens once in a while, I can see it is looping inside serial - getc() code waiting for input. But there is nothing shown on terminal and nothing can be input, since GAFR1_L is not setup to provide FFUART function. I've attached objdump and BDI output while single-stepping around critical section. Any ideas? reagrds, hk -- hinko <dot> kocevar <at> iskramedical <dot> si Hinko Kocevar, embedded systems developer Iskra Medical d.o.o., Stegne 23, 1k LJ, SLO-EU "Aì rén" | [Analects XII:22] objdump u-boot.bin: ldr r0, =GPDR2 a30804f0: e59f021c ldr r0, [pc, #540] ; a3080714 <.text+0x714> ldr r1, =CFG_GPDR2_VAL a30804f4: e3a01902 mov r1, #32768 ; 0x8000 str r1, [r0] a30804f8: e5801000 str r1, [r0] ldr r0, =GAFR0_L a30804fc: e59f0214 ldr r0, [pc, #532] ; a3080718 <.text+0x718> ldr r1, =CFG_GAFR0_L_VAL a3080500: e3a01000 mov r1, #0 ; 0x0 str r1, [r0] a3080504: e5801000 str r1, [r0] ldr r0, =GAFR0_U a3080508: e59f020c ldr r0, [pc, #524] ; a308071c <.text+0x71c> ldr r1, =CFG_GAFR0_U_VAL a308050c: e3a01000 mov r1, #0 ; 0x0 str r1, [r0] a3080510: e5801000 str r1, [r0] ldr r0, =GAFR1_L a3080514: e59f0204 ldr r0, [pc, #516] ; a3080720 <.text+0x720> ---------------------------------------------------------------------------- BDI2000 output while single step (this is without VECTOR CATCH directive) ... Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x000004f8 Current CPSR : 0xa00000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x000004fc Current CPSR : 0xa00000d3 (Supervisor) Core#0>ti - Vector Tables in Mini IC updated (low : high) - 0xEAFFC20E : 0xEA00020E - 0x00000000 : 0xE1200070 - 0x23001010 : 0xE1200070 - 0x33300000 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00000500 Current CPSR : 0xa00000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00000504 Current CPSR : 0xa00000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00000508 Current CPSR : 0xa00000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : External Debug Event Current PC : 0x00000008 Current CPSR : 0xa00000db (Undefined) # Step timeout detected ---------------------------------------------------------------------------- BDI2000 output while single step (this is with VECTOR CATCH 0xDE). This time 'UNDEFINED' instruction occoured. DATA ABORT and PREFETCH ABORT were also seen... ... - Core#0: BDI clears hold_rst - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed Core#0>g - Vector Tables in Mini IC updated (low : high) - 0xEAFFC20E : 0xEA00020E - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - 0xE59FF014 : 0xE1200070 - Core#0: Invalid debug entry message ignored - Core#0: Invalid debug entry message ignored - TARGET: core #0 has entered debug mode Core#0>g - TARGET: core #0 has entered debug mode Core#0>i Core number : 0 Core state : debug mode (ARM) Debug entry cause : Vector Trap (UNDEFINED) Current PC : 0x00000508 Current CPSR : 0xa00000d3 (Supervisor)

1 1

Re: [U-Boot-Users] JFFS2 support - was: (no subject)
by Wolfgang Denk 05 May '05

05 May '05

Hello, in message <0ee5768feeb4609b1a0f3ec58d88e7bb(a)sundius.com> you wrote: > > while my kernel can read the jffs2 filesystem fine. u-boot seems to > have some > trouble when reading (ls) of symbolic links.. It seems we found this problem. Please feel free to try the attached patch (which I'm checking in right now). Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Motto of the Electrical Engineer: Working computer hardware is a lot like an erect penis: it stays up as long as you don't fuck with it.

1 0

[U-Boot-Users] u-boot/linux MPC8xx PCMCIA woes
by Mike Quicquaro 04 May '05

04 May '05

Any MPC8xx PCMCIA experts out there? I have a problem I was hoping someone can help me out with. My hardware is very similar to the MPC885ADS (DUET) board. I have the PCMCIA interface working fine in Linux 2.4.26 I have recently enabled the PCMCIA support in u-boot. It also seems to be working just fine. My problem is, that once I enabled PCMCIA in u-boot, when Linux comes up, my hardware hangs in the Linux PCMCIA initialization code. I have traced the hang down to an instruction in _fpqpcmcia_reset() which is in the file .....kernel/drivers/pcmcia/pqpcmcia.c The following code snipet shows where the hang occurs: /* reset the mem/io windows */ /* 01 mem_win slot_A ... 0N mem-win slot_A 01 io-win slot_A ... 0N io-win slot_A 01 mem-win slot_B ... 0N mem-win slot_B 01 io-win slot_B ... 0N io-win slot_B */ for ( i = p_ctx->first_mem_win; i < (p_ctx->first_mem_win + p_ctx->mem_wins_num); i++ ) { p_ctx->REGS->win[i].pbr = 0; /******************* HANGS HERE **********/ p_ctx->REGS->win[i].por = 0; } for ( i = p_ctx->first_io_win; i < (p_ctx->first_io_win + p_ctx->io_wins_num); i++ ) { p_ctx->REGS->win[i].pbr = 0; p_ctx->REGS->win[i].por = 0; } I've tried doing a reset of the PCMCIA (*p_ctx->pgcr = Q_PCMCIA_PGCRX_CXRESET;) in various places before this Linux initialization takes place, but it just causes kernel crashes. I've also tried doing the reset earlier on. I'm kind of stumped on this one. Is there a way to get the PCMCIA into the state it was at reset, without resetting? I was hoping to fix this problem without becoming a ppc PCMCIA guru. I am using the MPC870. Does this ring a bell with anyone here? Regards, - Mike

1 0

[U-Boot-Users] loadb (kermit) with hyperterminal in windows XP
by Wayne Lee 04 May '05

04 May '05

Hello, u-boot folks, I command "loadb 10000 9600" in u-boot prompt. Then I send file by windows' hyper-terminal kemit mode. Windows hyper-terminal sent file successfully. However, u-boot still waits for packets. By ICE, I found that the file has actually been sent and is correct at target DRAM. It looks like u-boot Kermit protocol codes wait for some stop packet. Have anyone use u-boot loadb with window hyper-terminal? Thanks. Wayne

2 4

[U-Boot-Users] Isseus with porting and debugging u-boot
by Abdel El-Masoudi 04 May '05

04 May '05

I want to upgrade my u-boot version (1.0.0) For a EP7312(ARM7) based custom designed board to the latest u-boot version. I downloaded u-boot 1.1.2 and patched it manually with my specific board configuration files. Unfortunally the patched u-boot version would not boot. I did the following to debug the u-boot with a bdi2000 (with a good configuration file, hardware breakpoints). Load u-boot.bin at 0x00000000 Start GDB with u-boot elf file (first address = 0xc0f00000) connect to bdi20000 etc.. board information FLASH = 0x00000000 RAM = 0xc0000000 TEXT_BASE = 0xc0f00000 / System.map /bash-2.05b$ more System.map c0f00000 T _start c0f00020 t _undefined_instruction c0f00024 t _software_interrupt c0f00028 t _prefetch_abort/ *How to debug u-boot when the first address in the ELF file is not the same as the address of the image on the target?*/ I tried to change the addresses by changing TEXT_BASE to 0x00000000 in the board specific config.mk file, but i think this is not the solution!! When i debugged u-boot in FLASH i could step through it, but it looks like i did not execute any code. For example the registers R0, R1 etc.. did not get a proper value when a assembler move instruction executed. I tried the latest u-boot cvs version, because it had the capability to start from RAM by skipping relocation code (CONFIG_SKIP_RELOCATE_UBOOT). My BDI2000 did the initial configuration and start/load the U-boot RAM version. A strange thing is that the u-boot version starts without any problems, but when i compile u-boot without CONFIG_SKIP_RELOCATE_UBOOT and flash it to the first address (0x00000000) it would not start. The difference between the two version is only the relocation code. My u-boot 1.0.0 with my board specific patches works without any problem. Could somebody have any clue what the problem is?

1 0

[U-Boot-Users] A&M Rattler8248 ethernet config
by tony.ford＠quadrics.com 03 May '05

03 May '05

Hi, I've got a basic u-boot port going on this card and am now looking at getting ethernet working. I've set all the network parameters AFAIK but ping returns: ping failed: host xxx.xxx.xxx.xxx is not alive. The host I'm pinging is on the same subnet. I'm confident that the network fabric is in good shape. I'm less confident about the mpc8248 ethernet configuration. The Motorola documentation has *plenty* to say about FCC configuration, the question is how much do I need ? I'm fully prepared to RTFM but am wondering if anyone can give me some direct pointers. Best regards, Tony.

3 2

[U-Boot-Users] flash driver for atmel AT49BV162A
by andreas_schmidt＠ifm-electronic.com 03 May '05

03 May '05

Hallo at all I wanted to ask if somebody has a flash patch (flash.c) for Atmel AT49BV162A Flash or similarly one? best regards, Andreas Schmidt

1 0

Re: [U-Boot-Users] A question on ELDK PATH Setting
by Sam Song 03 May '05

03 May '05

Wolfgang Denk <wd(a)denx.de> wrote: > > > "xd" should be replaced by "xxd". At least for > > > RED HAT 7.3/9.0. > > > > If you look closely you will see that the examples > > run on the target so the question is really "what > > is the tool named in the ELDK?" Ok, [snip] > The tool I used in our regression tests is indeed > called "xd". This is a home-made hexdump tool > I've been using on all systems for the > last 15 years or so. > > > right now. By the way, this was _never_ a typo. > > There was a tool named "xd" around doing just > > what is shown - the examples were captured from > > live sessions rather than being dreamed up. > > Right. But we might use xxd as well. OK, I get it. "xd" is a home-made target command of ELDK. "xxd" is a HOST one. Yeah, I worked under NFS to check the MTD content. Thanks a lot for the reply from both of you:) Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

1 0

[U-Boot-Users] Re: [PATCH 3/4] add csb637 (at91rm9200) support
by Anders Larsen 03 May '05

03 May '05

Anders Larsen wrote: >Changelog: > * patch by Anders Larsen, 2004-04-29 > add support for Cogent csb637 Oops, that's 2005-04-29, of course. <:-o ^ Cheers Anders

1 0

AW: [U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support
by Martin Krause 03 May '05

03 May '05

Hi Anders, Anders Larsen wrote on Dienstag, 3. Mai 2005 11:36: > "Martin Krause" <Martin.Krause(a)tqs.de> wrote: > > That's very similar to your results, but not exact the same. > > Perhaps because you are using a 2.6 kernel. What CPU clock frequency > > do you use? We use 179 MHz. > > Hi Martin, > my csb637 runs at 184MHz, and yes, my RSA encryption benchmark runs OK, that explains your slightly better nbench results. A clock rate > 180 MHz could be problematic. According errata 42 (AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata sheet (doc6015) the PLL is limited to 180 MHz. We already had problems with this bug (with about 10%-15% of the CPUs). After configuring the PLL for 179 MHz no errors occour any mor (before we used 207 MHz). > > Here are my nbench results for synchronous clock mode > > (nbench 2.2.1 on cmc-pu2 board): > ... > > > > And this are the results for fast bus mode: > > Err, didn't you say the results were the same? Yes. In my first email I referred to a nbench result taken with U-Boot 1.1.2 (some weeks ago). Then I did a new measurement with the actual U-Boot (1.1.3) and get the results mentioned in my second email - whith only one third of the old performance :-(, because the setting of the clock mode has changed in U-boot. > Synchronous mode is about three times faster than FastBus mode > on your HW... Yes, I think this is because of a CPU clock to master clock ratio of 3:1. > AFAICT synchronous clock mode performs marginally better than > asynchronous mode, but since asynchronous mode has less restrictions > than synchronous mode, asynchronous is arguably the better (= more > general) solution. I'll submit an alternative patch. OK, I would also prefere the asynchronous mode, because that was the mode used by U-Boot 1.1.2 and we've done already a lot tests with our hardware with this mode. Regards, Martin

2 1

Re: [U-Boot-Users] A question on ELDK PATH Setting
by Sam Song 03 May '05

03 May '05

Wolfgang Denk <wd(a)denx.de> wrote: > If you have a look at the contrents of the ELDK's > bin directories you will see that you will be missing the > ${CROSS_COMPILE}rpm tool if you omit Well, no wander I haven't met any trouble on compiling kernel. Actually, I have no idea on ${CROSS_COMPILE} rpm. > But actually this is completely off topic here... Ummm, if so, where could we discuss something about DULG? I noticed there is one charming words below the DULG linkage, says "You are invited to contribute". The doc benfits me a lot. And has been updating frequently. Really wanna to see it better:) Btw, I reported one typo for you about MTD part on OLD linuxppc maillist. But you still haven't corrected it yet. I don't know why:) http://www.denx.de/twiki/bin/view/DULG/FlashFilesystemsMTD "xd" should be replaced by "xxd". At least for RED HAT 7.3/9.0. Thanks for your reply, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

3 2

AW: [U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support
by Martin Krause 03 May '05

03 May '05

Hi Anders, Anders Larsen wrote on Montag, 2. Mai 2005 14:13: > > I've also done an nbench benchmark under linux running in > > synchronous clock mode. But the results are the same as in fast bus > > clock mode. Strange. I've no idea why. > > Perhaps your Linux switches clock mode itself? (the at91rm9200 patch I can't say, but I think not because system boot time decreases in syncronous bus mode. > from maxim.org.za does _not_, however) I use the linuxarm tree from denx.de > What does /proc/cpuinfo say about this? > With my patch I get: > # grep -i bogomips /proc/cpuinfo > BogoMIPS : 91.95 > and without it I get appr. 28. With syncronous mode I get: root@CMC-TC-PU2:/>grep -i bogomips /proc/cpuinfo BogoMIPS : 89.70 root@CMC-TC-PU2:/> And without it I get: # grep -i bogomips /proc/cpuinfo BogoMIPS : 29.90 # That's very similar to your results, but not exact the same. Perhaps because you are using a 2.6 kernel. What CPU clock frequency do you use? We use 179 MHz. > For reference here's the output from nbench 2.2.2 on my csb637 board: Here are my nbench results for synchronous clock mode (nbench 2.2.1 on cmc-pu2 board): BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 54.237 : 1.39 : 0.46 STRING SORT : 3.7939 : 1.70 : 0.26 BITFIELD : 1.2875e+07 : 2.21 : 0.46 FP EMULATION : 5.5534 : 2.66 : 0.61 FOURIER : 5.9549 : 0.01 : 0.00 ASSIGNMENT : 0.4583 : 1.74 : 0.45 IDEA : 164.47 : 2.52 : 0.75 HUFFMAN : 21.4 : 0.59 : 0.19 NEURAL NET : 0.0068962 : 0.01 : 0.00 LU DECOMPOSITION : 0.23381 : 0.01 : 0.01 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 1.669 FLOATING-POINT INDEX: 0.010 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : L2 Cache : OS : Linux 2.4.27-vrs1 C compiler : arm-linux-gcc libc : static MEMORY INDEX : 0.380 INTEGER INDEX : 0.447 FLOATING-POINT INDEX: 0.005 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. And this are the results for fast bus mode: BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 20.295 : 0.52 : 0.17 STRING SORT : 1.2613 : 0.56 : 0.09 BITFIELD : 4.3108e+06 : 0.74 : 0.15 FP EMULATION : 1.8553 : 0.89 : 0.21 FOURIER : 1.9967 : 0.00 : 0.00 ASSIGNMENT : 0.19771 : 0.75 : 0.20 IDEA : 54.685 : 0.84 : 0.25 HUFFMAN : 7.1418 : 0.20 : 0.06 NEURAL NET : 0.0023085 : 0.00 : 0.00 LU DECOMPOSITION : 0.078419 : 0.00 : 0.00 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 0.587 FLOATING-POINT INDEX: 0.003 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : L2 Cache : OS : Linux 2.4.27-vrs1 C compiler : arm-linux-gcc libc : static MEMORY INDEX : 0.138 INTEGER INDEX : 0.153 FLOATING-POINT INDEX: 0.002 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. On last November I have already done a nbench run for our board. There I got the same results like now with synchronous mode. So I guess in earlier versions of U-boot the synchronous mode had already been set. I checked this. In U-Boot 1.1.2 the asynchronous mode was used for the AT91RM9200 cpu. This was changed by a patch by Steven Scholz when doing the SoC cleanup for the arm920t directory tree (I could not say, which patch exactly). Steven, did you have a special reason for doing this? For performance reasons I suggest we should switch back to asynchronous (or synchronous clock mode, no idea which one is favorable). Any suggestions? Regards, Martin

2 1

[U-Boot-Users] Re: Baudrate of UART in U-Boot
by Yusuf Ibrahim Ozkok 03 May '05

03 May '05

Hi, You should change the CONFIG_BAUDRATE, defined in the board config header file (/include/configs/<board_name.h>). But before that you should set CFG_NS16550_CLK in the same file to the appropriate console uart frequency. If that is not set correctly the baudrate generator in the console uart could not calculate the baudrates defined by CONFIG_BAUDRATE, appropriately. Hope to help... Best Wishes. Yusuf Ibrahim Ozkok Software Eng. ASELSAN Inc. ###################################################################### Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz. Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte, guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi gorusu olmak zorunda degildir. ###################################################################### Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any views or opinions presented are solely those of the author and do not necessarily represent the views of the company. ######################################################################

1 0

[U-Boot-Users] still got "*** Warning - bad CRC, using default environment" after saveenv is sucessfully done
by Wayne Lee 02 May '05

02 May '05

Hi, u-boot users, I have written hardware-dependent flash functions for my EVB u-boot support. Hence, "saveenv" works and I can see the env data in the configured env sector by "md" command. However, I still get the warning messages, "*** Warning - bad CRC, using default environment", after press reset button. Should any CONFIG/CFG need to be added in board configuration file? I use u-boot 1.1.2 and the followings are part of board configurations. /*----------------------------------------------------------------------- * Physical Memory Map */ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ #define PHYS_SDRAM_1 0x00000000 /* SDRAM Bank #1 */ #define PHYS_SDRAM_1_SIZE 0x04000000 /* 64 MB */ #define PHYS_FLASH_1 0xFF800000 /* Flash Bank #1 */ #define CFG_FLASH_BASE PHYS_FLASH_1 /*----------------------------------------------------------------------- * FLASH and environment organization */ #define CFG_MAX_FLASH_BANKS 1 /* max number of memory banks */ #define PHYS_FLASH_SIZE 0x00400000 /* 4MB */ #define CFG_MAX_FLASH_SECT (71) /* max number of sectors on one chip */ /* addr of environment */ #define CFG_FLASH_CFI /* The flash is CFI compatible */ #define CFG_ENV_IS_IN_FLASH 1 #define CFG_ENV_SIZE 0x2000 /* Total Size of Environment Sector */ #define CFG_ENV_SECT_SIZE 0x2000 #define CFG_ENV_OFFSET 0x3F8000 /* environment starts here */ #define CFG_ENV_ADDR (CFG_FLASH_BASE + CFG_ENV_OFFSET) Thanks. Wayne

3 3

AW: [U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support
by Martin Krause 02 May '05

02 May '05

Hi Anders, u-boot-users-admin(a)lists.sourceforge.net wrote on : > this patch switches the at91rm9200 to synchronous clock mode after > initialization (it would otherwise stay in FastBus mode which is the > _slowest_ clock mode). This lets the core run at full speed when not > doing bus accesses, increasing overall performance by a factor of > four. > > Changelog: > * patch by Anders Larsen, 2004-04-29 > set the at91rm9200 clock to synchronous mode > > Cheers > Anders I've tested your patch on the cmc_pu2 board. Boot time is reduced from about 32 s to 26 s with your patch (measured from starting power supply to a specific status message of our linux application). This is great! I wonder if there are some pitfalls doing this on the AT91RM9200 cpu? As I understand the ARM920T Technical Reference Manual the clocking modes are a feature of the ARM920T core and not affected by the surrounding on-chip peripherals added by Atmel. So it should work for all cpu's with ARM920T core without problems? I've also done an nbench benchmark under linux running in synchronous clock mode. But the results are the same as in fast bus clock mode. Strange. I've no idea why. Regards, Martin

2 1

[U-Boot-Users] wlan driver
by Dan Malek 01 May '05

01 May '05

Hello everyone. Has anyone worked on a 802.11 wireless driver for u-boot? I'm faced with a board that has mini-PCI, adapters aren't working for standard cards, and it looks like the only solution may be a 3.3V wireless LAN card. There are some "standard" 3.3V mini-PCI cards for laptops, but I don't know how the connectors attach or if the magnetics are on the cards. If anyone knows, that would be useful information too. Thanks for any suggestions (I suspect Wolfgang will respond with a URL to an archive I couldn't find) :-) -- Dan

2 1