netkas.org

I have found out that 32-bit apps support in Catalina was disabled but not completely removed

Current state is enough to run some console 32-bit apps in catalina

to have it run this command:

sudo nvram boot-args=”no32exec=0″

if one wants more, like gui app, need to use some libs from mojave probably.

next is some output from console

$ uname -a

Darwin Macs-Mac-Pro.local 19.0.0 Darwin Kernel Version 19.0.0: Wed Sep 25 20:18:50 PDT 2019; root:xnu-6153.11.26~2/RELEASE_X86_64 x86_64

$ file EfiDecompress.macosx

EfiDecompress.macosx: Mach-O executable i386

$ ./EfiDecompress.macosx

EfiDecompress v1.1 -Efi File Decompress Utility

Copyright (c) 2005-2006 Intel Corporation. All rights reserved.

Usage: EfiDecompress Inputfile Outputfile

$ otool -L EfiDecompress.macosx

EfiDecompress.macosx:

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)

$ file /usr/lib/libSystem.B.dylib

/usr/lib/libSystem.B.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386]

/usr/lib/libSystem.B.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

/usr/lib/libSystem.B.dylib (for architecture i386): Mach-O dynamically linked shared library i386

$ nvram boot-args

boot-args no32exec=0

 

here is how one can try to run 32-bit gui app, can’t say it’s working very well

DYLD_ROOT_PATH=/Volumes/Macintosh\ SSD/ ./CrossOver

 

DYLD_ROOT_PATH should specify root volume for macos mojave

Comments(1)

Yeaterday I booted old Catalina DP on MY NMP, it showed update – DP beta 11.
I thought, ok, lets see.

Update got downloaded… reboot…. firmware update… reboot… mac is dead.

Mac doesn’t boot anymore.
It just starts up, no bootchime (and I have it disabled anyway), after like 5 mins it lights up connected display, displaying black screen on it (even tho at proper resolution)

That’s it, no boot, wait many hours, nothing changes.

PRAM reset – didn’t help. SMC reset – didn’t help..

A secret way to do pram reset – didn’t help. (take out cmos battery, it clears RTC, mac will boot in “EFI_BOOT_WITH_DEFAULT_PARAMETERS” mode next time, ignoring NVRAM on startup, at least in PEI mode)

Cool update I thought. At least I can swap ssd to macmini and get my data back.

The final solution was to get access to eeprom, it’s on bottom pcb, inside NMP.

Using CH341A/AsProgrammer (thanks Alex for CH341A), I was able to read and write the EEPROM chip with main bios rom.

I tried to make pram reset in hard way, wiping out content of two VSS partitions inside efi ( they hold nvram arguments).
That helped, mac booted.

Appearently it’s a bug in new fw of parsing some nvram params.

Apple, Wanna that firmware ? I still have that dump.

P.S. this is how mac looked for few days, still can boot it this way. bios rom IC is on the other side of pcb you can see.

nmp

Comments(0)

Some thought amd cards would never work again on macs without sse4.2

 

MP3,1, radeon 560, full metal and opengl acceleration in Mojave
Details in forum

Comments(0)

In the comment to this news – https://videocardz.com/newz/amd-radeon-navi-gpus-spotted-in-macos-mohave-update

Navi10, Navi16, Navi9 is not chip names, the number is just c++ name separator

I would use c++filt name demangler to show this:

Function names as is:

$nm AMDRadeonX6000HWServices | grep Navi

__GLOBAL__sub_I_AMDRadeonHWServicesNavi.cpp

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi10MatchTableE

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi10gMetaClassE

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi10superClassE

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi16ProjectNameTableE

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi16getMatchPropertyEv

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi9MetaClassC1Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi9MetaClassC2Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi9MetaClassD0Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi9MetaClassD1Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNavi9metaClassE

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviC1EPK11OSMetaClass

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviC1Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviC2EPK11OSMetaClass

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviC2Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviD0Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviD1Ev

__ZN38AMDRadeonX6000_AMDRadeonHWServicesNaviD2Ev

__ZNK38AMDRadeonX6000_AMDRadeonHWServicesNavi12getMetaClassEv

__ZNK38AMDRadeonX6000_AMDRadeonHWServicesNavi9MetaClass5allocEv

__ZTV38AMDRadeonX6000_AMDRadeonHWServicesNavi

__ZTVN38AMDRadeonX6000_AMDRadeonHWServicesNavi9MetaClassE

__ZZN38AMDRadeonX6000_AMDRadeonHWServicesNavi16getMatchPropertyEvE18PROJECT_NAME_COUNT

with c++ name demangling: $ nm AMDRadeonX6000HWServices | grep Navi | c++filt

__GLOBAL__sub_I_AMDRadeonHWServicesNavi.cpp

AMDRadeonX6000_AMDRadeonHWServicesNavi::MatchTable

AMDRadeonX6000_AMDRadeonHWServicesNavi::gMetaClass

AMDRadeonX6000_AMDRadeonHWServicesNavi::superClass 

AMDRadeonX6000_AMDRadeonHWServicesNavi::ProjectNameTable 

AMDRadeonX6000_AMDRadeonHWServicesNavi::getMatchProperty() 

AMDRadeonX6000_AMDRadeonHWServicesNavi::MetaClass::MetaClass() 

AMDRadeonX6000_AMDRadeonHWServicesNavi::MetaClass::MetaClass() 

 AMDRadeonX6000_AMDRadeonHWServicesNavi::MetaClass::~MetaClass() 

AMDRadeonX6000_AMDRadeonHWServicesNavi::MetaClass::~MetaClass()

AMDRadeonX6000_AMDRadeonHWServicesNavi::metaClass

AMDRadeonX6000_AMDRadeonHWServicesNavi::AMDRadeonX6000_AMDRadeonHWServicesNavi(OSMetaClass const*)

AMDRadeonX6000_AMDRadeonHWServicesNavi::AMDRadeonX6000_AMDRadeonHWServicesNavi()

AMDRadeonX6000_AMDRadeonHWServicesNavi::AMDRadeonX6000_AMDRadeonHWServicesNavi(OSMetaClass const*)

AMDRadeonX6000_AMDRadeonHWServicesNavi::AMDRadeonX6000_AMDRadeonHWServicesNavi()

AMDRadeonX6000_AMDRadeonHWServicesNavi::~AMDRadeonX6000_AMDRadeonHWServicesNavi()

AMDRadeonX6000_AMDRadeonHWServicesNavi::~AMDRadeonX6000_AMDRadeonHWServicesNavi()

AMDRadeonX6000_AMDRadeonHWServicesNavi::~AMDRadeonX6000_AMDRadeonHWServicesNavi()

AMDRadeonX6000_AMDRadeonHWServicesNavi::getMetaClass() const

AMDRadeonX6000_AMDRadeonHWServicesNavi::MetaClass::alloc() const

vtable for AMDRadeonX6000_AMDRadeonHWServicesNav

vtable for AMDRadeonX6000_AMDRadeonHWServicesNavi::MetaClass 

AMDRadeonX6000_AMDRadeonHWServicesNavi::getMatchProperty()::PROJECT_NAME_COUNT

Comments(5)

Just enter this in command line then type in your admin user password:

sudo vmmap -v 1

After some short time the system will completely hard freeze

Comments(0)

Just updated to Mojave Beta2 on some 15″ mac book pro 2017 (with touchbar) and found out unpleasant thing.
Mac firmware was updated and mac efi now refuses to boot into efi shell (bootx64.efi file located on efi partition in /EFI/BOOT folder), it was working fine before update.

Either it’s some error or Apple is forcing signature check on efi boot file now (boot.efi and apfs.efi already has signatures)

Bootpicker sees the EFI_BOOT record, but choosing it results in booting macos, further investigation shows mac efi won’t even trying to run custom bootloader, its entry point is never called.

UPDATE: probably a bug, placing efi shell to /usr/standalone/i386/boot.efi location and using system prefs to reboot into target volume (which will rebless the partition) helped to get efi shell booted. no sig check obviously.

Comments(0)

A bit old news, but
With some of DP for high sierra Apple has accidentially released fw for imac pro.
You can find it here – https://github.com/gdbinit/firmware_vault/blob/master/EFI/Unknown%20Models/AAPJ1371_0058_B00.fd

Why I think it’s imac pro ? dsdt has name of model – imac. ALso there is uefi driver for amd radeon vg10.

That matches imac pro.

few other interesting things I’ve found: apple secure boot and microsoft secure boot support. first time spi flash rom is 16 mb (prevuously it waws 8 mb). voice over uefi driver (siri on separate cpu will work even in uefi ?)

Comments(3)

Following new GTX Titan Xp announce: https://blogs.nvidia.com/blog/2017/04/06/titan-xp/

Open to Mac Community

Speaking of users, we’re also making the new TITAN Xp open to the Mac community with new Pascal drivers, coming this month. For the first time, this gives Mac users access to the immense horsepower delivered by our award-winning Pascal-powered GPUs.

Comments(6)

One of our forum members has successfully bypassed blacklist of tb3 devices in macos and running egpu in razer core on new mbp.

More here

For anyone skilled enough who wants to repeat it.
“After digging around, it looks like the decision is made by IOThunderboltFamily. There is a shouldSkipEnumeration function and by patching it to always return false”

Comments(3)

More news:

Using same trick as for R9 Nano it was possible to get new RX 480 card working in osx.

Not very stable.

more info in forum.

Comments(3)