lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 20 Apr 2008 21:54:13 -0700
From:	"Yinghai Lu" <>
To:	"Mitch Bradley" <>
Cc:	"H. Peter Anvin" <>,
	"Andres Salomon" <>,
	"Eric W. Biederman" <>,
	"Ingo Molnar" <>,
	"Andrew Morton" <>,
	"Joseph Fannin" <>,,
Subject: Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

On Sun, Apr 20, 2008 at 8:39 PM, Mitch Bradley <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists