November 2004 - U-Boot

[U-Boot-Users] [U-Boot-Users][PATCH] to add COBRA5272-board-support
by Florian Schlote 09 Jan '05

09 Jan '05

Hi Wolfgang, Please find attached a patch (gzip) that adds (SenTec-)COBRA5272-board-support. The diff is done against the 1.1.1 version. Thanks to Josef Baumgartner for a his good work creating the coldfire support. --- CHANGELOG * Patch by Florian Schlote Added support for SenTec-COBRA5272-board (Coldfire) --- Best regards & thanks for integration, Florian --- mailto: FMWWS(a)gmx.de

2 1

[U-Boot-Users] [PATCH] mpc824x: set PCI latency timer to a sane value.
by gleb＠nbase.co.il 09 Jan '05

09 Jan '05

It is 0 after reset. -- Gleb.

2 1

[U-Boot-Users] [PATCH] Fpga bitstream load support
by Kurt Stremerch 09 Jan '05

09 Jan '05

Hi all. This patch, against current cvs, adds the option loadb to the fpga command. The option allows users to configure a fpga directly with a bitstream stored in memory. Actually, the configuration is still done by fpga_load(), except the necessary bitswapping is applied on the configuration data before calling it. For now, only Xilinx bitstreams are supported. In FPGA_DEBUG mode, the loadb option can print bitstream project details like the design name, part number, date/time and the length of bitstream. Regards Kurt CHANGELOG: * Patch by Kurt Stremerch, 03 September 2004: Add bitstream configuration option for fpga command (Xilinx only).

2 1

[U-Boot-Users] [PATCH] Spartan2E family support
by Kurt Stremerch 09 Jan '05

09 Jan '05

Hi all. This small patch, against current cvs, adds Xilinx Spartan2E support. Only the bitstream size differs from the Spartan2 family but the configuration method stays the same. Regards Kurt CHANGELOG: * Patch by Kurt Stremerch, 03 September 2004: Add Xilinx Spartan2E family fpga support

2 1

[U-Boot-Users] [PATCH]: Support for EP8260 H2 (300MHz)
by Jeff Angielski 09 Jan '05

09 Jan '05

I was going through my records and noticed that I neglected to send in the updated patch for this hardware. The problem with the original patch I submitted was that the SYPCR[BMT] was not being set to 0x6 (48 clocks) as specified in the latest revision of the user manual. Without studying the design in detail, I am not sure why this is the case. However, if the BMT is not set to 0x6, FCC3 will generate TX buffer underrun errors for larger packets when used in Linux. In any event, here is the patch that adds support for this latest H2 version of the EP8260 board from Embedded Planet. CHANGELOG * Patch by Jeff Angielski, 02 Sep 2004 - Added support for H2 revision of the EP8260 board. Fixed the formatting for some of the EP8260 related source files. Jeff Angielski

3 5

[U-Boot-Users] [PATCH] MPC85XX ADS/CDS Fix environment saving
by Jon Loeliger 09 Jan '05

09 Jan '05

Wolfgang, Here is a patch to correct the sizes of the monitor used by the CFI driver to mark sectors for read-only status. With this patch, we can once again save the environment on the MPC85xx ADS and CDS releases. Thanks, jdl * Patch by Jon Loeliger, 02-Sep-2004: Reset monitor size back to 256 so environment can be written to flash on MPC85xx ADS and CDS releases. Index: include/configs/MPC8540ADS.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/MPC8540ADS.h,v retrieving revision 1.1.1.1.4.15 retrieving revision 1.1.1.1.4.16 diff -u -r1.1.1.1.4.15 -r1.1.1.1.4.16 --- include/configs/MPC8540ADS.h 2004/08/18 16:08:50 1.1.1.1.4.15 +++ include/configs/MPC8540ADS.h 2004/08/30 18:48:44 1.1.1.1.4.16 @@ -264,7 +264,7 @@ #define CFG_GBL_DATA_OFFSET (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE) #define CFG_INIT_SP_OFFSET CFG_GBL_DATA_OFFSET -#define CFG_MONITOR_LEN (512 * 1024) /* Reserve 256 kB for Mon */ +#define CFG_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ #define CFG_MALLOC_LEN (128 * 1024) /* Reserved for malloc */ /* Serial Port */ Index: include/configs/MPC8541CDS.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/Attic/MPC8541CDS.h,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- include/configs/MPC8541CDS.h 2004/08/20 17:20:17 1.1.2.1 +++ include/configs/MPC8541CDS.h 2004/08/30 18:43:54 1.1.2.2 @@ -254,7 +254,7 @@ #define CFG_GBL_DATA_OFFSET (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE) #define CFG_INIT_SP_OFFSET CFG_GBL_DATA_OFFSET -#define CFG_MONITOR_LEN (512 * 1024) /* Reserve 512 kB for Mon */ +#define CFG_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ #define CFG_MALLOC_LEN (128 * 1024) /* Reserved for malloc */ /* Serial Port */ Index: include/configs/MPC8555CDS.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/Attic/MPC8555CDS.h,v retrieving revision 1.1.4.22 retrieving revision 1.1.4.23 diff -u -r1.1.4.22 -r1.1.4.23 --- include/configs/MPC8555CDS.h 2004/08/20 17:20:17 1.1.4.22 +++ include/configs/MPC8555CDS.h 2004/08/30 18:43:54 1.1.4.23 @@ -254,7 +254,7 @@ #define CFG_GBL_DATA_OFFSET (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE) #define CFG_INIT_SP_OFFSET CFG_GBL_DATA_OFFSET -#define CFG_MONITOR_LEN (512 * 1024) /* Reserve 512 kB for Mon */ +#define CFG_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ #define CFG_MALLOC_LEN (128 * 1024) /* Reserved for malloc */ /* Serial Port */ Index: include/configs/MPC8560ADS.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/MPC8560ADS.h,v retrieving revision 1.1.1.1.4.16 retrieving revision 1.1.1.1.4.17 diff -u -r1.1.1.1.4.16 -r1.1.1.1.4.17 --- include/configs/MPC8560ADS.h 2004/08/18 16:08:50 1.1.1.1.4.16 +++ include/configs/MPC8560ADS.h 2004/08/30 18:48:44 1.1.1.1.4.17 @@ -267,7 +267,7 @@ #define CFG_GBL_DATA_OFFSET (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE) #define CFG_INIT_SP_OFFSET CFG_GBL_DATA_OFFSET -#define CFG_MONITOR_LEN (512 * 1024) /* Reserve 256 kB for Mon */ +#define CFG_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ #define CFG_MALLOC_LEN (128 * 1024) /* Reserved for malloc */ /* Serial Port */

2 1

[U-Boot-Users] .bss section problem
by Paolo Broggini 09 Jan '05

09 Jan '05

Hi there, I'm working on the port of U-Boot to a new custom board based on the i.MX1 (ARM920T). I noticed that in the start.S the code in which the .bss will be cleared, loops until _bss_start != _bss_end i.e. clear_bss: ldr r0, _bss_start /* find start of bss segment */ add r0, r0, #4 /* start at first byte of bss */ ldr r1, _bss_end /* stop here */ mov r2, #0x00000000 /* clear */ clbss_l:str r2, [r0] /* clear loop... */ add r0, r0, #4 cmp r0, r1 bne clbss_l So, when _bss_end is not forced to be .ALIGNED(4) like the _bss_start is, the code may loops till it crashs :-( This is what actually happened in my case. Now to fix the problem on my port I changed my u-boot.lds as: . = ALIGN(4); __bss_start = .; .bss : { *(.bss) } _end = ALIGN(4); and to be consistent I replaced the 'bne clbss_1' with 'ble clbss_1' instruction. I was wondering if I'm missing something on the linker directives or indeed it is small bug. Thanks for your suggestions, -Paolo Broggini

2 1

[U-Boot-Users] CLI over Ethernet
by Srivatsan 22 Dec '04

22 Dec '04

Hi all, Greetings. There is a requirement to provide CLI over Ethernet in uboot. 1) The CLI works over LAN (not using TCP/IP) using Logical link control Layer. (Is this possible?) 2) Anyone who has done a similar stuff has any advice for us? (Not in negative :-)) 3) Is there any documentation or RFC available which talks of (Ethernet) connectivity at LLC layer? Thanks and Best Regards, C.R.Srivatsan -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of u-boot-users-request(a)lists.sourceforge.net Sent: Wednesday, November 24, 2004 8:43 PM To: u-boot-users(a)lists.sourceforge.net Subject: U-Boot-Users digest, Vol 1 #1106 - 13 msgs Send U-Boot-Users mailing list submissions to u-boot-users(a)lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/u-boot-users or, via email, send a message with subject or body 'help' to u-boot-users-request(a)lists.sourceforge.net You can reach the person managing the list at u-boot-users-admin(a)lists.sourceforge.net When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot-Users digest..." Today's Topics: 1. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Friedrich, Lars) 2. question on drive (zhonglei) 3. boot problem (Alessio Raccis) 4. Re: question on drive (Marc Leeman) 5. boot problem (Alessio Raccis) 6. R: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 (Paolo Broggini) 7. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk) 8. Re: boot problem (Wolfgang Denk) 9. Re: question on drive (Wolfgang Denk) 10. Re: question on drive (Marc Leeman) 11. RE: CONFIG_BOOTBINFUNC for AT91RM9200 (Paugam Luc) 12. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Steven Scholz) 13. Re: CONFIG_BOOTBINFUNC for AT91RM9200 (Wolfgang Denk) --__--__-- Message: 1 Subject: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 Date: Wed, 24 Nov 2004 08:46:45 +0100 From: "Friedrich, Lars" <lars.friedrich(a)wago.com> To: <u-boot-users(a)lists.sourceforge.net> > > Why is that so bad? It makes it possible to debug U-Boot > > with just loading the image into RAM using BDI2000. > Which is an unsupported mode of operation which works for a handfull > of experts and causes confusion with many, many newbees. How do these lines of code confuse a newbie more than any other code in the file? > > But how would you debug U-Boot? > As I always do. Attach the BDI, burn to flash, start in GDB. There are 53982 other hardware debuggers out there and only the minority (is there actually one besides the BDI?) support the burn to flash feature you rely on. So if you need to start U-Boot to flash U-Boot, you either do those few lines of code to skip the relocation or get/use another piece of actually redundant software to get the image on the flash. I don't know why the latter should save me time. > You can do this if you know exactly what you're doing, Isn't this what is assumed here anyway? Best regards, Lars Friedrich --=20 --__--__-- Message: 2 Date: Wed, 24 Nov 2004 15:25:07 +0800 From: "zhonglei" <zhonglei(a)RCS-9000.COM> Reply-To: <zhonglei(a)RCS-9000.COM> To: <u-boot-users(a)lists.sourceforge.net> Subject: [U-Boot-Users] question on drive hi Sorry for bothering you! But would you please give me a hand.When I insert a Intel Pro/100s server Adapter into the PCI slot on Lite5200(motorola MPC5200 development kit) and start the kernel,the kernel run into a dead lock. The reports are as follows: . . . IP-Config: Retrying forever (NFS root)... eth1: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. eth1: Waiting for the link to be up... eth1: status: link up, 100 Mbps Full Duplex, auto-negotiation complete. e100: eth0 NIC Link is Up 100 Mbps Full duplex Sending DHCP requests ...... timed out! Please tell me how can I handle it! Thanks in advance! Best Regards zhonglei --__--__-- Message: 3 From: "Alessio Raccis" <lolloz(a)tiscali.it> To: <u-boot-users(a)lists.sourceforge.net> Date: Wed, 24 Nov 2004 10:10:39 +0100 Subject: [U-Boot-Users] boot problem Hi all, I have a problem and now, it's weird to say, I pray to a kernel panic ! I'm working on smdk2410 and I have a u-boot version modified to boot from smartmedia. I want, or better I hope to boot 2.6.7 linux kernel. So, I create a zImage by compiling kernel and then I make: gzip -9 zImage ./mkimage -A arm -O linux -T kernel -C gzip -a 0x30008000 -e 0x30008000 -n "Linux Kernel Image" -d zImage.gz uimage At this point, I download uimage at 33000000 address from a tftp server. SMDK2410 # tftpboot 33000000 uimage TFTP from server 10.124.7.161; our IP address is 10.124.7.50 Filename 'uimage'. Load address: 0x33000000 Loading: ################################################################# ################################################################# ######################################################## done Bytes transferred = 950519 (e80f7 hex) Now I boot the kernel and I have: SMDK2410 # bootm ## Booting image at 33000000 ... Image Name: Linux Kernel Image Created: 2004-11-17 13:50:56 UTC Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 950455 Bytes = 928.2 kB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Uncompressing Linux................................................................... done, booting the kernel. Nothing else !! Can anyone help me, please ? Which is my mistake ? thanks in advance. Best regards, Alex --__--__-- Message: 4 Date: Wed, 24 Nov 2004 10:14:33 +0100 From: Marc Leeman <marc.leeman(a)gmail.com> Reply-To: Marc Leeman <marc.leeman(a)gmail.com> To: zhonglei(a)rcs-9000.com Subject: Re: [U-Boot-Users] question on drive Cc: u-boot-users(a)lists.sourceforge.net I don't think this has to do with u-boot :) I think you should send this to the correct mailing list. > IP-Config: Retrying forever (NFS root)... > eth1: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. > eth1: Waiting for the link to be up... > eth1: status: link up, 100 Mbps Full Duplex, auto-negotiation complete. > e100: eth0 NIC Link is Up 100 Mbps Full duplex Maybe your board configuration of the kernel is not quite correct and/or some interrupt lines are wongly addressed. > Sending DHCP requests ...... timed out! > Please tell me how can I handle it! Thanks in advance! $ find . -name '*.c' | xargs grep Sending\ DHCP And start debugging/instrumenting from there. --=20 ash nazg durbatul=FBk, ash nazg gimbatul, ash nazg thrakatul=FBk agh burzum-ishi krimpatul --__--__-- Message: 5 From: "Alessio Raccis" <lolloz(a)tiscali.it> To: <u-boot-users(a)lists.sourceforge.net> Subject: [U-Boot-Users] boot problem Date: Wed, 24 Nov 2004 10:18:22 +0100 Hi all, I have a problem and now, it's weird to say, I pray to a kernel panic ! I'm working on smdk2410 and I have a u-boot version modified to boot from smartmedia. I want, or better I hope to boot 2.6.7 linux kernel. So, I create a zImage by compiling kernel and then I make: gzip -9 zImage ./mkimage -A arm -O linux -T kernel -C gzip -a 0x30008000 -e 0x30008000 -n "Linux Kernel Image" -d zImage.gz uimage At this point, I download uimage at 33000000 address from a tftp server. SMDK2410 # tftpboot 33000000 uimage TFTP from server 10.124.7.161; our IP address is 10.124.7.50 Filename 'uimage'. Load address: 0x33000000 Loading: ################################################################# ################################################################# ######################################################## done Bytes transferred = 950519 (e80f7 hex) Now I boot the kernel and I have: SMDK2410 # bootm ## Booting image at 33000000 ... Image Name: Linux Kernel Image Created: 2004-11-17 13:50:56 UTC Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 950455 Bytes = 928.2 kB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Uncompressing Linux................................................................... done, booting the kernel. Nothing else !! Can anyone help me, please ? Which is my mistake ? thanks in advance. Best regards, Alex --__--__-- Message: 6 From: "Paolo Broggini" <pbroggini(a)softool.ch> To: "Friedrich, Lars" <lars.friedrich(a)wago.com>, <u-boot-users(a)lists.sourceforge.net> Subject: R: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 Date: Wed, 24 Nov 2004 10:29:52 +0100 > -----Messaggio originale----- > Da: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]Per conto di Friedrich, > Lars > Inviato: mercoledì, 24. novembre 2004 08:47 > A: u-boot-users(a)lists.sourceforge.net > Oggetto: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 > > > > > Why is that so bad? It makes it possible to debug U-Boot > > > with just loading the image into RAM using BDI2000. > > Which is an unsupported mode of operation which works for a handfull > > of experts and causes confusion with many, many newbees. > > How do these lines of code confuse a newbie more than any other code > in the file? > > > > You can do this if you know exactly what you're doing, > > Isn't this what is assumed here anyway? > I fully agree with you !!! Regards -Paolo Broggini > Best regards, > Lars Friedrich > > -- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > --__--__-- Message: 7 To: "Friedrich, Lars" <lars.friedrich(a)wago.com> Cc: u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 Date: Wed, 24 Nov 2004 11:26:56 +0100 Dear Lars, in message <AB4979EC12A5EB419810807434495A17283C1E(a)svex01001.wago.local> you wrote: > > > Which is an unsupported mode of operation which works for a handfull > > of experts and causes confusion with many, many newbees. > > How do these lines of code confuse a newbie more than any other code > in the file? It's not the lines of code, but the mode of operation. People tend to underestimate the complexity of the task and the impact of the required modifications. > > As I always do. Attach the BDI, burn to flash, start in GDB. > > There are 53982 other hardware debuggers out there and only the > minority (is there actually one besides the BDI?) support the > burn to flash feature you rely on. So if you need to start U-Boot C'me on. You must be joking. Please name a few commercial debuggers which do not support flash programming. Maybe we should add a list of such broken devices to our wiki so people can avoid them? Let me check: * Abatron BDI2000: ok (of course) * Windriver visionICE II: ok * Lauterbach Trace32: ok * Macraigor Wiggler / Raven / usbDemon: ok * Agilent 3070 Series etc: ok Even the free BDM4GDB project suports flash programming. Please be specific: which BDM/JTAG debugger cannot program flash? I really would like to know to be able to warn our customers. > > You can do this if you know exactly what you're doing, > > Isn't this what is assumed here anyway? Yes. People should think, machines should work ;-) There are areas, where small errors have small consequences which are easy to spot. AQnd there are really nasty problems. If you look back at the archives you will see that this is one of these nasty problem domains. And it's a FAQ. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke --__--__-- Message: 8 To: "Alessio Raccis" <lolloz(a)tiscali.it> Cc: u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] boot problem Date: Wed, 24 Nov 2004 11:32:35 +0100 In message <001e01c4d205$7e2ca120$cb077c0a@bart> you wrote: > > I have a problem and now, it's weird to say, I pray to a kernel panic ! Alternatively, try a post-mortem dump of the log_buf area, see http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis Or even better: attach your BDI2000 and debug the Linux kernel code. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de If God had a beard, he'd be a UNIX programmer. --__--__-- Message: 9 To: Marc Leeman <marc.leeman(a)gmail.com> Cc: zhonglei(a)rcs-9000.com, u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] question on drive Date: Wed, 24 Nov 2004 11:30:14 +0100 In message <1f729c4804112401141cd5deb7(a)mail.gmail.com> you wrote: > I don't think this has to do with u-boot :) I think you should send > this to the correct mailing list. thanks for pointing out. > > IP-Config: Retrying forever (NFS root)... > > eth1: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. > > eth1: Waiting for the link to be up... > > eth1: status: link up, 100 Mbps Full Duplex, auto-negotiation complete. > > e100: eth0 NIC Link is Up 100 Mbps Full duplex > > Maybe your board configuration of the kernel is not quite correct > and/or some interrupt lines are wongly addressed. No, you are wrong here. It seems the kernel is working perfectly fine. > > Sending DHCP requests ...... timed out! > > Please tell me how can I handle it! Thanks in advance! > > $ find . -name '*.c' | xargs grep Sending\ DHCP > And start debugging/instrumenting from there. Always try simple things first! Is there a DHCP server running to answer the DHCP requests from the target? Did you run a network sniffer and actually see the DHCP reply packets on the wire? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7 --__--__-- Message: 10 Date: Wed, 24 Nov 2004 11:47:25 +0100 From: Marc Leeman <marc.leeman(a)gmail.com> Reply-To: Marc Leeman <marc.leeman(a)gmail.com> To: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] question on drive > Always try simple things first! Is there a DHCP server running to > answer the DHCP requests from the target? Did you run a network > sniffer and actually see the DHCP reply packets on the wire? Hm, I assumed this was already checked since it the easiest to do :) I know, 'assuming' is bad... This would be (on the server) # tail -f /var/log/syslog to check the DCHP packages arriving at the server and the replies being sen= t. --=20 ash nazg durbatul=FBk, ash nazg gimbatul, ash nazg thrakatul=FBk agh burzum-ishi krimpatul --__--__-- Message: 11 Subject: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 Date: Wed, 24 Nov 2004 11:54:09 +0100 From: "Paugam Luc" <luc.paugam(a)thomson.net> To: "Wolfgang Denk" <wd(a)denx.de>, "Steven Scholz" <steven.scholz(a)imc-berlin.de> Cc: <u-boot-users(a)lists.sourceforge.net> Dear Steven & Wolfgang, There is perhaps a confusion between _relocation_ and _copy_. Beware to the fact that actually the AT91RM9200 starter code (especially = start.S) does not relocate any code from Flash to RAM (as we can see it into PowerPC starter code, for example) but rather do a simple copy of=20 u-boot code from Flash to RAM. _TEXT_BASE is still defined with a RAM address! This way to do is unfortunately inherited from ATMEL with their 2 stages = boot process. Regards - Luc > -----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: mardi 23 novembre 2004 17:43 > To: Steven Scholz > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200=20 >=20 >=20 > In message <41A35A7E.1020605(a)imc-berlin.de> you wrote: > >=20 > > is there a standard way in U-Boot to prevent to the startup=20 > code from relocating=20 > > into RAM? >=20 > No. U-Boot will always relocate itself to RAM. Well, nearly always - > in any halfway sane implementation. >=20 > > I know that arm920t figures out the currebt address.=20 > compares it to _TEXT_BASE=20 > > and decides wether to relocate or not. > >=20 > > relocate: /* relocate U-Boot to=20 > RAM */ > > adr r0, _start /* r0 <- current=20 > position of code */ > > ldr r1, _TEXT_BASE /* test if we run from=20 > flash or RAM */ > > cmp r0, r1 /* don't reloc during=20 > debug */ >=20 > I wish that code was never written. >=20 > > So there might be no need for a define like=20 > CFG_DONT_RELOCATE. But how about=20 > > other cpus? >=20 > All CPUs always relocate the code to RAM. This is the general case. > Anything else is not supported. >=20 > > (I am asking cause you wrapped the relocate code in=20 > cpu/at91rm9200/start.S with=20 > > CONFIG_BOOTBINFUNC instead of using the above technique. >=20 > Please consider the CONFIG_BOOTBINFUNC as an optimization of effort > and effect (read: quick & dirty hack). Feel free to clean up as long > the result is working code, too. >=20 > Best regards, >=20 > Wolfgang Denk >=20 > --=20 > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > Fools ignore complexity. Pragmatists suffer it. Some can avoid it. > Geniuses remove it. > - Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users >=20 --__--__-- Message: 12 Date: Wed, 24 Nov 2004 13:54:33 +0100 From: Steven Scholz <steven.scholz(a)imc-berlin.de> To: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 Wolfgang Denk wrote: > In message <41A36CFE.9050900(a)imc-berlin.de> you wrote: > >>Hmm. So I suggest replacing it with CONFIG_INIT_LOWLEVEL or CONFIG_LOWLEVEL_INIT. > > > Hmmm.. CONFIG or CFG? And what exactly is low (vs. high?) level here? > > >>But then: these init steps (clocks and memory) are vital for U-Boot to run. So >>why do we need this define anyway if these steps should be done always... ? > > > Good question. The only reason I can think of is to allob such a > two-stage boot loader as used by Atmel on the AT91RM9200DK. So we check if all other arm920t boards have an implementation of memsetup(). Then kick out CONFIG_INIT_CRITICAL and introduce CONFIG_DO_NOT_MAKE_LOWLEVEL_INIT or something like that !? ;-) -- Steven Scholz --__--__-- Message: 13 To: Steven Scholz <steven.scholz(a)imc-berlin.de> Cc: u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 Date: Wed, 24 Nov 2004 16:06:46 +0100 In message <41A48489.80203(a)imc-berlin.de> you wrote: > > So we check if all other arm920t boards have an implementation of memsetup(). > Then kick out CONFIG_INIT_CRITICAL and introduce > CONFIG_DO_NOT_MAKE_LOWLEVEL_INIT or something like that !? ;-) Sounds like a plan to me - but let's use a better name, please. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Why can you only have two doors on a chicken coop? If it had four it would be a chicken sedan. --__--__-- _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users End of U-Boot-Users Digest ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. ****************************************************************************

3 9

[U-Boot-Users] Ping issue
by Vidya S 07 Dec '04

07 Dec '04

Hi, I am using smc91111.c driver of u-boot. all my network functionalities are working well. i am able to ping an other ip address and i get a message that the host is alive or not. Only problem is, when someone pings the target ip (my network card ip), it says destination not reachable. Is this really a problem? if so, pls help me solving it. regards vidya

5 8

[U-Boot-Users] u-boot for pxa255
by Sharad P. Katti 06 Dec '04

06 Dec '04

Hi All, I'm working on a PXA255 reference board, I'm able to get u-boot prompt on my serial console, I appended the kernel image with the u-boot.bin file, and write the new image onto the flash. But when I give the address from where my kernel is starting (in the appended .bin file), I can just see the message starting application at 0xa000ebc4.... (which is the address of the kernel ) and stops there only. How can I check whether the bootloader and kernel are copied to the ram from the flash, as I'm not using the network features to download the image. TIA -- Sharad P.Katti

3 9