linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: linux-galileo@source.mvista.com, linuxppc-dev@lists.linuxppc.org
Subject: Re: [Linux-galileo] ev64260 bi_rec patch
Date: Fri, 29 Mar 02 16:42:22 PST	[thread overview]
Message-ID: <0203300042.AA13129@ivan.Harhan.ORG> (raw)


Mark A. Greer <mgreer@mvista.com> wrote:

> It *is* in the kernel source (and not the bootloader).

I don't understand what you are talking about.

find_bootinfo looks for bi_recs in a magic location in memory. An external
bootloader has no way of knowing where in memory that is and thus can't put
bi_recs in a place where the kernel will find them. A port that uses
find_bootinfo() can't be booted by anything except the wrapper.

> Also, 15 of the *_setup.c
> files in arch/ppc/platforms call find_bootinfo

That's because no one has bothered so far to boot any of those 15 ports with
any bootloader other than the wrapper. And that's in turn because I haven't
worked on any of those ports. :-) See k2_setup.c and adir_setup.c for the
difference.

> including ev64260_setup.c before I
> modified it.

In my patch I changed it.

> I think the R3 way of doing things is out of date now but maybe Tom
> can elaborate.

It can't be out of date w.r.t. find_bootinfo(), as first everyone used the
latter then I screamed and screamed and screamed and got the K2 port changed.

As the wrapper now puts its bi_recs in the magic location *and* sets R3 to
point to them, either way will work for you, but the R3 way makes it work for
me too.

> You may have a point here.

This is not a may, it's certain.

> I thought the bi_rec's were left around but I need to
> verify.

They aren't.

> I took a quick look and didn't see it being reused but I may have missed it.

You won't see the kernel explicitly reusing the bi_recs memory because it
doesn't even know where that memory is! The bootloader can put the bi_recs
absolutely anywhere in memory. They can be parsed in platform_init because
Linux memory management hasn't started yet, but once it's started the memory
belongs to Linux and you can't expect some random bytes in the middle of memory
to be preserved for eternity.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2002-03-30  0:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-30  0:42 Michael Sokolov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-02  3:35 [Linux-galileo] ev64260 bi_rec patch Michael Sokolov
2002-04-03  5:09 ` Troy Benjegerdes
2002-04-01 20:09 Michael Sokolov
2002-04-01 19:31 Michael Sokolov
2002-04-01 18:03 ` Mark A. Greer
2002-03-29 23:59 Michael Sokolov
2002-03-29 22:24 ` Mark A. Greer
2002-03-29 22:30   ` Mark A. Greer
2002-03-29 22:41     ` Mark A. Greer
2002-03-30  0:45       ` Michael Sokolov
2002-04-01 15:20         ` Tom Rini
2002-04-01 15:25   ` Tom Rini
2002-04-01 15:09     ` Mark A. Greer
2002-04-01 18:53       ` Tom Rini
2002-04-01 19:52         ` Michael Sokolov
2002-04-01 20:21           ` Tom Rini
2002-04-02  2:38           ` Paul Mackerras
2002-04-02  2:50       ` Paul Mackerras

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=0203300042.AA13129@ivan.Harhan.ORG \
    --to=msokolov@ivan.harhan.org \
    --cc=linux-galileo@source.mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).