linux-kernel - Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <480C4EAB.9090004@firmworks.com>
Date:	Sun, 20 Apr 2008 22:22:03 -1000
From:	Mitch Bradley <wmb@...mworks.com>
To:	Yinghai Lu <yhlu.kernel@...il.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

Yinghai Lu wrote:
>
>> 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.
>   

The 0x800000 ramdisk load address is an OLPC-specific firmware 
implementation detail that could easily be changed without affecting 
anything else. I probably shouldn't have mentioned it because it isn't 
really an integral part of the interface "contract".

I certainly hope that the OLPC kernel never gets anywhere near that 
size.  The OLPC hardware has limited configurability, so it's not 
plausible that the kernel would grow that large to include a huge kit of 
drivers.  If the kernel file becomes large as a result of including the 
initramfs in the same file, the 0x800000 ramdisk load address won't 
apply (because there won't be a separate load of the initramfs file), so 
the kernel could be extend way past that boundary with no problems.

If we get to the point where we do need huge kernels on OLPC, we can 
release a firmware upgrade along with the new OS.  We have mechanisms 
for coordinating firmware and OS upgrades.

If a new customer for OFW on x86 appears, I'll remember to float the 
boundary above the bzImage uncompressed size (assuming that the bzimage 
format is still applicable when that happens).
> 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/