lkml.org 
[lkml]   [2008]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
On Sun, Apr 20, 2008 at 8:39 PM, Mitch Bradley <wmb@firmworks.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


\
 
 \ /
  Last update: 2008-04-21 06:57    [W:0.627 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site