1109 replies to this topic

[scrax]

Master Chief, on Feb 8 2010, 06:47 PM, said:

I have e-mailed you Revolution 0.6.15 and today I hope to fix verbose mode with 0.6.16 (boot prompt shows up already, but isn't working yet.  Should be fine later today).

I've tried it after changing the UUID and the serial, made it to load as C2D instead of Xeon but it won't boot. I see only a flash of the black screen (the one that load boot0) without spinner tc. after that little flash it load a white backgroumd but the apple logo or the spinning wheel never appair. I can't see the boot menu or anything. I'll wait the 0.6.16 for verbose mode.

EDIT: I've tried without changing CPU type and other things but still nothing...

[dgsga]

I've been following this thread with great interest from the start.  So far I've been using the Revolution 0.4 files and have followed a similar path to scrax removing unused bits of code from chameleon where I can.  It makes a big difference in boot time embedding a 'micro-DSDT' in the boot file rather than having it in /Extras.  I'm down to 4.5 revs of the spinning counter after a momentary flash of the text spinner, and my boot file is 131KB in size (no embedded GUI).. The work you have both done here is great, hats off to you!  I'd like to share any knowledge or code changes I've made.  So far I've implemented the changes scrax listed in an earlier post (modding makefiles and removing hpet,nvidia,ati etc.)  then proceeded to strip out unwanted code from smbiospatcher.c and replaced model defaults with my own so I no longer need an smbios.plist.  I've tried to remove all code relating to the (unwanted) GUI in gui.c but I'm not sure what I'm doing and it hasn't worked out so far.  I have made the changes to options.c as per rekursors latest revision from svn so i can use the keyboard to get into verbose or single-user mode whilst in Quiet Boot.  If you need any help with this project or want me to post files/code the let me know.  I'd love to try out / help bugfix the latest revision of Revolution if this is what 0.4 can do!


Master Chief in post 31 you mentioned that your goal was to change chameleon source so you can compile the boot 2 folder 'as if nothings really changed'.  This included a code snippet.  Sorry for being a bit thick here, could you clarify what you mean??

[Master Chief]

Guys,

Let me add that a lot has changed with the introduction of Revolution 0.6.15  Most of it are 'removals' in the usual style:

#if CHAMELEON (et all)
.. Chameleon code
#else
.. My stripped down / modified code for Revolution
#endif

Like I said earlier, in a previous post (#31 specifically) my goal is to be able to compile a 'normal' version of Chameleon RC4 from my sources, without first having to make all sort of changes.  It should be as simple as launching make > logfile.txt and that is it.

This is not yet the case.  Still working on it.  The problem is that I got carried away.  And a few times already.  Which means that I still have work to do on some of the files.  There's also source code where I still have to figure out what to do with it and if we need it or not.

I also want to remove ALL verbose and debug related text.   I still have to finish my new API for it, but it will (eventually) enable you to select a preferred language from Rekursor's new pref panel.  Enter easy and much anticipated translations!

[scrax]

Hi
still nothing to do with Revo 0.6.15 added my ssdt in acpi_patcher.h but it still not load even if the dsdt is the same as the 0.4 one that for me works, so there is something in the code removed that it's need for my configuration

[Master Chief]

scrax, on Feb 13 2010, 02:09 PM, said:

Hi
still nothing to do with Revo 0.6.15 added my ssdt in acpi_patcher.h but it still not load even if the dsdt is the same as the 0.4 one that for me works, so there is something in the code removed that it's need for my configuration

Your configuration probably needs function scanDisks (in sys.c) and newFilteredBVChain (in options.c) so first change the: #if CHAMELEON into #if 1 // CHAMELEON

The next step would be to open boot.c and scroll down to function common_boot where you need to change one or two blocks.  Specifically this one:

#if 1 // CHAMELEON
	// Create a list of partitions on device(s).
	if (gScanSingleDrive)
		scanBootVolumes(gBIOSDev, &bvCount);
	else
		scanDisks(gBIOSDev, &bvCount);

	// Create a separated bvr chain using the specified filters.
	bvChain = newFilteredBVChain(0x80, 0xFF, allowBVFlags, denyBVFlags, &gDeviceCount);

	gBootVolume = selectBootVolume(bvChain);
#endif

and the next one as well (I presume):

#if 1 // CHAMELEON
	setBootGlobals(bvChain);
#endif

Does that work for you?

Note: I just made these changes myself so let me give it a try.  Ok.  It compiles and boot is now 65888 bytes.  That's too big for me, but let me try to reboot.  Done!  It works.  Give it a try.

Edit: Verbose and safe boot are functional again in Revolution 0.6.16 but I don't want a menu so I removed it.  This also includes the help text (? at boot) which I think should be stored on disk somewhere, and we don't need it anyway.

I have attached version 0.6.16 for you, with the specific changes, so that you and other people here willing to have a go with it can.  But let me remind people here that there are no bells and whistles in this version.  No GUI, no disk selection menu nothing.  It won't even read DSDT and/or SSDT anymore because we incorporate it in the boot file.

You can only add the boot drive UUID to: /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
but nowhere else.  SMBIOS.plist is no more because we change the smbios_patcher.c before we compile it for our hardware!!!

Edit 2: There are two things you should change:

1) The hard coded serial number (MASTERCHIEF) in fake_efi.c
2) The hard coded test UUID in fake_efi.c

And you'll have to change these or iTunes won't work properly anymore!  Also.  Defining CHAMELEON alone won't be enough to compile a 'normal' Chameleon version from the attached source code, simply because I removed all unused files!

Edit 3: A new attachment, with minor improvements, is now available (fake serial number and UUID was changed back to the Chameleon default).  I also changed graphics.c a little (you may need to change the default screen width / height) and this new version compiles to 65120 bytes (less than one 64KB segment).

Attached Files

•  Revolution_616b.zip   264.63K   153 downloads

[jamesah]

So I've been digging slowly into DSDT and will continue to but I just wanted to post and hopefully be able to get involved in this thread to learn and eventually contribute (even if it's something minuscule) .  Thanks for your work Master Chief.  And I saw something about you leaving the scene earlier? Is this still happening? If so- I wish you well.

[Master Chief]

jamesah, on Feb 14 2010, 12:13 PM, said:

So I've been digging slowly into DSDT and will continue to but I just wanted to post and hopefully be able to get involved in this thread to learn and eventually contribute (even if it's something minuscule) .  Thanks for your work Master Chief.  And I saw something about you leaving the scene earlier? Is this still happening? If so- I wish you well.

Thanks.  And no I won't leave the scene (I was asked to stay by many people here).  I do have other things to do as well, of course, but I'll keep trying to do as much as I can in my (now limited) free time.

[dgsga]

Hi MC

Thanks for sharing the eagerly-awaited revolution code, you've done a great job in condensing the code.  I'd only managed to get as far as 87392 bytes!!.  I have modified acpipatcher.h with my DSDT.aml in little endian format and removed SSDT stuff from this file and acpipatcher.c as I dont need to modify SSDT on my mobo. All compiles OK but when I try to boot I get an immediate KP with the 'unable to find driver for this platform' error.  Is there any other code I need to mod that you can think of??

[Master Chief]

dgsga, on Feb 14 2010, 01:13 PM, said:

Hi MC

Thanks for sharing the eagerly-awaited revolution code, you've done a great job in condensing the code.  I'd only managed to get as far as 87392 bytes!!.

Thanks.  Please note that we can reduce boot2 even more, but that would also complicate things even more.

dgsga, on Feb 14 2010, 01:13 PM, said:

I have modified acpipatcher.h with my DSDT.aml in little endian format and removed SSDT stuff from this file and acpipatcher.c as I dont need to modify SSDT on my mobo.

Let's start with some questions:

1) What is the size of your DSDT.aml

2) Can your DSDT.aml be divided by four?  As in have you checked the end of the file and does that match with the one in the acpi_patcher.h?

3) You should also have SSDT.aml with your: LAN, audio, graphics and P-State data.
- otherwise my general DSDT won't work for you, which is a next step in this process.

dgsga, on Feb 14 2010, 01:13 PM, said:

All compiles OK but when I try to boot I get an immediate KP with the 'unable to find driver for this platform' error.  Is there any other code I need to mod that you can think of??

Getting it to compile properly is only step one.  Anyway.  This sounds suspiciously like a HPET and smbios_patcher issue.  Have you change anything in smbios_patcher perhaps?

p.s. I would advise you to do a diff -uwr to see what you have (working) and I did / changed.  That might help you.

[dgsga]

Master Chief, on Feb 14 2010, 01:34 PM, said:

Thanks.  Please note that we can reduce boot2 but that would complicate things even more.


Let's start with some questions:

1) What is the size of your DSDT.aml

2) Can your DSDT.aml be divided by four?  As in have you checked the end of the file and does that match with the one in the acpi_patcher.h?

3) You should also have SSDT.aml with your: LAN, audio, graphics and P-State data.
- otherwise my general DSDT won't work for you, which is a next step in this process.


Getting it to compile properly is only step one.  Anyway.  This sounds suspiciously like a HPET and smbios_patcher issue.  Have you change anything here?

p.s. You can do a diff -uwr to see what I did / changed.  That might help you.

MC,

Thanks for your help on this!  In answer to your questions:

1) My DSDT.aml is 5672 bytes

2) I have added Noops to make it divisible by 4

3) I have LAN, audio graphics fixes in DSDT.  The reason for this is that power management works fine with native SSDT and C6 enabled in bios, so I have left SSDT well alone.

I was thinking along the same lines as you so I corrected default MacPro table in smbiospatcher.h to match that for MacPro4,1 (I have x58 chipset), and changed entries at start of fakeefi.c to match.  HPET has worked OOB so no changes there. The good news is that it now boots to Desktop but very slowly (about 20 revs cw usual 4-5).  I then had a look in  IORegExplorer and at top of tree it says Apple004,1 Instead of MacPro4,1.  The other thing I noticed was that when I try to click on AboutThisMac it crashes and restarts Finder.  Hmmm.....  I think you're right, something to do with SMBIOS, but i'm not sure where to go next.

Having looked at the Revolution code I'm amazed at all the changes you've made.  It's taken me hours, so I guess  it must've taken you ages.  Good work.

[Master Chief]

dgsga, on Feb 14 2010, 03:39 PM, said:

...

I was thinking along the same lines as you so I corrected default MacPro table in smbiospatcher.h to match that for MacPro4,1 (I have x58 chipset), and changed entries at start of fakeefi.c to match.  HPET has worked OOB so no changes there. The good news is that it now boots to Desktop but very slowly (about 20 revs cw usual 4-5).

-> SMBIOS (most definitely).

Edit: You need to change the following line:

orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable();

in smbios_patcher.c (remove the hard coded address, which was only a test to see how long it takes).

dgsga, on Feb 14 2010, 03:39 PM, said:

Having looked at the Revolution code I'm amazed at all the changes you've made.  It's taken me hours, so I guess  it must've taken you ages.  Good work.

Thanks.  It is a slow process yes, but I have done most of it in smaller steps.  Sometimes I look at a particular piece of code for a second, or a third time even, and think: What the beep is that.  Time for another change.

Here's an example: I just changed function initGraphicsMode (in graphics.c) into a one liner.  And a next candidate for todays work is function  getVESAModeWithProperties in the same file.  We don't need it; VESA is a well known standard and most people – if not all – are using the same video mode over and over again.  And since my hardware isn't going to drop VESA support any time soon, and I'm also not going to change the video mode... let's pick one our selfs and we are done looking for it every single boot.

[dgsga]

Master Chief, on Feb 14 2010, 04:02 PM, said:

Edit: You need to change the following line:

orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable();

in smbios_patcher.c (remove the hard coded address, which was only a test to see how long it takes).

Hi MC

Have tried your suggestion on a single-drive setup and it does indeed work.     However, when I use the same boot file on my RAID0 setup I get the same old KP.  As far as I can tell none of the RAID code has been removed so yet another mystery to solve...

[Master Chief]

dgsga, on Feb 15 2010, 06:27 PM, said:

Hi MC

Have tried your suggestion on a single-drive setup and it does indeed work.     However, when I use the same boot file on my RAID0 setup I get the same old KP.  As far as I can tell none of the RAID code has been removed so yet another mystery to solve...

Ah.  Good news.  Another little step forward.  I wonder; Did you reinstate the code I mentioned in post #45?

You probably noticed that the background color changes a little sooner in the boot process.  And there was this short delay (up until Revolution v0.6.16) which made the Apple logo appear after a short delay.  But not anymore; I optimized bootlogo.c and drivers.c and now the gray background and Apple logo appear (almost) simultaneously.  And this without moving the calls to functions showBackground and showBootLogo which would be cheating.

The problem here was that all except one function in bootlogo.c was written to make it work (which I simply copied from Chameleon).  Not to do it as fast as possible. Which also shows that my work can have a positive affect on Chameleon.  Some people 'just' don't get it.  Let's have a look at one example:

	[color="#008000"]int rem = (pixelBytes * width) % 4;	
	int length = pixelBytes * width / 4;[/color]

	while (height--)
	{
		// [color="#FF0000"]int rem = (pixelBytes * width) % 4;[/color]

		// [color="#FF0000"]if (rem)
			bcopy(&color, vram, rem);[/color]

		// [color="#FF0000"]stosl(vram + rem, color, pixelBytes * width / 4);[/color]
		stosl(vram + rem, color, length);
		vram += VIDEO(rowBytes);
	}

And while this is just a minor improvement – you have to look at the bigger picture here, because this sort of 'hand brakes' keep adding up for a notable slower boot process – doing 2400 multiplications – at a screen resolution of 1900 x 1200 – is was pretty much useless.  Not to mention that function convertImage did it even 16384 times... but hey these are just a few milliseconds.  Yeah right.

Another problem is that Chameleon let people dump their files anywhere on their hard disk, which basically results in a considerably slower boot process.  Being a tad more restrictive with this kind of "features" would have helped, and a lot.

The most important note for today is – at least for some of our readers here – is that I am not blaming any of the Chameleon developers for it, but I am merely trying to help improve our boot time.  Maybe this wasn't clear (enough) for some, but it should now.

Edit: New text added about the Boot Process in post #1.

[Master Chief]

Update: I keep making process (boot2 is now 63008 bytes) but I also need some time for my new hardware (Asus main board, dual Xeon 5520, 24MB ECC RAM, ATI 5770) which apparently arrives tomorrow already.

Edit: I think to have made room for the missing boot drive selection menu.  Let me try to add it back in (keeping boot2 below the 65536 bytes marker).

[bossob]

Nice work indeed.   

Cant wait to try it

[Master Chief]

Good news.  My new hardware arrived today and thus I installed OS X (Server Edition) and everything but audio is working.  Had to disable the on-board video, and I still have some DSDT hacking to do, but the boot time is basically the same, even with two 5550's, as my P5K Pro hack.  Please note that I used the same brand/type of hard drives so that might explain it.

Note: My Intel Xeon L5520's should arrive in a day or two, but I couldn't resist and thus I decided to install two 5550's from a defunct server board.  The CPU's I am using now are much faster, but also a lot more power hungry (two L5520 are using less power than one single 5550) than what I will be using.

This new hardware shows me something that even I wasn't expecting, which is that our boot loader is still as slow/fast as before, and thus I took the original boot-132 sources to give it a whirl.  Boy this is fun because I can now boot, be it in 32-bit mode only, with Apple's boot-132 plus Dave Elliot's modifications only.

There's one thing I have to fix and that is that booting without smbios_patcher makes it a slow dog, so I have to come up with something better or use Macerintel's smbios_patcher (for the time being).  All in all another step forward.  Something I was looking for so long already.

[dgsga]

MC,

Good luck with your experiments.  Have tried re-instating the code you mentioned but still no joy.  It's a pity because the boot logo appears almost instantly after bios POST screen before the KP occurs. Would it be possible for me to reinstate the old smbios code or would that defeat the object?

[Master Chief]

dgsga, on Feb 18 2010, 10:36 AM, said:

MC,

Good luck with your experiments.  Have tried re-instating the code you mentioned but still no joy.  It's a pity because the boot logo appears almost instantly after bios POST screen before the KP occurs. Would it be possible for me to reinstate the old smbios code or would that defeat the object?

Hi,

Should not be a problem.  Give it a try.

And I will keep experimenting to find other possible improvements, and share them when possible (read: when they are ready for the general public).  We're on track, but I need to find a more general acceptable booter.  One that works for a wider audience.  Should be possible, but it might be a bumpy ride to get there.

Anyway.  Keep me posted!

[Master Chief]

Today I made a few changes to improve USB boot support, and that was when I was hit by a five rev penalty on my hard drive!  Please note that I did not replace a single file on my hard drive.  Only /boot  on my USB stick.  Which begs the question why something this simple can even have such a huge impact!

The first thing I tried was to clear (remove):

/System/Library/Caches/
/Library/Caches/

Which unfortunately did not help.  It's still the same.  The "Waiting for DSMOS..." is back. I don't get it!?!

We have to figure out what it is, because this could lead to much improved boot times for everyone!!!

[Master Chief]

Revision 0.6.18 will soon be released [maybe after lunch already].

This version [with only a few minor modifications to 0.6.16] boots from a cheap 4GB Kingston USB memory stick.  Please note that I disabled all hard drives [under ACPI] in the BIOS so that it passes the BIOS post routine a lot quicker [at least here with five hard drives].  And this is all I have on this USB stick:

drwxrwxr-x  8 chief  staff	   340 Feb 22 11:42 .
drwxrwxrwt@ 9 root   admin	   306 Feb 22 11:37 ..
drwxr-xr-x  3 root   admin	   102 Feb 22 11:34 Library
drwxr-xr-x  3 root   wheel	   102 Feb 22 11:08 System
-rw-r--r--@ 1 root   admin	 63520 Feb 22 11:26 boot
-rw-r--r--@ 1 root   wheel  18676624 Feb 22 11:11 mach_kernel

Nothing special in com.apple.Boot.plist from /Library/Preferences/SystemConfiguration/:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com...yList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Kernel</key>
	<string>mach_kernel</string>
	<key>Kernel Flags</key>
	<string>arch=i386 boot-id=uuid boot-uuid=2F539C63-CA1B-3361-AFE0-F05616148A71</string>
	<key>Graphics Mode</key>
	<string>1600x1200x32</string>
</dict>
</plist>

Please note that you need Extensions.mkext (in /System/Library/Caches/com.apple.kext.caches/Startup/) so that OS X can take care of the drive initialization, and then /boot loads without any issues.  Even with the drives disabled in the BIOS.  Sweet.

Let's hope that this update works [like it does here] for people where Revolution previously failed to boot from USB sticks.

Edit: If you get a gray background but not the Apple logo, then you must disable the drives in the BIOS.  I hope to fix this in the next update [or just revert the: if 1 // CHAMELEON lines] !!!

Attached Files

•  Revolution_618.zip   264.05K   99 downloads