All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.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 23:20:29 +0200	[thread overview]
Message-ID: <20030918212034.CF477C59E4@atlas.denx.de> (raw)
In-Reply-To: Your message of "Thu, 18 Sep 2003 14:15:21 +0200." <fc.004c4e48001cc2803b9aca007685644e.1cc321@rea.de>

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

-- 
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.

  reply	other threads:[~2003-09-18 21:20 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
2003-09-18 21:20     ` Wolfgang Denk [this message]
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=20030918212034.CF477C59E4@atlas.denx.de \
    --to=wd@denx.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.