hi Anders, the patch works for omap(omap1510/omap1610) based boards. But now should we change our TEXT_BASE to accomodate for malloc() memory allocations. regards -kshitij

-----Original Message----- From: Anders Larsen [mailto:alarsen@rea.de] Sent: Thursday, September 18, 2003 5:45 PM To: Wolfgang Denk Cc: Peter Figuli; Marius Grger; Kyle Harris; Gary Jennejohn; Gupta, Kshitij; David Mller; Rolf Offermanns; Robert Schwebel; Alex Z pke; u-boot-users@lists.sourceforge.net Subject: Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour

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