From: Pantelis Antoniou <panto@intracom.gr>
To: Wolfgang Denk <wd@denx.de>
Cc: linuxppc64-dev@ozlabs.org, linuxppc-embedded@ozlabs.org,
u-boot-users@lists.sourceforge.net, linuxppc-dev@ozlabs.org
Subject: Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
Date: Thu, 19 May 2005 16:16:32 +0300 [thread overview]
Message-ID: <428C91B0.4090702@intracom.gr> (raw)
In-Reply-To: <20050519131844.7D707C1512@atlas.denx.de>
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. There are many
> embedded systems where resources are tight and requirements are aven
> tighter. 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.
>
> But my biggest concern is that we should try to come up with a
> solution that has a wider acceptance. 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.
>
> 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).
>
>
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
>
> Maybe you want to post the RFC to lkml, or at least to the
> linux-arm-kernel and linux-mips mailing lists?
>
I'm really interested in having this discussion.
I'm forced to maintain my own u-boot based solution for doing this and
I'd be very interested in whatever gets chosen.
IMHO the current mess is considerable, and at this point I wouldn't
really care if the resulting solution is less than optimal, as long
as there is one.
> Best regards,
>
> Wolfgang Denk
>
Regards
Pantelis
next prev parent reply other threads:[~2005-05-19 13:16 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 [this message]
2005-05-19 22:20 ` Benjamin Herrenschmidt
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=428C91B0.4090702@intracom.gr \
--to=panto@intracom.gr \
--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).