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@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