February 2006 - U-Boot

[U-Boot-Users] How to obtain patches?
by Umar Qureshey 23 Feb '06

23 Feb '06

Hi, I have an ARM Integrator/CP which has the embedded environment problem for which you have posted patches. You mention that "previous patches 009 - 015" are also necessary for this patch to apply. Question is how do I get those previous patches and this one also? Thanks, Umar

1 0

[U-Boot-Users] transmission just works in loopback mode
by Josef Angermeier 23 Feb '06

23 Feb '06

Dear u-boot users, i used the MPC875 FEC internal loopback mode and the external transceiver-loopback mode. In both cases i could send *and* receive the data. But when using no loopback at all, but a (working) crossover cable to connect the board to a second PC (see below), no packets get received there. Where could the failure be ? MPC875 <-> transceiver(LTX970) <-> RJ45-connector <-> crossover -cable <-> second PC with RJ54-connector my custom board contains a MPC875, whose FEC is connected to a LTX970 transceiver chip, which uses a twisted pair cable interface. best regards Josef

1 0

[U-Boot-Users] U-Boot hang on icache enable
by Siju Viswanath 23 Feb '06

23 Feb '06

Hi, I have a MPC8247 board with 2MB flash and 64MB SDRAM. I am using u-boot 1.1.2. The u-boot comes up if I disable the icache. But when I enable instruction cache from config file (HID0_ICE set in CFG_HID0_FINAL) it hangs in cpu/mpc8260/start.S code shown below. Any pointers as to what could be the issue would be helpful. in_ram: /* * Relocation Function, r14 point to got2+0x8000 * * Adjust got2 pointers, no need to check for 0, this code * already puts a few entries in the table. */ li r0,__got2_entries@sectoff@l la r3,GOT(_GOT2_TABLE_) lwz r11,GOT(_GOT2_TABLE_) mtctr r0 sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) add r0,r0,r11 stw r0,0(r3) bdnz 1b thanks, Siju Viswanath Tejas Networks

2 2

[U-Boot-Users] CFG_NO_FLASH configuration parameter
by Mustafa Çayır 23 Feb '06

23 Feb '06

Hi, Could you point out CFG_NO_FLASH configuration parameter? If CFG_NO_FLASH is defined, do it means that there is really no flash in system? if so, how is system able to boot from flash? Thanks.

4 4

[U-Boot-Users] test MPC875 FEC -> LTX970 connection with loopback mode
by Josef Angermeier 23 Feb '06

23 Feb '06

Dear u-boot users, I am using a MPC875 board, on which the FEC is connected to a LTX970 transceiver chip. Connecting to LTX970 MII management interface works correctly, but transferring data from the MPC to the LTX over the wire doesn't work yet. To find out if the data flow breaks between MPC and LTX or between LTX and the twisted pair wire, i would like to use the LTX loopback mode. Has this done someone before ? Is there some test code included in u-boot ? thanks, best regards Josef

1 0

[U-Boot-Users] Timer interrupt in Uboot
by Bhavin Patel 23 Feb '06

23 Feb '06

Greetings, I am using uboot to bringup my board having MIPS to run OS. Can anyone tell me whether is it possible to have some kind of interrupt mechanism in Uboot so that I am able to get interrupt at say every 10 microsec? Thanks. -- View this message in context: http://www.nabble.com/Timer-interrupt-in-Uboot-t1173407.html#a3083687 Sent from the Uboot - Users forum at Nabble.com.

3 2

[U-Boot-Users] about Redirection in Linux issue
by jie han 22 Feb '06

22 Feb '06

Hi everyone: I defined CONFIG_SILENT_CONSOLE in my board config file,so all console messages (by U-Boot and Linux!) can be silenced with the "silent" environment variable.Mu question is how Can I redirect to normal define as normal(0 = stdin 1 = stdout 2 = stderr) when I already login in linux shell? Thanks ahead, Sincerely, Jie __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[U-Boot-Users] (no subject)
by ??? 21 Feb '06

21 Feb '06

Dear Mr.Wolfgang: In the TQM860L Where is the code about: SMC1 Register (SMCMR)Setting; SCC1 Registers(GSMR_L,DSR and so on.) Setting; FEC Register(SDCR) Setting; PAPAR,PCPAR and PDPAR Setting; Yours Sincerely, Yuwei Qin yuwei_qin(a)photontec.com 2006-02-21

2 1

RE: [U-Boot-Users] [PATCH] Integrator CP Environment
by Peter Pearse 21 Feb '06

21 Feb '06

wd(a)denx.de wrote: > U-Boot does not "lose" the environmet once it > has been successfully written to flash. ??? > The Integrator/CP code was incorrectly configured such that ENV_IS_EMBEDDED was true during compilation, causing the environment to be assumed to be in environment[] in the code copied to RAM. Since the environment remains in flash, environment[] is empty at reboot. This causes a CRC error and the default environment is used. The patch configures the Integrator/CP code such that the environment is correctly found in the flash. Regards Peter -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 0

[U-Boot-Users] [PATCH] Integrator CP Environment
by Peter Pearse 21 Feb '06

21 Feb '06

The attached gzipped file contains my patch number 016 against the GIT head of 21st Feb 2006. This patch depends on all my outstanding previous patches 009 - 015. It patches u-boot/include/configs/integratorcp.h such that the environment is no longer embedded. This ensures that changes to the environment, saved to flash, are not lost at reboot. CHANGELOG: Ensure saved environment changes for Integrator/CP are maintained across reboot. Patch by Peter Pearse, 21st Feb. Regards Peter Pearse.

2 1

[U-Boot-Users] Fast flashing with MPCBDM
by Thomas Stark 20 Feb '06

20 Feb '06

Hello U-Boot users, when i write an uboot image to my flash with ppc-linux-gdb (with a MPCBDM cable), i get from time to time the following message: ---Type <return> to continue, or q <return> to quit--- This is pretty annoying when you have to flash very often. Can anybody please tell me how to get rid of this? Thanks in advance. Greetings, Thomas

2 1

[U-Boot-Users] (no subject)
by Wilson Callan 20 Feb '06

20 Feb '06

1 0

[U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
by Josef Angermeier 20 Feb '06

20 Feb '06

Dear u-boot-users, u-boot works on my custom board (MPC875, 64MB RAM, 16MB flash) but linux hangs (see debug console output below) when started with bootm-command. I am using the ELDK 3.1.1 kernel sources (version 2.4.25) and a u-boot CVS version which is slightly newer than the 1.1.3 release. CLOCKS_IN_MHZ is not defined in my u-boot board config file and the IMMR define is in kernel and u-boot board config file identical. I noticed, that bd_info structure in u-boot/asm-ppc/u-boot.h and eldk/ppc_8xx/ usr/src/linux/include/asm-ppc/ppcboot.h differ abit: in the kernel sources a mon_fnc_t *bi_mon_fnc; /* Pointer to monitor functions */ } bd_t; pointer to monitor funcs is defined, which is does not appear in u-boot.h. Is this intended or a bug ? What else could i tryout before analyzing kernel log buffer and debugging the kernel ? best regards, Josef ---------------- SERIAL DEBUG OUTPUT ------------------------------ U-Boot 1.1.3 (Feb 20 2006 - 09:31:08) CPU: MPC885ZPnn at 40 MHz: 8 kB I-Cache 8 kB D-Cache FEC present clock 40000000Hz != 100000Hz You made sure it's an ESM this is running on, right? DRAM: 64 MB Top of RAM usable for U-Boot at: 04000000 Reserving 203k for U-Boot at: 03fcd000 Reserving 2564k for malloc() at: 03d4c000 Reserving 60 Bytes for Board Info at: 03d4bfc4 Reserving 48 Bytes for Global Data at: 03d4bf94 Stack Pointer at: 03d4bf78 New Stack Pointer is: 03d4bf78 Now running in RAM - U-Boot at: 03fcd000 FLASH: 61.3 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial U-Boot relocated to 03fcd000 Net: FEC ETHERNET => bootm 0xe0080000 ## Booting image at e0080000 ... Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 284357 Bytes = 277.7 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x03D4BCE8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF00 bd address = 0x03D4BFC4 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xE0000000 flashsize = 0x03D4BF78 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFF000000 bootflags = 0x00000001 intfreq = 40 MHz busfreq = 40 MHz ethaddr = D6:60:1B:EF:B4:11 IP addr = 131.188.51.169 baudrate = 38400 bps No initrd ## Transferring control to Linux (at address 00000000) ...

2 5

[U-Boot-Users] tftp can not load file!
by junping feng 20 Feb '06

20 Feb '06

Dear, My uboot1.1.4 has working on my board,but tftp has not working normally. During using tftp,that following: =>tftp 0x100000 pImage using FCC1 Ethernet device TFTP from server 192.168.1.10,Our IP address is 192.168.1.6 Filename 'pImage' loading address : 0x100000 loading : fec: tx error T fec :tx buffer not ready fec:tx buffer not ready T fec :tx buffer not ready _ Tftp can not load file to sdram or flash, please help me.Why is it? --------------------------------- 雅虎1G免费邮箱百分百防垃圾信雅虎助手-搜索、杀毒、防骚扰

2 1

[U-Boot-Users] Flash Configuration in TQM860L?
by ??? 20 Feb '06

20 Feb '06

Dear all: I want to know the Flash configuration in TQM860L. Please help me point out the bugs in the following configuration: Two AM29LV160 chips; A29-A10 (MPC860) is connected to A0-A19 (AM29LV160); CS0# ( MPC860) is connected to CE# (AM29LV160); OE#/GPL_AB1(MPC860) is connected to OE# (AM29LV160); WE0#/BS_B0# (MPC860) is connected to WE#(AM29LV160-chip1); WE2#/BS_B2# (MPC860) is connected to WE#(AM29LV160-chip2); BYTE#(AM29LV160) is set to Vcc; RY/BY#(AM29LV160) is NC??; Thank you very much! Yours Sincerely, Yuwei Qin yuwei_qin(a)photontec.com 2006-02-20

2 1

[U-Boot-Users] Subject: [PATCH] Git ignore generated files in sub-directory tools.
by Jon Loeliger 20 Feb '06

20 Feb '06

Signed-off-by: Jon Loeliger <jdl(a)freescale.com> --- tools/.gitignore | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 tools/.gitignore ee1b1a7ee4f4b7540c8a016e41cb653ea20b8427 diff --git a/tools/.gitignore b/tools/.gitignore new file mode 100644 index 0000000..76ab6ae --- /dev/null +++ b/tools/.gitignore @@ -0,0 +1,10 @@ +# +# Generated files +# +bmp_logo +crc32.c +envcrc +environment.c +gen_eth_addr +img2srec +mkimage -- 0.99.9n

3 8

[U-Boot-Users] RE: U-Boot-Users digest, Vol 1 #1713 - 14 msgs
by Darin Lo 20 Feb '06

20 Feb '06

Dear sir, I want to unable my U-Boot-Users account . Please do not send me email again. Thank you -----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: Sunday, February 19, 2006 11:07 PM To: u-boot-users(a)lists.sourceforge.net Subject: U-Boot-Users digest, Vol 1 #1713 - 14 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. S3C2410 booting from Nand (kalfalfa) 2. Re: Memory Banks & Flash Mapping (Josef Angermeier) 3. Re: PPC8xx chip select configuration at startup (Wolfgang Denk) 4. Re: PPC8xx chip select configuration at startup (Wolfgang Denk) 5. Re: Re: Safe firmware updates (Wolfgang Denk) 6. Re: PPC8xx chip select configuration at startup (Wolfgang Denk) 7. Re: PPC8xx chip select configuration at startup (Jerry Van Baren) 8. RE: PPC8xx chip select configuration at startup (Steve Strublic) 9. RE: MPC8xx chip select configuration at startup (Steve Strublic) 10. Re: PPC8xx chip select configuration at startup (Vladimir Gurevich) 11. Re: PPC8xx chip select configuration at startup (Wolfgang Denk) 12. Flash Configuration in TQM860L? (=?gb2312?B?x9jT7s6w?=) 13. Re: Flash Configuration in TQM860L? (Wolfgang Denk) 14. [PATCH] Add target 'cscope' to Makefile (Horst Kronstorfer) --__--__-- Message: 1 Date: Fri, 17 Feb 2006 11:56:49 -0800 (PST) From: kalfalfa <kalfalfa(a)gmail.com> Reply-To: kalfalfa <kalfalfa(a)gmail.com> To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] S3C2410 booting from Nand Hi, I have a board based around the S3C2410 but with no NOR flash, only NAND flash. This processor can boot from nand by loading the 1st 4k of nand into memory and running it (which would then presumably load more things from nand into ram to run). I'm wondering how to get uBoot running on such a system? Does it supposrt this, or do I have to write my own 4K bootloader to load the uBoot code into ram and start it from there? (and what would be the best way of doing that?) Thanks -Patrick -- View this message in context: http://www.nabble.com/S3C2410-booting-from-Nand-t1142843.html#a2996155 Sent from the Uboot - Users forum at Nabble.com. --__--__-- Message: 2 From: Josef Angermeier <Josef.Angermeier(a)informatik.stud.uni-erlangen.de> Date: Fri, 17 Feb 2006 21:27:01 +0100 To: Wolfgang Denk <wd(a)denx.de> Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] Memory Banks & Flash Mapping Hello Wolfgang > > I see. Which files hold the sourcecode to map the flash away ? - I'd > > like to understand that one! > That's the memory controller initialization - function cpu_init_f() > in "cpu/mpc8xx/cpu_init.c" AAAHH! Thanks, i think i finally understood it! My flash memory space gets now fully initialized in cpu_init_f. Changed TEXT_BASE to 0x40f00000 and BR0_PRELIM to 0x40000001. So MPC875 starts execution at 0xfff00100, because of ignoring the upper 8 address bits and CS0 default usage after reset, u-boot is executed anyway. When jumping to 0x40fXXXXX, the CPU is aware of the flash destination and br0 is updated to 0x40000000 to stop aliasing and keep execution in flash working... :-))) big thanks goes to Wolfgang! > Best regards, > Wolfgang Denk byebye Josef --__--__-- Message: 3 To: Vladimir Gurevich <vag(a)paulidav.org> cc: u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Date: Fri, 17 Feb 2006 21:48:22 +0100 In message <43F6091D.7040901(a)paulidav.org> you wrote: > > So, yes, the first instruction to be executed is located at 0x0 (that's > how your CPU works), but then the code works using 0x04000000 as a base > and that is fine. The CPU does not care. This is not correct. Depending on your HRCW the first instruction is either fetched from physical address 0x0100, or 0xFFF00100. And by the way: that's MPC8xx (not PPC... which traditionally usually refers to a IBM / AMCC processor). > > The desired location for FLASH memory will be at 0x0400_0000. This is= =20 > > the address space to which I link U-Boot. > > > That's OK. It will simply limit your SDRAM size to 64M. And my cause other problems as well. Don't do it. Map flash at a high address. Best regards, Wolfgang Denk --=20 Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Change is the essential process of all existence. -- Spock, "Let That Be Your Last Battlefield", stardate 5730.2 --__--__-- Message: 4 To: "Steve Strublic" <SStrublic(a)hypercom.com> cc: "Vladimir Gurevich" <vag(a)paulidav.org>, u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Date: Fri, 17 Feb 2006 21:52:23 +0100 In message <482F3C06ECF00C44AEC226520C6FCB1A51ECFF(a)EXCHANGEVS.HYPERCOM.CO= M> you wrote: >=20 > And I agree that the hard reset word may be other than what U-Boot's > startup sequence requires, but I'm stuck. I cannot spin the board to > alter its contents. =20 U-Boot does not have any specific requirements. Your configuration may be sub-optimal, but this just effects where the U-Boot ode ends up in your flash device; worst case is that it leaves you with 700...800 kB of unused / unusable space. > So I need a way to work with what I've got. If I can do it without > modifying U-Boot, that's great... but if I can't, then I need a way tha= t No need to modify U-Boot. Just configure it correctly. Best regards, Wolfgang Denk --=20 Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de "...all the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs!" - David E. Lundstrom, "A Few Good Men From Univac", MIT Press, 1987 --__--__-- Message: 5 To: do <dosilasolfamiredo(a)o2.pl> cc: u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] Re: Safe firmware updates Date: Fri, 17 Feb 2006 22:03:23 +0100 In message <dt527p$arr$1(a)sea.gmane.org> you wrote: > > Yes of course, my mistake - sorry. But by the way, is there a=20 > possibility for safely update u-boot? Yes, if you have hardware to support this (i. e. two flash banks that can be swapped, where the "switch" can be controlled by software, remembers it's state when powered off *and* has some kid of watchdog function to toggle back to the other position in case the system does not come up). Not many systems support this ;-) Best regards, Wolfgang Denk --=20 Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de If I don't document something, it's usually either for a good reason, or a bad reason. In this case it's a good reason. :-) - Larry Wall in <1992Jan17.005405.16806(a)netlabs.com> --__--__-- Message: 6 To: "Steve Strublic" <SStrublic(a)hypercom.com> cc: "Vladimir Gurevich" <vag(a)paulidav.org>, u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Date: Fri, 17 Feb 2006 22:08:03 +0100 In message <482F3C06ECF00C44AEC226520C6FCB1A51ED01(a)EXCHANGEVS.HYPERCOM.CO= M> you wrote: >=20 > So guess what. I got U-boot to run without the 'boot value' > modification to CS0 I had discussed. I think my problem was related to > my debugging tool, the visionCLICK ICE... I had it configured to set WHile I have nothing against a little Vision*-bashing, you should stay honest here: The tool is probably not to blame... > values into the target at reset. So of course the values of BR0/OR0 ... this was a pilot error. > were overridden with whatever I had in there... which were not the same > as what the board booted up with. I hadn't occurred to me to look for > and turn off this option until you asked for the values. I always recommend to use a *minimal* init file in your debug tool, just doing what is unavoidable (i. e. disable the watchdog). You should never mess with the memory controller configuration when trying to debug U-Boot. Best regards, Wolfgang Denk --=20 Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant; the population is growing. --__--__-- Message: 7 Date: Fri, 17 Feb 2006 16:14:28 -0500 From: Jerry Van Baren <gerald.vanbaren(a)smiths-aerospace.com> To: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Wolfgang Denk wrote: > In message <43F6091D.7040901(a)paulidav.org> you wrote: [snip] >>> The desired location for FLASH memory will be at 0x0400_0000. This is >>> the address space to which I link U-Boot. >>> >> That's OK. It will simply limit your SDRAM size to 64M. > > And my cause other problems as well. Don't do it. Map flash at a high > address. Just to be explicit: you _must_ map your flash _well_above_ 0xC000_0000 (the start of the linux kernel area) if you want to run linux. Since _you_ control BR0 (don't listen to them hardware engineers), you can put it anywhere you want. 0xFF00_0000 is a good spot. 0xFFF0_0000 is not as good of a spot because it limits you to 16MB of flash. Think big. ;-) > Best regards, > > Wolfgang Denk Best regards, gvb --__--__-- Message: 8 Subject: RE: [U-Boot-Users] PPC8xx chip select configuration at startup Date: Fri, 17 Feb 2006 14:16:57 -0700 From: "Steve Strublic" <SStrublic(a)hypercom.com> To: <wd(a)denx.de> Cc: "Vladimir Gurevich" <vag(a)paulidav.org>, <u-boot-users(a)lists.sourceforge.net> > -----Original Message----- > From: wd(a)denx.de [mailto:wd@denx.de] > Sent: Friday, February 17, 2006 2:08 PM > To: Steve Strublic > Cc: Vladimir Gurevich; u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup >=20 > In message > <482F3C06ECF00C44AEC226520C6FCB1A51ED01(a)EXCHANGEVS.HYPERCOM.COM> you > wrote: > > > > So guess what. I got U-boot to run without the 'boot value' > > modification to CS0 I had discussed. I think my problem was related to > > my debugging tool, the visionCLICK ICE... I had it configured to set >=20 > WHile I have nothing against a little Vision*-bashing, you should > stay honest here: The tool is probably not to blame... >=20 > > values into the target at reset. So of course the values of BR0/OR0 >=20 > ... this was a pilot error. Yup, sure was. I'm just glad everything is running smoothly. >=20 > > were overridden with whatever I had in there... which were not the same > > as what the board booted up with. I hadn't occurred to me to look for > > and turn off this option until you asked for the values. >=20 > I always recommend to use a *minimal* init file in your debug tool, > just doing what is unavoidable (i. e. disable the watchdog). You > should never mess with the memory controller configuration when > trying to debug U-Boot. >=20 > Best regards, >=20 > Wolfgang Denk >=20 > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > Mr. Cole's Axiom: > The sum of the intelligence on the planet is a constant; > the population is growing. --__--__-- Message: 9 Subject: RE: [U-Boot-Users] MPC8xx chip select configuration at startup Date: Fri, 17 Feb 2006 14:42:50 -0700 From: "Steve Strublic" <SStrublic(a)hypercom.com> To: "Jerry Van Baren" <gerald.vanbaren(a)smiths-aerospace.com>, <u-boot-users(a)lists.sourceforge.net> > Wolfgang Denk wrote: > > In message <43F6091D.7040901(a)paulidav.org> you wrote: >=20 > [snip] >=20 > >>> The desired location for FLASH memory will be at 0x0400_0000. This is > >>> the address space to which I link U-Boot. > >>> > >> That's OK. It will simply limit your SDRAM size to 64M. > > > > And my cause other problems as well. Don't do it. Map flash at a high > > address. >=20 > Just to be explicit: you _must_ map your flash _well_above_ 0xC000_0000 > (the start of the linux kernel area) if you want to run linux. I didn't know that about Linux... but who says I'm going to run Linux? (OK, I am, just kidding.) >=20 > Since _you_ control BR0 (don't listen to them hardware engineers), you > can put it anywhere you want. 0xFF00_0000 is a good spot. 0xFFF0_0000 > is not as good of a spot because it limits you to 16MB of flash. Think > big. ;-) 0xFF00_0000 makes sense to me, and works fine. It fits in with what I've seen in other implementations. As I stated previously, 0x0400_0000 was a purely historical number. I'll take the recommendations of those who have been there before... thanks. >=20 > > Best regards, > > > > Wolfgang Denk >=20 > Best regards, > gvb Thanks Jerry, Steve --__--__-- Message: 10 Date: Fri, 17 Feb 2006 14:11:20 -0800 From: Vladimir Gurevich <vag(a)paulidav.org> To: Wolfgang Denk <wd(a)denx.de> CC: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Hi Wolfgang, Wolfgang Denk wrote: > This is not correct. Depending on your HRCW the first instruction is > either fetched from physical address 0x0100, or 0xFFF00100. > My bad, wrt 0x0100 (I was more concerned about aliasing while writing the previous email), but my understanding is that typically MPC8xx ports of U-boot assume that HCRW is configured for the low boot option, don't they? > And by the way: that's MPC8xx (not PPC... which traditionally usually > refers to a IBM / AMCC processor). > Agreed. > And my cause other problems as well. Don't do it. Map flash at a high > address. > What are the other problems? I believe the TQM8xx ports do (or, at least used to) use this address. Thanks, Vladimir --__--__-- Message: 11 To: Vladimir Gurevich <vag(a)paulidav.org> cc: u-boot-users(a)lists.sourceforge.net From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Date: Fri, 17 Feb 2006 23:30:05 +0100 In message <43F64A08.7020806(a)paulidav.org> you wrote: >=20 > My bad, wrt 0x0100 (I was more concerned about aliasing while writing=20 > the previous email), but my understanding is that typically MPC8xx port= s=20 > of U-boot assume that HCRW is configured for the low boot option, don't= =20 > they? You can chose any setting you like. It's just that low boot is usually the most efficient and flexible one, as it allows to put the U-Boot code at the begin of the flash memory with room to grow after it, so you don't have any nasty gaps and it's trivial to change flash device sizes. > What are the other problems? I believe the TQM8xx ports do (or, at leas= t=20 > used to) use this address. See previous postings. And no, TQM uses 0x4000.0000, not 0x0400.0000. Best regards, Wolfgang Denk --=20 Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Above all else -- sky. --__--__-- Message: 12 Date: Sun, 19 Feb 2006 11:45:03 +0800 From: "=?gb2312?B?x9jT7s6w?=" <yuwei_qin(a)photontec.com> To: "u-boot-users" <u-boot-users(a)lists.sourceforge.net> Subject: [U-Boot-Users] Flash Configuration in TQM860L? RGVhciBhbGw6DQogICANCiAgICAgSSB3YW50IHRvIGtub3cgdGhlIEZsYXNoIGNvbmZpZ3Vy YXRp b24gaW4gVFFNODYwTC5oLg0KICAgIA0KICAgICBQbGVhc2UgaGVscCBtZSBwb2ludCBvdXQg dGhl IGJ1Z3MgaW4gdGhlIGZvbGxvd2luZyBjb25maWd1cmF0aW9uOg0KICAgIA0KICAgICAgICAg VHdv IEFNMjlMVjE2MCBjaGlwczsNCiAgICAgICAgIEEyOS1BMTAgKE1QQzg2MCkgaXMgY29ubmVj dGVk IHRvIEEwLUExOSAoQU0yOUxWMTYwKTsNCiAgICAgICAgIENTMCMgKCBNUEM4NjApIGlzIGNv bm5l Y3RlZCB0byBDRSMgKEFNMjlMVjE2MCk7DQogICAgICAgICBPRSMvR1BMX0FCMShNUEM4NjAp IGlz IGNvbm5lY3RlZCB0byBPRSMgKEFNMjlMVjE2MCk7DQogICAgICAgICBXRTAjL0JTX0IwIyAo TVBD ODYwKSBpcyBjb25uZWN0ZWQgdG8gV0UjKEFNMjlMVjE2MC1jaGlwMSk7DQogICAgICAgICBX RTIj L0JTX0IyIyAoTVBDODYwKSBpcyBjb25uZWN0ZWQgdG8gV0UjKEFNMjlMVjE2MC1jaGlwMik7 DQog ICAgICAgICBCWVRFIyhBTTI5TFYxNjApIGlzIHNldCB0byBWY2M7DQogICAgICAgICBSWS9C WSMo QU0yOUxWMTYwKSBpcyBOQz8/Ow0KICAgICAgDQogICAgVGhhbmsgeW91IHZlcnkgbXVjaCEN Cg0K ICAgIFlvdXJzIFNpbmNlcmVseSwNCiAgICAgICAgICAgICAgIFl1d2VpIFFpbiAgDQoJICAg ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICChoaGhoaGhoaGhoaGhoQ0KoaGh oaGh oaGhoaGhoaGhoXl1d2VpX3FpbkBwaG90b250ZWMuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGh oTIw MDYtMDItMTkNCg== --__--__-- Message: 13 To: "=?gb2312?B?x9jT7s6w?=" <yuwei_qin(a)photontec.com> cc: "u-boot-users" <u-boot-users(a)lists.sourceforge.net> From: Wolfgang Denk <wd(a)denx.de> Subject: Re: [U-Boot-Users] Flash Configuration in TQM860L? Date: Sun, 19 Feb 2006 15:44:46 +0100 In message <OF2D8C2186.EFD8D714-ON4825711A.0016169F(a)photontec.com> you wr= ote: > RGVhciBhbGw6DQogICANCiAgICAgSSB3YW50IHRvIGtub3cgdGhlIEZsYXNoIGNvbmZpZ3V= yYXRp > b24gaW4gVFFNODYwTC5oLg0KICAgIA0KICAgICBQbGVhc2UgaGVscCBtZSBwb2ludCBvdXQ= gdGhl > IGJ1Z3MgaW4gdGhlIGZvbGxvd2luZyBjb25maWd1cmF0aW9uOg0KICAgIA0KICAgICAgICA= gVHdv > IEFNMjlMVjE2MCBjaGlwczsNCiAgICAgICAgIEEyOS1BMTAgKE1QQzg2MCkgaXMgY29ubmV= jdGVk > IHRvIEEwLUExOSAoQU0yOUxWMTYwKTsNCiAgICAgICAgIENTMCMgKCBNUEM4NjApIGlzIGN= vbm5l > Y3RlZCB0byBDRSMgKEFNMjlMVjE2MCk7DQogICAgICAgICBPRSMvR1BMX0FCMShNUEM4NjA= pIGlz > IGNvbm5lY3RlZCB0byBPRSMgKEFNMjlMVjE2MCk7DQogICAgICAgICBXRTAjL0JTX0IwIyA= oTVBD > ODYwKSBpcyBjb25uZWN0ZWQgdG8gV0UjKEFNMjlMVjE2MC1jaGlwMSk7DQogICAgICAgICB= XRTIj > L0JTX0IyIyAoTVBDODYwKSBpcyBjb25uZWN0ZWQgdG8gV0UjKEFNMjlMVjE2MC1jaGlwMik= 7DQog > ICAgICAgICBCWVRFIyhBTTI5TFYxNjApIGlzIHNldCB0byBWY2M7DQogICAgICAgICBSWS9= CWSMo > QU0yOUxWMTYwKSBpcyBOQz8/Ow0KICAgICAgDQogICAgVGhhbmsgeW91IHZlcnkgbXVjaCE= NCg0K > ICAgIFlvdXJzIFNpbmNlcmVseSwNCiAgICAgICAgICAgICAgIFl1d2VpIFFpbiAgDQoJICA= gICAg > ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICChoaGhoaGhoaGhoaGhoQ0KoaG= hoaGh > oaGhoaGhoaGhoXl1d2VpX3FpbkBwaG90b250ZWMuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaG= hoTIw > MDYtMDItMTkNCg=3D=3D Please do not send base 64 encoded messages. Please do not send HTML messages. Please send plain text only. Message unreadable, ignored. Sorry. --__--__-- Message: 14 Date: Sun, 19 Feb 2006 16:06:41 +0100 From: Horst Kronstorfer <crimm(a)elemaa.net> To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] [PATCH] Add target 'cscope' to Makefile hi! the following patch adds target 'cscope' to the main makefile. it also puts the list of directories with source files and the arguments to `find' into make variables. Signed-off-by: Horst Kronstorfer <hkronsto(a)frequentis.com> diff --git a/Makefile b/Makefile index 9305cab..80e3677 100644 --- a/Makefile +++ b/Makefile @@ -135,6 +135,14 @@ SUBDIRS = tools \ post/cpu .PHONY : $(SUBDIRS) +# Directories with files for tag generation +TAGDIRS := $(SUBDIRS) include lib_generic board/$(BOARDDIR) cpu/$(CPU)\ + lib_$(ARCH) fs/cramfs fs/fat fs/fdos fs/jffs2 net disk rtc dtt drivers\ + drivers/sk98lin common + +# Arguments to `find' when generating a list of files for tag generation +TAGFINDARGS := $ -name CVS -prune $ -o $ -name '*.[ch]' -print $ + ######################################################################## # ######################################################################## # @@ -179,19 +187,14 @@ gdbtools: depend dep: @for dir in $(SUBDIRS) ; do $(MAKE) -C $$dir .depend ; done +cscope: + find $(TAGDIRS) $(TAGFINDARGS) >cscope.files; cscope -b -q -k + tags: - ctags -w `find $(SUBDIRS) include \ - lib_generic board/$(BOARDDIR) cpu/$(CPU) lib_$(ARCH) \ - fs/cramfs fs/fat fs/fdos fs/jffs2 \ - net disk rtc dtt drivers drivers/sk98lin common \ - $ -name CVS -prune $ -o $ -name '*.[ch]' -print $` + ctags -w `find $(TAGDIRS) $(TAGFINDARGS)` etags: - etags -a `find $(SUBDIRS) include \ - lib_generic board/$(BOARDDIR) cpu/$(CPU) lib_$(ARCH) \ - fs/cramfs fs/fat fs/fdos fs/jffs2 \ - net disk rtc dtt drivers drivers/sk98lin common \ - $ -name CVS -prune $ -o $ -name '*.[ch]' -print $` + etags -a `find $(TAGDIRS) $(TAGFINDARGS)` System.map: u-boot @$(NM) $< | \ @@ -1838,7 +1841,7 @@ clobber: clean -o -name '*.srec' -o -name '*.bin' -o -name u-boot.img \) \ -print0 \ | xargs -0 rm -f - rm -f $(OBJS) *.bak tags TAGS + rm -f $(OBJS) *.bak tags TAGS cscope.* rm -fr *.*~ rm -f u-boot u-boot.map u-boot.hex $(ALL) rm -f tools/crc32.c tools/environment.c tools/env/crc32.c -h --__--__-- _______________________________________________ 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.11/264 - Release Date: 2006/2/17 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.11/264 - Release Date: 2006/2/17

1 0

[U-Boot-Users] Flash Configuration in TQM860L?
by 秦宇伟 19 Feb '06

19 Feb '06

Dear all: I want to know the Flash configuration in TQM860L.h. Please help me point out the bugs in the following configuration: Two AM29LV160 chips; A29-A10 (MPC860) is connected to A0-A19 (AM29LV160); CS0# ( MPC860) is connected to CE# (AM29LV160); OE#/GPL_AB1(MPC860) is connected to OE# (AM29LV160); WE0#/BS_B0# (MPC860) is connected to WE#(AM29LV160-chip1); WE2#/BS_B2# (MPC860) is connected to WE#(AM29LV160-chip2); BYTE#(AM29LV160) is set to Vcc; RY/BY#(AM29LV160) is NC??; Thank you very much! Yours Sincerely, Yuwei Qin 　　　　　　　　　　　　　　　yuwei_qin(a)photontec.com 　　　　　　　　　　2006-02-19

2 1

[U-Boot-Users] PPC8xx chip select configuration at startup
by Steve Strublic 17 Feb '06

17 Feb '06

Hello all, After a lot of reading of code, FAQs, and this list, I have successfully ported U-Boot to my custom PowerPC 852T platform. (And by the way, all you out there that have problems with SDRAM... make sure your UPM tables are right; cost me a day for two mistyped values.) However, I ran into something that I call unusual, and would like some advice/opinions. My board boots to address 0x0, with FLASH located there. The desired location for FLASH memory will be at 0x0400_0000. This is the address space to which I link U-Boot. The way I understand U-Boot to work is that for PPC8xx platforms, FLASH memory is generally located at address 0x0, and CS0 is required to map both address 0x0 and your absolute address space (0x0400_0000 in my example) so it can seamlessly jump from one to the other. Later on, when SDRAM needs to be initialized, all chip selects 0-7 are configured based on definitions in your board's config include file. Assuming this is correct, I found that my platform would not run past the jump from address space mapped at 0x0 to address space mapped at 0x0400_0000, and I boiled it down to values in CS0's option register that are contrary to what I require. What I ended up doing is program CS0 base and option registers with what I call 'boot' values, to correctly configure OR0 to allow this duplication of address space for FLASH. This was done immediately prior to the jumpoff point. Everything from that point on was per normal U-Boot startup (including the remapping of CS0 later on). This puts my platform into a known state that correctly maps all peripheral devices with their proper sizing and address masks. Is this something uncommon or am I missing something obvious? Is this contrary to the goals for U-Boot's architecture at startup of PPC8xx processors? Or is this possibly something one would like to see incorporated into U-Boot? Any advice/comments are appreciated... TIA, Steve ------ Steve Strublic Network Solutions Group Hypercom Corporation Phoenix, AZ

4 6

RE: [U-Boot-Users] MPC8xx chip select configuration at startup
by Steve Strublic 17 Feb '06

17 Feb '06

> Wolfgang Denk wrote: > > In message <43F6091D.7040901(a)paulidav.org> you wrote: > > [snip] > > >>> The desired location for FLASH memory will be at 0x0400_0000. This is > >>> the address space to which I link U-Boot. > >>> > >> That's OK. It will simply limit your SDRAM size to 64M. > > > > And my cause other problems as well. Don't do it. Map flash at a high > > address. > > Just to be explicit: you _must_ map your flash _well_above_ 0xC000_0000 > (the start of the linux kernel area) if you want to run linux. I didn't know that about Linux... but who says I'm going to run Linux? (OK, I am, just kidding.) > > Since _you_ control BR0 (don't listen to them hardware engineers), you > can put it anywhere you want. 0xFF00_0000 is a good spot. 0xFFF0_0000 > is not as good of a spot because it limits you to 16MB of flash. Think > big. ;-) 0xFF00_0000 makes sense to me, and works fine. It fits in with what I've seen in other implementations. As I stated previously, 0x0400_0000 was a purely historical number. I'll take the recommendations of those who have been there before... thanks. > > > Best regards, > > > > Wolfgang Denk > > Best regards, > gvb Thanks Jerry, Steve

1 0

RE: [U-Boot-Users] PPC8xx chip select configuration at startup
by Steve Strublic 17 Feb '06

17 Feb '06

> -----Original Message----- > From: wd(a)denx.de [mailto:wd@denx.de] > Sent: Friday, February 17, 2006 2:08 PM > To: Steve Strublic > Cc: Vladimir Gurevich; u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup > > In message > <482F3C06ECF00C44AEC226520C6FCB1A51ED01(a)EXCHANGEVS.HYPERCOM.COM> you > wrote: > > > > So guess what. I got U-boot to run without the 'boot value' > > modification to CS0 I had discussed. I think my problem was related to > > my debugging tool, the visionCLICK ICE... I had it configured to set > > WHile I have nothing against a little Vision*-bashing, you should > stay honest here: The tool is probably not to blame... > > > values into the target at reset. So of course the values of BR0/OR0 > > ... this was a pilot error. Yup, sure was. I'm just glad everything is running smoothly. > > > were overridden with whatever I had in there... which were not the same > > as what the board booted up with. I hadn't occurred to me to look for > > and turn off this option until you asked for the values. > > I always recommend to use a *minimal* init file in your debug tool, > just doing what is unavoidable (i. e. disable the watchdog). You > should never mess with the memory controller configuration when > trying to debug U-Boot. > > 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 > Mr. Cole's Axiom: > The sum of the intelligence on the planet is a constant; > the population is growing.

1 0

RE: [U-Boot-Users] PPC8xx chip select configuration at startup
by Steve Strublic 17 Feb '06

17 Feb '06

Vladimir, I've solved my problem thanks to your request for the values of CS0 at power-up. Here's how my board comes up at hard reset: BR0 0400_0801 OR0 0000_0FF4 (the defaults) And this makes sense to me... the board boots at address 0, with FLASH repeating at 0400_0000, 0800_0000, etc., and OR0 allows access to all instances of the aliasing, with max wait states, relaxed timing, burst inhibit, etc. So guess what. I got U-boot to run without the 'boot value' modification to CS0 I had discussed. I think my problem was related to my debugging tool, the visionCLICK ICE... I had it configured to set values into the target at reset. So of course the values of BR0/OR0 were overridden with whatever I had in there... which were not the same as what the board booted up with. I hadn't occurred to me to look for and turn off this option until you asked for the values. So I can thankfully say this is a non-issue for me, and I don't have to do anything to U-Boot, which pleases me greatly. Thanks much for the help! Steve -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Vladimir Gurevich Sent: Friday, February 17, 2006 10:35 AM To: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Hi Steve, Steve Strublic wrote: > I understand that 0400_0000 is my choice; it's what we use in the > current product implementation (an eCos-based solution). It wouldn't be > a bad idea to bump it. So, you are trying to use U-boot to boot some existing code that you can't modify, correct? > And I agree that the hard reset word may be other than what U-Boot's > startup sequence requires, but I'm stuck. I cannot spin the board to > alter its contents. > That's a pain. Why don't you send us the values of BR0/OR0 just after power-on reset and what you'd like them to be so that we can take a look and see more clearly what the problem is if it is there. Happy hacking, Vladimir ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ 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] Safe firmware updates
by Ian Ridge 17 Feb '06

17 Feb '06

Hi, Power disconnect during firmware update: We are implementing facility for automatic firmware upgrades (either the Linux uImage or cramfs) on our embedded device. However there is a requirement that the device is not broken by (the user for example) disconnecting the power supply at any stage during the flash update. In the absence of a backup battery, I guess the boot loader would have to be modified to cope with this. Has anybody produced a solution already? If not I'm considering adding a command to u-boot. 'update' could work as follows: 1) Linux application / scripts are responsible for downloading the firmware upgrade, then erasing and copying into an image in free area of the flash with CRC. 2) Linux reboots the device, so u-boot can take over. 3) 'update' command is called early in bootcmd script. 4) 'update' routine checks specified flash location for new upgrade image with valid CRC. If no image found or has bad CRC it returns, control passes to next command in bootcmd, and Linux boots normally. 5) 'update' routine erases target area of flash, and then copies content of upgrade image to target location. 6) 'update' routine erases upgrade image to prevent upgrade attempt on subsequent boots. Power cut during stage 1 would result in original firmware remaining. Power cut during stages 2 to 5 would result in firmware upgrade when power is restored. Power cut during state 6 would result in new firmware remaining. (as partial erase of update image would have bad CRC). Maybe the upgrade (cramfs, kernel uImage, etc) could be stored in another uImage with a new type. Any comments? Ian DISCLAIMER: The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone. This email has been scanned by our Anti Virus software before leaving the premises. APD Communications takes no responsibility for any damage or loss caused by any undetected virus being inadvertently transmitted with this message.

3 5

RE: [U-Boot-Users] PPC8xx chip select configuration at startup
by Steve Strublic 17 Feb '06

17 Feb '06

Hi Vladimir, So I was at least partially right. That's comforting. :) I understand about the aliasing, but thanks for the explanation anyhow. It confirms my knowledge. I understand that 0400_0000 is my choice; it's what we use in the current product implementation (an eCos-based solution). It wouldn't be a bad idea to bump it. And I agree that the hard reset word may be other than what U-Boot's startup sequence requires, but I'm stuck. I cannot spin the board to alter its contents. So I need a way to work with what I've got. If I can do it without modifying U-Boot, that's great... but if I can't, then I need a way that would be acceptable to the community as a whole (I've been down the path of maintaining one-off 'open source' software before, and I won't do it again). I'm certainly no U-Boot savant, as I've only been working with it for a couple of weeks. The ease by which I was able to get U-Boot running speaks highly of its design, implementation, and support. So it's remotely possible that I don't understand something. :) If there's a currently supported way to do what I need, I'll use it... but I didn't see one. So any help is appreciated, even if it's less than constructive criticism. I can't be the only one out there who's experienced this type of issue... Thanks, Steve -----Original Message----- From: Vladimir Gurevich [mailto:vag@paulidav.org] Sent: Friday, February 17, 2006 9:58 AM To: Steve Strublic Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup Hello Steve, Steve Strublic wrote: > > My board boots to address 0x0, with FLASH located there. > What actually happens is that right after power-on reset CS0 covers the whole memory address space. So, for example, if you have 64MB FLASH (0x04000000) and thus you have 26 address lines (A0-A25 on the FLASH chip which is A6-A31 on PPC) connected, your FLASH will appear at addresses 0x00000000, 0x04000000, 0x08000000, 0x0c000000, 0x10000000, etc. This is called aliasing. U-boot relies on this effect. So, it is linked to run using 0x04000000 as the base address and you can see it in the debugger. So even though initially CS0 points to address 0, this is still possible because of aliasing. So, yes, the first instruction to be executed is located at 0x0 (that's how your CPU works), but then the code works using 0x04000000 as a base and that is fine. The CPU does not care. > > The desired location for FLASH memory will be at 0x0400_0000. This is > the address space to which I link U-Boot. > That's OK. It will simply limit your SDRAM size to 64M. > > The way I understand U-Boot to work is that for PPC8xx platforms, > FLASH memory is generally located at address 0x0, and CS0 is required > to map both address 0x0 and your absolute address space (0x0400_0000 > in my example) so it can seamlessly jump from one to the other. > I am not sure "required" is the right word. Let's say you get it for free :) > > Later on, when SDRAM needs to be initialized, all chip selects 0-7 are > configured based on definitions in your board's config include file. > Correct. > > Assuming this is correct, I found that my platform would not run past > the jump from address space mapped at 0x0 to address space mapped at > 0x0400_0000, and I boiled it down to values in CS0's option register > that are contrary to what I require. What I ended up doing is program > CS0 base and option registers with what I call 'boot' values, to > correctly configure OR0 to allow this duplication of address space for > FLASH. This was done immediately prior to the jumpoff point. > I am not sure what is wrong with your CS0 configuration. Most probably your power-on reset word is not quite correct, because that's where these initial values come from. What you are doing is definitely an unnecessary step. Happy hacking, Vladimir

3 2

[U-Boot-Users] Memory Banks & Flash Mapping
by Josef Angermeier 17 Feb '06

17 Feb '06

Hello u-boot users, in the README-file you can read this: - FLASH_BASE0_PRELIM, FLASH_BASE1_PRELIM, CFG_REMAP_OR_AM, CFG_PRELIM_OR_AM, CFG_OR_TIMING_FLASH, CFG_OR0_REMAP, CFG_OR0_PRELIM, CFG_BR0_PRELIM, CFG_OR1_REMAP, CFG_OR1_PRELIM, CFG_BR1_PRELIM: Memory Controller Definitions: BR0/1 and OR0/1 (FLASH) So memory bank 1 shouldn't get used for SDRAM, but bank 2 and 3 ? *_PRELIM is the address before u-boot relocation to RAM, isn't it ? But *_REMAP after that ? Whats CFG_FLASH_BASE good for, if i have to configure the memory bank base register value of my MPC875-board anyway with CFG_BR0_* ? Further, i am now facing the problem, that my BR1 SDRAM-memory bank gets changed correctly at u-boot runtime, but the BR0-flash-memory-bank keeps its PRELIM-value when reaching the command shell. I now wonder, if i misconfigured my board header file, or if not, where i shall add the new memory bank reprogramming code for flash space - in drivers/cfi_flash.c:flash_init() ? One last question: I am porting u-boot to a not yet very popular developer board with a MPC875. Shall i add my changes although to your CVS repository ? Thanks in advance Josef

2 6