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

Thank you too Maniac10.

I'll take a look :)

 

EDIT:

I can see what looks like your patched DSDT and SSDT but not original BIOS tables.

Looking at your forum signature I see your board is the Z68AP-D3, and I see the BIOS uses ACPI v1.0b

 

My script has a bug, or lack of correct code handling, for the ACPI v1.0 RSDT and currently, wrongly, iterates through the RSDT expecting 8 byte pointer addresses (as that's all I've been testing with), where as it needs to take 4 byte pointer addresses.

 

The log shows:

Found Table:  at b0fa8340b0fa3100 | Length: 0
Found Table:  at b0fa8480b0fa8400 | Length: 0
Found Table:  at b0fa8640b0fa8600 | Length: 0
Found Table:  at b0faaa30b0faa970 | Length: 0
Found Table:  at b0fa8240b0faaa90 | Length: 0
Found Table:  at b0faecc0b0fab380 | Length: 0
 
Where as your RSDT shows:
[024h 0036   4]       ACPI Table Address   0 : B0FA3100
[028h 0040   4]       ACPI Table Address   1 : B0FA8340
[02Ch 0044   4]       ACPI Table Address   2 : B0FA8400
[030h 0048   4]       ACPI Table Address   3 : B0FA8480
[034h 0052   4]       ACPI Table Address   4 : B0FA8600
[038h 0056   4]       ACPI Table Address   5 : B0FA8640
[03Ch 0060   4]       ACPI Table Address   6 : B0FAA970
[040h 0064   4]       ACPI Table Address   7 : B0FAAA30
[044h 0068   4]       ACPI Table Address   8 : B0FAAA90
[048h 0072   4]       ACPI Table Address   9 : B0FA8240
[04Ch 0076   4]       ACPI Table Address  10 : B0FAB380
[050h 0080   4]       ACPI Table Address  11 : B0FAECC0

I'll post a revised script soon.

 

Thanks for testing.

Share this post


Link to post
Share on other sites

@Maniac10 - I have revised the script and posted v0.40 in earlier post.

If you could please re-test when you get time then that would be great.

Thanks

Clover UEFI...

 

Here's the new dump > http://cl.ly/2t0H4641262u

 

Thank you again!

Thanks again kynnder.

I'll take a look.

 

EDIT:

The good news is the routine deciding which memory regions to read now performs as expected.

However, looking at the dumped DSDT I see

Name (VER0, "Clover auto patched")

So it's not the native BIOS DSDT table.

 

My local tests have been with CloverEFI and not UEFI. I will need to conduct tests with Clover UEFI here before knowing more.

 

Thanks for your time kynnder.

Share this post


Link to post
Share on other sites
@Maniac10 - Thanks for providing a dump with v0.40.
The script now correctly finds 12 tables from following your v1.0 RSDT. However you have helped find another bug where the script failed to look in the FACP for the FACS and DSDT address pointers.
I hope to have now fixed that and posted a revised v0.41 of the script to my original post for this.
Would it be possible to run another test please?

I can try booting in UEFI mode but my BIOS is actually a hybrid, not full UEFI. Would you like it anyway?

Thanks. But only if you wish to do so. No problem if you don't.
 
 
@joe75 - Thank you for testing also :)
This is the first example I've seen where no valid RSDP pointers have been found in the ACPI_NVS regions of memory.
Maybe the script needs to search other areas of memory?

Share this post


Link to post
Share on other sites

Actually.. looking at debug_resolve_rsdp_pointers.txt file from your supplied test I see you do actually have two valid XSDT tables.

My script grabbed the memory block 8 bytes early so therefore failed to read the signature. I'll look in to why...

 

EDIT: @joe75 - Can you try with version 0.43 when you get time please?

Share this post


Link to post
Share on other sites

 

@Maniac10 - Thanks for providing a dump with v0.40.
The script now correctly finds 12 tables from following your v1.0 RSDT. However you have helped find another bug where the script failed to look in the FACP for the FACS and DSDT address pointers.
I hope to have now fixed that and posted a revised v0.41 of the script to my original post for this.
Would it be possible to run another test please?
 
Thanks. But only if you wish to do so. No problem if you don't.

 

Here's the dump with rev 0.42: dump_103600.zip

 

Tonight I'll upload a dump from UEFI.

Share this post


Link to post
Share on other sites

Here's the dump with rev 0.42: attachicon.gifdump_103600.zip

 

Tonight I'll upload a dump from UEFI.

Bingo! - That looks good from here. Thanks for your patience Maniac10 :)

Can you confirm the AML_b0fa3040/DSDT-GBTUACPI.aml is your original BIOS table?

@.::Fabio::. - Thank you for your test too.

It looks good here, both patched and original tables.

That's a large DSDT!

Can you confirm which loader used to boot that system please?

Share this post


Link to post
Share on other sites

I've tested your dump script.

It successfully dumped both original and patched tables from memory.

It did however skip one SSDT table because of the size (> 1MB, why?)

I'm using Clover R2815 (my own custom blend) in UEFI mode.

Attached dump for your review ;)

dump_162206.zip

Share this post


Link to post
Share on other sites

Thanks for your test Andy :)

The SSDT table skipped was

"CPU0IST ", 
0xDB859018, 
0x000009AA,
Which you can see should be only 2474 bytes in size.
 
However the address pointer points to invalid data.
7B57D253EA58C8BA
This should be the table signature and size which is clearly wrong.
I've seen this problem in a few dumps and seems quite common.
 
I have put that 1MB limit in place to prevent the script from trying to dump what would be, in this case, 3931687098 bytes.
 
 
EDIT: I've revised the script to now v0.44 to check for non-original SSDT Cpu-Pm tables, such as PM tables generated by Revogirl/Pike's  SSDT-PR gen script. This should prevent you seeing the incorrect, %D4_~-%E8%E2%8E%FF.aml and @%9Df.aml files

Share this post


Link to post
Share on other sites

Bingo! - That looks good from here. Thanks for your patience Maniac10 :)

Can you confirm the AML_b0fa3040/DSDT-GBTUACPI.aml is your original BIOS table?

 

I'll do a dump with Clover and compare them tonight (can't reboot for now).

 

This it the dump with v0.43: dump_124006.zip

Share this post


Link to post
Share on other sites

I'll do a dump with Clover and compare them tonight (can't reboot for now).

 

This it the dump with v0.43: attachicon.gifdump_124006.zip

I see that v0.43 now finds one extra RSDP pointer..

ACPI v1.0 Checksum 00 is valid.
Pointer is valid and correctly resolves to an RSDT table.
Rev:00 | RSDT:b0c2a038 | Checksum:00 | Valid

Have you rebooted since last dump?

It's great to see some positive results coming in. As I'm seeing multiple RSDP pointers in these dumps I will have to figure out the best way to incorporate this in to DarwinDumper... For example, would it be best to just dump all pointers as this script currently does?

 

Has anybody experienced a freeze/crash from running the script?

 

Is anyone booting using Chameleon willing to test?

 

I haven't forgotten about your dump kynnder...

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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,

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.



×