[U-Boot-Users] PPC8xx chip select configuration at startup
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
In message 482F3C06ECF00C44AEC226520C6FCB1A51ECB6@EXCHANGEVS.HYPERCOM.COM you wrote:
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
I recommend NOT to use such a low 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
No, this is completely wrong.
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
Please read the README. It's all dicumented there.
Best regards,
Wolfgang Denk
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
In message 43F6091D.7040901@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 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
Wolfgang Denk wrote:
In message 43F6091D.7040901@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
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
In message 43F64A08.7020806@paulidav.org you wrote:
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?
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 least used to) use this address.
See previous postings. And no, TQM uses 0x4000.0000, not 0x0400.0000.
Best regards,
Wolfgang Denk
participants (4)
-
Jerry Van Baren -
Steve Strublic -
Vladimir Gurevich -
Wolfgang Denk