October 2003 - U-Boot

[U-Boot-Users] PQ2VADS (8270) & BDI2000 - III
by Matias Sundman (AL/EAB) 21 Oct '03

21 Oct '03

Hi, I tried to flash the u-boot.bin file to 0xff900000 and 0xff800000 but I cant get anything on the console ... am I missing some steps? I made the following steps: 1. Edited the MPC8260ADS.h file in order to set CFG_PQ2FADS as the target board ... 2. make MPC8260ADS_config 3. make clean 4. make all 5. Flashed area 0xff900000 and restarted the board No output on the console ... 6. Flashed area 0xff800000 and restarted the board No output on the console ... Any ideas? Cheers // Matias =========================================================================== -----Original Message----- From: Matias Sundman (AL/EAB) Sent: den 21 oktober 2003 10:24 To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] PQ2VADS (8270) & BDI2000 - II Hello again, I have now received a BDI2000 from Abatron. There is a configuration file included with the package for my target board, which is - PQ2FADS. U-boot is compiled with the CFG_PQ2FADS define in the MPC8260ADS.h file. Can I use the configuration file as is and burn u-boot.bin to the flash, and after a restart of the board I get a working u-boot automagically? Regards // Matias ------------------------------------------------------------------------- -----Original Message----- From: Chris Simmonds [mailto:chris@2net.co.uk] Sent: den 6 oktober 2003 10:45 To: Matias Sundman (TB/EAB) Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PQ2VADS (8270) & BDI2000 Hi, I am using BDI2000 with an 8270 right now and it works fine. Its just the standard package for ppc 6xx/7xx/82xx/7400/7410. I used the configuration file for the vads8260 and fixed it up for my board (a custom unit). I don't have a config for the pq2vads board I'm afraid. Chris. Matias Sundman (TB/EAB) wrote: >Comrades, >I have compiled uboot for the PQ2VADS Motorola >evaluation board and tried to flash it with a >JTAG probe from GreenHills. Unfortunately their >probe does not support the 8270 architecture today. > >Does BDI2000 support the ppc8270 JTAG chain architecture? > >If so , does someone have a configuration file for the >PQ2VADS Motorola evaluation board? > >Best Regards // Matias > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >U-Boot-Users mailing list >U-Boot-Users(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/u-boot-users > -- Chris Simmonds 2net Limited chris(a)2net.co.uk http://www.2net.co.uk/ Tel: +44 (0)1962 869003 Fax: +44 (0)870 056 7556 "If it's not connected, it's not effective"(tm) ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] I have a mistake on making u-boot-0.4.0
by Dannel_Zhang 21 Oct '03

21 Oct '03

Hi all, I am working intel xscale pxa255 based board. I have a mistake on makeing u-boot-0.4.0,The erro information message as follow. who would please give me some ideas please? pt/u-boot/tools' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/tools' make[1]: Entering directory `/opt/u-boot/lib_generic' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/lib_generic' make[1]: Entering directory `/opt/u-boot/lib_arm' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/lib_arm' make[1]: Entering directory `/opt/u-boot/cpu/pxa' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/cpu/pxa' make[1]: Entering directory `/opt/u-boot/board/lubbock' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/board/lubbock' make[1]: Entering directory `/opt/u-boot/common' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/common' make[1]: Entering directory `/opt/u-boot/disk' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/disk' make[1]: Entering directory `/opt/u-boot/fs' make[2]: Entering directory `/opt/u-boot/fs/jffs2' make[2]: `.depend' is up to date. make[2]: Leaving directory `/opt/u-boot/fs/jffs2' make[2]: Entering directory `/opt/u-boot/fs/fdos' make[2]: `.depend' is up to date. make[2]: Leaving directory `/opt/u-boot/fs/fdos' make[2]: Entering directory `/opt/u-boot/fs/fat' make[2]: `.depend' is up to date. make[2]: Leaving directory `/opt/u-boot/fs/fat' make[1]: Leaving directory `/opt/u-boot/fs' make[1]: Entering directory `/opt/u-boot/net' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/net' make[1]: Entering directory `/opt/u-boot/rtc' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/rtc' make[1]: Entering directory `/opt/u-boot/dtt' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/dtt' make[1]: Entering directory `/opt/u-boot/drivers' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/drivers' make[1]: Entering directory `/opt/u-boot/post' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/post' make[1]: Entering directory `/opt/u-boot/post/cpu' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/post/cpu' make[1]: Entering directory `/opt/u-boot/examples' make[1]: `.depend' is up to date. make[1]: Leaving directory `/opt/u-boot/examples' make[1]: Entering directory `/opt/u-boot/tools' gcc -g -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xa3000000 -DUSE_HOSTCC -O -c envcrc.c gcc -g -I../include -I.. -DTEXT_BASE=0xa3000000 -DUSE_HOSTCC -c environment.c gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xa3000000 -DUSE_HOSTCC -O -o envcrc envcrc.o crc32.o environment.o make[2]: Entering directory `/opt/u-boot/tools/gdb' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/opt/u-boot/tools/gdb' make[1]: Leaving directory `/opt/u-boot/tools' make[1]: Entering directory `/opt/u-boot/lib_generic' arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-loa d-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3000000 -I/opt/u-boot/include - fno-builtin -nostdinc -isystem /opt/xscale/bin/../lib/gcc-lib/arm-linux/3.2.1/in clude -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -mtune=strongarm1100 -Wall -Wstrict-prototypes -c -o crc32.o crc32.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-loa d-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3000000 -I/opt/u-boot/include - fno-builtin -nostdinc -isystem /opt/xscale/bin/../lib/gcc-lib/arm-linux/3.2.1/in clude -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -mtune=strongarm1100 -Wall -Wstrict-prototypes -c -o display_options.o display_options.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-loa d-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3000000 -I/opt/u-boot/include - fno-builtin -nostdinc -isystem /opt/xscale/bin/../lib/gcc-lib/arm-linux/3.2.1/in clude -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -mtune=strongarm1100 -Wall -Wstrict-prototypes -c -o vsprintf.o vsprintf.c arm-linux-ar crv libgeneric.a crc32.o ctype.o display_options.o ldiv.o string.o vsprintf.o zlib.o r - crc32.o r - ctype.o r - display_options.o r - ldiv.o r - string.o r - vsprintf.o r - zlib.o make[1]: Leaving directory `/opt/u-boot/lib_generic' make[1]: Entering directory `/opt/u-boot/lib_arm' arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-loa d-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3000000 -I/opt/u-boot/include - fno-builtin -nostdinc -isystem /opt/xscale/bin/../lib/gcc-lib/arm-linux/3.2.1/in clude -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -mtune=strongarm1100 -Wall -Wstrict-prototypes -c -o armlinux.o armlinux.c arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-loa d-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3000000 -I/opt/u-boot/include - fno-builtin -nostdinc -isystem /opt/xscale/bin/../lib/gcc-lib/arm-linux/3.2.1/in clude -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -mtune=strongarm1100 -Wall -Wstrict-prototypes -c -o board.o board.c arm-linux-ar crv libarm.a _udivsi3.o _umodsi3.o armlinux.o board.o cache.o div0. o r - _udivsi3.o r - _umodsi3.o r - armlinux.o r - board.o r - cache.o r - div0.o make[1]: Leaving directory `/opt/u-boot/lib_arm' make[1]: Entering directory `/opt/u-boot/cpu/pxa' arm-linux-gcc -Wa,-gstabs -D__ASSEMBLY__ -g -Os -fno-strict-aliasing -fno-co mmon -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3000 000 -I/opt/u-boot/include -fno-builtin -nostdinc -isystem /opt/xscale/bin/../lib /gcc-lib/arm-linux/3.2.1/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march= armv4 -mtune=strongarm1100 -c -o start.o /opt/u-boot/cpu/pxa/start.S /opt/u-boot/cpu/pxa/start.S: Assembler messages: /opt/u-boot/cpu/pxa/start.S:145: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:146: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:160: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:167: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:169: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:381: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:382: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:387: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:388: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:393: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:394: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:399: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:400: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:405: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:406: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:429: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:430: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:435: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up /opt/u-boot/cpu/pxa/start.S:436: Error: internal_relocation (type: OFFSET_IMM) n ot fixed up make[1]: *** [start.o] Error 1 make[1]: Leaving directory `/opt/u-boot/cpu/pxa' make: *** [subdirs] Error 1 Thanks & Regards, Dannel Zhang

1 0

[U-Boot-Users] Maintainer of AT91RM9200DK???
by Steven Scholz 21 Oct '03

21 Oct '03

Hi there, who considers himself as the U-Boot maintainer of the AT91RM9200 cpu and the AT91RM9200DK eval board? Rick, is that you? I just porting U-Boot to our AT91RM9200 based board and it migth be necessary to change some code in the AT91RM9200 relevant stuff. So I am looking for people to talk to before that. Thanks a million. Steven

4 6

[U-Boot-Users] PQ2VADS (8270) & BDI2000 - II
by Matias Sundman (AL/EAB) 21 Oct '03

21 Oct '03

Hello again, I have now received a BDI2000 from Abatron. There is a configuration file included with the package for my target board, which is - PQ2FADS. U-boot is compiled with the CFG_PQ2FADS define in the MPC8260ADS.h file. Can I use the configuration file as is and burn u-boot.bin to the flash, and after a restart of the board I get a working u-boot automagically? Regards // Matias ------------------------------------------------------------------------- -----Original Message----- From: Chris Simmonds [mailto:chris@2net.co.uk] Sent: den 6 oktober 2003 10:45 To: Matias Sundman (TB/EAB) Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PQ2VADS (8270) & BDI2000 Hi, I am using BDI2000 with an 8270 right now and it works fine. Its just the standard package for ppc 6xx/7xx/82xx/7400/7410. I used the configuration file for the vads8260 and fixed it up for my board (a custom unit). I don't have a config for the pq2vads board I'm afraid. Chris. Matias Sundman (TB/EAB) wrote: >Comrades, >I have compiled uboot for the PQ2VADS Motorola >evaluation board and tried to flash it with a >JTAG probe from GreenHills. Unfortunately their >probe does not support the 8270 architecture today. > >Does BDI2000 support the ppc8270 JTAG chain architecture? > >If so , does someone have a configuration file for the >PQ2VADS Motorola evaluation board? > >Best Regards // Matias > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >U-Boot-Users mailing list >U-Boot-Users(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/u-boot-users > -- Chris Simmonds 2net Limited chris(a)2net.co.uk http://www.2net.co.uk/ Tel: +44 (0)1962 869003 Fax: +44 (0)870 056 7556 "If it's not connected, it's not effective"(tm)

1 0

[U-Boot-Users] not booting
by Rakesh jagota 21 Oct '03

21 Oct '03

Hi all, I am working on mpc8245 based board. I have compiled the ppcboot with 64MB ram and its working fine and linux is ported successfully. But when I have configured the RAM to 128MB in ppcboot, I am getting the boot prompt and while loading linux its crashing . What can be the reason? Thanks & Regards, rakesh

2 1

[U-Boot-Users] Enhanced SDRAM tests with u-boot
by Thomas Schäfer 21 Oct '03

21 Oct '03

Hi all, I have problems with the Bringup of a custom MPC8280 board and I assume that SDRAM could be the reason. When performing memory tests on the complete SDRAM with the test routines included with u-boot 0.4.5, everything is working fine. Also, u-boot is running without problems. But when booting a (known to work) linux kernel (2.4.18, MontaVista 3.0), I get exceptions after decompressing the kernel (alignment, 0x600) and when executing the initial scripts (program, 0x700). So I would like to perform more sophisticated SDRAM tests with u-boot, including burst tests. Is there anybody who has done this before? Any hints are appreciated. Best regards Thomas Schäfer ____________________________________ GIGA STREAM GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

2 1

RE: [U-Boot-Users] Any *urgent* bug fixes pending?
by Woodruff, Richard 21 Oct '03

21 Oct '03

Wolfgang, Should I wait before sending in device chaining again? There are several other patches, but I haven't had the time to clean them enough to get beyond the entrance threshold. -- the effect useful -- omap_toto # coninfo List of available devices: lcd 00000002 ..O stdout stderr keypad 00000001 .I. stdin touch 00000001 .I. stdin serial 80000003 SIO stdin stdout stderr Regards, Richard W. -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: Monday, October 20, 2003 8:07 AM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] Any *urgent* bug fixes pending? Hi everybody, getting closer to a 1.0.0 release I would like to verify that there are no _urgent_ bug fixes left. Can you please verify that I checked in all _urgent_ patches / bug fixes sent to me, or that I acknowledged that I will postpone the modifications until after 1.0.0? 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 "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] MPC8270 Custom Board: Stack Pointer Corruption
by mss59＠att.net 20 Oct '03

20 Oct '03

I am working on an MPC8270 based custom board. u-boot is ported from EP8260 board version. RAM is 128M, flash is 16M. After u-boot relocates code in the ram, sometimes, stack pointer gets corrupted. And sometimes, I get bus fault which overwirtes all u-boot area in the RAM with some pattern like this bus fault 07f6bcd0 : 02001111 07f6be18 07f6bc68 11111111 ...........h.... 07f6bce0 : 42757320 4661756c 74204020 30782020 Bus Fault @ 0x 07f6bcf0 : 20202020 20202020 20202020 20202020 07f6bd00 : 20202020 20202020 20202020 20202020 07f6bd10 : 20202020 20202020 20202020 20202020 07f6bd20 : 20202020 20202020 20202020 20202020 07f6bd30 : 20202020 20202020 20202020 20202020 07f6bd40 : 20202020 20202020 20202020 20202020 07f6bd50 : 20202020 20202020 20202020 20202020 07f6bd60 : 20202020 20202020 20202020 20202020 07f6bd70 : 20202020 20202020 20202020 20202020 07f6bd80 : 20202020 20202020 20202020 20202020 07f6bd90 : 20202020 20202020 20202020 20202020 07f6bda0 : 20202020 20202020 20202020 20202020 07f6bdb0 : 20202020 20202020 20202020 20202020 07f6bdc0 : 20202020 20202020 20202020 20202020 ---> This patters is written till the end of ram. BDImn8270>rd GPR00: 00000000 07f6bbd0 ffdfffff 08000004 GPR04: 00000000 00000010 07f58a9d 00000007 GPR08: 00000001 00000000 00000000 00000007 GPR12: 00000020 00400000 07ffd000 080cc000 GPR16: fffdffff bffdffff ff7fffff fff7ef5f GPR20: 48000002 07f6bad0 00000000 07fcf098 GPR24: 07f6bce0 00000001 07fecdbc 07f6bfb4 GPR28: 07f6bcee 07f6bf70 07ffdcb8 07ff2ed8 CR : 48000002 MSR: 00000000 Any ideas..... Thanks Ravi.

2 1

[U-Boot-Users] 859/866 clock issues
by Nye Liu 20 Oct '03

20 Oct '03

two minor things on the 859/866 1) measure_gclk() is very inaccurate. Better to use the plprcr and CFG_8XX_XIN (which MUST BE 10MHz for that cpu) to derive the "real" bus clock. 2) the 859/866 does NOT support external speeds higher than 66MHz, so if cpu_clk is greater, EBDF01 MUST BE USED IN CFG_SCCR I have a patch for 1, but i no longer have my 859/866 eval board I have no patch for 2, but eventually we should come up with some sort of solution; the 859/866 is almost always configured to run faster than 66MHz. -- Nye Liu nliu(a)mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

3 3

[U-Boot-Users] Stack Pointer Problem: MPC8270 Custom Board
by mss59＠att.net 20 Oct '03

20 Oct '03

I am working on an MPC8270 based custom board. u-boot is ported from EP8260 board version. RAM is 128M, flash is 16M. After u-boot relocates code in the ram, sometimes, stack pointer gets corrupted. And sometimes, I get bus fault which overwirtes all u-boot area in the RAM with some pattern like this bus fault 07f6bcd0 : 02001111 07f6be18 07f6bc68 11111111 ...........h.... 07f6bce0 : 42757320 4661756c 74204020 30782020 Bus Fault @ 0x 07f6bcf0 : 20202020 20202020 20202020 20202020 07f6bd00 : 20202020 20202020 20202020 20202020 07f6bd10 : 20202020 20202020 20202020 20202020 07f6bd20 : 20202020 20202020 20202020 20202020 07f6bd30 : 20202020 20202020 20202020 20202020 07f6bd40 : 20202020 20202020 20202020 20202020 07f6bd50 : 20202020 20202020 20202020 20202020 07f6bd60 : 20202020 20202020 20202020 20202020 07f6bd70 : 20202020 20202020 20202020 20202020 07f6bd80 : 20202020 20202020 20202020 20202020 07f6bd90 : 20202020 20202020 20202020 20202020 07f6bda0 : 20202020 20202020 20202020 20202020 07f6bdb0 : 20202020 20202020 20202020 20202020 07f6bdc0 : 20202020 20202020 20202020 20202020 ---> This patters is written till the end of ram. BDImn8270>rd GPR00: 00000000 07f6bbd0 ffdfffff 08000004 GPR04: 00000000 00000010 07f58a9d 00000007 GPR08: 00000001 00000000 00000000 00000007 GPR12: 00000020 00400000 07ffd000 080cc000 GPR16: fffdffff bffdffff ff7fffff fff7ef5f GPR20: 48000002 07f6bad0 00000000 07fcf098 GPR24: 07f6bce0 00000001 07fecdbc 07f6bfb4 GPR28: 07f6bcee 07f6bf70 07ffdcb8 07ff2ed8 CR : 48000002 MSR: 00000000 Any ideas..... Thanks Ravi.

2 1

[U-Boot-Users] Any *urgent* bug fixes pending?
by Wolfgang Denk 20 Oct '03

20 Oct '03

Hi everybody, getting closer to a 1.0.0 release I would like to verify that there are no _urgent_ bug fixes left. Can you please verify that I checked in all _urgent_ patches / bug fixes sent to me, or that I acknowledged that I will postpone the modifications until after 1.0.0? 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 "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid

2 2

[U-Boot-Users] Bug in at91rm9200_ether.c
by Steven Scholz 20 Oct '03

20 Oct '03

Hi there, I think there's terrible bug in the U-Boot ethernet driver for AT91RM9200 cpus. The function at91rm9200_EmacWritePhy() does not write the correct data. Attached patch fixes that. Thanks, -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland fon: +49 30 467090-0 Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 + diff -u ./cpu/at91rm9200/at91rm9200_ether.c.orig ./cpu/at91rm9200/at91rm9200_ether.c --- ./cpu/at91rm9200/at91rm9200_ether.c.orig Sat Oct 18 18:14:46 2003 +++ ./cpu/at91rm9200/at91rm9200_ether.c Sat Oct 18 18:15:33 2003 @@ -341,7 +341,8 @@ { p_mac->EMAC_MAN = (AT91C_EMAC_HIGH & ~AT91C_EMAC_LOW) | AT91C_EMAC_CODE_802_3 | AT91C_EMAC_RW_W | - (RegisterAddress << 18); + (RegisterAddress << 18) | + (*pOutput); udelay (10000);

2 1

[U-Boot-Users] PATCH, mpc8xx - typo in mpc8xx.h
by Nye Liu 20 Oct '03

20 Oct '03

Wolfgang, there is a minor typo in mpc8xx.h Index: mpc8xx.h =================================================================== RCS file: /home/cvs/u-boot-mrv/include/mpc8xx.h,v retrieving revision 1.1.1.4 retrieving revision 1.5 diff -u -r1.1.1.4 -r1.5 --- mpc8xx.h 19 Sep 2003 23:43:28 -0000 1.1.1.4 +++ mpc8xx.h 18 Oct 2003 00:16:44 -0000 1.5 @@ -138,7 +138,7 @@ #define PLPRCR_MF_MSK 0xffff001e /* Multiplication factor + PDF bits */ #define PLPRCR_MFN_MSK 0xf8000000 /* Multiplication factor numerator bits */ #define PLPRCR_MFN_SHIFT 0x0000001b /* Multiplication factor numerator shift*/ -#define PLPRCR_MFD_MSK 0x03c00000 /* Multiplication factor denominator bits */ +#define PLPRCR_MFD_MSK 0x07c00000 /* Multiplication factor denominator bits */ #define PLPRCR_MFD_SHIFT 0x00000017 /* Multiplication factor denominator shift*/ #define PLPRCR_S_MSK 0x00300000 /* Multiplication factor integer bits */ #define PLPRCR_S_SHIFT 0x00000014 /* Multiplication factor integer shift */ -- Nye Liu nliu(a)mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

2 1

[U-Boot-Users] cpu/arm925 timer fixes.
by Woodruff, Richard 20 Oct '03

20 Oct '03

Hello, This patch fixes a few bugs which made udelay() not work properly on 925 based systems. A while back when I increased my boards clock speed I ran into quite a few problems which resulted in these fixes. I think the Innovator should be switched over to use a real udelay code instead of its busy spins. They do not scale at all with clock speed, and do not keep the useful timestamp properly updating. Regards, Richard W.

2 1

[U-Boot-Users] Patch: Nios dk1c20 network support
by Scott McNutt 20 Oct '03

20 Oct '03

This patch adds networking support for the Altera Nios Development Kit, Cyclone Edition (DK-1C20). Regards, --Scott McNutt <<nios-net.diff>> begin 600 nios-net.diff M9&EF9B`M3F%U<F(@=2UB;V]T+3(P,#,M3V-T+3$U+6]R:6<O9&]C+U)%041- M12YD:S%C,C`@=2UB;V]T+3(P,#,M3V-T+3$U+6YE=R]D;V,O4D5!1$U%+F1K M,6,R,`HM+2T@=2UB;V]T+3(P,#,M3V-T+3$U+6]R:6<O9&]C+U)%041-12YD M:S%C,C`),C`P,RTQ,"TQ-2`R,CHR,SHS-2XP,#`P,#`P,#`@+3`T,#`**RLK M('4M8F]O="TR,#`S+4]C="TQ-2UN97<O9&]C+U)%041-12YD:S%C,C`),C`P M,RTQ,"TQ-2`R,CHU-SHT,"XP,#`P,#`P,#`@+3`T,#`*0$`@+3(L-R`K,BPW M($!`"B`)"0D@3FEO<R!$979E;&]P;65N="!+:70*(`D)"2`@($-Y8VQO;F4@ M161I=&EO;G,*(`HM"0D@("`@3&%S="!5<&1A=&4Z($]C=&]B97(@-"P@,C`P M,PHK"0D@("`@3&%S="!5<&1A=&4Z($]C=&]B97(@,34L(#(P,#,*(#T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]"B`*(%1H:7,@9FEL92!C;VYT86EN<R!I;F9O M<FUA=&EO;B!R96=A<F1I;F<@52U";V]T(&%N9"!T:&4@06QT97)A"D!`("TS M-"PW("LS-"PQ,"!`0`H@4')O9W)A;6UI;F<@52U";V]T(&EN=&\@1DQ!4T@@ M=VET:"!'15)-4PH@+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2T*(%1H92!C=7)R96YT('9E<G-I;VX@;V8@=&AE($1++3%#,C`@ M<&]R="!O8V-U<&EE<R!L97-S('1H86X*+38P($M">71E+B!3;R!E=F5R>71H M:6YG('=I;&P@9FET(&EN=&\@82!S:6YG;&4@1FQA<V@@<V5C=&]R+@HK-C`@ M2T)Y=&4@=VET:"!N971W;W)K('-U<'!O<G0@9&ES86)L960N(%-O(&5V97)Y M=&AI;F<@=VEL;"!F:70**VEN=&\@82!S:6YG;&4@9FQA<V@@<V5C=&]R+B!7 M:71H(&YE='=O<FL@<W5P<&]R="`H92YG+B!B;V]T<"P**W1F='!B;V]T+"!P M:6YG+"!E=&,I('1H92!F;&%S:"!F;V]T<')I;G0@:7,@86)O=70@-S=++@HK M"B!4;R!P<F]G<F%M(%4M0F]O="!I;G1O('1H92!$2RTQ0S(P(&9L87-H('5S M:6YG($=%4DU3(&1O('1H90H@9F]L;&]W:6YG.@H@"F1I9F8@+4YA=7)B('4M M8F]O="TR,#`S+4]C="TQ-2UO<FEG+V1O8R]214%$344N;FEO<R!U+6)O;W0M M,C`P,RU/8W0M,34M;F5W+V1O8R]214%$344N;FEO<PHM+2T@=2UB;V]T+3(P M,#,M3V-T+3$U+6]R:6<O9&]C+U)%041-12YN:6]S"3(P,#,M,3`M,34@,C(Z M,C,Z,S4N,#`P,#`P,#`P("TP-#`P"BLK*R!U+6)O;W0M,C`P,RU/8W0M,34M M;F5W+V1O8R]214%$344N;FEO<PDR,#`S+3$P+3$U(#(R.C4Y.C,U+C`P,#`P M,#`P,"`M,#0P,`I`0"`M,2PW("LQ+#<@0$`*(`H@"0D)("`@52U";V]T(&9O M<B!.:6]S+3,R"B`*+0D)("`@($QA<W0(a)57!D871E.B!/8W1O8F5R(#0L(#(P M,#,**PD)("`@($QA<W0(a)57!D871E.B!/8W1O8F5R(#$U+"`R,#`S"B`]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/0H@"B!4:&ES(&9I;&4@8V]N=&%I;G,@:6YF M;W)M871I;VX@<F5G87)D:6YG(%4M0F]O="!A;F0@=&AE($%L=&5R80I`0"`M M,3<T+#@@*S$W-"PV($!`"B!4:&5R92!A<F4@<&QE;G1Y(&]F(&%R96%S('=H M97)E(&AE;'`@:7,@;F5E9&5D+B!(97)E)W,@87)E('-O;64@:61E87,*(&9O M<B!T:&]S92!I;G1E<F5S=&5D(&EN(&-O;G1R:6)U=&EN9SH*(`HM+5--0R`Y M,4,Q,3$@<W5P<&]R="X@12YG+B!A9&0@:6X@=&9T<&)O;W0L(&5T8RX*+0H@ M+4-O;7!A8W1&;&%S:"X@4&]R="`F('1E<W0@0T8O1D%4+@H@"B`M05--22!S M=7!P;W)T+B!5<V4@05--22!F;W(@96YV:7)O;FUE;G0L(&5T8RX*9&EF9B`M M3F%U<F(@=2UB;V]T+3(P,#,M3V-T+3$U+6]R:6<O9')I=F5R<R]S;6,Y,3$Q M,2YH('4M8F]O="TR,#`S+4]C="TQ-2UN97<O9')I=F5R<R]S;6,Y,3$Q,2YH M"BTM+2!U+6)O;W0M,C`P,RU/8W0M,34M;W)I9R]D<FEV97)S+W-M8SDQ,3$Q M+F@),C`P,RTQ,"TQ-2`R,CHR,SHS-RXP,#`P,#`P,#`@+3`T,#`**RLK('4M M8F]O="TR,#`S+4]C="TQ-2UN97<O9')I=F5R<R]S;6,Y,3$Q,2YH"3(P,#,M M,3`M,34@,C(Z-3`Z,C8N,#`P,#`P,#`P("TP-#`P"D!`("TQ-S@L-B`K,3<X M+#,Q($!`"B`)"0D)?2D*("-E;F1I9@H@"BLC:68@9&5F:6YE9"A#3TY&24=? M4TU#7U5315\S,E]"250I"BL**R-D969I;F4)4TU#7VEN;"AR*2`)*"HH*'9O M;&%T:6QE(&1W;W)D("HI*%--0U]"05-%7T%$1%)%4U,K*'(I*2DI"BL**R-D M969I;F4@4TU#7VEN<VPH<BQB+&PI(`DH>PEI;G0@7U]I(#L@(%P**PD)"0D) M9'=O<F0@*E]?8C([("!<"BL)"0D@("`@"0E?7V(R(#T@*&1W;W)D("HI(&([ M("!<"BL)"0D@("`@"0EF;W(@*%]?:2`](#`[(%]?:2`\(&P[(%]?:2LK*2![ M("!<"BL)"0D)"2`@*BA?7V(R("L@7U]I*2`](%--0U]I;FPH<BD[("!<"BL) M"0D)"2`@4TU#7VEN;"@P*3L@(%P**PD)"0D)?3L@(%P**PD)"0E]*0HK"BLC M9&5F:6YE"5--0U]O=71L*&0L<BD)*"HH*'9O;&%T:6QE(&1W;W)D("HI*%-- M0U]"05-%7T%$1%)%4U,K*'(I*2D@/2!D*0HK"BLC9&5F:6YE(%--0U]O=71S M;"AR+&(L;"D)*'L):6YT(%]?:3L@7`HK"0D)"0ED=V]R9"`J7U]B,CL@7`HK M"0D)"0E?7V(R(#T@*&1W;W)D("HI(&([(%P**PD)"0D)9F]R("A?7VD@/2`P M.R!?7VD@/"!L.R!?7VDK*RD@>R!<"BL)"0D)"2`@("!334-?;W5T;"@@*BA? M7V(R("L@7U]I*2P@<BD[(%P**PD)"0D)?2!<"BL)"0D)?2D**PHK(V5N9&EF M("\J($-/3D9)1U]334-?55-%7S,R7T))5"`J+PHK"B`C96YD:68*(`H@+RHM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2T*9&EF9B`M3F%U<F(@=2UB;V]T+3(P,#,M3V-T M+3$U+6]R:6<O:6YC;'5D92]C;VYF:6=S+T1+,4,R,"YH('4M8F]O="TR,#`S M+4]C="TQ-2UN97<O:6YC;'5D92]C;VYF:6=S+T1+,4,R,"YH"BTM+2!U+6)O M;W0M,C`P,RU/8W0M,34M;W)I9R]I;F-L=61E+V-O;F9I9W,O1$LQ0S(P+F@) M,C`P,RTQ,"TQ-2`R,CHR,SHT,BXP,#`P,#`P,#`@+3`T,#`**RLK('4M8F]O M="TR,#`S+4]C="TQ-2UN97<O:6YC;'5D92]C;VYF:6=S+T1+,4,R,"YH"3(P M,#,M,3`M,34@,C(Z-3,Z-#@N,#`P,#`P,#`P("TP-#`P"D!`("TY-BPQ,B`K M.38L,3`@0$`*("\J+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM"B`@*B!% M=&AE<FYE="`M+2!N965D<R!W;W)K(0H@("HM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM*B\*+2-I9B`P"B`C9&5F:6YE($-/3D9)1U]$4DE615)?4TU#.3$Q M,3$)"0DO*B!5<VEN9R!334,Y,6,Q,3$)*B\*+2-D969I;F4(a)0T].1DE'7U-- M0SDQ,3$Q7T)!4T4),'@P,#DQ,#`P,`DO*B!"87-E(&%D9')E<W,)"2HO"BTC M=6YD968@($-/3D9)1U]334,Y,3$Q,5]%6%1?4$A9"0D)+RH@3F\@97AT97)N M86P@4$A9"2HO"BTC9&5F:6YE($-/3D9)1U]334-?55-%7S,R7T))5`DQ"0DO M*B`S,BUB:70@:2]F"0DJ+PHM(V5N9&EF"BLC9&5F:6YE($-/3D9)1U]334,Y M,3$Q,5]"05-%"3!X,#`Y,3`S,#`)+RH@0F%S92!A9&1R97-S"0DJ+PHK(W5N M9&5F("!#3TY&24=?4TU#.3$Q,3%?15A47U!(60D)"2\J($EN=&5R;F%L(%!( M60D)*B\**R-D969I;F4(a)0T].1DE'7U--0U]54T5?,S)?0DE4"0D)+RH@,S(M M8FET(&1A=&$@<F0O=W()*B\*(`H@(V1E9FEN92!#3TY&24=?151(041$4@D) M,#@Z,#`Z,V4Z,C8Z,&$Z-6(*("-D969I;F4(a)0T].1DE'7TY%5$U!4TL)"3(U M-2XR-34N,C4U+C`*0$`@+3$S,2PW("LQ,CDL-B!`0`H@"0D)"2!#1D=?0TU$ M7TI&1E,R"7P@7`H@"0D)"2!#1D=?0TU$7TM'1$()?"!<"B`)"0D)($-&1U]# M341?3D%.1`E\(%P*+0D)"0D@0T9'7T--1%].150)?"!<"B`)"0D)($-&1U]# M341?34U#"7P@7`H@"0D)"2!#1D=?0TU$7TU)20E\(%P*(`D)"0D@0T9'7T-- M1%]00TD)?"!<"F1I9F8@+4YA=7)B('4M8F]O="TR,#`S+4]C="TQ-2UO<FEG M+VQI8E]N:6]S+V)O87)D+F,@=2UB;V]T+3(P,#,M3V-T+3$U+6YE=R]L:6)? M;FEO<R]B;V%R9"YC"BTM+2!U+6)O;W0M,C`P,RU/8W0M,34M;W)I9R]L:6)? M;FEO<R]B;V%R9"YC"3(P,#,M,3`M,34@,C(Z,C,Z-#4N,#`P,#`P,#`P("TP M-#`P"BLK*R!U+6)O;W0M,C`P,RU/8W0M,34M;F5W+VQI8E]N:6]S+V)O87)D M+F,),C`P,RTQ,"TQ-2`R,CHS-3HQ,"XP,#`P,#`P,#`@+3`T,#`*0$`@+3(W M+#8@*S(W+#<@0$`*("-I;F-L=61E(#QC;VUM;VXN:#X*("-I;F-L=61E(#QD M979I8V5S+F@^"B`C:6YC;'5D92`\=V%T8VAD;V<N:#X**R-I;F-L=61E(#QN M970N:#X*(`H@"B`O*@I`0"`M,3`W+#8@*S$P."PX($!`"B`*(`EB9%]T("IB M9#L*(`EI;FET7V9N8U]T("HJ:6YI=%]F;F-?<'1R.PHK"6-H87(@*G,L("IE M.PHK"6EN="!I.PH@"B`)+RH@4&]I;G1E<B!I<R!W<FET86)L92!S:6YC92!W M92!A;&QO8V%T960@82!R96=I<W1E<B!F;W(@:70N"B`)("H@3FEO<R!T<F5A M=',@0T9'7T="3%]$051!7T]&1E-%5"!A<R!A;B!A9&1R97-S+@I`0"`M,3(Y M+#8@*S$S,BPQ,B!`0`H@"6)D+3YB:5]S<F%M<W1A<G0]($-&1U]34D%-7T)! M4T4["B`)8F0M/F)I7W-R86US:7IE"3T@0T9'7U-204U?4TE:13L*(`EB9"T^ M8FE?8F%U9')A=&4)/2!#3TY&24=?0D%51%)!5$4["BL)8F0M/F)I7VEP7V%D M9'(@/2!G971E;G9?25!A9&1R("@B:7!A9&1R(BD["BL)<R`](&=E=&5N=B`H M(F5T:&%D9'(B*3L**PEF;W(@*&D@/2`P.R!I(#P@-CL@*RMI*2!["BL)"6)D M+3YB:5]E;F5T861D<EMI72`](',@/R!S:6UP;&5?<W1R=&]U;"`H<RP@)F4L M(#$V*2`Z(#`["BL)"6EF("AS*2!S(#T@*"IE*2`_(&4@*R`Q(#H@93L**PE] M"B`*(`EF;W(@*&EN:71?9FYC7W!T<B`](&EN:71?<V5Q=65N8V4[("II;FET M7V9N8U]P='([("LK:6YI=%]F;F-?<'1R*2!["B`)"6EF("@H*FEN:71?9FYC M7W!T<BD@*"D@(3T@,"D@>PI`0"`M,38T+#,@*S$W,RPT($!`"B`)<'5T<R@B M(R,C($524D]2(",C(R!0;&5A<V4@<F5S970@8F]A<F0@(R,C7&XB*3L*(`EF .;W(@*#L[*3L*('T**PH= ` end

2 1

[U-Boot-Users] Re: Revised patch: is_console_quiet(), and user feedback control during a TFTP operation
by Wolfgang Denk 20 Oct '03

20 Oct '03

Dear Jon, in message <1066216586.8112.17.camel(a)smoke.cideas.com> you wrote: > > I did some QA on my two latest patches, and found some minors problems > with the patch generation. I have regenerated these two patches. I > have verified that each patch by itself applies cleanly and doesn't > cause code bloat. > > I should of done this for the first iteration, but I thought it wasn't > needed. Sorry :< > > The two revised patches are attached. ... > CVS Comments: > > - Adding the CFG_CONSOLE_IS_QUIET option to support runtime changes in > console output. The is_console_quiet() function is used to > determine the status of quiet mode. Quiet mode is based on the > value of the "quiet" environment variable. Non-zero values indicate > that quiet mode is active. Please explain why we need yet another environment variable to control the output of console messages. I know that you are aware of the "silent" stuff. Why do we need something new like "quiet" now? I don't like to have 20 different implementations of more or less the same feature. Also, please consider the use of "setenv stdout nulldev". Put on hold with a strong tendency to reject it. > CHANGELOG: > > - Adding a number of options to control the user feedback during a > TFTP operation: > CFG_TFTP_BLINK_STATUS_ON_DATA_IN > CFG_TFTP_BLOCKS_PER_HASH > CFG_TFTP_HASHES_PER_FLASH > CFG_TFTP_HASHES_PER_LINE > CFG_TFTP_PROGESS_QUIET > CFG_TFTP_TIMEOUT_COUNT Come on - this is complete overkill, isn't it? > - Toggle the Status LED on TFTP activity - gives nice visual > indication of booting / network activity Conflicts with existing status LED driver, which has a pre-defined function on many boards. > - Change Status LED back to blinking on TFTP timeout Breaks function of status LED driver on many boards. > - Provide control over the maximum TFTP timeout Please note that code has been added to enable the TFTP client code to specify to the server the desired timeout value (see RFC-2349). This should be used. Sorry, but this is IMHO creaping featurism that does not add any value but renders the code unreadable. Can you please explain why you think I should add this? 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 If I had to live my life again, I'd make the same mistakes, only sooner. -- Tallulah Bankhead

1 0

[U-Boot-Users] README patch to add hint about CONFIG_SILENT_CONSOLE
by Jon Diekema 20 Oct '03

20 Oct '03

--- README 2003-10-14 07:12:06.000000000 -0400 +++ README 2003-10-14 20:08:20.000000000 -0400 @@ -479,6 +479,10 @@ When CONFIG_CFB_CONSOLE is defined, video console is default i/o. Serial console can be forced with environment 'console=serial'. + + When CONFIG_SILENT_CONSOLE is defined, console + messages can be silenced with the "silent" environment + variable. See doc/README.silent for more information. -- ------------------\\----------------------\\---------------------------- Jon Diekema | | Smiths Aerospace (616) 241-8310 | | 3290 Patterson Avenue, SE jon.diekema(a)smiths-aerospace.com \\ Grand Rapids, MI 49512 ****************************************** 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. ******************************************

2 1

[U-Boot-Users] Stack Size for MPC8xx???
by Steven Scholz 18 Oct '03

18 Oct '03

Hi there, does someone know how big the stack is for an MPC8xx based boards? I had this problem: I started porting U-Boot to my new AT91RM9200 based board. After doing the flash code I tried "saveenv". Simple reading, writing and erasing was working. But the board crashed when doing "saveenv". I found these lines in common/env_flash.c: int saveenv(void) { ... #if defined(CFG_ENV_SECT_SIZE) && (CFG_ENV_SECT_SIZE > CFG_ENV_SIZE) ulong flash_offset; uchar env_buffer[CFG_ENV_SECT_SIZE]; #else ... /* copy old contents to temporary buffer */ memcpy (env_buffer, (void *)flash_sect_addr, CFG_ENV_SECT_SIZE); I have CFG_ENV_SECT_SIZE = 64K and CFG_ENV_SIZE=4K and realized that my stack was far to small to save an 64KB flash sector. The funny thing is that I never worried about that issue. And it never seems to be a problem on our MPC8xx based boards... Thanks. -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland fon: +49 30 467090-0 Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576

2 1

[U-Boot-Users] problems about flash setting
by wang cheng 18 Oct '03

18 Oct '03

dear all! sorry ,but i really don't understand. 1.What's the meaning of flash memory banks,is the number of flash chips? ie:if i have 2 chips of 29f040s on my board,then the CFG_MAX_FLASH_BANKS should be 2,right? 2.What's the meaning of FLASH_BASE0_PRELIM and FLASH_BASE1_PRELIM, Is the FLASH_BASE0_PRELIM should be set to the flash_base_addr that defined by cs0? Then what about flash_base1_prelim? 3.What's the difference between br/or_prelim and br/or_remap and their respective function ??Is the br/or_remap must be set or optional depended on my board? Thanks very much for any help!

2 1

[U-Boot-Users] u-boot on cerfboard
by rik rm 17 Oct '03

17 Oct '03

Hi list, Has anybdy ported the u-boot on cerf board 250 (intrinsyc pxa250) ?? I am interested in doing the same but i do not have the BDI debugger and flashing a non working /non tested u-boot is a bit of a risk !!! Any pointers will be of great help. regards rik --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search

2 1

[U-Boot-Users] AT91RM9200 and -mtune=arm7dtmi ???
by Steven Scholz 17 Oct '03

17 Oct '03

Hi there, the file cpu/at91rm9200/config.mk contains an option "-mtune=arm7tdmi". I am new to ARM processors so please bear my stupid question: The Atmel AT91RM9200 is and ARM9 / ATM920T. So shouldn't this option be different? Like "-mtune=atm920" or something? What is it good for anyway? Thanks a million! -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland fon: +49 30 467090-0 Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576

1 0

[U-Boot-Users] linux 2.6 kernel support for u-boot
by Holger Schurig 17 Oct '03

17 Oct '03

Hi ! I just saw that u-boot has now official support in the Linux 2.6 kernel. In Linus' current Bitkeeper tree was a checkin of a change that allows one to execute "make uImage": $ make -n V=1 uImage ... echo ' Kernel: arch/arm/boot/zImage is ready' ... /bin/sh /usr/src/ramses/linux-2.6/scripts/mkuboot.sh -A arm \ -O linux -T kernel -C none -a 0xa0008000 -e 0xa0008000 \ -n 'Linux-2.6.0-test7-bkpxa' -d arch/arm/boot/zImage \ arch/arm/boot/uImage ... echo ' Image arch/arm/boot/uImage is ready' -- Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at http://www.mn-logistik.de/unsupported/linux-2.6/

1 0

[U-Boot-Users] u/zImage and 64360
by Ronen Shitrit 16 Oct '03

16 Oct '03

Hi 1. As specified in the U-Boot README: " Building a Linux Image: ----------------------- With U-Boot, "normal" build targets like "zImage" or "bzImage" are not used. If you use recent kernel source, a new build target "uImage" will exist which .... " Does it means I can't load a zImage of the kernel by using the tftp??? 2. Does anyone knows if there is already a u-boot version for the Marvell 64360 boards?? Thanks -- Ronen Shitrit M.S.I.L D.N. Misgav 20184 Tel: +972-4-9951000 Fax: +972-4-9951001 Email: mailto: ronen.shitrit(a)il.marvell.com _____________________________________________________________ This message may contain confidential, proprietary or legally privileged information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone, or by e-mail and delete the message from your computer.

3 3

[U-Boot-Users] Starting with Lite5200 Eval Board
by Aquin Remi 16 Oct '03

16 Oct '03

Hello, How to configure U-Boot + Linux with : - Video Card on PCI, - HD, - CD Reader, - CAN Driver.

2 1

[U-Boot-Users] MIPS support
by Ronen Shitrit 16 Oct '03

16 Oct '03

Hi I'm a little confused, in the web page http://sourceforge.net/projects/u-boot/ it says: "CPU architectures are supported: PowerPC(MPC5xx, MPC8xx, MPC82xx, MPC7xx, MPC74xx, 4xx), ARM(ARM7, ARM9, StrongARM, Xscale), MIPS(4Kc,5Kc)," but when I loaded the u-boot-0.4.0 version , I read the README file and there it says: "* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; Currently supported: PowerPC)." So I wanted to know if someone has a clue whether the README file isn't update or the web site, and if someone tried to run it on a MIPS. (I saw under the lib cpu that there is a dir for the MIPS) Thanks alot -- Ronen Shitrit M.S.I.L D.N. Misgav 20184 Tel: +972-4-9951000 Fax: +972-4-9951001 Email: mailto: ronen.shitrit(a)il.marvell.com _____________________________________________________________ This message may contain confidential, proprietary or legally privileged information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone, or by e-mail and delete the message from your computer.

2 1