October 2004 - U-Boot

[U-Boot-Users] RTC Question
by Robin Getz 09 Oct '04

09 Oct '04

All: General question, in the specific processor (Blackfin BF533) that I am using, the on-board RTC can have a 32768 days, and defaults to starting at 01Jan1970. This means that RTC rollover will occur around Fri, 19-Sep-2059 11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970. Should I add extra complexity, to extend things past this? I see issues in other code that will roll over around 19Jan2038, so I would expect that others are not concerned about it? -Robin

4 4

[U-Boot-Users] ATA driver in U-Boot
by Victor Wren 08 Oct '04

08 Oct '04

I am not sure if this is off-topic, because I'm unsure of the division of labor. Is there any reason that U-Boot needs ATA support compiled in? I ask because I'm trying to speed up booting on a small system with a hard drive. U-Boot waits for the devices to become available, scanning the ATA bus, before proceeding to load the Linux kernel. It appears to me that the kernel then does the same thing again, whereas if it went ahead and went straight to loading the kernel, it would give the drive another second or two to spin up and be ready for a bus scan. Given that the kernel is being loaded out of flash (with all drivers compiled in), and that the only reference to the IDE drive that U-Boot really knows about is a commandline parameter passed to the kernel, would it cause any conspicuous problems to remove ATA support from U-Boot, or does the kernel depend on hardware information that U-Boot is providing (I notice there's a "U-Boot" section in the kernel config)? Thanks, Victor Wren

3 2

RE: [U-Boot-Users] Unable to run hello_world
by Smith, Craig 08 Oct '04

08 Oct '04

>>## Ready for binary (kermit) download to 0x00040000 at 19200 bps... >>## Total Size = 0x000022b0 = 8880 Bytes My hello_world.bin (for ppc) is 66280 bytes. Have you tried the s-record format? What terminal program are you using? minicom won't work...at least I can't get it to. Regards, -Craig

2 1

[U-Boot-Users] U-Boot for IXP425 Little-endian
by Herb Radford 08 Oct '04

08 Oct '04

I'm going to be using an IXP425 for u-boot and a kernel but in order to re-use existing software I want to use BOTH u-boot and the kernel in little-endian. Is there someone who has done this for this target or is working on it? I'll do it myself, but I thought I'd ask first. Regards, Herb --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.769 / Virus Database: 516 - Release Date: 9/24/2004

3 2

[U-Boot-Users] Re: how to run hello_world
by Farrukh Masood 08 Oct '04

08 Oct '04

Hi! Please tell me where can i find hello_world.bin file and where should it be put on the host system to be accessible from u-boot based target system with tftpboot command. It will be quite helpful for me if you can stepwise describe the procedure as I am unable to understand it from the denx tutorial. thanks alot Regards Chishti Wolfgang Denk <wd(a)denx.de> wrote: In message <20041007160300.20228.qmail(a)web25404.mail.ukl.yahoo.com> you wrote: > > As described in u-boot readme file, to run hello_world example we have to write "loads", but this command doesnt seem to work with me and give the following msg > > Unknown command 'loads' - try 'help' Then it seems this command was not enabled in your board configuration. But you can load the file using TFTP as well. > and when i give the command go 40004 Hello World! This is a test. > > following error msg appears Ummm.. did you really expect that some magic code would spring into life and do something reasonable when you jump to this address after --------------------------------- Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish.

3 2

RE: [U-Boot-Users] Re: how to run hello_world
by Smith, Craig 08 Oct '04

08 Oct '04

>>Please tell me where can i find hello_world.bin file In the "examples" directory. >>and where should it be put on >>the host system to be accessible from u-boot based target system with tftpboot command. That depends on how your tftp server was set up. See http://www.denx.de/twiki/bin/view/DULG/SystemSetup#Section_4.6. >>It will be quite helpful for me if you can stepwise describe the procedure as I >>am unable to understand it from the denx tutorial. The procedure is already described "stepwise". See http://www.denx.de/twiki/bin/view/DULG/UBootStandalone#Section_5.12.1. Now, everyone, all together..."Please don't post HTML", that's a good way to get your message ignored. Regards, -Craig

1 0

[U-Boot-Users] u-boot on floppy from x86
by Shakthi Kannan 08 Oct '04

08 Oct '04

Greetings! I read that u-boot can be installed on a floppy and can be booted from the floppy. Is it possible on an x86 (Intel PII) system? I downloaded u-boot-1.1.1. The README says that u-boot can be used for i386 CPUs and architecture. But, the Makefile has only one entry for i386 for AMD SC520 CDP. I need to do "make <arch>_config" first and not sure which one I should do for an x86 target system. My main objective is to write my own commands in the u-boot monitor source program, and test it when u-boot boots the system. Any suggestions? Thanks, Shaks _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

2 2

[U-Boot-Users] compiling error
by Alessio Raccis 08 Oct '04

08 Oct '04

Hi all, I'm a newbie in u-boot, then sorry for all my fool questions. I'm trying to compile u-boot for smdk2410, but I have an error. This is what I have: .............. make[1]: Leaving directory `/root/u-boot-0.4.8_new/drivers' make[1]: Entering directory `/root/u-boot-0.4.8_new/drivers/sk98lin' arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skge.o skge.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skaddr.o skaddr.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skgehwt.o skgehwt.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skgeinit.o skgeinit.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skgepnmi.o skgepnmi.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skgesirq.o skgesirq.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o ski2c.o ski2c.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o sklm80.o sklm80.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skqueue.o skqueue.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skrlmt.o skrlmt.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o sktimer.o sktimer.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skvpd.o skvpd.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skxmac2.o skxmac2.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o skcsum.o skcsum.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o uboot_skb.o uboot_skb.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -Wall -Wstrict-prototypes -I. -DSK_USE_CSUM -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0x33F80000 -I/root/u-boot-0.4.8_new/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -c -o uboot_drv.o uboot_drv.c In file included from /root/u-boot-0.4.8_new/include/common.h:40, from uboot_drv.c:26: /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stdarg.h:43: parse error before `__gnuc_va_list' /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stdarg.h:43: warning: data definition has no type or storage class /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stdarg.h:110: parse error before `va_list' /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stdarg.h:110: warning: data definition has no type or storage class In file included from uboot_drv.c:26: /root/u-boot-0.4.8_new/include/common.h:438: parse error before `va_list' /root/u-boot-0.4.8_new/include/common.h:438: warning: function declaration isn't a prototype /root/u-boot-0.4.8_new/include/common.h:468: parse error before `va_list' /root/u-boot-0.4.8_new/include/common.h:468: warning: function declaration isn't a prototype make[1]: *** [uboot_drv.o] Error 1 make[1]: Leaving directory `/root/u-boot-0.4.8_new/drivers/sk98lin' make: *** [subdirs] Error 1 these are my compilers: gcc-3.2.2-5 gcc-c++-3.2.2-5 libgcc-3.2.2-5 gcc-g77-3.2.2-5 gcc-java-3.2.2-5 gcc-objc-3.2.2-5 and these are my glibc glibc-common-2.3.2-5 glibc-2.3.2-5 glibc-devel-2.3.2-5 glibc-kernheaders-2.4-8.10 thanks in advance for the help !! best regards @le

4 5

RE: [U-Boot-Users] compile
by Friedrich, Lars 08 Oct '04

08 Oct '04

> can metrowerks's codewarrior complile the u-boot? > i want to port the u-boot to my arm lpc2210 in linux , but > the board don't give the jtag driver that can write/read > flash in linux ,so i want to complile the u-boot in > codewarrior and write into flash by jtag in windows a) The AXD Debugger is able to load the compiled u-boot loader even if it was not compiled with Metrowerks Codewarrior. Of course, you have to select to load *.* and not *.axf files. So there is no need to compile it under Metrowerks. b) I'm quite sure that gdb can communicate with your JTAG interface, if the AXD debugger can do so. The AXD Debugger uses the Arm/Angel protocol and the gdb can do so, too. If the gdb has ARM support compiled in, it automatically adds the necessary RDI entries for Arm/Angel support via ethernet and serial interface. Therefore you can load u-boot into memory via JTAG, execute it and use u-boot to write to flash. Best regards, Lars Friedrich

1 0

RE: [U-Boot-Users] RTL8139 compilation error
by Santoso, Yusdi 08 Oct '04

08 Oct '04

What value should I put in then? Is this the PCI_IO_BASE? Or 0x0000 ? Hm...I'm not so familiar with PPC, does it have separate IO and Mem instruction like in x86 or the same address as in MC68000? Thanks, Yusdi -----Original Message----- From: wd(a)denx.de [mailto:wd@denx.de] Sent: Friday, October 08, 2004 2:20 AM To: Santoso, Yusdi Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] RTL8139 compilation error In message <16808BEAD68708489AE865F48D8793890301D4(a)AMSE2K02.adaptec.com> you wrote: > > So how do you get this _IO_BASE? Should I define it in the > "include/config/<board>.h" ? Yes. 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 One of the advantages of being a captain is being able to ask for ad- vice without necessarily having to take it. -- Kirk, "Dagger of the Mind", stardate 2715.2

2 1

RE: [U-Boot-Users] compile
by Mészáros Lajos 08 Oct '04

08 Oct '04

> sdusthd2000(a)yahoo.com.cn wrote > can metrowerks's codewarrior complile the u-boot? Yes but it isn't simple task. Nobody in their senses would go about it ... > i want to port the u-boot to my arm lpc2210 in linux , but > the board don't give the jtag driver that can write/read > flash in linux ,so i want to complile the u-boot in > codewarrior and write into flash by jtag in windows Use ELDK to compile then flash the "u-boot.mot" with CW. Ludwig

1 0

[U-Boot-Users] compile
by 吴兵 08 Oct '04

08 Oct '04

hi all can metrowerks's codewarrior complile the u-boot? i want to port the u-boot to my arm lpc2210 in linux , but the board don't give the jtag driver that can write/read flash in linux ,so i want to complile the u-boot in codewarrior and write into flash by jtag in windows

1 0

[U-Boot-Users] *.lds for examples
by Robin Getz 08 Oct '04

08 Oct '04

I noticed there was linker files for the examples directory for two architectures (mips and nios), but was struggling to figure out where the default came from. If I have architecture specific examples, do I need to add lds file for the examples? I was trying to add an example, and was unable to get things to work properly. To start I tried just copying the hello_world.c to a smc91111_eeprom.c, and making what I thought were the correct entries in the examples/Makefile and top level Makefile (for make clean only). However, if smc91111_eeprom and hello_world.c are exactly the same, I end up with different object files, because the entry point is different. The following linker error occurs /home/rgetz/uClinux/toolchainoutput/bin/bfin-elf-ld.real: warning: cannot find entry symbol smc91111_eeprom; defaulting to 00001000 So, where is the entry point set? The actual make looked OK to me (sorry for the long lines): bfin-elf-gcc -O0 -ffixed-P5 -D__KERNEL__ -DTEXT_BASE=0x20000000 -I/home/rgetz/u-boot/u-boot_1.1.1/include -fno-built in -ffreestanding -nostdinc -isystem /home/rgetz/uClinux/toolchainoutput/lib/gcc-lib/bfin-elf/3.3.3/include -pipe -D_ _BLACKFIN__ -mno-underscore -DCONFIG_blackfin -D__blackfin__ -I/home/rgetz/u-boot/u-boot_1.1.1 -Wall -Wstrict-prototyp es -c -o hello_world.o hello_world.c bfin-elf-ld -g -Ttext 0x1000 \ -o hello_world -e hello_world hello_world.o libstubs.a \ -L/home/rgetz/uClinux/toolchainoutput/lib/gcc-lib/bfin-elf/3.3.3 -lgcc bfin-elf-objcopy -O srec hello_world hello_world.srec 2>/dev/null bfin-elf-gcc -O0 -ffixed-P5 -D__KERNEL__ -DTEXT_BASE=0x20000000 -I/home/rgetz/u-boot/u-boot_1.1.1/include -fno-built in -ffreestanding -nostdinc -isystem /home/rgetz/uClinux/toolchainoutput/lib/gcc-lib/bfin-elf/3.3.3/include -pipe -D_ _BLACKFIN__ -mno-underscore -DCONFIG_blackfin -D__blackfin__ -I/home/rgetz/u-boot/u-boot_1.1.1 -Wall -Wstrict-prototyp es -c -o smc91111_eeprom.o smc91111_eeprom.c bfin-elf-ld -g -Ttext 0x1000 \ -o smc91111_eeprom -e smc91111_eeprom smc91111_eeprom.o libstubs.a \ -L/home/rgetz/uClinux/toolchainoutput/lib/gcc-lib/bfin-elf/3.3.3 -lgcc bfin-elf-objcopy -O srec smc91111_eeprom smc91111_eeprom.srec 2>/dev/null bfin-elf-objcopy -O binary hello_world hello_world.bin 2>/dev/null bfin-elf-objcopy -O binary smc91111_eeprom smc91111_eeprom.bin 2>/dev/null Any thoughts? pointers appreciated. Thanks -Robin

2 1

[U-Boot-Users] board/board/flash.c
by Bradley Remedios 08 Oct '04

08 Oct '04

Hello All, If we only have Nand flash on our board, does board/ourboard/flash.c really have to be implemented? Shouldn't it be sufficient to just use cmd_nand.c and env_nand.c? For our configuration, U-Boot will actually come up and running from SDRAM itself as we will be using a Primary Bootloader to load U-Boot from Nand Flash. So the only functionality that we should really need is reading and writing to nand flash for writing downloaded images and booting kernels. Regards, -- Bradley Remedios bremedios(a)gmail.com

2 1

[U-Boot-Users] (no subject)
by Eren Gurses 07 Oct '04

07 Oct '04

Hello, I am new to u-boot, but have experience with high-level programming on Linux desktop. But this is my first time to deal with device drivers and flash programming kind of issues. Please forgive my possible naive questions concerning to low level hardware and kernel concepts... We have sandpoint board with mpc8245 CPU. Our goal is to plug-in and run an ethernet card on the PCI bus(specifically Digital DC2114x ethernet, surely it is supported in u-boot). I have been debugging the u-boot for a while, and I concluded that it may be due to interrupt problems(but I may be totally wrong). And when I saw that interrupt routines in cpu/824x/interrupt.c is not implemented yet, I thought that "Yeahh, I found the problem". Then I saw Mr. Denk's following mail, then I confused about the situation. Does u-boot communicate with any hardware on PCI bus without using interrupts. Is this the common way for u-boot (I mean u-boot ports for different architectures, especially comparing with prort for the mpc824x arch.). By the way, I have to say that leds on the ethernet card did never blink under u-boot. (Obviously it is running/blinking on some other Linux PC's). Does it mean something informative (except that it doesn't work)... I am completely stucked at this point. Any kind of help is very appreciated. Thanks in advance... --Eren In message <001201c362f9$aaf09c60$240110ac@jsbae> you wrote: > > i use mpc824x and U-Boot .. > is there someone who used external interrupt to the mpc824x platform?? > how can i setting EPIC for use external interrupt. U-Boot has little (or no) need for interrupts at all. What exactly are you trying to do? Best regards, Wolfgang Denk

3 2

[U-Boot-Users] [PATCH] initrd on MIPS Au1x00
by Thomas Lange 07 Oct '04

07 Oct '04

* Patch by Thomas Lange 07 Oct 2004: - Use cached initrd sdram address for au1x00 cpu:s Patch makes u-boot work with linux 2.4.25 from AMD/MontaVista for dbau1x00 boards. /Thomas Index: lib_mips/mips_linux.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/lib_mips/mips_linux.c,v retrieving revision 1.4 diff -p -u -r1.4 mips_linux.c --- lib_mips/mips_linux.c 7 Dec 2003 18:32:39 -0000 1.4 +++ lib_mips/mips_linux.c 7 Oct 2004 12:12:59 -0000 @@ -198,7 +198,11 @@ void do_bootm_linux (cmd_tbl_t * cmdtp, linux_env_set ("memsize", env_buf); +#ifdef CONFIG_AU1X00 + sprintf (env_buf, "0x%08X", (uint) initrd_start); +#else sprintf (env_buf, "0x%08X", (uint) UNCACHED_SDRAM (initrd_start)); +#endif linux_env_set ("initrd_start", env_buf); sprintf (env_buf, "0x%X", (uint) (initrd_end - initrd_start));

2 2

[U-Boot-Users] how to run hello_world
by Farrukh Masood 07 Oct '04

07 Oct '04

hello everyone! As described in u-boot readme file, to run hello_world example we have to write "loads", but this command doesnt seem to work with me and give the following msg Unknown command 'loads' - try 'help' and when i give the command go 40004 Hello World! This is a test. following error msg appears ## Starting application at 0x00040004 ... Bus Fault @ 0x00000700, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 03bc3190 Unknown values in msr NIP: 00000700 XER: 00000000 LR: 03FCE234 REGS: 03bc3190 TRAP: 0200 DAR: 03BC3268 MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 03FCE224 03BC3280 8C03115E 00000002 03BC3674 00000010 FFFFFFFE 00000004 GPR08: 00000041 FFF00208 00000000 FFF00211 00000030 00002002 03FF3000 C3FC4000 GPR16: 40022049 20224A10 03402C44 0000D00C 00003002 00000001 00000000 00000001 GPR24: 00000000 03BC3670 00000000 03BC3674 00040004 03BC3760 03FF35B0 00000002 Call backtrace: machine check U-Boot 1.1.2 Version: 120/240804 MPC8250 Reset Status: Check Stop, External Soft, External Hard MPC8250 Clock Configuration - Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq 100-300 - dfbrg 1, corecnf 0x1e, busdf 4, cpmdf 1, plldf 1, pllmf 4 - vco_out 333333330, scc_clk 83333332, brg_clk 20833333 - cpu_clk 233333331, cpm_clk 166666665, bus_clk 66666666 CPU: MPC8250 (HiP4 Rev 14, Mask B.1 4K25A) at 233.333 MHz Board: Marconi PUC I2C: ready DRAM: 64 MB FLASH: 8 MB Regular MDIO/MDC layout Net: FCC1 ETHERNET, FCC3 ETHERNET Enabled autonegotiation for PHY at addr 0 Enabled autonegotiation for PHY at addr 1 Hit any key to stop autoboot: 0 "U-Boot" Please help me in this regard, as it migth be a minor error which i am unable to encounter. I am stuck at this point and cant start to write my own standalone applications. Thanks in advance Kind Regards Chishti __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[U-Boot-Users] DC21124x (PCI)ethernet problem on Sandpoint8245
by Eren Gurses 07 Oct '04

07 Oct '04

Excuse me for my previous "(no subject)" e-mail, it was due to the timeout of our proxy. I forgot to copy paste my Subject, sorry for disturbance... Here is my problem again: Hello, I am new to u-boot, but have experience with high-level programming on Linux desktop. But this is my first time to deal with device drivers and flash programming kind of issues. Please forgive my possible naive questions concerning to low level hardware and kernel concepts... We have sandpoint board with mpc8245 CPU. Our goal is to plug-in and run an ethernet card on the PCI bus(specifically Digital DC2114x ethernet, surely it is supported in u-boot). I have been debugging the u-boot for a while, and I concluded that it may be due to interrupt problems(but I may be totally wrong). And when I saw that interrupt routines in cpu/824x/interrupt.c is not implemented yet, I thought that "Yeahh, I found the problem". Then I saw Mr. Denk's following mail, then I confused about the situation. Does u-boot communicate with any hardware on PCI bus without using interrupts. Is this the common way for u-boot (I mean u-boot ports for different architectures, especially comparing with prort for the mpc824x arch.). By the way, I have to say that leds on the ethernet card did never blink under u-boot. (Obviously it is running/blinking on some other Linux PC's). Does it mean smoething... I am completely stucked at this point. Any kind of help is very appreciated. Thanks in advance... --Eren In message <001201c362f9$aaf09c60$240110ac@jsbae> you wrote: > > i use mpc824x and U-Boot .. > is there someone who used external interrupt to the mpc824x platform?? > how can i setting EPIC for use external interrupt. U-Boot has little (or no) need for interrupts at all. What exactly are you trying to do? Best regards, Wolfgang Denk -- Eren Gurses Researcher, Bilkent University Web : http://www.eee.metu.edu.tr/~gurses Phone : +90-312-2902457 / 139

2 1

[U-Boot-Users] RTL8139 compilation error
by Santoso, Yusdi 07 Oct '04

07 Oct '04

Hi all, I am currently trying to run u-boot on 8241 based board. I am copying my settings from MUSENKI which is also based on 8241. The board has on board Realtek8139 based ethernet port, so I enable CONFIG_RTL8139. But during compilation, the following error occur: rtl8139.c: In function 'rtl8139_probe': rtl8139.c:253: '_IO_BASE' undeclared (first us in the function) ... Basically the out* definitions refused to compile because it is tranlated into _out*( (addr)+_IO_BASE, ... ). So how do you get this _IO_BASE? Should I define it in the "include/config/<board>.h" ? The only other board using RTL8139 is TB0229 but I also can't find _IO_BASE definition anywhere. Thanks, any help is appreciated. Yusdi

3 2

[U-Boot-Users] complile problem
by 吴兵 07 Oct '04

07 Oct '04

hi everyone i have a problem about compliling u-boot my board had not give the tools that can debug by jtag under linux, so i want to compile the u-boot in the ads, i don't know these two compliling tools are compatible . i have no good idea to solve the problem

2 1

RE: [U-Boot-Users] how to run hello_world
by Smith, Craig 07 Oct '04

07 Oct '04

>>As described in u-boot readme file In case you didn't know, the DULG is also a great source of info. http://www.denx.de/twiki/bin/view/DULG/Manual >>to run hello_world example we have to write "loads" >>but this command doesnt seem to work with me and give the following msg >>Unknown command 'loads' - try 'help' Make sure you have CFG_CMD_LOADS (or CONFIG_CMD_DFL) included in the definition of CONFIG_COMMANDS your board's config header file. >>and when i give the command go 40004 Hello World! This is a test. >>following error msg appears >>## Starting application at 0x00040004 ... >>Bus Fault @ 0x00000700, fixup 0x00000000 >>Machine check in kernel mode. This is expected behavior if you haven't loaded the program. Regards, -Craig

1 0

[U-Boot-Users] PCI in U-boot.
by Prathima_Kolar 07 Oct '04

07 Oct '04

Hi all, I have just started to understand the PCI interface in U-boot. I have started by reading pci.c for mpc826x. Could anyone please tell me if that is the right place to begin? Thanks & Warm 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. **************************************************************************

2 1

RE: [U-Boot-Users] FW: [440GX/PCI]
by Barbier, Renaud (GE Infrastructure) 07 Oct '04

07 Oct '04

Actually, this is because the PISE bit is not set in the strap pin register. If you take a look at the code pci_440_init aborts initialization: #if defined (CONFIG_440_GX) mfsdr(sdr_sdstp1,strap); if ( (strap & 0x00010000) == 0 ){ printf("PCI: SDR0_STRP1[PISE] not set.\n"); printf("PCI: Configuration aborted.\n"); return; } I indeed moved the call to pci_target_init at the top and the inbound size attributes get initialized as I need. So maybe this function call needs to be moved before that. Thanks.

1 0

RE: [U-Boot-Users] FW: [440GX/PCI]
by Barbier, Renaud (GE Infrastructure) 07 Oct '04

07 Oct '04

I see in the function pci_440_init that pci_target_init(hose) is called quite late. Would not it be better to call that at the beginning so board that are used in agent mode(arbiter/PISE bit off) can defined their inbound window?

2 1

Re: [U-Boot-Users] U-Boot for IXP425 Little-endian
by Herb Radford 07 Oct '04

07 Oct '04

Thanks, Anders but that's not what I asked. I've looked at that target (it'll probably be my first target to try, I think I have access to one) but I wondered if the work had been done already or was in progress. Is there another target which IXP425 little-endian? Regards, Herb --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.769 / Virus Database: 516 - Release Date: 9/24/2004

1 0

[U-Boot-Users] initrd on MIPS
by Thomas Lange 07 Oct '04

07 Oct '04

I have been testing initrd for my dbAu1000 board. It seems that my kernel ( 2.4.25 ) expects the start address of the initrd to be given as a cached sdram address. If this is true for all mips boards, I will prepare a patch for lib_mips/mips_linux.c Any objections? /T

2 1

[U-Boot-Users] Porting U-boot
by calvin 07 Oct '04

07 Oct '04

I am trying to port U-boot to a board which uses Galileo(GT64120) system controller to access SDRAM. does any of the boards supported by U-boot have a similar interface ? Thanks and Regards, Pooja

1 0

[U-Boot-Users] Debugging in u-boot
by MuthuGanesh M 07 Oct '04

07 Oct '04

Hi , I am working with MPC885 processor. I am using BDI2000 for debugging. I can able to debug u-boot by stepping. Using gdb i loaded new symbol file(in ram address) and i am now in a position to debug in ram. I am having my own commands for my custom board, i want to debug the functions, called by the commands. So if i issue a break point, i cannot break at the function call. Once i give breakpoints, the line number and file names coming in gdb prompt are fine. But it is not hitting the break point. BDI config files are OK. My procedure is as per the manual (DULG/Manual). Can anybody help me in solving this Regards, Muthu ganesh.M

1 0

[U-Boot-Users] sc520 problems with objcopy
by Aras Vaichas 07 Oct '04

07 Oct '04

I've been porting to an sc520 based board and I've had several compiler and linker issues which I think I have solved. The problem now is that objcopy never finishes and uses all available memory. I have to kill the process otherwise it starts to try and use all virtual memory as well. I did a system call trace, and from it you can see that it gets to a point where it is calling brk() and from this it never seems to end. Has anyone else had this problem? Is it a problem caused by linker/compiler settings? Any clues would be appreciated! root@gentoo u-boot-1.1.1 # make ... SNIP ... UNDEF_SYM=`objdump -x lib_generic/libgeneric.a board/sc520_dsb/libsc520_dsb.a cpu/i386/libi386.a lib_i386/libi386.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a |sed -n -e 's/.*$__u_boot_cmd_.*$/-u\1/p'|sort|uniq`;\ ld -Bstatic -T /samba/development/40_Magellan_Standard_Software/MAL/boot/u-boot-1.1.1/board/sc520_dsb/u-boot.lds -Ttext 0x387c0000 $UNDEF_SYM cpu/i386/start.o cpu/i386/start16.o cpu/i386/reset.o \ --start-group lib_generic/libgeneric.a board/sc520_dsb/libsc520_dsb.a cpu/i386/libi386.a lib_i386/libi386.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a net/libnet.a disk/libdisk.artc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a --no-warn-mismatch -L /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4 -lgcc --end-group \ -Map u-boot.map -o u-boot objcopy --gap-fill=0xff -O srec u-boot u-boot.srec ... I press CTRL+C at this point to interrupt, otherwise all my memory gets used. make: *** [u-boot.srec] Interrupt root@gentoo u-boot-1.1.1 # objcopy --version GNU objcopy 2.14.90.0.8 20040114 root@gentoo u-boot-1.1.1 # ll u-boot -rwxrwxr-x 1 root root 594727 Oct 6 12:04 u-boot ... I perform a system call trace here to see what is happening during objcopy root@gentoo u-boot-1.1.1 # strace objcopy --gap-fill=0xff -O srec u-boot u-boot.srec execve("/usr/bin/objcopy", ["objcopy", "--gap-fill=0xff", "-O", "srec", "u-boot", "u-boot.srec"], [/* 52 vars */]) = 0 uname({sys="Linux", node="gentoo", ...}) = 0 brk(0) = 0x808b000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=76539, ...}) = 0 mmap2(NULL, 76539, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/usr/lib/libbfd-2.14.90.0.8.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\370"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=618708, ...}) = 0 mmap2(NULL, 634196, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000 mmap2(0x400b8000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8f) = 0x400b8000 mmap2(0x400bf000, 15700, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400bf000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\34\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=10964, ...}) = 0 mmap2(NULL, 8624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400c3000 mmap2(0x400c5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0x400c5000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1174424, ...}) = 0 mmap2(NULL, 1104676, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400c6000 mmap2(0x401ce000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x107) = 0x401ce000 mmap2(0x401d2000, 6948, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401d2000 close(3) = 0 munmap(0x40015000, 76539) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, "\316\324\316\262", 4) = 4 close(3) = 0 brk(0) = 0x808b000 brk(0x80ac000) = 0x80ac000 brk(0) = 0x80ac000 brk(0) = 0x80ac000 stat64("u-boot", {st_mode=S_IFREG|0775, st_size=594727, ...}) = 0 stat64("u-boot", {st_mode=S_IFREG|0775, st_size=594727, ...}) = 0 open("u-boot", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0775, st_size=594727, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\0|84"..., 4096) = 4096 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 557056, [557056], SEEK_SET) = 0 read(3, "entoo Linux 3.3.4-r1, ssp-3.3.2-"..., 4096) = 4096 _llseek(3, 561152, [561152], SEEK_SET) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\0|84"..., 4096) = 4096 stat64("u-boot.srec", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 open("u-boot.srec", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4 _llseek(3, 557056, [557056], SEEK_SET) = 0 read(3, "entoo Linux 3.3.4-r1, ssp-3.3.2-"..., 4096) = 4096 read(3, "\0\0\0\0\0\0\361\377=\5\0\0 \360\376\377\0\0\0\0\0\0\361"..., 16384) = 16384 read(3, "\n\0\0\0\22\0\1\0\3;\0\0\324\214|8\372\0\0\0\22\0\1\0\v"..., 4096) = 4096 brk(0) = 0x80ac000 brk(0x80db000) = 0x80db000 read(3, "urge_tx_ring\0rx_next\0rx_ring\0tx_"..., 12288) = 12288 read(3, "\0__u_boot_cmd_cp\0strspn\0NetSendP"..., 4096) = 807 _llseek(3, 8192, [8192], SEEK_SET) = 0 read(3, "\270\30\0\0\0\216\340\216\330\216\350\216\300\216\320\275"..., 81920) = 81920 read(3, "\311\351\t\371\377\377\215e\364[^_\311\303U\211\345WVS"..., 4096) = 4096 brk(0) = 0x80db000 brk(0x8103000) = 0x8103000 _llseek(3, 94208, [94208], SEEK_SET) = 0 read(3, "Redirect to \0*** ERROR: `serveri"..., 16384) = 16384 read(3, "h() routine too large (%d) %p - "..., 4096) = 4096 _llseek(3, 114688, [114688], SEEK_SET) = 0 read(3, "\0\0|8\0\0\2008\313\232}8\0\0@\0\223\f\0\0\224\f@\0\314"..., 4096) = 4096 _llseek(3, 4096, [4096], SEEK_SET) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 _llseek(3, 118784, [118784], SEEK_SET) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 _llseek(3, 122880, [122880], SEEK_SET) = 0 read(3, "\272\374\377f\270\313\360\r\200f\357\270\0\337\216\330"..., 4096) = 4096 _llseek(3, 126976, [126976], SEEK_SET) = 0 _llseek(3, 126976, [126976], SEEK_SET) = 0 read(3, "\1\0\0\0\0\0\260\3\\\3\0\0\1\0\0\0d\0\0\0\0\0|8\22\0\0"..., 8192) = 8192 read(3, "\275\1\0\0\0\0\0\0D\0`\1\301\1\0\0\0\0\0\0D\0a\1\304\1"..., 4096) = 4096 read(3, "!\0I\23/\v\0\0\t\17\0\v\vI\23\0\0\n\25\1\1\23\'\f\0\0\v"..., 28672) = 28672 read(3, "8\n\0\0\16\26\0\3\10:\v;\vI\23\0\0\17\23\1\1\23\3\16\v"..., 4096) = 4096 mmap2(NULL, 286720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401d4000 read(3, "Tu\7\0\0\0214\10\0\0\f\n\v1\6\307*\0\0\v!F\4\0\0\2#\0\6"..., 278528) = 278528 read(3, "\207\2\0\0\3#\264\4\5\327O\0\0\2@\207\2\0\0\3#\200\5\005"..., 4096) = 4096 munmap(0x401d4000, 286720) = 0 read(3, "\34V\325)I,V2V\10\36r\253p\234\200\342\343\272\236\3\t"..., 45056) = 45056 read(3, "\270b7;\270\3\274\1c/\3\v\267\3uc\3\f9da\3u9\3\f9:\3\346"..., 4096) = 4096 _llseek(3, 503808, [503808], SEEK_SET) = 0 read(3, "A\16\10\205\2B\r\5 \0\0\0\270\f\0\0\341=|8\227\0\0\0A\16"..., 16384) = 16384 read(3, "\2B\r\5F\203\5\206\4\207\3].\10\0\0\34\0\0\0\264M\0\0\324"..., 4096) = 4096 read(3, "\0__u_boot_cmd_chpart\0\0\0\0\0\256\1\0\0\2\0\331"..., 4096) = 4096 read(3, "\0\0flash_info\0\0\0\0\0p\0\0\0\2\0#>\3\0\207\17\0\0\217"..., 4096) = 4096 read(3, "\0\0p\0\0\0\206\0\0\0\0\0\0\0\0\0\0\0\301\0\0\0\315\0\0"..., 4096) = 4096 read(3, "ArpWaitPacketMAC\0NetOurHostName\0"..., 16384) = 16384 read(3, "pos\0data_in\0rtime_decompress\0com"..., 4096) = 4096 read(3, "entoo Linux 3.3.4-r1, ssp-3.3.2-"..., 4096) = 4096 brk(0) = 0x8103000 brk(0x8125000) = 0x8125000 brk(0) = 0x8125000 brk(0x8147000) = 0x8147000 brk(0) = 0x8147000 ... never ends ... regards, Aras Vaichas

1 1

[U-Boot-Users] (no subject)
by Eren Gurses 06 Oct '04

06 Oct '04

1 0

[U-Boot-Users] Programming 28F640J3 flash on ARM Integrator CP gets timeout
by Shawn 06 Oct '04

06 Oct '04

Hi, I use the ported ARM Integrator CP board and modified the flash part to support the new flash chip Intel StrataFlash 28F640J3. When programming the Flash with a big chunk of data (hundreds of KB or MB), it very often gets timeout. I changed the timeout value to a big numer (10 times of the original value), but it didn't help. I don't see the issue is related to the software. What else will cause this problem? I printed the status when programming or erasing gets timeout. Sometimes it shows low programming voltage detected (SR.3 == 1). Any hints are appreciated. -Shawn.

1 0

[U-Boot-Users] problem with cfi_flash.c & AT91RM9200DK
by Morten 05 Oct '04

05 Oct '04

Hello ! I have exchanged the flash on my AT91RM9200DK with a AT49BV320C cfi flash, and done all needed mods to the config file, every thing seems ok except that it get the size of the flash incorectly. It sayes that it is a 16x16 4m, 71 sector cfi complient flash, when it should be a 2097 x 16, 32m, 71 sector flash ? Anyone have any tips for me on how to fix this ? protect / unprotect seems to work fine, and it even writes without complaining, but nothing actualy gets writen ! Debug: U-Boot 1.1.2 (Oct 4 2004 - 11:17:41) U-Boot code: 21F00000 -> 21F188E4 BSS: -> 21F1CFB4 RAM Configuration: Bank #0: 20000000 32 MB flash detect cfi fwc addr 10000000 cmd ff ff 8bit x 8 bit fwc addr 10000055 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr 10000010 is= ff 51 fwc addr 10000000 cmd ff ffff 16bit x 8 bit fwc addr 100000aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr 10000020 is= 0051 5151 fwc addr 10000000 cmd ff 00ff 16bit x 16 bit fwc addr 100000aa cmd 98 0098 16bit x 16 bit is= cmd 51(Q) addr 10000020 is= 0051 0051 is= cmd 52(R) addr 10000022 is= 0052 0052 is= cmd 59(Y) addr 10000024 is= 0059 0059 ushort addr is at 10000050 info->portwidth = 2 addr[0] = 0x1 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x1 device interface is 1 found port 2 chip 2 port 16 bits chip 16 bits ushort addr is at 10000026 info->portwidth = 2 addr[0] = 0x3 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x3 10000020 : 51 00 52 00 59 00 03 00 00 00 41 00 00 00 00 00 Q.R.Y.....A..... 10000030 : 00 00 00 00 00 00 27 00 36 00 b5 00 c5 00 04 00 ......'.6....... 10000040 : 00 00 0a 00 00 00 03 00 00 00 03 00 00 00 16 00 ................ 10000050 : 01 00 00 00 00 00 00 00 02 00 07 00 00 00 20 00 .............. . 10000060 : 00 00 3e 00 00 00 00 00 01 00 ff ff ff ff ff ff ..>............. 10000070 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 10000080 : ff ff 50 00 52 00 49 00 31 00 30 00 86 00 01 00 ..P.R.I.1.0..... 10000090 : 00 00 00 00 80 00 03 00 03 00 ff ff ff ff ff ff ................ manufacturer is 3 size_ratio 1 port 16 bits chip 16 bits found 2 erase regions long addr is at 1000005a info->portwidth = 2 addr[0] = 0x7 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x20 addr[5] = 0x0 addr[6] = 0x0 addr[7] = 0x0 erase_region_count = 8 erase_region_size = 8192 long addr is at 10000062 info->portwidth = 2 addr[0] = 0x3e addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x0 addr[5] = 0x0 addr[6] = 0x1 addr[7] = 0x0 erase_region_count = 63 erase_region_size = 65536 ushort addr is at 10000054 info->portwidth = 2 addr[0] = 0x0 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x0 fwc addr 10000000 cmd ff 00ff 16bit x 16 bit Flash: 4 MB Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors Erase timeout 8192 ms, write timeout 0 ms, buffer write timeout 1 ms, buffer size 1 Sector Start Addresses: 10000000 (RO) 10002000 (RO) 10004000 (RO) 10006000 (RO) 10008000 (RO) 1000A000 (RO) 1000C000 (RO) 1000E000 (RO) 10010000 (RO) 10020000 (RO) 10030000 (RO) 10040000 (RO) 10050000 (RO) 10060000 (RO) 10070000 (RO) 10080000 (RO) 10090000 (RO) 100A0000 (RO) 100B0000 (RO) 100C0000 (RO) 100D0000 (RO) 100E0000 (RO) 100F0000 (RO) 10100000 (RO) 10110000 (RO) 10120000 (RO) 10130000 (RO) 10140000 (RO) 10150000 (RO) 10160000 (RO) 10170000 (RO) 10180000 (RO) 10190000 (RO) 101A0000 (RO) 101B0000 (RO) 101C0000 (RO) 101D0000 (RO) 101E0000 (RO) 101F0000 (RO) 10200000 (RO) 10210000 (RO) 10220000 (RO) 10230000 (RO) 10240000 (RO) 10250000 (RO) 10260000 (RO) 10270000 (RO) 10280000 (RO) 10290000 (RO) 102A0000 (RO) 102B0000 (RO) 102C0000 (RO) 102D0000 (RO) 102E0000 (RO) 102F0000 (RO) 10300000 (RO) 10310000 (RO) 10320000 (RO) 10330000 (RO) 10340000 (RO) 10350000 (RO) 10360000 (RO) 10370000 (RO) 10380000 (RO) 10390000 (RO) 103A0000 (RO) 103B0000 (RO) 103C0000 (RO) 103D0000 (RO) 103E0000 (RO) 103F0000 (RO) Best Regards Morten

2 3

[U-Boot-Users] Porting U-Boot to an ARM920T-Based Board.
by Rodel Miguel 05 Oct '04

05 Oct '04

Hi, I would like to get some help to port u-boot on a new hardware (the hardware is still under heavy development). I have listed the following issues which I've encountered while reading the README and browsing the source tree. 1. My board has an ARM920T core. Instinctively, I would choose a "template" board support subdirectory that has the same core. If my platform is very different from the template, can I just choose the board that fits my needs (e.g. UART, FLASH, MEMORY MAP, etc.) and just re-configure the core? If this is possible, how do I do this? 2. My UART port is 16550 compliant. The ARM920T core (cpu/arm920T/) is using a serial.c that is compliant to S3C24XX. Can I just simply overwrite cpu/arm920t/serial.c with 16550 compliant serial.c? 3. Can somebody please tell me the files that are most-likely to change when porting u-boot to a new platform? Currently I am modifying the following: board/myboard /* copied from board smdk2410 */ - What should be placed here? Initialization routines? What is the "minimal" requirement for this subdirectory? Makefile - to make our board noticable to the main kernel tree include/configs/myboard.h 4. Are there other important files to modify in order to build the proper u-boot image? Please advise on the stated issues. Thank you very much. Regards, Rodel Miguel

2 1

[U-Boot-Users] fishing for ideas
by Benjamin Collar 05 Oct '04

05 Oct '04

Greetings folks Yesterday's problems have been overcome. Mostly I was just misunderstanding what was going on / what was supposed to be going on. Thanks for the clues overall. But there is a bit more to it. At the end of the day yesterday, I performed exactly the same 'loads' command, with exactly the same srec file, as I had done at the beginning of the day, and it worked. Talk about frustration! Today I was working on it and loaded a linux kernel image. When I 'loads' it, using the u-boot command line, into ram, the 'md' command at the loaded area shows 00010000: 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0 }.Z.9@...L..;... 00010020: 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... 00010030: 00000000 00000000 00000000 00000000 ................ while objdump shows 00000 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., 00010 00000000 00000000 82847f95 05070201 ................ 00020 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... of course, you'll notice immediately that the 5th word is completely bogus, among others. I've spoken with the board developer (who also wrote a bootloader for the board) and showed him the sdram initialization function, and he said it was correct. However, I've got the behavior shown above. Is there another reason why this sort of corruption would happen? (btw, using 'cu' to download the image into RAM). Thanks for any tips Ben -- Benjamin Collar Siemens AG CT SE 2 Embedded Linux 089-636-53711

4 4

RE: [U-Boot-Users] How to compile U-boot using Metrowerks Code warrior on windows.
by VanBaren, Gerald (AGRE) 05 Oct '04

05 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of > Prathima_Kolar > Sent: Tuesday, October 05, 2004 2:15 AM > To: 'u-boot-users(a)lists.sourceforge.net' > Cc: Apoorv_Sangal; Nishant_Galange > Subject: [U-Boot-Users] How to compile U-boot using Metrowerks Code > warrior on windows. > > > Hi all, > > A little bird told me that the u-boot image created by Metrowerks > Codewarrior on windows is a lot smaller than the image > created by the gcc > tool chain. > > I need to verify the accuracy of that statement. So I > installed Codewarrior > on my (ugh) windows partition, but how do I tell Codewarrior > to compile my > u-boot source tree? The "Makefile Importer Wizard" gives a vague error > saying "no target found for Metrowerks EPPC" (or something > like that) when I > point it to the Makefile I got with u-boot. > > I'm completely new to Codewarrior, and reading the docs > didn't help at all. > Can somebody please help me out here? > > Waiting, > Prathima > > Ps. I'm using Codewarrior IDE ver. 5.5.1.1358 How much smaller did the little bird estimate? Unless you are at 101% of your available memory and have no more u-boot commands that you can disable, making u-boot smaller has no benefit. Jerry's Rule: Any memory that is not used by the program is wasted. This little bird says that disabling unnecessary commands is likely to save you more memory than changing compilers and it is much less painful. Building u-boot under Windows is swimming upstream through the rapids. Besides the obvious extra effort it takes, there are a lot of rocks in there. Building under Windows and simultaneously switching to an unfamiliar compiler is trying to swim/jump up a waterfall. I've seen salmon do it, but it is a huge effort and many of them never make it. Bottom line: Tell the little bird to verify the accuracy of his statement on his own (politely, of course, if he is your PHB). 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] Resent: How to compile U-boot using Metrowerks Code warrior on wi ndows.
by Prathima_Kolar 05 Oct '04

05 Oct '04

Hi all, A little bird told me that the u-boot image created by Metrowerks Codewarrior on windows is a lot smaller than the image created by the gcc tool chain. I need to verify the accuracy of that statement. So I installed Codewarrior on my (ugh) windows partition, but how do I tell Codewarrior to compile my u-boot source tree? The "Makefile Importer Wizard" gives a vague error saying "no target found for Metrowerks EPPC" (or something like that) when I point it to the Makefile I got with u-boot. I'm completely new to Codewarrior, and reading the docs didn't help at all. Can somebody please help me out here? Waiting, Prathima Ps. I'm using Codewarrior IDE ver. 5.5.1.1358 ************************************************************************** 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. **************************************************************************

2 1

[U-Boot-Users] Resend:MPC8272 PCI bridge problem?
by Jack Liu 05 Oct '04

05 Oct '04

hi,all Sorry to resend this message here. But I really have a problem using MPC8272 PCI bridge. Currently I am debugging our own board with a MPC8272 and PCI IDE chip (VIA VT6410). However I can not visit the memory of PCI space. In u-boot, When I type "md F40001F0", there is always a program check. My configuration is as follows: * 0x00000000-0x07FFFFFF 128MB SDRAM * 0x80000000-0x9FFFFFFF 512MB outbound prefetchable PCI memory window * 0xA0000000-0xBFFFFFFF 512MB outbound non-prefetchable PCI memory window * 0xF0000000-0xF001FFFF 128KB MPC8272 internal memory * 0xF4000000-0xF7FFFFFF 64MB outbound PCI I/O window * 0xFE000000-0xFFFFFFFF 32MB flash /* PCIBR0 */ #define CFG_PCI_MSTR0_LOCAL 0x80000000 /* Local base */ #define CFG_PCIMSK0_MASK PCIMSK_1GB /* Size of window */ /* PCIBR1 */ #define CFG_PCI_MSTR1_LOCAL 0xF4000000 /* Local base */ #define CFG_PCIMSK1_MASK PCIMSK_64MB /* Size of window */ #define CFG_PCI_MSTR_IO_LOCAL 0xF4000000 /* Local base */ #define CFG_PCI_MSTR_IO_BUS 0xF4000000 /* PCI base */ #define CFG_CPU_PCI_IO_START PCI_MSTR_IO_LOCAL #define CFG_PCI_MSTR_IO_SIZE 0x04000000 /* 64MB */ #define CFG_POCMR2_MASK_ATTRIB (POCMR_MASK_64MB | POCMR_ENABLE | POCMR_PCI_IO) So, I am wondering why the configured PCI space can not be accessed since I have configured the outbound window and PCIBR? In MPC8241, I can access PCI space by "md FE0001F0". Any kind help will be greatly appreciated. Best regard Jack liu

2 1

[U-Boot-Users] How to compile U-boot using Metrowerks Code warrior on windows.
by Prathima_Kolar 05 Oct '04

05 Oct '04

Hi all, A little bird told me that the u-boot image created by Metrowerks Codewarrior on windows is a lot smaller than the image created by the gcc tool chain. I need to verify the accuracy of that statement. So I installed Codewarrior on my (ugh) windows partition, but how do I tell Codewarrior to compile my u-boot source tree? The "Makefile Importer Wizard" gives a vague error saying "no target found for Metrowerks EPPC" (or something like that) when I point it to the Makefile I got with u-boot. I'm completely new to Codewarrior, and reading the docs didn't help at all. Can somebody please help me out here? Waiting, Prathima Ps. I'm using Codewarrior IDE ver. 5.5.1.1358 ************************************************************************** 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. **************************************************************************

2 1

[U-Boot-Users] DB1000 Little-Endian U-Boot
by Charles Eidsness 04 Oct '04

04 Oct '04

Hi All, I would like to use u-boot on my DB1000 card (with an AMD Au1000 processor) in little endian mode. After a little bit of playing around I have gotten it to compile, load in to the parameter FLASH and run from the Yamon prompt, i.e. go bec00000. But, when I switch to boot completely from u-boot in the parameter flash (switch S8) the card just hangs. Does anyone have any ideas? Thanks, Charles

2 1

[U-Boot-Users] Getting Error Relocating the code
by raju rediff 04 Oct '04

04 Oct '04

Hi, We are porting u-boot on our card. We have take SBC board as reference and changed the code from that board's code. In the process, we got stuck-up with a problem of relocating the code. Please see the following dump. We are loading the code through emulator into the ram at address 0x00000000. ====================================================================== U-Boot 1.1.1 (Sep 22 2004 - 13:28:21) MPC8260 Reset Status: External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x1a, busdf 4, cpmdf 1, plldf 1, pllmf 4 - vco_out 330000000, scc_clk 82500000, brg_clk 20625000 - cpu_clk 264000000, cpm_clk 165000000, bus_clk 66000000 CPU: MPC8260 (HiP4 Rev 14, Mask B.1 4K25A) at 264 MHz Board: EST ALI8260 DRAM: Setup 60x SDRAM controller Setup Local SDRAM controller64 MB Bus Fault @ 0x00003388, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 07fb5c58 Unknown values in msr NIP: 00003388 XER: 20000000 LR: 00004A20 REGS: 07fb5c58 TRAP: 0200 DAR: 46498442MSR: 00003000 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00 GPR00: 8408FFFC 07FB5D48 00000000 07FD6000 04000000 FC024000 00000020 03FD6000 GPR08: FFFFFFFC 07FB5D6C 07FD6000 07FB5DB4 00000020 00000000 03FFF000 03FD6000 GPR16: 00000000 00000000 00000000 00000000 0000A920 00000001 00001002 0000E87C GPR24: 00000000 00000000 00000001 07FB5D6C 07FD6000 F0003F80 03FFF0B4 07FB5D48 Call backtrace: machine check ======================================================================= The bus fault location @3388 corresponds to the function "relocate_code" from objdump. The header file of the card is attached to this mail. Please let us know if you can identify any problem with the header file. With Best Regards, Raju

2 1

[U-Boot-Users] cfi_flash.c
by Tolunay Orkun 04 Oct '04

04 Oct '04

We are using this driver with CSB272 and CSB472 (both PPC405 based boards). The driver works OK on CSB272 where flash is setup as 2 side-by- side chips each x16 and accessed via a 32 bit CS. However, on CSB472 we have some apparently minor issue somewhere. The flash is setup as 1 chip of x16 and accessed via a 16 bit chip select. The protect on/off, erase commands work well. cp command also work OK but after the flash write is completed it leaves the flash array in command mode instead of returning to read mode. The workaround for now is to reset the board after programming or issue a protect on/off command. The flash chip is an Intel 28F640 and I've sync to U-Boot CVS last monday. Has anyone seen this problem, made a patch? I've posted about this before a few months ago but there was more pressing issues to deal with. If someone has solved this problem and a patch is in pipeline, I would like to try it otherwise I need to get my hands dirty to find out why the array is left in command mode. Best regards, Tolunay

1 0

[U-Boot-Users] Usb support
by swamy 04 Oct '04

04 Oct '04

Hi, I am interested in knowing any development on bootloader (Uboot) to download kernel using usb port( PXA255) instead of serial or Ethernet? Thanks swamy

1 0

AW: [U-Boot-Users] problem with cfi_flash.c & AT91RM9200DK
by Martin Krause 04 Oct '04

04 Oct '04

Hi Morten, Morten wrotes on Montag, 4. Oktober 2004 12:40: > Hello ! > > I have exchanged the flash on my AT91RM9200DK with a > AT49BV320C cfi flash, > and done all needed mods to the config file, every thing > seems ok except > that it get the size of the flash > incorectly. > > It sayes that it is a 16x16 4m, 71 sector cfi complient > flash, when it > should be a 2097 x 16, 32m, 71 sector flash ? Why should it be 2097 x 16, 32m? The datasheet says the flash is organized 2M x 16. This means 2M (= 2^21 = 2.097.152) Addresses each 16 Bit (= word) wide. And this is a size of 4 MByte. > size_ratio 1 port 16 bits chip 16 bits ... > Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors This means U-Boot has detected a flash that is connected to a 16 bit port (bus) and the flash chip itself has also a 16 bit wide interface. The dirver seems working correctly to me. Regards, Martin

1 0

RE: [U-Boot-Users] Relocate code
by Holger L. Bille 04 Oct '04

04 Oct '04

Hi Raju Sending HTML to this list is inconsiderate. Please don't! > <A target="_blank" HREF="http://clients.rediff.com/signature/track_sig.asp"><IMG SRC="http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbo…" BORDER=0 VSPACE=0 HSPACE=0></a> Sending tracking HTLM is downright rude! Don't do that! Not to this list - don't do it at all! Holger Bille -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net on behalf of raju rediff Sent: Mon 2004-10-04 8:26 To: u-boot-users(a)lists.sourceforge.net Cc: Subject: [U-Boot-Users] Relocate code Hi, Can any of you tell what exactly "relocate_code" function does when a. u-boot code is fused into the prom b. u-boot code is loaded into RAM using emulator It will be grateful if you can tell taking sbc board as reference. With Best Regards, Raju

1 0

[U-Boot-Users] Relocate code
by raju rediff 04 Oct '04

04 Oct '04

Hi, Can any of you tell what exactly "relocate_code" function does when a. u-boot code is fused into the prom b. u-boot code is loaded into RAM using emulator It will be grateful if you can tell taking sbc board as reference. With Best Regards, Raju

1 0

[U-Boot-Users] pagetable / BDI2000 question
by Stuart Yoder 04 Oct '04

04 Oct '04

This is not specifically a u-boot question, but involves some things that knowledgeable u-boot person may have insight into. We are debugging a Linux kernel that has been booted via U-boot on our own custom PowerPC board-- 750GX processor. Early in the Linux kernel initialization our system bridge chip (Marvell 64360 / DiscoveryII) is remapped to a new virtual address (via the ioremap() kernel call). At that point the new virtual address returns bad data. Physical address is: 0xF1000000 Original virtual address: 0xF1000000 Remapped virtual address: 0xEF5F0000 After the remapping occurs the following is true: -programmatic/kernel access to virtual address 0xF1000000 returns good data -programmatic/kernel access to new virtual address 0xEF5F0000 returns bad data -access via the BDI2000 to address 0xF1000000 returns good data -access via the BDI2000 to address 0xEF5F0000 returns _good data_ THIS MAKES NO SENSE. The fact that the BDI2000 can read the data proves that the page table entry is good. Here is the key question: How is it possible that the same location in memory accessed via the BDI2000 and accessed programmatically return DIFFERENT values. This remapped location is not supposed to be cached since it is IO memory. We have the page table / mmu option turned on the BDI config. Also, the Linux kernel has the BDI2000 config option enabled. Stuart

2 1

[U-Boot-Users] [PATCH] Add support for OMAP242x/arm1136 and TI H4 omap242x reference board 2/2.
by Woodruff, Richard 01 Oct '04

01 Oct '04

Hello, This patch adds support for the TI OMAP2420 processor and its reference board the H4. It like other OMAP's it has multiple cores. The ARM core is an ARMv6-ARM1136JF-S. The patch is a bit big, but it mainly is new files, and a couple minor OMAP specific teaks to a few common files. The patch was done against the latest image out on ftp.denx.de (u-boot 1.1.2). I have been using a GCC-3.4.0 tool chain downloadable from Codesourcery to build this. GCC 3.4 is the first version of GCC which has ARMv6 support. Thus this tool chain is required for kernel builds as the v6 kernel makes use of v6 instructions. U-boot could be a bit more flexible, but all my testing so far has been with this version of GCC. The is currently split into two parts. Regards, Richard W.

1 0

[U-Boot-Users] [PATCH] Add support for OMAP242x/arm1136 and TI H4 omap242x reference board 1/2.
by Woodruff, Richard 01 Oct '04

01 Oct '04

Hello, This patch adds support for the TI OMAP2420 processor and its reference board the H4. It like other OMAP's it has multiple cores. The ARM core is an ARMv6-ARM1136JF-S. The patch is a bit big, but it mainly is new files, and a couple minor OMAP specific teaks to a few common files. The patch was done against the latest image out on ftp.denx.de (u-boot 1.1.2). I have been using a GCC-3.4.0 tool chain downloadable from Codesourcery to build this. GCC 3.4 is the first version of GCC which has ARMv6 support. Thus this tool chain is required for kernel builds as the v6 kernel makes use of v6 instructions. U-boot could be a bit more flexible, but all my testing so far has been with this version of GCC. The is currently split into two parts. Regards, Richard W.

1 0

[U-Boot-Users] [PATCH] - fixed missing System ACE CF device
by Sean Chang 01 Oct '04

01 Oct '04

Hi, If there are any problems please let me know and I'll be more than happy to fix it. This patch is applied against the u-boot 1.1.1 release. The CHANGELOG is below. Regards, Sean ======================================================================= CHANGELOG (ace_fat.patch): Patch by Sean Chang, 9 Aug 2004: Fixed missing System ACE CF device during get FAT partition info in fat_register_device function. =======================================================================

3 8

RE: [U-Boot-Users] fishing for ideas
by VanBaren, Gerald (AGRE) 01 Oct '04

01 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Benjamin > Collar > Sent: Friday, October 01, 2004 12:04 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] fishing for ideas > > > Greetings folks > > Yesterday's problems have been overcome. Mostly I was just > misunderstanding what was going on / what was supposed to be going on. > Thanks for the clues overall. > > But there is a bit more to it. At the end of the day yesterday, I > performed exactly the same 'loads' command, with exactly the > same srec > file, as I had done at the beginning of the day, and it worked. Talk > about frustration! > > Today I was working on it and loaded a linux kernel image. When I > 'loads' it, using the u-boot command line, into ram, the 'md' > command at > the loaded area shows > > 00010000: 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., > 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0 }.Z.9@...L..;... > 00010020: 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... > 00010030: 00000000 00000000 00000000 00000000 ................ > > while objdump shows > > 00000 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., > 00010 00000000 00000000 82847f95 05070201 ................ > 00020 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... > > of course, you'll notice immediately that the 5th word is completely > bogus, among others. > > I've spoken with the board developer (who also wrote a bootloader for > the board) and showed him the sdram initialization function, > and he said > it was correct. However, I've got the behavior shown above. Is there > another reason why this sort of corruption would happen? (btw, using > 'cu' to download the image into RAM). > > Thanks for any tips > Ben > > -- > Benjamin Collar > Siemens AG > CT SE 2 > Embedded Linux > 089-636-53711 Just because he said his bootloader works doesn't necessarily mean it really and truly works (I'm a skeptic: my first statement is invariably "show me"). Do you have caching enabled? Did he? Caching enables burst mode which is a well know cause of SDRAM corruption due to what appears to be and is claimed to be working initialization but actually is not correct. Can you create a situation where the same operation works on his bootloader but doesn't work on yours? Can you make his bootloader fail like yours when doing the same or similar operation (not necessarily downloading with cu)? Yours with no answers, just questions... 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