2463 replies to this topic

[spakk]

dmazar, on 02 November 2012 - 01:45 PM, said:

cparm's branch is Chameleon. Changing branch would not change anything. But, it is even not clear if what I write you is correct. Can you dump FirmwareMemoryMap with DarwinDumper?
And, do you need to use -x switch?

I will check it out tonight.
thx

[spakk]

Donk, on 31 October 2012 - 03:44 PM, said:

Well was replying to the poster who seemed to imply it was easy, and wanted to point out that it isn't, and those working on it going to have a big, but very interesting, job getting it working.

1. This is the change to the bcopy.s routine that has been in other patches for Snow Leopard and Lion. Assembler change to xnu source code. http://tgwbd.org/darwin/xnu.html
2. This is a source code change to xnu and is in the C code
3. Well there are other things such as MSR and TSC related code that are CPU specific and need changing in the xnu C code. (For example cpu.c and tsc.c)
4. I haven't seen any code for this, but am still looking to find something that would help. I did think about qemu code but haven't really looked in detail.
5. Actually AndyV's work in post #324 really applies to this issue on fixing CPUID in Mach-O format executables. This is a static patcher rather than dynamic, and would mean if a 3rd party app used SSSE3 or indeed SSE4 it would likely panic when the opcode was executed. Meklort and others built a dyld patch, no source, that fixed this up on loading the executable.

For a Bulldozer CPU 2,3 and 5 would be needed. For those AMD processors without SSSE3, 1 and 4 are also required.

I don't have access to an AMD machine, but I have had an idea using VMware to see if masking the vCPU CPUID would work. This would at least see if an AMD Bulldozer CPU could boot by masking out AMD string from CPUID. I will need to have a bit more of a think about it, but may help see if the other CPUID values work. It's a bit of a long shot and if I think it is possible would need someone with AMD Bulldozer SVM enabled CPU..

I have found a C-Code for the high-resolution timer on many CPUs and compiler read.

here

[instant idiot]

Gils posted a pic over here: http://osx86.co/f102....html#post59113

[spakk]

instant idiot, on 02 November 2012 - 08:41 PM, said:

Gils posted a pic over here: http://osx86.co/f102....html#post59113

Is that not the wrong approach of Gils? He has tested the connatic custom kernel on an Intel machine. Gils should do the test on his AMD Buldozer machine, I think he has a CPU FX8120, then we can see whether or not the kernel runs.

[spakk]

spakk, on 02 November 2012 - 05:31 PM, said:

I will check it out tonight.
thx

here is my test tonight (with only 8 GB of 16 GB of RAM installed)
booted with boot flag:   -v -x cpus=6 arch=x86_64 busratio=20 maxmem=4096 npci=0x2000 ending with KPs like last time.


with boot flag:  -s cpus=6 arch=x86_64  

here the images:

http://www.workuploa...m/image/DlM5dKx
http://www.workuploa...m/image/rR5FVx0


Please make a few suggestions, so that I clean the problems.

tested on Hachintosh: GA-990FXA-UD3 with AMD Phenom II X6 1100T / 8 GB  DDR3 1600 C9 / NVIDIA Geforce GTX 550 TI 3072 MB

With the following BIOS settings (BIOS Version F2 ,First release):

Intelligent Tweaker (MIT) -> • Everything left at default!

Standard CMOS Features---> • Mountain Lion HDD connected in the first place. All other unnecessary hardware is removed.

Advanced BIOS Features ->  • AMD C1E [Disabled]
  • Virtualization [Enabled]
  • AMD 8 Col & Q. [Auto]

Integrated Peripherals ---> • On Chip SATA Controller [Enabled]
   • On Chip SATA Type [AHCI / Native IDE]
   • On-chip SATA 3.0 [Enabled]
   • F_USB30 Controller [Enabled]
   • SATA3 Controller [Enabled]
   • SATA3 Ctrl Mode [AHCI]
   • ON Board 1394 Function [Disabled]
   • The rest remains unchanged!

[zchef2k]

I am of the opinion that the roadblock is userspace FIPS mode. Kernelspace FIPS mode can be avoided with fips_mode=0. During boot, /usr/libexec/cc_fips_test gets executed. No one, no kernel so far, has gotten past this point.

[spakk]

zchef2k, on 02 November 2012 - 11:02 PM, said:

I am of the opinion that the roadblock is userspace FIPS mode. Kernelspace FIPS mode can be avoided with fips_mode=0. During boot, /usr/libexec/cc_fips_test gets executed. No one, no kernel so far, has gotten past this point.

and how can you fix the problem in detail?

Should I be using boot flag:-s cpus = 6 arch = x86_64 fips_mode = 0 boot?
or how do you mean?

[zchef2k]

spakk, on 02 November 2012 - 11:05 PM, said:

and how can you fix the problem in detail?

Oh, I have no idea. But, if you boot with fips_mode=0 you will see it skip the FIPS POST test and claim that it is 'Bypassing FIPS mode for kernel space!" and then it hangs. Open the cc_fips_test executable in a hex or even text editor and you'll find a similar string "Bypassing FIPS mode for user space!". How to get there, with either a boot arg, kernel source modification, or binary patching is a mystery.

[spakk]

zchef2k, on 02 November 2012 - 11:10 PM, said:

Oh, I have no idea. But, if you boot with fips_mode=0 you will see it skip the FIPS POST test and claim that it is 'Bypassing FIPS mode for kernel space!" and then it hangs. Open the cc_fips_test executable in a hex or even text editor and you'll find a similar string "Bypassing FIPS mode for user space!". How to get there, with either a boot arg, kernel source modification, or binary patching is a mystery.

thank you very much, I'll try. Then I will report.

[zchef2k]

spakk, on 02 November 2012 - 11:05 PM, said:

and how can you fix the problem in detail?

Should I be using boot flag:-s cpus = 6 arch = x86_64 fips_mode = 0 boot?
or how do you mean?

Mind your spaces on both sides of the '='.

[spakk]

zchef2k, on 02 November 2012 - 11:22 PM, said:

Mind your spaces on both sides of the '='.

[zchef2k]

It's worth noting that cc_fips_test depends on /usr/lib/system/libcorecrypto.dylib.

Perhaps at least one of these can be disassembled and patched to return some value that appeases the boot process. On this I will defer to the programmers following this thread.

[spakk]

Hi guys, now my corocrypt.kext file under S / L / E.
Yesterday I installed on the other partition ML 10.8.2 and then  the installation installed in S / L / E the corocrypt.kext file.

Then I have copied the file on my ML 10.8 partition, done.

[IiTz ShAnE]

This is my boot on AMD Athlon II X2 215 using the latests kernel with corecrypto deleted.

Used the following boot flags,

-v arch=x86_64

 IMG_0036.JPG   210.93K   19 downloads  IMG_0037.JPG   210.64K   16 downloads

[zchef2k]

IiTz ShAnE, on 05 November 2012 - 03:03 PM, said:

This is my boot on AMD Athlon II X2 215 using the latests kernel with corecrypto deleted.

Used the following boot flags,

-v arch=x86_64

What about with fips_mode=0 arch=x86_64 -v

[IiTz ShAnE]

Exactly the same thing. Seems to freeze at the mig_table_max_displ part. Tried limiting the RAM to 2GB and 4GB still the same.

[zchef2k]

IiTz ShAnE, on 05 November 2012 - 03:21 PM, said:

Exactly the same thing. Seems to freeze at the mig_table_max_displ part. Tried limiting the RAM to 2GB and 4GB still the same.

At the very least, I would restore corecrypto to its original location and continue testing. Boot will halt if the kext has been modified or (ostensibly) missing.

[IiTz ShAnE]

zchef2k, on 05 November 2012 - 03:23 PM, said:

At the very least, I would restore corecrypto to its original location and continue testing. Boot will halt if the kext has been modified or (ostensibly) missing.

Here is it with corecyrtpo back and the bootflags you posted.

 IMG_0038.JPG   279.74K   18 downloads

[spakk]

We will not move forward with the current kernel. The current kernel stops at all in the same place.
We need to be patient a few days until theconnatic for us makes a new kernel. Which, I hope it will work.

[zchef2k]

IiTz ShAnE, on 05 November 2012 - 03:35 PM, said:

Here is it with corecyrtpo back and the bootflags you posted.

Can you repost a wider shot of that screen? There's output before the freeze I don't see on my machine.