[U-Boot-Users] Memory map on ARM
I would really love to see the memory map problem on ARM being fixed before Wolfgang makes a new release. The problem is that ARMboot had the malloc area above the relocated bootloader, u-boot has it below.
I have fixed this for my two PXA250 board (CSB226, Innokom) and I have a patch for lib_arm/board.c which was rejected by Wolfgang in.
Now we have the situation that some boards do work with the current code, but don't follow the memory map stated in the README and some others do, but don't work without the patch.
IMHO the correct thing to do is to fix the other ARM boards to use the correct memory map. Wolfgang, what is your position?
Robert
In message 20030331112655.GV7702@pengutronix.de you wrote:
I would really love to see the memory map problem on ARM being fixed before Wolfgang makes a new release. The problem is that ARMboot had the
This will not happen. I will release soon, and I will not introduce any bigger architectural changes before.
malloc area above the relocated bootloader, u-boot has it below.
I have fixed this for my two PXA250 board (CSB226, Innokom) and I have a patch for lib_arm/board.c which was rejected by Wolfgang in.
Only because if did not address the whole problem. To do it right, the whole relocation to RAM part has to be redone, taking into account variable RAM sizes.
IMHO the correct thing to do is to fix the other ARM boards to use the correct memory map. Wolfgang, what is your position?
See above.
Best regards,
Wolfgang Denk
On Mon, Mar 31, 2003 at 01:40:28PM +0200, Wolfgang Denk wrote:
This will not happen. I will release soon, and I will not introduce any bigger architectural changes before.
Would you accept a patch with board configuration dependend code for board.c as a workaround solution, just to make the boards work with the release?
Robert
In message 20030331114826.GY7702@pengutronix.de you wrote:
Would you accept a patch with board configuration dependend code for board.c as a workaround solution, just to make the boards work with the release?
The patch I've seen before?
But this does only re-order the position of some memory areas. This should have zero impact on the functioning or non-functioning of the code at all.
Best regards,
Wolfgang Denk
On Mon, Mar 31, 2003 at 02:33:12PM +0200, Wolfgang Denk wrote:
Would you accept a patch with board configuration dependend code for board.c as a workaround solution, just to make the boards work with the release?
The patch I've seen before?
The only thing I did is to change
mem_malloc_init (_armboot_real_end);
into mem_malloc_init(_armboot_start - CFG_MALLOC_LEN);
in board.c. Everything else is ok, at least for my ports I don't have do do other changes.
But this does only re-order the position of some memory areas. This should have zero impact on the functioning or non-functioning of the code at all.
I relocate u-boot to the top of RAM as recommended in the readme, which means that it breaks if mem_malloc_init() wants to initialize the malloc are above _armboot_real_end.
Robert
I would really love to see the memory map problem on ARM being fixed before Wolfgang makes a new release. The problem is that ARMboot had the malloc area above the relocated bootloader, u-boot has it below.
What is the exact problem?
I have a PXA250 target as well (I will never contribute it to u-boot because I like to have CVS write access for my sources). It works perfect for what I can see.
On Mon, Mar 31, 2003 at 04:14:37PM +0200, Holger Schurig wrote:
What is the exact problem?
I have a PXA250 target as well (I will never contribute it to u-boot because I like to have CVS write access for my sources). It works perfect for what I can see.
Yes, but the memory map which is documented in README is different from what ARMboot implemented. When I started my ports I followed the documentation, so all the other ARM implementations rely on the old scheme and my ports on the new one. Long term Wolfgang is surely right when he says that the code has to be cleaned up and unified; I suspect that most of the stuff in lib_[arm|ppc|...] can be unified. But for today's release it would be nice to have a quick fix which makes the boards at least work without a patch.
Robert
participants (4)
-
Holger Schurig -
Robert Schwebel -
Robert Schwebel -
Wolfgang Denk