GrootWitBaas Posted February 1, 2011 Share Posted February 1, 2011 It Boots and everything seems to work Link to comment Share on other sites More sharing options...
magnifico Posted February 1, 2011 Share Posted February 1, 2011 Sorry for OFF TOPIC please Scrax, empties pm. Sorry again Link to comment Share on other sites More sharing options...
humph Posted February 1, 2011 Share Posted February 1, 2011 Good to hear. Is that with or without having a UUID in com.apple.Boot.plist because then we can be even faster. Faster with or w/o UUID in caBp ? Anyway, as others, also got 637 booting off preferred partition using UUID reference . Noticed that setting all the verbose flags in private_data.h did not automatically turn on verbose (only saw the EFI bit, then went to normal apple logo boot screen). Plus did not seem to be able to "catch" pressing of "v" during boot - perhaps now too fast!!! So used -v in caBp to get to see debug. Initially thought was hung & not working at all, until I realised that. Strangely, went back in to set stuff to use static CPU (and other) and get compile error cpu/static_data line 12 void thing. Also, looks like CPU flag in private_data is not aligned with stuff in CPU. Think you may have mentioned that in earlier post, but mid in spin at the moment! But, now can't get to compile at all, despite trashing everything and using new files! Same error. Will try again after dinner... Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 1, 2011 Share Posted February 1, 2011 And after a bit of clean-up ... Just for reference using bios boot selection (F12 on Gigabyte board) from time disk is selected until browser open on this forum ready to type is only 32.5 seconds. Compared to 40seconds for the same on old boot-loader (on the SSD disk). Yes that is 7,5 seconds off yea I know it is not about speed yet, but about getting it to work for anyone ....but also nice to know. Groot Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 1, 2011 Share Posted February 1, 2011 The longest time is spent by the kernel itself. Just count the number of revs of the spinner which roughly equals 1+ second. So it should be faster from the SSD disk than from the usb boot ....mmmmm /me gets out the old backup drive to make a CCC image just in case .... And Finally found the part from lion king I was looking to post 1st time I could boot with Revo ....itstarts.mov Edit: Replacing boot on my SSD does not make it boot. doing it on USB does ..... /me goes back to reading older posts Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 1, 2011 Share Posted February 1, 2011 p.s. Don't forget the update the UUID in com.apple.Boot.plist – that is if you have one there, or it won 't boot. stayed away from UUID in c.a.B.p ...to be precise only ting in there is kernel flag -v if needed ...else there is nothing. UPDATE: So based on above I added rd=uuid boot-uuid=MySSDUUId and now it boots. But I was expecting it to boot the only drive I have installed without having a static UUId ..... Link to comment Share on other sites More sharing options...
scrax Posted February 1, 2011 Share Posted February 1, 2011 @scrax: I checked your FADT table right after receiving your ioreg dump (you've attached it here remember) and it has this Reset Register Supported (V2) : 1 so I wonder why it doesn't work for you(r nvidia chipset). I also notice that your FACP table is invalid. Not to mention that your DSDT includes code that shouldn't be part of it. Almost looks like a snippet from your HDD. p.s. Do you happen to have a datasheet for your chipset? If not, try to get one! Could the FACP table be patched by chameleon? I'll use linux to dump all the original table but i need to check how. I'll try to find the datasheet for my chipset now because I have none. Note. I had only one boot without -x and the previously posted options, now it keeps restarting instead of loading kernel, I don't know why. I've tried to change the options but nothing worked. I think I need more time to make accurate test. The dsdt is not the original one, i'll attach the original one with all the ACPI table i can get from linux Link to comment Share on other sites More sharing options...
blackosx Posted February 2, 2011 Share Posted February 2, 2011 I don't think so (not patched in the attached ioreg dump). And it's actually the FACS table. Sorry my mistake. Yours looks like: <"FACS@"> and that is not what it should be. Mine is the same, even on the original ACPI dump from Linux I did back in 2009. /* * Intel ACPI Component Architecture * AML Disassembler version 20091013 * * Disassembly of /ACPIDUMP from Linux - 011109/DSL/FACS.aml, Wed Nov 4 08:16:07 2009 * * ACPI Data Table [FACS] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "FACS" [004h 0004 4] Length : 00000040 [008h 0008 4] Hardware Signature : 00000000 [00Ch 0012 4] 32 Firmware Waking Vector : 00000000 [010h 0016 4] Global Lock : 00000000 [014h 0020 4] Flags (decoded below) : 00000000 S4BIOS Support Present : 0 64-bit Wake Supported (V2) : 0 [018h 0024 8] 64 Firmware Waking Vector : 0000000000000000 [020h 0032 1] Version : 00 [021h 0033 3] Reserved : 000000 [024h 0036 4] OspmFlags (decoded below) : 00000000 64-bit Wake Env Required (V2) : 0 Raw Table Data 0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 FACS@........... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Link to comment Share on other sites More sharing options...
blackosx Posted February 2, 2011 Share Posted February 2, 2011 Your table is fine. Your table includes data (read: bytes), but the the table in the ioreg that scrax attached here is that there's only a name. Nothing else. Just a name. And that is wrong. Okay.. I'm not at my hack right now and I don't have a copy of my ioreg with me so I can't be certain but I think when I look at my ioreg, next to FACS, all I see is <"FACS@">. I'll verify this tonight. EDIT: Yep.. see screenshot.. This is booted from Revolution 637, but it's the same using Chameleon. So I guess we need to add to patcher.h a section for completing the FACS table so it looks like this? (for my machine) Now about the latest update i.e. Revolution 637 which I tell you is riddled with bugs. Far too many errors. Doesn't even boot, or even reboots on an internal drive. Problem here is that I don't have a hack myself. My current build of Revolution-637 boots fine for me from an internal HDD, though I did have problems with the system just rebooting very early on in the boot process when I first tried it. I just tweaked private_data.h until it worked. EDIT: Forgot to mention that it's working for me from internal HDD without a UUID in com.apple.Boot.plist. Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 2, 2011 Share Posted February 2, 2011 Now about the latest update i.e. Revolution 637 which I tell you is riddled with bugs. Far too many errors. Doesn't even boot, or even reboots on an internal drive. Problem here is that I don't have a hack myself. Got to have a simple desktop hack myself. Asked my brother what he has in stock for me because this I tell you is not working for me. It sucks. Has to change. 637 is the one working for me, only I need the UUID in c.a.B.p I have a Case (or 2), A PSU, Some GT120 cards (5 to be exact), Don't have a "good" hack MB, but Have some spare ones that can work ....Just say what you need Had a scary moment there today, unplugged my USB drive on the wrong time and corrupted it. At that time I had the UUId removed on my main drive .....Lucky I had a old boot CD .....Just made a spare Emergency Boot-key and turned on Write-protection on it Link to comment Share on other sites More sharing options...
scrax Posted February 3, 2011 Share Posted February 3, 2011 Your table is fine. Your table includes data (read: bytes), but the the table in the ioreg that scrax attached here is that there's only a name. Nothing else. Just a name. And that is wrong. I think blackosx is right, because this is what I get from linux: /* * Intel ACPI Component Architecture * AML Disassembler version 20091112 * * Disassembly of /Users/scriz/Desktop/ACPI Dump Zotac/FACS.aml, Wed Feb 2 18:53:08 2011 * * ACPI Data Table [FACS] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "FACS" [004h 0004 4] Length : 00000040 [008h 0008 4] Hardware Signature : 00000000 [00Ch 0012 4] 32 Firmware Waking Vector : 00000000 [010h 0016 4] Global Lock : 00000000 [014h 0020 4] Flags (decoded below) : 00000000 S4BIOS Support Present : 0 64-bit Wake Supported (V2) : 0 [018h 0024 8] 64 Firmware Waking Vector : 0000000000000000 [020h 0032 1] Version : 00 [021h 0033 3] Reserved : 000000 [024h 0036 4] OspmFlags (decoded below) : 00000000 64-bit Wake Env Required (V2) : 0 Raw Table Data 0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 FACS@........... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ We have the same Raw Table Data but it seems not loaded right by chameleon or Revolution... Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 3, 2011 Share Posted February 3, 2011 I can also confirm the same for my system for what it is worth and from mac mini Groot Link to comment Share on other sites More sharing options...
scrax Posted February 3, 2011 Share Posted February 3, 2011 Hi scrax,Neither Revolution nor Chameleon "loads" this data. AppleAHCIPlatform.kext does this. Not us. thank's for clarification. I just checked the facs table on the P5KC setup and it's loaded correctly but it has a little difference from the one of the zotac board, The version bit is at 1 instead of 0 Zotac 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 P5KC 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MacMini 46 41 43 53 40 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 On the macmini the green bit is for Hardware Signature : 00000400 GrootWitBaas can you please check if your data are like the one we have me and blackosx? Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 3, 2011 Share Posted February 3, 2011 If you tell me where to check sure. What I have posted above is what I see, but If you tell me where and how to get it I can do. Remember I am learning here Have a Linux live Key drive, just need the command to dump it Link to comment Share on other sites More sharing options...
scrax Posted February 3, 2011 Share Posted February 3, 2011 If you tell me where to check sure. What I have posted above is what I see, but If you tell me where and how to get it I can do. Remember I am learning here Have a Linux live Key drive, just need the command to dump it You can use DSDTSE from osx. Once opened above the "Extract Table" button there is a drop down menu to select the table you need. Select facs and click the button to have your table. Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 3, 2011 Share Posted February 3, 2011 [000h 0000 4] Signature : "FACS" [004h 0004 4] Length : 00000040 [008h 0008 4] Hardware Signature : 00000000 [00Ch 0012 4] 32 Firmware Waking Vector : 00000000 [010h 0016 4] Global Lock : 00000000 [014h 0020 4] Flags (decoded below) : 00000000 S4BIOS Support Present : 0 64-bit Wake Supported (V2) : 0 [018h 0024 8] 64 Firmware Waking Vector : 0000000000000000 [020h 0032 1] Version : 00 [021h 0033 3] Reserved : 000000 [024h 0036 4] OspmFlags (decoded below) : 00000000 64-bit Wake Env Required (V2) : 0 Raw Table Data 0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 FACS@........... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Link to comment Share on other sites More sharing options...
humph Posted February 3, 2011 Share Posted February 3, 2011 FWIW, here's my FACS from S12, grabbed from IOReg ACPI Tables section: <46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> Link to comment Share on other sites More sharing options...
magnifico Posted February 3, 2011 Share Posted February 3, 2011 You can use DSDTSE from osx. Once opened above the "Extract Table" button there is a drop down menu to select the table you need. Select facs and click the button to have your table. you answer for courtesy Thank's Link to comment Share on other sites More sharing options...
blackosx Posted February 3, 2011 Share Posted February 3, 2011 Good to read you have been busy again DHP. Getting ready now..... Is there a directive to enable for #if STATIC_FACS_TABLE_INJECTION ? I've added the data, just couldn't see a switch, or maybe it's automatic? Got to stop leave for a while now. I'll check in later. Link to comment Share on other sites More sharing options...
GrootWitBaas Posted February 3, 2011 Share Posted February 3, 2011 Prepared and ready to try the next one ... Link to comment Share on other sites More sharing options...
dgsga Posted February 3, 2011 Share Posted February 3, 2011 DHP, just a quick question about #define STATIC_CPU_QPISpeed. My QPI is 6.532 GT/s = 6532MT/s = 6532000KT/s = 6532000000T/s Am I right in thinking that #define STATIC_CPU_QPISpeed should be 6532000000ULL? I like the way private_data is heading, very neat indeed. Link to comment Share on other sites More sharing options...
DB1 Posted February 3, 2011 Share Posted February 3, 2011 The next release (Revolution 0.6.38) will add support for the following new directives: STATIC_APIC2_TABLE_INJECTION STATIC_ECDS_TABLE_INJECTION STATIC_FACS_TABLE_INJECTION STATIC_HPET_TABLE_INJECTION They are however not part of our template, as you noticed, but that's only because I want them to be verified and confirmed to work first. Great. Still one very annoying bug to fix... getting closer. Thanks. Me too. Much more fun this way. Was a bit of work, but I'm glad I did it. And you make it look like I know something LOL I guess this is right, but please don't blame me when it doesn't work. Back to cracking a nut. Err bug or two... And here it is. Compiled fine with static as well as dynamic CPU and SMBIOS data. Also checked the new directives. No compiler warnings/errors. Won't have loads of time tonight, but this version is our next reference point. See if you spot ehh what's that name again. Oh yeah regressions Was unable to fix the bug I was working on, but that's part of all boot loaders since Chameleon v1.0 already so... no worries. Will get it sorted some day soon so that we can all enjoy an even quicker boot time. p.s. One note about the addition of APIC2 You only need this on systems with more than 8 logical cores! Excellent work DHP, fastest boot yet for me (40 seconds from switch on to log in) and everything working as should (on SDCard) everything is static bar for cpu. I was getting a bit despondent as previous variant caused me bootlag problems i could not solve but this is great. Suggestion for next update. Instead of trying to remember or interpret from failed compile where to put links to private dat why not pre define the link and sit the file within the Revolution package. Link to comment Share on other sites More sharing options...
blackosx Posted February 3, 2011 Share Posted February 3, 2011 Hi DHP. Well done with your hard work continuing here and Rev-638 boots fine for me, though I am still running some tests. The automatic UUID detection works wonderfully, though it does seem to slow the boot process down for me. I guess that's to do with my having 12 partitions over two HDD's? EDIT: Here's a compilation of screenshots of the debug of one test boot. Should this revision patch my FACS table? as I haven't had any success with it. I've tried adding #define STATIC_FACS_TABLE_INJECTION 1 in to private_data.h, along with #if STATIC_FACS_TABLE_INJECTION #define STATIC_FACS_TABLE_DATA \ /* 0x0000 */ 0x46, 0x41, 0x43, 0x53, 0x40, 0x00, 0x00, 0x00, \ /* 0x0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ /* 0x0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ /* 0x0018 */ 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ /* 0x0020 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ /* 0x0028 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ /* 0x0030 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ /* 0x0038 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 #endif // STATIC_FACS_TABLE_INJECTION Am I approaching this completely the wrong way? EDIT: Looked at this again, now trying to use: 0x53434146, 0x00000040, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, \ 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 Also, in private_data.h the line for the pre-linked kernel reads: #define PRE_LINKED_KERNEL_SUPPORT 1 // Set to 1 by default. Change this to 1 to disable the use of pre-linked kernels. Shouldn't this read set to 0 to disable the use of pre-linked kernels. ? But as dgsga commented, private_data.h is coming on great and I like the option's you're including there, including the one to set the resolution. Good work Link to comment Share on other sites More sharing options...
DB1 Posted February 4, 2011 Share Posted February 4, 2011 Good evening DB1, Excellent news. This is exactly the kind of response I hoped for but you never know what's next. Good idea. Let me make a quick patch for it. Done. See attachments. Now add a new file in i386/private_data.h with something like this: #ifndef __LIBSAIO_PRIVATE_H #define __LIBSAIO_PRIVATE_H // #include "private_data_asus.h" #include "../../private_data_hp.h" #endif /* !__LIBSAIO_PRIVATE_H */ Which shows you that I have two. This is also why I was so quick, because I am in fact already using something like this. One for the new Asus and one for the HP G72 notebook. It's late and I've had to many glasses of red but will try this before I go to work if I get 10 minutes free otherwise will try tomorrow evening. I have no doubts it will work. A great couple of day s work and I really appreciate being part of this groundbreaking stuff with you and the others that are testing and pushing the boundaries. Keep it up and we'll be ready for Lion and instaboot by the time of release. D Link to comment Share on other sites More sharing options...
dgsga Posted February 4, 2011 Share Posted February 4, 2011 Hi All Just an update to let you know that 638 works fine, detects internal RAID drive OK and boots seamlessly. Good work DHP Link to comment Share on other sites More sharing options...
Recommended Posts