linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Wolfgang Denk <wd@denx.de>
Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev@ozlabs.org,
	linuxppc-embedded@ozlabs.org, u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
Date: Fri, 20 May 2005 08:20:29 +1000	[thread overview]
Message-ID: <1116541230.5153.8.camel@gaston> (raw)
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>

On Thu, 2005-05-19 at 15:18 +0200, Wolfgang Denk wrote:
> Dear Ben,
> 
> in message <1116478614.918.75.camel@gaston> you wrote:
> > 
> > And here is a second draft with more infos.
> > 
> >            Booting the Linux/ppc64 kernel without Open Firmware
> 
> Thanks a lot for taking the initiative to come to an agreement  about
> the kernel boot interface.
> 
> I have some concerns about the memory foot print and  increased  boot
> time  that  will  result  from  the proposed solution. 

Like everybody it seems, which is funny in a way as I expect pretty much
none (or a few Kb maybe). The kernel side code for managing a
device-tree may represent more, but heh, have you seen the size of a
ppc64 kernel anyways ? I don't think that is very relevant. On the
bootloader side, I don't expect any significant impact. The device-tree
can be very small, and the code required on the bootloader side ranges
from nothing for a pre-built one, to a little bit if the bootloader has
to be able to change/add properties/nodes.

> There are many embedded systems where resources are tight and requirements
> are  aven tighter.  

Amen. (Though heh, this is ppc64, you can't be _that_ tight :)

>It  would  be probably a good idea to also ask for feedback
> from these folks - for example by posting your RFC on the celinux-dev
> mailing list.

I will do when I have a little bit more mature proposal.

> But my biggest concern is that we  should  try  to  come  up  with  a
> solution  that  has  a  wider  acceptance.

No other solution will be accepted on the kernel side. At least for
ppc64

> Especially from the U-Boot
> point of view it is not exactly nice that each of  PowerPC,  ARM  and
> MIPS  use  their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.

True.

> As is, your proposal will add just another incompatible way of  doing
> the  same  thing  (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).

My proposal is the only supported way to boot a ppc64 kernel. There are
talks about backporting support for that to ppc32 as well. Other
architectures are welcome to use it too though :) The device-tree in the
kernel is fully expanded into a tree structure on ppc, since it's
heavily used by various pieces of code all over the place, but for other
architectures that would like to use that, it's possible to limit
themselves to the flattened format. The ppc64 kernel contains some code
to access nodes & properties directly from the flattened format (used
early during boot) which represents very little code.

> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well? 

This has been discussed over and over again, that is the best way to
never come up with a solution as everybody will want something different
and nobody will ever agree.

The present proposal is implemented today on the ppc64 kernel already,
and we have decided to not go backward on this requirement. 

> Maybe you want  to  post  the  RFC  to  lkml,  or  at  least  to  the
> linux-arm-kernel and linux-mips mailing lists?
> 
> Best regards,
> 
> Wolfgang Denk
> 

  parent reply	other threads:[~2005-05-19 22:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1116478614.918.75.camel@gaston>
2005-05-19 13:18 ` [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2) Wolfgang Denk
2005-05-19 13:16   ` Pantelis Antoniou
2005-05-19 22:20   ` Benjamin Herrenschmidt [this message]
2005-05-19 23:14     ` Wolfgang Denk
2005-05-19 23:28       ` Benjamin Herrenschmidt
2005-05-20  6:44       ` Stefan Nickl
2005-05-20  3:51   ` Hollis Blanchard
2005-05-20  6:59     ` Wolfgang Denk
2005-05-20  4:24   ` Paul Mackerras
2005-05-20  4:28     ` 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=1116541230.5153.8.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=u-boot-users@lists.sourceforge.net \
    --cc=wd@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 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).