Message-ID: <86802c440804202154t184671d5t33b44fffc4d88cd5@mail.gmail.com>
Date:	Sun, 20 Apr 2008 21:54:13 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Mitch Bradley" <wmb@...mworks.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Andres Salomon" <dilinger@...ued.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Joseph Fannin" <jfannin@...il.com>, linux-kernel@...r.kernel.org,
	jordan.crouse@....com
Subject: Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

On Sun, Apr 20, 2008 at 8:39 PM, Mitch Bradley <wmb@...mworks.com> wrote:
>
> H. Peter Anvin wrote:
>
> > Mitch Bradley wrote:
> >
> > >
> > > The x86 architecture doesn't make this problem easy.
> > >
> > >
> >
> > [long rant about the x86 architecture]
> >
> > It would be more useful if you described the actual defined entry
> conditions from OpenFirmware look like, including if they are well-defined
> for all OF implementations or only for OLPC.
> >
> >    -hpa
> >
>
>  Fair enough...
>
>  To get the second subquestion out of the way:  At the present time, on the
> x86 architecture, "all OF implementations" and "OLPC" are effectively the
> same.  I am unaware of any other x86 OFW deployments in current use.  There
> have been some in the past, on bespoke systems such as Network Appliance
> servers and at least one settop box, but those have fallen by the wayside as
> those companies have shifted over to commodity PC hardware.  The current
> market status quo is that x86 boards are primarily designed for Windows, and
> thus must run legacy BIOS, with some recent migration to EFI, neither of
> which are open source in the strong sense.  While I would like to see more
> OFW penetration into the larger x86 market, I don't really expect it.  x86
> motherboard manufacturing is becoming more and more difficult as signal
> speeds increase, leading to a decline in the number of manufacturers.  The
> existing manufacturers depend on Windows for sales volume and their internal
> procedures and working knowledge are based on legacy BIOS.
>
>  Once upon a time, we had an OFW "binding" document that stipulated the
> interface conditions, with the intention of making that "standard" across
> all OFW-on-x86 systems.  However, by the time OLPC came around, there were
> no other systems to consider, so I felt free to make some changes in the
> interface.  I ended up choosing an ABI that resulted in a simple (in the
> sense of not much code, and no complex state transitions) interface with 2.6
> Linux kernels.
>
>  The interface defined below is not inherently OLPC-specific - it would be
> suitable for any ia32 system that used OFW.  (At a higher level, the set of
> OFW callback functions is architecture-neutral; in this message I am
> focusing on the very low-level details of the ia32 ABI)
>
>  The system conditions for the OFW to Linux kernel transition are as
> follows:
>
>  a) OFW can load the Linux kernel from either bzimage format or ELF format
> (either uncompressed or zlib-compressed.)  If the kernel is in ELF format
> with symbols, OFW can do symbolic kernel debugging.  Further discussion will
> focus on bzimage format, as that is what OLPC uses and is also the "greased
> path" for kernel builds.
>
>  b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if any,
> at 0x800000.

so you are assuming that your uncompressed vmlinux only use less 8M space?

you are supposed to check the bzImage to get uncompressed vmlinux size.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists