bring ARM memory layout in line with the documented behaviour
PATCH 1/1 bring ARM memory layout in line with the documented behaviour
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
Dear Anders,
Quoted 7 lines · in message <[email protected]> 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!)
Quoted 6 lines
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_BASEof 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.
Quoted 8 lines
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?
Quoted 3 lines
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
Signature · 5 lines
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
Wolfgang Denk <[email protected]> schreibt:
Quoted 13 lines
Quoted 4 lines · in message <[email protected]> you wrote:
Since the stack and malloc-heap are now located below the U-Boot code, the
TEXT_BASEof 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_BASEshould 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:
Quoted 8 lines
TEXT_BASEdetermines 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?
Quoted 10 lines
Quoted 9 lines
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]
Quoted 4 lines
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.
Quoted 4 lines
I think some more code should be changed like the allocation of display memory (see
CONFIG_VFDin "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.
Quoted 3 lines
Any test results / comments from the other board maintainers?
Any comment is appreciated!
Cheers
Anders
Dear Anders,
Quoted 3 lines · in message <[email protected]> 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.
Quoted 2 lines
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...
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
_armboot_endis 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.
Quoted 2 lines
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
Signature · 5 lines
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
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
Quoted 1 line · Anders Larsen
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
Signature · 5 lines
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
In reply to Anders LarsenDear Anders,
Quoted 3 lines · in message <[email protected]> you wrote:
on 2003-09-17 I suggested a lengthy (and quite intrusive) patch to brush up the ARM memory layout.
...
Quoted 4 lines
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 :-(
Quoted 1 line
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
Signature · 4 lines
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
Wolfgang Denk <[email protected]> schreibt:
Quoted 6 lines
Quoted 1 line · in message <[email protected]> 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
Dear Anders,
Quoted 6 lines · in message <[email protected]> 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.
Quoted 1 line
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
Signature · 4 lines
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
Quoted 3 lines · Wolfgang Denk
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
Signature · 5 lines
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
Dear Robert,
Quoted 5 lines · in message <[email protected]> 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
Signature · 3 lines
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
Quoted 3 lines · Wolfgang Denk
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
Signature · 5 lines
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
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Wolfgang Denk
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
Signature · 4 lines
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 LehenbauerHi,
I am confused about ARM and the use of TEXT_BASE:
Quoted 8 lines · Anders Larsen
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]
Quoted 2 lines · Wolfgang Denk
TEXT_BASEdetermines 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
Steven Scholz <[email protected]> schreibt:
Quoted 1 line
I am confused about ARM and the use of
TEXT_BASE:
That's understandable.
Quoted 10 lines
Quoted 8 lines · Anders Larsen
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.
Quoted 5 lines
Quoted 2 lines · Wolfgang Denk
TEXT_BASEdetermines the start address in FLASH memory which is used before relocation.
...for all architectures except ARM.
Quoted 4 lines
Now is
TEXT_BASEthe "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
Wolfgang Denk
AppliedPATCH 1/1 bring ARM memory layout in line with the documented behaviour
In reply to Anders LarsenDear Anders,
Quoted 7 lines · in message <[email protected]> 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!)
Quoted 6 lines
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_BASEof 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.
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 5 lines
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
PATCH 1/1 bring ARM memory layout in line with the documented behaviour
Quoted 4 lines · Wolfgang Denk
Quoted 2 lines
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
Signature · 5 lines
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