Jump to content

SSE2 & 3 Retail Leo and Vanilla installs - Boot 132 on pre-Core !


munky
 Share

614 posts in this topic

Recommended Posts

*** SSE2 & SSE3 Intel owners, you CAN boot the retail Leopard DVD! ***

 

Latest News: I posted a guide on how to install patches/kernels to the hidden EFI partition: here

 

(Older posts on this subject, leading up to me actually getting it to work are archived here)

 

As we all know, dfe's excellent modified Boot-132 bootloader allows us to place extra kernel extensions on a ramdisk, which can be used to boot the retail Leopard DVD on Core architecture PCs. An amazing milestone in OSx86 history, as i'm sure we all agree.

 

But what exactly is required to run the retail Leopard DVD and the so-called vanilla (ie Apple-supplied) kernel? Why can't my Pentium D run it?

 

It turns out the kernel performs an explicit check for the CPU 'family'. Only processors in 'Family 6' (or P6 processors) are permitted to boot. Pentium 4 and its derivatives (including Celeron D and Pentium D) are in Family 7 (P7).

 

There are a whole bunch of intel CPUs in the P6 family, but only Core Solo and above have SSE3, thus effectively limiting the kernel to Core processors.

 

64-bit operation adds another level of complexity - the only implementation of a certain routine in the kernel code (bcopy) in 64-bit mode uses SSSE3 (Supplemental SSE3), which - again - only Core and better CPUs have.

 

The upshot is that my machine *requires* a patched kernel to boot. The changes needed are fairly minimal, but as it stands my machine cannot run the kernel which is on the retail Leopard DVD.

 

Thus my thoughts turned to another approach - can I specify the 'extra' kernel extensions *and* a kernel, and have the machine boot from the DVD? I emailed dfe to ask if this is something he could add support for, only to discover it was already possible:

 

 

Hi Munky,

 

If you look slightly more closely at the code you'll realize that it names the ramdisk rd(u,p) just like hard drives are hd(u,p). So it already works to do something like rd(0,1)/mach_kernel.custom assuming you have a file mach_kernel.custom in the root of the ramdisk and the partition is numbered 1. I think partition numbers start at 1 so you should be ok with that. If not try 0.

 

It's been a while since I did this but I remember it working fine. That is, you simply enter the full path to the kernel on the boot command-line followed by any options.

 

Enjoy,

-Dave

 

This led me to perform a whole bunch of experiments to try to get my Pentium D to boot the retail DVD. See here for the blow-by-blow account of me getting this to work :rolleyes:

 

Ok munky, get to the damn point. Where's the beef?

 

Heh.. ok, well here's what i've managed so far:

 

- Booted the retail DVD from a modified boot-132 CD.

- Installed successfully to a fresh partition on a GPT disk.

- Booted the installed partition and completed setup, again by booting from the boot-132 CD.

 

To boot, you need to place a suitable patched kernel in the root of the ramdisk image (initrd.img), and at boot time, after typing in the two-digit code to boot the Leopard DVD (or your hard disk partition), you boot thus:

 

rd(0,1)/mach_kernel.patched -legacy boot-uuid=

 

OR

 

rd(0,1)/mach_kernel.patched -legacy rd=diskXsY

 

So, to break that down:

 

rd(0,1) refers to the ramdisk, so rd(0,1)/mach_kernel.patched is how we're specifying the kernel to boot.

 

-legacy is needed if the kernel cannot operate in 64-bit mode. the kernel i have been testing with is an experimental pre-release kernel and still has SSSE3 routines in the 64-bit code, so I have to force 32-bit operation.

 

boot-uuid= or rd=diskXsY - this is the real trick. specifying a kernel on a different device causes the boot sequence to switch the 'root' device to the device which holds the kernel. trying to boot without specifying the uuid or root device (rd) will cause mach to try to boot from the ramdisk itself. this is obviously not what we want. so you need to specify the uuid or the correct bsd address of the device you want to boot - the Leopard DVD or the installed partition.

 

Remember, this is all down to dfe and his cunningness, and his helpfulness and patience in assisting me. Thanks dfe!!!

Link to comment
Share on other sites

rd(0,1)/mach_kernel.patched -legacy boot-uuid=<uuid of boot device>

 

So, to break that down:

 

rd(0,1) refers to the ramdisk, so rd(0,1)/mach_kernel.patched is how we're specifying the kernel to boot.

 

-legacy is needed if the kernel cannot operate in 64-bit mode. the kernel i have been testing with is an experimental pre-release kernel and still has SSSE3 routines in the 64-bit code, so I have to force 32-bit operation.

 

boot-uuid=<uuid> - this is the real trick. specifying a kernel on a different device causes the boot sequence to switch the 'root' device to the device which holds the kernel. trying to boot without specifying the uuid will cause mach to try to boot from the ramdisk itself. this is obviously not what we want. so you need to specify the uuid of the device you want to boot - the Leopard DVD or the installed partition.

 

Well just done some tests in VMware using the vanilla kernel on the ram disk. Works fine and in this configuration you can use the rd parameter rather than boot-uuid one. Not sure if this is true for all circumstances but in this test case it work. Haven't tired with installation DVD yet.

 

rd(0,1)/mach_kernel.donk -v rd=disk1s2

 

Just need a test kernel now with minimum changes.

Link to comment
Share on other sites

funny, i did wonder if rd would work. i had tried it but i think in retrospect i'd specified the wrong drive for the DVD. if it does work, then the whole uuid thing is unnecessary ;)

 

donk: what hardware are you using? if its pre-Core, could you perhaps test with the Modbin kernel?

 

http://www.infinitemac.com/940-modbin-kernel-for-amd-intel/

Link to comment
Share on other sites

funny, i did wonder if rd would work. i had tried it but i think in retrospect i'd specified the wrong drive for the DVD. if it does work, then the whole uuid thing is unnecessary :thumbsup_anim:

 

donk: what hardware are you using? if its pre-Core, could you perhaps test with the Modbin kernel?

 

http://www.infinitemac.com/940-modbin-kernel-for-amd-intel/

 

I have both pre & post-Core available plus AMD. However, won't be able to test until tomorrow, but will give it a go.

Link to comment
Share on other sites

nickhe: yes, why not test it out? :D

 

ok a couple updates:

 

1) i was being an idiot with the rd= thing... it DOES work, so no need to faff about with UUIDs.

 

2) modbin kernel works for me to boot a vanilla install.

 

I'm going to make an ISO and upload it somewhere for people to test. Nickhe: you up for it? You got a retail Leopard DVD?

Link to comment
Share on other sites

for anyone wishing to test this out, i have prepared an iso with the bare minimum patched kexts (inc. ps/2 ones, dsmos.kext, SMBIOSEnabler and IntelPMDisabler) and the modbin kernel.

 

download here

 

- burn it to CD-R (or better still, to CD-RW so you dont waste a disc ;))

 

- boot from it

 

- swap for your Leopard retail DVD (hope you bought one!)

 

- type the two-digit code for ur dvd-rom drive (mine is 90)

 

- you should see the 'Press any key to start from CD-ROM or press F8 to specify...', hit F8

 

- now type:

 

rd(0,1)/mach_kernel.modbin -legacy -v rd=diskXsY

where X and Y specify the Leo DVD. i'm not actually certain how you figure this out... example:

rd(0,1)/mach_kernel.modbin -legacy -v rd=disk3s0

 

if you cant figure it out, but have access to a mac or working hackintosh install, put your retail Leo DVD in, open Disk Utility, click on the Leo DVD and click the blue 'Info' button. take a note of the UUID. now try to boot with:

 

rd(0,1)/mach_kernel.modbin -legacy -v boot-uuid=<the uuid you noted down>

 

example:

 

rd(0,1)/mach_kernel.modbin -legacy -v boot-uuid=CE49A5C7-53DC-3A11-A9CD-BE59D84BBCA9

 

either approach (rd= or boot-uuid=) should work. lemme know how you get on!

Link to comment
Share on other sites

well... funny thing, i actually think this could open up booting retail to more people.

 

anyone know the state of the art of SSE3 emulation for SSE2 processors? or AMD binary patching?

 

if either of those can be fixed 'on-the-fly' via kernel or kext, then its possible this could work for those machines as well.

 

ie if there exists a kernel with built-in SSE3 emulation, then booting the retail DVD using that should theoretically work....

 

anyone who knows about these things (i have never had an AMD hacky, and I moved on from SSE2 a long time ago...) please get in touch ;)

 

update: well it seems like i picked a good kernel to put on that ISO... its apparently SSE2 compatible, with built-in SSE3 emulation.

 

can someone who happens to have a retail Leopard disc and an SSE2 intel machine please test?! :superman:

Link to comment
Share on other sites

Just want to toss out 2 ideas. Consider using prelinked kernels. This effectively combines your custom kernel with a mkext cache and allows for specificying multiple "profiles". This could help in making a very generic booter.

 

A kernelcache of the currently booted system is stored at /System/Library/Caches/com.apple.kernelcaches/kernelcache. You can use that as the kernel to load and can totally ignore the mkext cache.

 

Also instead of using boot-uuid consider the following method as explain in the BootHelp.txt of boot-132.

 

	[device]<kernel> [arguments]
Example arguments include
device: rd=<BSD device name>	   (e.g. rd=disk0s2)
	 rd=*<IODeviceTree path>	(e.g. rd=*/PCI0@0/CHN0@0/@0:1)
kernel: kernel name				(e.g. "mach_kernel" - must be in "/" )

 

The root device is probably easier to find than the boot uuid. While it will change on a lot of systems its still easier than entering uuid which will change for all the different Leopard releases as well.

Link to comment
Share on other sites

Haha it worked! Awsome i succeded in booting the retail on a Intel Pentium D 3.2MHz mobo Asus P5GPL-X SE HDD on SATA. Even though i`ve got stuck a little. After it load the kexts it shows me this (i don`t have a realtek network card):

 

RTL8139::fixEnetFlowControl - Flow Control is disabled
  Still wainting for the root device...
  ....
  ....

 

I managed to fix the thing above by adding the system.kext that comes with modbin kernel but now i`m stuck elsewhere :

 

Apple16X50UARTSync1: Detected 16550AF/C/CF FIFO=16 MaxBaudd=115200
Apple16X50ACPI1: Identified Serial Port on ACPI Device=UARACPI_SMC_CtrlLoop::initCPUCtrlLoop - pmCPUControl (PMIOCSETSTATETABLE) returned 0x34db600

 

any ideas ?

Link to comment
Share on other sites

Lastowl: Afaik speedstep is not required... in fact im certain my pentium d doesn't have it.

 

Synapse: not really sure... that doesn't look like an error tbh, just looks like it's setup your serial port correctly. Have you just tried waiting for a bit? Couple times I thought mine had hung but it was just 'thinking'. :-)

Link to comment
Share on other sites

...

Synapse: not really sure... that doesn't look like an error tbh, just looks like it's setup your serial port correctly. Have you just tried waiting for a bit? Couple times I thought mine had hung but it was just 'thinking'. :-)

 

Yes i let him 20 mintes to do its think..but no success :huh:. I think i`m missing a kext but dunno which one.

Link to comment
Share on other sites

Still looking for some intel sse2 testers!

 

synapse: draw up a list of kexts ur machine needs to boot a hackintosh and start adding them to the initrd.img. U need to add a clause to the Info.plist to get it to load from the ramdisk. See near the start of the main boot-132 thread for details. I'd post it here but I'm on iPhone with no copy paste ;-)

Link to comment
Share on other sites

Still looking for some intel sse2 testers!

 

synapse: draw up a list of kexts ur machine needs to boot a hackintosh and start adding them to the initrd.img. U need to add a clause to the Info.plist to get it to load from the ramdisk. See near the start of the main boot-132 thread for details. I'd post it here but I'm on iPhone with no copy paste ;-)

 

Thx...i`ve tryed doing that...but the problem is i don`t know the exact kexts that my machine needs...i`ve tryed adding a few from kalyway`s 10.5.2 same thing...then i`ve added the whole extension folder and this time didn`t worked at all...so to be honest to try them one by one it would take me a few days. :(

Link to comment
Share on other sites

Still looking for some intel sse2 testers!

 

synapse: draw up a list of kexts ur machine needs to boot a hackintosh and start adding them to the initrd.img. U need to add a clause to the Info.plist to get it to load from the ramdisk. See near the start of the main boot-132 thread for details. I'd post it here but I'm on iPhone with no copy paste ;-)

 

There is a way to test this in VMware even on Core 2 CPU. I have already done some tests with disabling SSSE3, and should be able to disable SSE3 as well. I will try it and get back to you.

Link to comment
Share on other sites

1: Boot munky´s CD

2: Swap Retail Leo DVD

3: Press 2x Enter

4: Press F8

5: boot: -v

 

crash no boot

 

 

1: Boot munky´s CD

2: Swap Retail Leo DVD

3: Press 2x Enter

4: Press F8

5: boot: rd(0,1)/mach_kernel.modbin -legacy -v

 

the last screen

DSC01047.JPG

Link to comment
Share on other sites

 Share

×
×
  • Create New...