[U-Boot-Users] PPC8xx chip select configuration at startup

[Steve Strublic]

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 at paulidav.org] 
Sent: Friday, February 17, 2006 9:58 AM
To: Steve Strublic
Cc: u-boot-users at 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