[Mactel-linux-devel] Fwd: Re: darwin and friends

[Scott D. D. <da...@4p...>]

>From: David Elliott <df...@tg...>
>To: "Scott D. Davilla" <da...@4p...>
>Subject: Re: darwin and friends
>Date: Tue, 11 Mar 2008 14:46:07 -0400
>
>Hi Scott,
>
>I suspect you are looking in IODeviceTree:/options and/or looking at 
>the NVRAM directly.  That, as you have found out, is the blessed 
>device not the one that actually booted.
>
>The one that actually booted is found in IODeviceTree:/chosen and 
>the key you want from that device tree node is most likely 
>boot-device-path which appears to be an EFI binary device path. 
>Somewhere here I've got a program I wrote to decode 
>device-properties from IODeviceTree:/efi because at the time 
>Netkas's boot loader was including this blob for different machines 
>to make the graphics work. I wondered what exactly was in there. 
>Since then someone else wrote a decoder but I've never released mine 
>since I don't particularly agree with filling in this info at the 
>bootloader level when it can be done just as well in a kext (see 
>Titan/Natit which have existed for quite a while).
>
>As it turns out, I didn't find what I was looking for in 
>device-properties which was to see if this same scheme was used for 
>other pieces of hardware.  It is, but at least on the dumps I've 
>processed it appears that it's mostly the graphics card and then the 
>overall system volume (which is how the machine knows how loud to 
>chime at startup).
>
>So nothing came of it other than writing a decoder for the binary 
>format which necessarily includes a decoder for EFI device paths.  
>Unfortunately I can't find the code at the moment and it wouldn't be 
>of too much use to you anyway other than to know which header files 
>to look through in TianoCore to find the device path structures.  
>Decoding them is fairly trivial if you just read the comments in 
>those headers.
>
>But I suppose that if you've already determined that the NVRAM 
>contains the blessed boot device then you probably already know how 
>to decode it so you can actually read it.  So hopefully knowing that 
>the real boot device is in IODeviceTree:/chosen should be enough.
>
>Also do you have any sort of public mailing list for your project? 
>If so please forward this message to it so that others may benefit.
>
>-Dave
>
>
>On Mar 11, 2008, at 3:00 PM, Scott D. Davilla wrote:
>
>>Nice stuff;
>>
>>	Quick question, I' working on an AppleTV bootloader that 
>>makes it much easier to boot Linux and friends. The AppleTV is 
>>special, pure EFI, no BIOS and efi firmware will only load a signed 
>>boot.efi so using other efi bootloaders are not possible. We get 
>>around that by creating a fake mach_kernel that is a secondary 
>>bootloader which does the actual boot of Linux. I've extended the 
>>original work to convert EFI memmaps into e820 memmap and relocate 
>>ACPI and SMBIOS table pointers to where Linux can find them. This 
>>and the standard vesafb as a linear framebuffer lets me boot 
>>non-efi unpatched linux kernels. This all works great and I'm 
>>moving into auto boot by searching for the various linux boot confs 
>>(grub, syslinux, etc), extracting the boot params and then using 
>>kexec to boot the real kernel.
>>
>>	So the question, I'd like to know which device I was booted 
>>from at the bootloader level. It's a swing point on the initial 
>>search patch for the real kernel. So this is at entry into a mach 
>>kernel. I've got the passed boot params and limited EFI info (EFI 
>>is gone at this point). It there are way to retrieve the boot 
>>device info. boot.efi knows it as I can see it as the fake mach 
>>kernel loads, but is this information present somewhere that can be 
>>assessed. EFI vars will only contain the blessed boot device not 
>>the real boot device (USB pen for example).
>>
>>	Any information you can point me to would be appreciated. I 
>>have grep'd xnu source but I have not found anything using this 
>>type of info.
>>
>>Thanks
>>Scott


-- 
-----------------------------------------------------------------------
Scott D. Davilla                       Phone: 919 489-1757 ext 13 (tel)
4pi Analysis, Inc.                            Fax:   919 489-1487 (fax)
3500 Westgate Drive, Suite 403                email: da...@4p...
Durham, North Carolina  27707-2534            web: http://www.4pi.com