Jump to content

Mac OS X Lion (Developer Preview) Released

harrydeo

By harrydeo,
in New Releases and Updates

 Share
1,521 posts in this topic

Recommended Posts

jmacie
jmacie
Posted
Posted
I've made a new atom kernel that will also work on HP mini netbooks (lapic fixed).

I've done both the DP1 and DP2 kernel.

NOTE: for booting 32bit you need DP1 kernel... I'm making progress on this and I'm working on a new bootloader that will allow this...

Downloadable below (kernels):

https://rapidshare.com/files/461846811/Lion...s_APICFixed.zip

I know a lot of mini owners would be thrilled to try lion on their 32 bit atoms. I wish you luck, as meklort has seemed to have stepped away from his developments.

Link to comment
Share on other sites
kocoman
kocoman
Posted
Posted

In Lion (booting 64bit), if I use 2GB Ram, USB is fine (no error messages), but if I add to 3GB ram or more, I get

 

AppleUSBEHCI(or OHCI)0xffffff80xxxxx:: UIMInitalize - unable to get device memory

error occured (0xe0002be)

 

UIMInitalize unable to get device memory

(then usb does not work)

 

I tried this with NEC and ALI usb chips, but same result

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

With some kernel debugging, I was able to figure out why my sandy bridge system would always immediately reboot when trying to install OSX 10.7. Adding to the confusion, some bootloaders (xpc, [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url]) would tend to hang/or black screen before even starting a kernel. Now that chameleon rc5 supports 10.7, I was able to merge the valv branch sandy bridge changes into the mainline code, and finally get beyond the bootloader issues.

 

The problem turned out to be that the OSX kernel's tsc_init() routine is failing to work properly for my sandy bridge system. tsc_init() has logic to use MSR_FLEX_RATIO, and for my system, that logic fails and leads to cpu_mhz = tscGranularity = flex_ratio = 0.

A small (1 byte!) patch to skip the MSR_FLEX_RATIO usage fixes this and the system then works just fine.

 

Strange that I seem to be the only one that has reported having this issue; is it a BIOS bug that MSR_FLEX_RATIO returns bit 16 set, but bits 8 thru 15 clear? Ie: 

% rdmsr -0 0x194
00000000000f0000
%

In intel's processor manual MSR section, I don't see MSR_FLEX_RATIO described, certainly not under the sandy bridge MSR subsection, yet the OSX kernel is using it for sandy bridge, westmere, nehalem...

Link to comment
Share on other sites
kocoman
kocoman
Posted
Posted
To avoid (in testphase) to open PC and add /remove RAM for 2 GB barrier, there is an kernel boot key to set max used mem.

maxmem=2048

 

edit: ok I fix the problem, I had to remove the existing dsdt.aml, reboot, then remake one, then add back my graphics p0p8.

Link to comment
Share on other sites
gigignopechegno
gigignopechegno
Posted
Posted
Hi guys!

 

I'm trying to install Lion on my P5Q deluxe from USB bootable with Chameleno RC5 Rev755 v7 but the installation stops here:

 

29eobuq.jpg

 

I can't understand what is the problem! Help me please!

 

I find one solution for Dsmos arrived.

 

1. Install Dp2 with my macbook pro.

 

2. Go in desktop with macbook pro

 

3. Install 3 kext FakeSMC.kext, IOPCIFamily.kext, AppleACPIPlatform.kext, download in my post 1218 ,with Kext utility for Lion.

 

4. Repair permission

 

5. Install Kabyl V3 or ^Andy^ bootloader , see post Ireset http://www.insanelymac.com/forum/index.php...5866&st=220

 

6. I utilize same Extra folder Snow .

 

7. This point is important , connect hard drive in first port but if you utilize another port you have (dsmos arrived)

 

 

 

With this metod I have 4 gtx 470 Evga work well with cuda 4.0.14 driver.

 

I try DP3 but not work.

 

I wait yours test and opinion

 

giginopechegno

post-168047-1305323653_thumb.png

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
@bcc9 - There's some work going on here for Sandy Bridge which might prove interesting reading. It's above me, but you might be able to add your input.

Before going to all the trouble of debugging the kernel, I searched and waited for over a month for something to come up. (Also detailed my problem in several threads.)

 

I saw that thread, but it seems to be particular to a lot of Asus issues, asus bios issues and its dsdt, and also revoboot. (My motherboard is a gigabyte ga-h67ma-ud2h-b3). I looked thru the source code to revoboot as well, didn't see a relevant fix there, the source code doesn't compile, and I didn't see any binaries to try.

 

I should point out that with my MSR fix I finally have a working lion install on my gigabyte motherboard. Perhaps this finding is worth a separate gigabyte lion thread...

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
Posted
Before going to all the trouble of debugging the kernel, I searched and waited for over a month for something to come up. (Also detailed my problem in several threads.)

 

I saw that thread, but it seems to be particular to a lot of Asus issues, asus bios issues and its dsdt, and also revoboot. (My motherboard is a gigabyte ga-h67ma-ud2h-b3). I looked thru the source code to revoboot as well, didn't see a relevant fix there, the source code doesn't compile, and I didn't see any binaries to try.

 

I should point out that with my MSR fix I finally have a working lion install on my gigabyte motherboard. Perhaps this finding is worth a separate gigabyte lion thread...

 

I just checked RevoBoot from github and it compiles just fine. I guess you missed the lines explaining what to do: either copy or rename some of the template files. Too bad that you had to run into this, and that you did not provide any feedback about this problem, because I would have taken care of it right away. Like I just did with my latest commit so that other people won't run into the same kind of trouble... when they skip the README file.

 

Anyway. Your GB board seems to have some sort of BIOS bug, or perhaps this is just due a wrong settings, but this is why I took care of it in RevoBoot... by checking a different MSR: 

msr = rdmsr64(MSR_PLATFORM_INFO); // 0xCE
uint16_t minBusRatio = (msr >> 40);
uint16_t maxBusRatio = ((msr >> 8) & 0xff);

printf("Busratio (min): 0x%x (%d)\n", maxBusRatio, maxBusRatio);
printf("Busratio (max): 0x%x (%d)\n", minBusRatio, minBusRatio);

So what does that give you? Oh. When this MSR also returns zero's where it should return the correct multipliers... All hail to Asus engineering for listening to us ;)

 

p.s. RevoBoot is just a vehicle to get things going.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
I just checked RevoBoot from github and it compiles just fine. I guess you missed the lines explaining what to do: either copy or rename some of the template files. Too bad that you had to run into this, and that you did not provide any feedback about this problem, because I would have taken care of it right away. Like I just did with my latest commit so that other people won't run into the same kind of trouble... when they skip the README file.

README is a zero byte file and typing make doesn't work. Yes I'm guilty of missing any explanation on how to compile if there are some special arcane steps that are necessary beyond the more customary simple make. There still seems to be no instructions:

% git clone https://github.com/RevoGirl/RevoBoot.git
Cloning into RevoBoot...
remote: Counting objects: 390, done.
remote: Compressing objects: 100% (355/355), done.
remote: Total 390 (delta 209), reused 96 (delta 16)
Receiving objects: 100% (390/390), 241.60 KiB, done.
Resolving deltas: 100% (209/209), done.
% cat RevoBoot/README 
% cd RevoBoot/
% git log README 
commit 0576a44a58333237ece1a20a2cb9192be9e1e7bc
Date:   Fri Mar 11 14:18:59 2011 +0100

first commit
%

 

Anyway. Your GB board seems to have some sort of BIOS bug, or perhaps this is just due a wrong settings, but this is why I took care of it in RevoBoot... by checking a different MSR: 
msr = rdmsr64(MSR_PLATFORM_INFO); // 0xCE

chameleon checks MSR_PLATFORM_INFO as well, but I fail to see how that avoids the MSR_FLEX_RATIO check in mach_kernel (which causes failure).

So what does that give you? Oh. When this MSR also returns zero's where it should return the correct multipliers... All hail to Asus engineering for listening to us :D
I see no fix here as the kernel is still checking MSR_FLEX_RATIO after control is passed to mach_kernel. Given that, it doesn't matter that the bootloader is avoiding the failed MSR_FLEX_RATIO check itself. Congrats, many chameleon builds don't have this problem either :blink:
p.s. RevoBoot is just a vehicle to get things going.
Seems to be just yet another forked boot132 based bootloader. Things are moving along more slowly with so many bootloaders ([url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url], xpc, clover, grub2, chameleon branches) to choose from for OSX with different bug&feature sets. At least some of the chameleon branch work is now making it to the mainline.
Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
Posted

@bcc9: Thanks for the "friendly" reminder. But looking at our Wiki and i386/config/README Not to mention RevoBuilder. I'd say yeah. We do have something to work with. And I did add the links to the empty README (I only have so little time to waste after all).

 

LOL Someone told me that you used the word "condescending" in a line that was somewhat later removed. Like I was patronizing you. Not! That and your need to expose my first name and e-mail address in this forum almost made me reconsider about helping you.

 

Anyway. The idea is to use the values from the MSR with the correct values, and stuff these into the 'broken' one. No idea if this really works for your board, but this way the following code snippet won't hurt you anymore:

		if (msr_flex_ratio & bit(16)) {
	 	/* Flex Enabled: Use this MSR if less than max */
		flex_ratio = (uint32_t)bitfield(msr_flex_ratio, 15, 8);
		if (flex_ratio < flex_ratio_max)
			tscGranularity = flex_ratio;
	}

At least for now because this is all going to change real soon.

 

p.s. You thought that exposing my first name and e-mail address was necessary? Really?

Link to comment
Share on other sites
stefano.85
stefano.85
Posted
Posted

New lion DP 3 update released these hours...downloading it now from software update..... 1,07 gb size for me.... i will report if anything goes wrong with it! cheers

p.s. hope we see some good news in it, specially for nvidia 5xx or ati 6xxx graphics drivers!

 

EDIT: netkas has just reported something in his blog regarding this.... at first sight seems there aren't any good news as i was hoping :P

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

dhp,

 

Helping me? I've yet to see anything you've posted that helps me. It's more like revo issues are being raised to distract from the issue at hand.

 

Condescending? Yes, that's the impression your "So what does that give you? Oh.... All hail to Asus engineering for listening to us" statement leaves. I did remove the condescension observation right away as you did put a smiley on the statement, yet the tone is there... So I revised my post to give you the benefit of the doubt.

 

Exposing you? What the heck are you talking about? I simply posted specific details showing how a normal developer would not be able to find any instructions like you were claiming. Specific details seemed in order as you seemed quite confident that your instructions were out there front and center. The makefile is at the top level dir, how I'd happen to know to go hunt for instructions 2 directory levels below is beyond me.

 

The code fragment you show from the OSX kernel source is exactly the bug I was referring to. It results in tscGranularity = flex_ratio = 0 for the MSR value I posted previously.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

So I was able to simply clear bit 16 in MSR_FLEX_RATIO, (via wrmsr64) from within chameleon, and now lion kernels boot just fine without any modification. This is cleaner than patching the kernel, but I'm still not sure whether MSR_FLEX_RATIO is supposed to be valid/safe to read for all sandy bridge systems (since it's not listed in Vol. 3b of the Intel arch. software developer manual that includes sandy bridge msrs).

Link to comment
Share on other sites
atlee
atlee
Posted
Posted

Mac OS X 10.7 11a459e - new update has been released :)

 

New lion DP 3 update released these hours...downloading it now from software update..... 1,07 gb size for me.... i will report if anything goes wrong with it! cheers

p.s. hope we see some good news in it, specially for nvidia 5xx or ati 6xxx graphics drivers!

 

EDIT: netkas has just reported something in his blog regarding this.... at first sight seems there aren't any good news as i was hoping :|

 

I specifically getting this to check out the newer GFX drivers :D if any i'm sure there will be.

Link to comment
Share on other sites
Graebags
Graebags
Posted
Posted
Mac OS X 10.7 11a459e - new update has been released :)

 

 

 

I specifically getting this to check out the newer GFX drivers :D if any i'm sure there will be.

 

Your probably disappointed then, see Netkas' comments: http://netkas.org/

 

For me, went on smoothly and seems best optimized to date.

Link to comment
Share on other sites
atlee
atlee
Posted
Posted
Your probably disappointed then, see Netkas' comments: http://netkas.org/

 

For me, went on smoothly and seems best optimized to date.

 

I'm after ATI :) newer is better then nothing :D i don't need netkas for confirmation :D i test things myself.

 

Tested newer kext's and internal screen still same issue, looks like Apple is being a pain :D

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
Posted
dhp,

 

Helping me? I've yet to see anything you've posted that helps me. It's more like revo issues are being raised to distract from the issue at hand...

First and foremost. There was absolutely nothing that I did to distract you. To fix a bug in RevoBoot. It is in fact plain simple. Or at least it should have been right from the start because when someone adds the following code snippet:

msr = rdmsr64(MSR_PLATFORM_INFO); // 0xCE
uint16_t minBusRatio = (msr >> 40);
uint16_t maxBusRatio = ((msr >> 8) & 0xff);

printf("Busratio (min): 0x%x (%d)\n", maxBusRatio, maxBusRatio);
printf("Busratio (max): 0x%x (%d)\n", minBusRatio, minBusRatio);

And ask you the following question: "So what does that give you?" meaning that you are supposed to check this, so that (like I said before) you can inject the data into the broken MSR.

 

And I said: "When this MSR also returns zero's where it should return the correct multipliers..." (ending with a smiley) that lucky us Asus owners don't have this problem. And that when there is a problem, that Asus engineers are willing to listen and solve the problem(s).

 

Anyway. Looking at the mach_kernel of Lion I see this: 

ffffff80002c438d	callq	_cpuid_cpufamily
ffffff80002c4392	cmpl	$0x5490b78c,%eax
ffffff80002c4397	je	0xffffff80002c43a7
ffffff80002c4399	cmpl	$0x573b5eec,%eax
ffffff80002c439e	je	0xffffff80002c43a7
ffffff80002c43a0	cmpl	$0x6b5a4cd2,%eax
ffffff80002c43a5	jne	0xffffff80002c4415
ffffff80002c43a7	movl	$0x00000194,%ecx
ffffff80002c43ac	rdmsr
ffffff80002c43ae	movl	%eax,%esi
ffffff80002c43b0	movl	$0x000000ce,%ecx
ffffff80002c43b5	rdmsr

Where WESTMERE, NEHALEM, and SANDYBRIDGE all jump to the same spot reading the MSR that caused you problems. And since Apple is Intels biggest client, and since Apple has Intel engineers working for them... I'd say that it is safe to assume that MSR 0x194 is part of what should work. Not to mention that more MSR's are missing from the docs/white papers, and that Asus engineers cite NDA restrictions when people do ask for info about them.

 

Now I like to go back to my Asus engineering remark, because I'm unaware of GB engineering fixing things in the same pace like Asus is doing these days.

 

And to round it up for this beautiful morning; It would be nice when you could at least confirm that the data from that other MSR is right (or not of course) so that other GB board owners can get a better fix. One that ports the data from one MSR to the other... simply because wiping that single bit might not be enough.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...