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

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

[Steve Strublic]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060213/4701ca70/attachment.htm 

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?"

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

[Vladimir Gurevich]

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

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Change is the essential process of all existence.
	-- Spock, "Let That Be Your Last Battlefield",
	   stardate 5730.2

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

[Jerry Van Baren]

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

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

[Vladimir Gurevich]

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

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Above all else -- sky.

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

[Steve Strublic]

Hi Wolfgang,

If I had a choice in using a boot address other than 0, I would use it,
but this is a porting effort to an existing platform.  I do not have a
way to change it.  So I'm stuck with what I've got.

And here's a snippet from the README that led me to the conclusion that
this was common:

>System Initialization:
>----------------------
> In the reset configuration, U-Boot starts at the reset entry point
> (on most PowerPC systems at address 0x00000100). Because of the reset
> configuration for CS0# this is a mirror of the onboard Flash memory.
> To be able to re-map memory U-Boot then jumps to its link address.

So to say that this is completely wrong seems a little strong.  What
part am I specifically wrong about?

Believe me, I have little desire to modify a known, stable, widely
available system that operates on a multitude of platforms and
processors.  I just want to get it right.  I've read the README
extensively and thanks to it I've gotten everything else straight; just
this one item is causing me problems.  Can you give me a hint as to
where in the README I should look to find the information that resolves
this issue?

Thanks,

Steve

-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Thursday, February 16, 2006 5:07 PM
To: Steve Strublic
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at startup 

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?"

[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

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

[Vladimir Gurevich]

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

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

[Wolfgang Denk]

In message <482F3C06ECF00C44AEC226520C6FCB1A51ECFF@EXCHANGEVS.HYPERCOM.COM> you wrote:
> 
> 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.  

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 that

No need to modify U-Boot. Just configure it correctly.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at 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

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

[Steve Strublic]

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@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Vladimir
Gurevich
Sent: Friday, February 17, 2006 10:35 AM
To: u-boot-users at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

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

[Wolfgang Denk]

In message <482F3C06ECF00C44AEC226520C6FCB1A51ED01@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.

> 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 at denx.de
Mr. Cole's Axiom:
        The sum of the intelligence on the planet is a constant;
        the population is growing.

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

[Steve Strublic]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: Friday, February 17, 2006 2:08 PM
> To: Steve Strublic
> Cc: Vladimir Gurevich; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] PPC8xx chip select configuration at
startup
> 
> In message
> <482F3C06ECF00C44AEC226520C6FCB1A51ED01@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 at denx.de
> Mr. Cole's Axiom:
>         The sum of the intelligence on the planet is a constant;
>         the population is growing.