Jump to content
InsanelyMac Forum
  • Announcements

    • Allan

      Solution to create a topic or post.   04/24/2018

      Hello guys. The majority of you are having issues to create a topic or post here. This are a problem with our current theme InsanelyMac.  Now the theme will be the Default IPS. Sorry for any inconvenience.

Recommended Posts

Advertisement

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::.

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..

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

lspci.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

v2.9.6 -> 2.9.7

 
2.9.7beta's have been in around for a while so let's wrap them up in to a release.
 
- Fix bug where clover revision number ending in zero would be truncated.
- Revert to reading ACPI tables from ioreg for all versions of OS X before Yosemite.
- EDID dump also reads data from Clover bootlog (if booted using Clover).
- Updated dmidecode from v2.12 to v2.12b (Thanks THe KiNG).
- Added memory dump option for Intel Graphics (more info) (Command line option only).
- Added experimental memory dump option for BIOS ACPI tables (Command line option only).

Share this post


Link to post
Share on other sites

For an example of why I included the experimental ACPI dump from memory.

 

On my iMac, using DarwinDumper's ACPI dump option from the UI, I get the following SSDT tables:
SSDT-CpuPm
SSDT-SataAhci
SSDT-SataPrt2
SSDT-SmcDppt
SSDT-UsbNoRmh

On my iMac, using DarwinDumper's memory ACPI dump option from the command line.

darwindumper -d acpiFromMem

I get the following SSDT tables:

SSDT-ApCst
SSDT-ApIst
SSDT-Cpu0Cst
SSDT-Cpu0Ist
SSDT-CpuPm
SSDT-SataAhci
SSDT-SataPrt2
SSDT-SmcDppt
SSDT-UsbNoRmh

 

Share this post


Link to post
Share on other sites

M using ROM for my AMD Radeon HD 7650m from internet resources, is it ok coz I've tried GPU-Z, AIDA64,DarwinDumper,DPCI Manager but no luck.

M getting Full QE/CI, only wanted to know if its ok to use someone ROM(same device) or it will cause problem to my graphics card.

Is VBios ROM device specific ! 

Also m having Gradient Issue !

 

 

i can see rom in Ubuntu 14.01 (Live USB)!

ubuntu@ubuntu:~$ find /sys/devices -name "rom"

/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/rom <- this is Bios (131kb)

/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/rom <- this is VBios ROM (65kb)

 

only need to copy !

Ive used Sudo but no luck !

But y does ubuntu is giving I/O error !

 
I finally managed to dump Bios using Intel Flash Tool 

http://www.insanelym...io-sve1712bcxb/

 

But m unable to open the file !

 

i used this cmd 

FPTW64.EXE -BIOS -D BACKUP.ROM

 

n i got this file.


should i use this 

FPTW64.exe -D -Bios   !

to get VBios !

BACKUP.ROM.zip

Share this post


Link to post
Share on other sites

thanks slice :)

 

but i dont know how to extract it :(

Yes, this is VBIOS beginning from offset 0x68.

You have to take VFCT.aml (don't decompile!) and cut first 0x68 bytes by HexEditor or by dd command.

Share this post


Link to post
Share on other sites

slice i dont have much knowledge abt it !

can u give some example :(

 

opened in textwrangler then  i got confused !

 

:( 

Share this post


Link to post
Share on other sites

DarwinDumper should read and decode the VFCT table. However, looking at it now I see v2.9.7 would fail because ACPI tables are no longer in ioreg with OS X Yosemite. Where I'd updated the main ACPI routine to handle this, I had not done so with the VBIOS routine.

 

Please try the VBIOS dump with this version in Yosemite.

 

EDIT: Attachment removed as v2.9.8 has been released.

Share this post


Link to post
Share on other sites

Thanks Slice n Blackosx ill surely try, after all u have given me hope after 2 month of trying.

Currently my hack is with my uncle but ill surely let u know.

 

Thanks a lot.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.



×