#12727 NORM Not Tri: OFW doesn't follow x86 linux boot protocol
Zarro Boogs per Child
bugtracker at laptop.org
Fri Jul 12 17:46:54 EDT 2013
#12727: OFW doesn't follow x86 linux boot protocol
---------------------------------+------------------------------------------
Reporter: dsd | Owner: Quozl
Type: defect | Status: new
Priority: normal | Milestone: Not Triaged
Component: ofw - open firmware | Version: not specified
Keywords: | Next_action: never set
Verified: 0 | Deployment_affected:
Blockedby: | Blocking:
---------------------------------+------------------------------------------
I think OFW doesn't quite follow the steps described by the x86 boot
protocol:
http://lxr.linux.no/linux+v3.10/Documentation/x86/boot.txt#L1021
New kernels (3.9 onwards) are detecting this through placing a 0xff
sentinel in the zero page at address 0x1ef. That falls outside of the
range of the data that should be loaded from the kernel image, instead it
is part of the memory region that should have been zeroed out.
The kernel boots and sees the sentinel value still in place and is not
100% happy.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5dcd14ecd41ea2b3ae3295a9b30d98769d52165f
I think these lines in cpu/x86/pc/linux.fth are responsible:
{{{
: code16-size ( -- #bytes ) load-base h# 1f1 + c@ 1+ d# 512 * ;
load-base 0 +lp code16-size move \ Copy the 16-bit stuff
loaded code16-size /string linux-base swap move \ Copy the 32-bit
stuff
}}}
But I can't quite get my head around them. Given that the 2nd line above
is effectively "copy memory from start of the loaded kernel image to the
place where the boot parameters will go" I see that as a suspect - but I
can't quite get my head around code16-size logic or what the final line
does.
--
Ticket URL: <http://dev.laptop.org/ticket/12727>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list