[U-Boot-Users] [PATCH][CFT] 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
participants (5)
-
Anders Larsen -
Robert Schwebel -
Robert Schwebel -
Steven Scholz -
Wolfgang Denk