[U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Anders Larsen]

Hi,

here's a fairly lengthy patch against 0.4.8 that brings the memory
layout of all supported ARM CPUs in line with the documentation.
This has the positive side-effect of allowing U-Boot to actually run on
PXA CPUs (the stock PXA implementation didn't set the start-address of
the malloc pool at all!)

The memory layout now more or less conforms to the standard as defined
in the README (the absolute addresses are board-specific, of course).

Since the stack and malloc-heap are now located below the U-Boot code,
the TEXT_BASE of the supported ARM boards can be increased accordingly
(for most (but not all) boards, the patch already does this).

Memory layout example based on my PXA255 (TEXT_BASE = 0xA07E0000):

0xA079FF74   Monitor Stack (growing downwards)
0xA079FF80   Board Info Data and permanent copy of Global Data
0xA07A0000   Malloc Arena
0xA07E0000   RAM copy of Monitor Code
...          optional: Frame Buffer
0xA07FFFFF   [End of RAM]

Since I only have access to PXA-based HW, I was only able to verify
that U-Boot still *builds* for all supported ARMs; I have to rely on
your help to see if it also *runs* correctly.

CHANGELOG:
   Bring ARM memory layout in line with the documentation.


Wolfgang: Please don't apply this patch until we have some feedback
from the ARM maintainers.

Robert: When/if this patch is eventually applied, you can probably push
most of your PXA -ptx stuff without having it break things.

Cheers
 Anders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot.arm-mem-layout.patch.gz
Type: application/x-gzip
Size: 6596 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20030917/9da24daf/attachment.bin 

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001cba02004c4e48001cba02.1cba71@rea.de> you wrote:
> 
> here's a fairly lengthy patch against 0.4.8 that brings the memory
> layout of all supported ARM CPUs in line with the documentation.
> This has the positive side-effect of allowing U-Boot to actually run on
> PXA CPUs (the stock PXA implementation didn't set the start-address of
> the malloc pool at all!)
> 
> The memory layout now more or less conforms to the standard as defined
> in the README (the absolute addresses are board-specific, of course).
> 
> Since the stack and malloc-heap are now located below the U-Boot code,
> the TEXT_BASE of the supported ARM boards can be increased accordingly
> (for most (but not all) boards, the patch already does this).

This is actually the biggest "problem" with the existing ARM code (as
inherited from ARMBoot): with  the  orginal  philosophy  of  PPCBoot,
TEXT_BASE should not play ANY role here.

The way I would  like  to  soo  this  implemented,  and  as  it  _is_
implemented in PPCBoot (and in U-Boot for PowerPC) is as follows:

TEXT_BASE determines the start address in FLASH memory which is  used
before relocation.

The RAM initialization code is, among other  things,  responsible  to
determine  the  size  of  the RAM, and the relocation address is then
calculated DYNAMICALLY dependend on the RAM size found.  This  allows
that boards with different RAM sizes will always provide maximum free
RAM under U-Boot.


> Memory layout example based on my PXA255 (TEXT_BASE = 0xA07E0000):
> 
> 0xA079FF74   Monitor Stack (growing downwards)
> 0xA079FF80   Board Info Data and permanent copy of Global Data
> 0xA07A0000   Malloc Arena
> 0xA07E0000   RAM copy of Monitor Code
> ...          optional: Frame Buffer
> 0xA07FFFFF   [End of RAM]

I still see  references  to  _armboot_start,  _armboot_end_data,  and
_armboot_end - which role do these play now? Can we get rid of them?

How are they (should they be) set in your memory map above?

> Since I only have access to PXA-based HW, I was only able to verify
> that U-Boot still *builds* for all supported ARMs; I have to rely on
> your help to see if it also *runs* correctly.


I think some more code should  be  changed  like  the  allocation  of
display memory (see CONFIG_VFD in "lib_arm/board.c") - this should be
done like we do for PowerPC, too.


Any test results / comments from the other board maintainers?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Politics:  A  strife  of  interests  masquerading  as  a  contest  of
principles. The conduct of public affairs for private advantage.
- Ambrose Bierce

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>in message <fc.004c4e48001cba02004c4e48001cba02.1cba71@rea.de> you wrote:
>> 
>> Since the stack and malloc-heap are now located below the U-Boot code,
>> the TEXT_BASE of the supported ARM boards can be increased accordingly
>> (for most (but not all) boards, the patch already does this).
>
>This is actually the biggest "problem" with the existing ARM code (as
>inherited from ARMBoot): with  the  orginal  philosophy  of  PPCBoot,
>TEXT_BASE should not play ANY role here.
>
>The way I would  like  to  soo  this  implemented,  and  as  it  _is_
>implemented in PPCBoot (and in U-Boot for PowerPC) is as follows:
>
>TEXT_BASE determines the start address in FLASH memory which is  used
>before relocation.
>
>The RAM initialization code is, among other  things,  responsible  to
>determine  the  size  of  the RAM, and the relocation address is then
>calculated DYNAMICALLY dependend on the RAM size found.  This  allows
>that boards with different RAM sizes will always provide maximum free
>RAM under U-Boot.

Dear Wolfgang,

are you saying that the patch doesn't go far enough?
(I feared that the patch might have gone too far :-)

It looks like a substantial amount of work to implement your wishes (but
its doable, I believe).

Would you accept the patch as is as a first step in that direction (in
order not to change too much in one step) provided the other ARM board
maintainers don't object?
>
>> Memory layout example based on my PXA255 (TEXT_BASE = 0xA07E0000):
>> 
>> 0xA079FF74   Monitor Stack (growing downwards)
>> 0xA079FF80   Board Info Data and permanent copy of Global Data
>> 0xA07A0000   Malloc Arena
>> 0xA07E0000   RAM copy of Monitor Code
>> ...          optional: Frame Buffer
>> 0xA07FFFFF   [End of RAM]
>
>I still see  references  to  _armboot_start,  _armboot_end_data,  and
>_armboot_end - which role do these play now? Can we get rid of them?
>
>How are they (should they be) set in your memory map above?

_armboot_start contains the value of TEXT_BASE (0xA07E0000); it seems
TEXT_BASE and _armboot_start are both used for the same purpose in
different parts of the (ARM) code.
Furthermore, the startup code (cpu/<arm>/start.S) internally uses
another variable (_TEXT_BASE) with the same content as _armboot_start.
I agree that this mess should be cleaned up.

_armboot_end_data is the end address of the initialized data section,
and is only used in one place (board/logodl/flash.c - the reference in
lib_arm/board.c is purely informational).

_armboot_end is the end address of the BSS and is used to determine
the address of the VFD buffer.

Eliminating those should be doable, and at least the patch already
eliminates _armboot_real_end.
>
>I think some more code should  be  changed  like  the  allocation  of
>display memory (see CONFIG_VFD in "lib_arm/board.c") - this should be
>done like we do for PowerPC, too.

Again, my available HW doesn't have a display, so I can't test it.
I'll take a look at it anyway, though.
>
>
>Any test results / comments from the other board maintainers?

Any comment is appreciated!

Cheers
 Anders

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001cc2803b9aca007685644e.1cc321@rea.de> you wrote:
> 
> are you saying that the patch doesn't go far enough?
> (I feared that the patch might have gone too far :-)

No, I didn't want to say that.I think the patch is pretty good as is,
separating one step can can be done indeoend of the other  things.  I
just  wanted  to  point out that this is only part of the tasks which
are ahead of us.

> It looks like a substantial amount of work to implement your wishes (but
> its doable, I believe).

Yes, it's some work; the most difficult thing is to verify that  such
changes don;t break any of the existing ports - and some of these are
pretty  complex  and feature-rich. Complete re-testing just one board
may well take a man-week or more...

> Would you accept the patch as is as a first step in that direction (in
> order not to change too much in one step) provided the other ARM board
> maintainers don't object?

Yes, I will.

> Furthermore, the startup code (cpu/<arm>/start.S) internally uses
> another variable (_TEXT_BASE) with the same content as _armboot_start.
> I agree that this mess should be cleaned up.

Fine. Let's remember this for the next step, then.

> _armboot_end is the end address of the BSS and is used to determine
> the address of the VFD buffer.

This not optimal. Ideally, the display buffer would be located at the
very end of memory (BTW: the same is  true  for  the  log  buffer  if
configured), and U-Boot below it.

> Again, my available HW doesn't have a display, so I can't test it.
> I'll take a look at it anyway, though.

Well, you probably can test with the log buffer enabled and check  if
the  log buffer information can be passed to the Linux kernel (umm...
I think this hasn't been tried ever on an ARM system)


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Anders Larsen]

Hi,

on 2003-09-17 I suggested a lengthy (and quite intrusive) patch to brush
up the ARM memory layout.

So far, only Kshitij (OMAP maintainer) has responded - he reported one
day after I suggested the patch that it worked on his hardware.

The other ARM maintainers probably either
- haven't found any adverse effects,
- haven't found the time to test the patch yet,
- or simply do not care too much.

How do we proceed from here?

Cheers
 Anders

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Robert Schwebel]

On Mon, Oct 13, 2003 at 06:10:07PM +0200, Anders Larsen wrote:
> How do we proceed from here?

I would welcome the patch as it would make my current tweaks
unnecessary, although it should be clear that the long term solution
Wolfgang wants to have is a reunified C sequence which is adapted to the
way it is done on ppc. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001d8a413b9aca0038e845ef.1d8a4a@rea.de> you wrote:
> 
> on 2003-09-17 I suggested a lengthy (and quite intrusive) patch to brush
> up the ARM memory layout.
...
> The other ARM maintainers probably either
> - haven't found any adverse effects,
> - haven't found the time to test the patch yet,
> - or simply do not care too much.

I am afraid it's the "don't care" attitide :-(

> How do we proceed from here?

I am in the process of  stabilizing  the  code  for  version  1.0;  I
checked  your patch - it looks OK to me, but I would like to merge it
only after releasing 1.0.


[Ummm... everybody who has some stuff in  his  queue  that  has  been
waiting  there  for ages: I will probaby delay _all_ major changes to
the code until after the release of 1.0 anyway, so take your time and
clean up before sending patches.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If the facts don't fit the theory, change the facts.
                                                   -- Albert Einstein

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>in message <fc.004c4e48001d8a413b9aca0038e845ef.1d8a4a@rea.de> you wrote:
>> How do we proceed from here?
>
>I am in the process of  stabilizing  the  code  for  version  1.0;  I
>checked  your patch - it looks OK to me, but I would like to merge it
>only after releasing 1.0.

Hi Wolfgang,

although I'd argue that the patch indeed acts to stabilize the ARM code
(at least it brings it one step in the direction you want), I realize
that it is a difficult decision - either you release 1.0 without the
patch, with known broken PXA implementation, or you merge it and risk
breaking (some of the) other ARM implementations...

At any rate, of course I'd like to see it merged in a foreseeable future
(since that would releave me of the burden of having to maintain my own
tree just for the sake of the one board I'm responsible for), and Robert
clearly has similar interests in PXA.

Perhaps you'd reconsider?

Cheers
 Anders

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001d8cf33b9aca0064fd7e87.1d8d36@rea.de> you wrote:
> 
> although I'd argue that the patch indeed acts to stabilize the ARM code
> (at least it brings it one step in the direction you want), I realize
> that it is a difficult decision - either you release 1.0 without the
> patch, with known broken PXA implementation, or you merge it and risk
> breaking (some of the) other ARM implementations...

Thisis exactly the dilemman I'm in. And my decision was in favour  of
keeping  known-to-be-stable  boards  stable, and accept that there is
unfinished work.

> At any rate, of course I'd like to see it merged in a foreseeable future

It will be merged RSN ;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Language shapes the way we think, and determines what we  can  think
about."                                                 - B. L. Whorf

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Robert Schwebel]

On Tue, Oct 14, 2003 at 10:30:14PM +0200, Wolfgang Denk wrote:
> Thisis exactly the dilemman I'm in. And my decision was in favour  of
> keeping  known-to-be-stable  boards  stable, and accept that there is
> unfinished work.

I know that this is not an easy decision for you and I've already
accepted that we have to live with our own -ptx patches for some time;
long term I would embrace if you could decide to have a clear separation
between a stable and unstable branch. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Wolfgang Denk]

Dear Robert,

in message <20031016095613.GJ25427@pengutronix.de> you wrote:
> 
> I know that this is not an easy decision for you and I've already
> accepted that we have to live with our own -ptx patches for some time;
> long term I would embrace if you could decide to have a clear separation
> between a stable and unstable branch. 

I spend a lot of time working with different branches of some  source
tree,  so this is something I will try to avoid for U-Boot. There are
clearly marked stable versions (x.y.0), and there are  "unstable"  or
"development"  versions.  This is what we have now, and what I intend
to stay with for the foreseeable future.

U-Boot is not such  a  big  project  with  many  independ  groups  of
developers working on different areas. Even bigger contributions like
support for a new hardware architecture are usually pretty orthogonal
to existing code - or can be made so.

I do not see the need for an "unstable branch".  On  contrary,  I  am
convinced  that  a second branch in the public source tree would only
increase the necessary maintenance efford.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I program, therefore I am.

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Robert Schwebel]

On Thu, Oct 16, 2003 at 12:31:11PM +0200, Wolfgang Denk wrote:
> I do not see the need for an "unstable branch".  On  contrary,  I  am
> convinced  that  a second branch in the public source tree would only
> increase the necessary maintenance efford.

Unfortunately this makes non-orthogonal patches difficult because they
surely could break things. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Wolfgang Denk]

In message <20031016105052.GR25427@pengutronix.de> you wrote:
> On Thu, Oct 16, 2003 at 12:31:11PM +0200, Wolfgang Denk wrote:
> > I do not see the need for an "unstable branch".  On  contrary,  I  am
> > convinced  that  a second branch in the public source tree would only
> > increase the necessary maintenance efford.
> 
> Unfortunately this makes non-orthogonal patches difficult because they
> surely could break things. 

I disagree. It just means that we will have to make sure to clean  up
any such mess quickly, at least before the next release.

This is a policy decision. It prevents that the project  is  drifting
apart  in  different  directions.  I  don't  have the manpower and/or
nerves to deal with many different branches.

Branches are evil. Just look at the mess we  have  with  the  PowerPC
Linux  kernel.  There  is  linux-2.4 and linux-2.5 on kernel.org, and
linuxppc-2.4 and linuxppc_2_4_devel and linuxppc-2.5 and BenH's "pmac
stable tree" and the ameslab tree and the ppc64 tree and ...


If some change breaks the code so hard that it is impossible  to  fix
it between releases that the change needs to be reworked first.

We did without branches when marging in ARMBoot, and when adding more
architectures, and we will try to do without branches in the  future.
Period.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There are bugs and then there are bugs.  And then there are bugs.
                                                    - Karl Lehenbauer

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Steven Scholz]

Hi,

I am confused about ARM and the use of TEXT_BASE:

Anders Larsen wrote:
 > Memory layout example based on my PXA255 (TEXT_BASE = 0xA07E0000):
 >
 > 0xA079FF74   Monitor Stack (growing downwards)
 > 0xA079FF80   Board Info Data and permanent copy of Global Data
 > 0xA07A0000   Malloc Arena
 > 0xA07E0000   RAM copy of Monitor Code
 > ...          optional: Frame Buffer
 > 0xA07FFFFF   [End of RAM]

Wolfgang Denk wrote:

> TEXT_BASE determines the start address in FLASH memory which is  used
> before relocation.

Now is TEXT_BASE the "address in FLASH memory" or the address of the "RAM copy 
of Monitor Code"???

Thanks!

Steven

[U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation

[Anders Larsen]

Steven Scholz <steven.scholz@imc-berlin.de> schreibt:
>I am confused about ARM and the use of TEXT_BASE:

That's understandable.
>
>Anders Larsen wrote:
> > Memory layout example based on my PXA255 (TEXT_BASE = 0xA07E0000):
> >
> > 0xA079FF74   Monitor Stack (growing downwards)
> > 0xA079FF80   Board Info Data and permanent copy of Global Data
> > 0xA07A0000   Malloc Arena
> > 0xA07E0000   RAM copy of Monitor Code
> > ...          optional: Frame Buffer
> > 0xA07FFFFF   [End of RAM]

The ordering of the blocks in the above memory map is only valid with
my patch applied.
>
>Wolfgang Denk wrote:
>
>> TEXT_BASE determines the start address in FLASH memory which is  used
>> before relocation.

...for all architectures except ARM.
>
>Now is TEXT_BASE the "address in FLASH memory" or the address of the "RAM
>copy 
>of Monitor Code"???

For ARM, TEXT_BASE refers to the RAM copy;
for all other architectures TEXT_BASE refers to FLASH.

Cheers
 Anders

[U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001cba02004c4e48001cba02.1cba71@rea.de> you wrote:
> 
> here's a fairly lengthy patch against 0.4.8 that brings the memory
> layout of all supported ARM CPUs in line with the documentation.
> This has the positive side-effect of allowing U-Boot to actually run on
> PXA CPUs (the stock PXA implementation didn't set the start-address of
> the malloc pool at all!)
> 
> The memory layout now more or less conforms to the standard as defined
> in the README (the absolute addresses are board-specific, of course).
> 
> Since the stack and malloc-heap are now located below the U-Boot code,
> the TEXT_BASE of the supported ARM boards can be increased accordingly
> (for most (but not all) boards, the patch already does this).

Applied. Will push to CVS later this nicght. Sorry this took _that_ long.


> Since I only have access to PXA-based HW, I was only able to verify
> that U-Boot still *builds* for all supported ARMs; I have to rely on
> your help to see if it also *runs* correctly.

I verified it on TRAB.


> Robert: When/if this patch is eventually applied, you can probably push
> most of your PXA -ptx stuff without having it break things.

Robert, please feel free to go on...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have never understood the female capacity to avoid a direct  answer
to any question.
	-- Spock, "This Side of Paradise", stardate 3417.3

[U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

[Robert Schwebel]

On Sat, Dec 06, 2003 at 05:08:52PM +0100, Wolfgang Denk wrote:
> > Robert: When/if this patch is eventually applied, you can probably push
> > most of your PXA -ptx stuff without having it break things.
> 
> Robert, please feel free to go on...

Ok - I have just updated our stuff to 1.0.0, so I'll start with CVS now. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4