Jump to content

DarwinDumper

Bootloader BIOS IOReg Device Properties LSPCI Dump VBIOS SMC ACPI NVRAM

  • Please log in to reply
236 replies to this topic

#221
Maniac10

Maniac10

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,212 posts
  • Gender:Not Telling

Have you rebooted since last dump?

 

Yes, and also these last two dumps were done from Mavericks and the other 2 from Yosemite.



#222
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,139 posts
  • Gender:Male
  • Location:UK

Clover 2795

Thanks for the confirmation .:Fabio:.

But was it CloverEFI or UEFI Clover? ;)


Yes, and also these last two dumps were done from Mavericks and the other 2 from Yosemite.

Thanks for the confirmation.

Which loader was used for your 2 dumps?

 

EDIT: Oops.. Sorry I see you already told me; Clover EFI. 


Hi blackosx

I think you will be able to use this method to dump video/system roms as well.

Yeah.. Slice showed this with his kernel memory dumper

I'd been wanting to use it for a while but it was 32bit only. So since Andy posted pmem.kext it's got me interested again..

 

So the question is, can we get more video rom data from direct memory than we can get already with the existing tools in DarwinDumper?



#223
STLVNUB

STLVNUB

    InsanelyMac Legend

  • Coders
  • 1,139 posts
  • Gender:Male

Yeah.. Slice showed this with his kernel memory dumper

I'd been wanting to use it for a while but it was 32bit only. So since Andy posted pmem.kext it's got me interested again..

 

So the question is, can we get more video rom data from direct memory than we can get already with the existing tools in DarwinDumper?

Well on my Z77pro3, can't dump bios, must be protected.

Also doesn't dump whole VBios, like legacy/UEFI. i.e 66k NOT 132K



#224
bs0d

bs0d

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 166 posts

you maybe able to read them directly from the cards this would also permit reading cards that haven't posted.

 

since usually only 1 video bios can be active in the legacy region.

 

most of the boot loaders have code for retrieving the rom directly from cards, this should be possible with a kext,



#225
.::Fabio::.

.::Fabio::.

    InsanelyMac Legend

  • Moderators
  • 8,597 posts
  • Gender:Male
  • Location:Italy

Thanks for the confirmation .:Fabio:.

But was it CloverEFI or UEFI Clover?

 

UEFI Clover

 

Fabio



#226
stehor

stehor

    InsanelyMac Protégé

  • Members
  • Pip
  • 40 posts
  • Gender:Male
  • Location:tx
  • Interests:MacMini6,1/MacMini6,2/ASROCK pro4 i5 3570k hd4000/ASROCK pro3 i5 3570k hd4000/ASROCK z97 Extreme...

dump from asrock z97extreme6 bios 1.30  https://www.dropbox....reMemoryMap.txt



#227
joe75

joe75

    Renegade

  • Retired
  • 2,276 posts
  • Gender:Male
  • Location:Rochester, NY

http://www.mediafire...dump_205035.zip

 

0.44 got it :D



#228
Maniac10

Maniac10

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,212 posts
  • Gender:Not Telling

Ok, here are the dumps for both boot, legacy and "UEFI" (hybrid actually).

 

Attached File  dump_220540_CloverEFI.zip   81.94KB   4 downloads

Attached File  dump_225514_hybrid_CloverUEFI.zip   65.1KB   3 downloads



#229
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,139 posts
  • Gender:Male
  • Location:UK

Well on my Z77pro3, can't dump bios, must be protected.

Also doesn't dump whole VBios, like legacy/UEFI. i.e 66k NOT 132K

Okay. I'll take a look once I'm happy with the ACPI dumps.


you maybe able to read them directly from the cards this would also permit reading cards that haven't posted.

 

since usually only 1 video bios can be active in the legacy region.

 

most of the boot loaders have code for retrieving the rom directly from cards, this should be possible with a kext,

Thanks for the info bs0d.


UEFI Clover

Thanks for the confirmation .::Fabio::.


dump from asrock z97extreme6 bios 1.30  https://www.dropbox....reMemoryMap.txt

Why have you posted a link to the FirmwareMemoryMay trace script?

If you wish to provide a test result then please supply the dump_<TIME> directory created after double-clicking the 'dumpACPIfromMem.command' script.


Great!.. Thanks for confirming joe75 :D

I notice your system has an SSDT with table ID CpuSsdt with links to four further tables (well 3 as I'm willing to bet the first address pointer will be invalid). The script had only been checking for a table ID of CpuPm so this table of your was missed.

I've fixed that in v0.45 of the script.


Ok, here are the dumps for both boot, legacy and "UEFI" (hybrid actually).

 

attachicon.gifdump_220540_CloverEFI.zip

attachicon.gifdump_225514_hybrid_CloverUEFI.zip

Thanks Maniac10 - checking now.

 

EDIT:
AML_b0fa3040 from both dumps contains your original tables.
AML_00000000b0dcd000 and AML_00000000b0c28000 contain your patched tables. There are slight differences in the DSDT of those dumps but that may be down to bootloader configs.
 
v0.45 of the script will leave you with a cleaner dump folder as the invalid AML_00000000b0c2a120 and AML_b0c2a038 directories will no longer be present.
 
Thanks for testing.

@kynnder - I've been thinking about your dump and am thinking along the lines that Clover's on-the-fly DSDT fixes patch the tables directly in memory. So maybe that's why your dump shows only the clover auto patched one. I don't make use of Clover's auto DSDT patching so have nothing else for comparison - I will have to test it here to be certain. But otherwise, ACPI table dumps from the script when booting with Clover UEFI are working..



#230
joe75

joe75

    Renegade

  • Retired
  • 2,276 posts
  • Gender:Male
  • Location:Rochester, NY

http://www.mediafire...dump_074404.zip

 

now we're talking!  looks like it got them all now. the SSDT-ami7hdm3 is the SSDT i inject with Oz and is from RampageDevs haswell pkg if you were wondering about the name



#231
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,139 posts
  • Gender:Male
  • Location:UK

Thanks for the report joe75.

It's great the script has detected all your tables, however as far as I can tell, it has not dumped your original bios DSDT.

The DSDT in the AML_00000000dcd87078 directory does not successfully decompile here using iASLme

Could not parse ACPI tables, AE_AML_NO_OPERAND

and MacIASL reports:

iASL returned:
ACPI Warning: Incorrect checksum in table [DSDT] - 0x41, should be 0xC8 (20100331/tbutils-351)]

I saw a similar issue trying to decompile a dumped DSDT from my hack when booted using Clover UEFI. The error was different, but I still couldn't open it.

 

EDIT: Now back on my hack and examining some of my tests I can surmise:

 

Dumping Original Tables:

Booting with Chameleon, Clover EFI, Clover UEFI and Ozmosis.
Memory region 00000000cabb1000 - 00000000cabb9fff provides RSDP pointer to XSDT at 00000000cabb1060
All tables are fine except DSDT which proves to be corrupt.
 
Booting with Chameleon, Clover EFI and Ozmosis. 
Memory region 00000000ca93f000 - 00000000cab91fff provides RSDP pointer to XSDT at 00000000cab84070
All tables are fine including DSDT.
 
Dumping Patched Tables:
Booting with Clover UEFI.
Memory region 00000000ca93f000 - 00000000cab91fff provides RSDP pointer to XSDT at 00000000cabc2000
All Tables are fine including DSDT
 
Booting with Chameleon, Clover EFI and Ozmosis
Memory region 00000000cab92000 to 00000000cabc3fff provides RSDP pointer to XSDT at 00000000cabc0070
All tables are fine including DSDT.
 
Conclusion:
I can’t get original DSDT using Clover UEFI.
 
EDIT: Some more thoughts on why the original DSDT may be corrupt when following XSDT at 00000000cabb1060...
 
I was thinking maybe the data inside the ACPI_recl region was being overwritten as ACPI_recl regions are reclaimable (meaning the OS can re-use this area once booted). And indeed I did find some DMI info in one supposed DSDT data dump.
 
The memory map in this instance was:
ACPI_NVS   00000000cabb1000 - 00000000cabb4fff   = 16,383 bytes
ACPI_recl  00000000cabb5000 - 00000000cabb7fff   = 12,287 bytes
ACPI_NVS   00000000cabb8000 - 00000000cabbefff   = 28,671 bytes
                                         Total   = 57,341 bytes
 
The DSDT (length of 47,866) was found at 00000000cabb1128, so that means 296 bytes in to first ACPI_NVS region and spanning across ACPI_recl region and in to next ACPI_NVS region taking it up to 00000000cabbcafa.
 
Thing is though, the DSDT corruption doesn’t really happen until after 0x6ED6 (28374 bytes) (which is the combined sum of ((16383-296)+12287). Meaning the corruption happens in the ACPI_NVS region which AFAIK is supposed to remain untouched by the OS.
 
So I'm not sure what to think ATM.


#232
Micky1979

Micky1979

    I realized that I am lucky

  • Moderators
  • 1,929 posts
  • Gender:Male
  • Location:a 100m dal Tevere, vicino a Peppe

Hi blackosx,

 

you have any plan on how to load DirectHW.kext if Apple remove kext-dev-mode flag in Yosemite GM kernel?

I've crete a obj-c code to run lspci (from Pandora) and store the output in a NSArray, line by line, so is easy to find what i need using "rangeOfString" method. 

I can repair permission of that kext and then load it (only if not alredy loaded)....but you can image the problem if kext-dev-mode will be removed..

 

Micky

 

Attached File  lspci.png   606.14KB   3 downloads



#233
joe75

joe75

    Renegade

  • Retired
  • 2,276 posts
  • Gender:Male
  • Location:Rochester, NY

Personally I don't think they are ready to remove that flag, for driver or app extensions. Also until they remove their own stock unsigned kexts there must be some way of loading them, either from excluded list or kernel flag.



#234
Micky1979

Micky1979

    I realized that I am lucky

  • Moderators
  • 1,929 posts
  • Gender:Male
  • Location:a 100m dal Tevere, vicino a Peppe

Personally I don't think they are ready to remove that flag, for driver or app extensions. Also until they remove their own stock unsigned kexts there must be some way of loading them, either from excluded list or kernel flag.

It would be nice. However if you want load DirectHW.kext (or any other)  on demand from an Application bundle can be problematic without a reboot  :(

 

EDIT

1° option is to sign it with a Dev account... but mine is expired  ($99  :cry:)



#235
Pavo

Pavo

    InsanelyMac Geek

  • Developers
  • 109 posts
  • Gender:Male
  • Location:Fort Gordon, GA
  • Interests:GA Z97X-SLI motherboard, i3 4160, 16Gb ram, EVGA GTX 770, ALC1150 on board sound, PERC 5i SAS ca...

iMac15,1 5k Imac Darwindump w/o admin rights

Attached Files



#236
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,139 posts
  • Gender:Male
  • Location:UK

Hi blackosx,

 

you have any plan on how to load DirectHW.kext if Apple remove kext-dev-mode flag in Yosemite GM kernel?

I've crete a obj-c code to run lspci (from Pandora) and store the output in a NSArray, line by line, so is easy to find what i need using "rangeOfString" method. 

I can repair permission of that kext and then load it (only if not alredy loaded)....but you can image the problem if kext-dev-mode will be removed..

 

Micky

 

attachicon.giflspci.png

Hi Micky1979 - sorry for the delay in coming back to you. I've been busy with other projects.

 

I currently have no plan on how to load DirectHW.kext (currently used for lspci and flashrom dumps ) if apple completely disallow unsigned kexts, other than have it as a signed kext. Nice work with your code for lspci output. 


iMac15,1 5k Imac Darwindump w/o admin rights

Thanks for sharing Pavo



#237
leatherman

leatherman

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts

Thanks Blackosx!!!!!!l for me this is the beast tooll for dump all info of the System and hardware, great work!!!!







Also tagged with one or more of these keywords: Bootloader, BIOS, IOReg, Device Properties, LSPCI, Dump, VBIOS, SMC, ACPI, NVRAM


2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy