All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anders Larsen <alarsen@rea.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour
Date: Thu, 18 Sep 2003 14:15:21 +0200	[thread overview]
Message-ID: <fc.004c4e48001cc2803b9aca007685644e.1cc321@rea.de> (raw)
In-Reply-To: <20030918110044.6595DC59E4@atlas.denx.de>

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

  reply	other threads:[~2003-09-18 12:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-17 14:35 [U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour Anders Larsen
2003-09-18 11:00 ` [U-Boot-Users] " Wolfgang Denk
2003-09-18 12:15   ` Anders Larsen [this message]
2003-09-18 21:20     ` Wolfgang Denk
2003-10-13 16:10       ` [U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation Anders Larsen
2003-10-13 16:16         ` Robert Schwebel
2003-10-13 16:40         ` Wolfgang Denk
2003-10-14  7:55           ` Anders Larsen
2003-10-14 20:30             ` Wolfgang Denk
2003-10-16  9:56               ` Robert Schwebel
2003-10-16 10:31                 ` Wolfgang Denk
2003-10-16 10:50                   ` Robert Schwebel
2003-10-16 11:21                     ` Wolfgang Denk
2003-10-27 15:05   ` [U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour Steven Scholz
2003-10-27 16:02     ` [U-Boot-Users] Re: [PATCH][CFT] bring ARM memory layout in line with the documentation Anders Larsen
2003-12-06 16:08 ` [U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour Wolfgang Denk
2003-12-07  8:37   ` Robert Schwebel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc.004c4e48001cc2803b9aca007685644e.1cc321@rea.de \
    --to=alarsen@rea.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.