Voodooprojects

Chameleon => DevTalk => Patches => Topic started by: andyvand on February 05, 2010, 09:45:24 PM

Title: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: andyvand on February 05, 2010, 09:45:24 PM
I think it would be a great idea to also backport Meklort's patches which fix atom support (and auto patch the cpuid panic).
This could have other advantages like auto patching the kernel for various things.
This way we could make it possible for running vanilla kernel (without patches) on much other (normally not supported) cpu's.
I've generated a full differences patch file (attached below).
Let me know if I should spend some work on this too (when I have the time).
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: prasys on February 06, 2010, 02:16:05 PM
The problem with his code (its superb) is the memory hog and we'll be having issues with AMD. So if we want , we can limit to say Intel Pentium 4/Pentium Ds for now (with SSE3)
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: andyvand on February 06, 2010, 03:47:34 PM
Yeah... we could do that or change the code slightly to fetch first a bool for PatchXNUCpuid=Yes and then patching the binary.
Otherwise no patching.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: zef on February 06, 2010, 04:47:02 PM
How about to make this feature more generic by implementing a very simple patcher 'engine'? This way the user can supply a patch image (eg. "KernelPatch=<patchfile>") which will be applied before the kernel gets executed. The patch image may contain some CRC data to make sure we patch the right kernel binary followed by an offset,length,data array.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: andyvand on February 06, 2010, 05:18:08 PM
That's a great idea Zef.
We must then write some method for patching.
If we also expand the patcher a little we could also patch up certain drivers this way.
May become very interesting this way (with a little more work).
I'll look into the precise working and think about designing an optimal binary patch format (+ a fast & efficient way for applying).
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: diamondsw on April 05, 2010, 12:11:43 AM
Sorry to dig up an old topic, but has there been any progress on this or coordination with Meklort? I bring it up as the 10.6.3 update made this type of improvement important again. A patched kernel was ultimately released, but it would be great if all the netbook users (and perhaps AMD, P4, etc) users could also avoid these issues.

As I'm no kernel/bootloader/ACPI/BIOS dev, I'm of course in no position to say how hard any of this is.  ;D
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on April 06, 2010, 09:00:15 AM
Nope, no coordination has happend (but I'd be happy to work in the voodoo svn with my own branch).

Anyway's, the only real issue with the code is it doesn't work on 64bit machines. The memory addresses are different and I currently am not reading the correct info from the symtable. I have updated the code so that it's cleaner, however it still needs some work.  The only other issue is that this currently assumes that the offending panic call is always the first panic call in the cpuid_set_info function. Apple could easily change the location / order of the panic call and the patcher would break (although it'd be easy to fix).

On a slightly less related note, I'm wondering about prasys memory hog comment (let me know what issues you see and I'll see if I can change them). The code doesn't (as far as I know) use any extra memory, it patches the kernel in place without copying it. The only extra memory used is the symbol string as well as a couple of pointers. I do agree that it shouldn't be run on AMD machines (or sse2 only machines), but that should be a fairly easy check with cpuid.


Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: zef on April 06, 2010, 10:47:46 AM
Nope, no coordination has happend (but I'd be happy to work in the voodoo svn with my own branch).

Hi meklort,

Welcome here! Just added your account to the Chameleon project members. Feel free to maintain your own branch in the repo :)

Bye,
zef
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 07, 2010, 10:03:21 AM
If anyone is wondering, I've committed the kernel patcher to my local branch. I've cleaned up the code slightly, as well as made it much easier for others to add their own patches. Anyways, I've also included a patch to take the place of SleepEnabler.kext (for those of you who need it), and this time it *won't* cause a panic when the kernel is updated, and, even more importantly, it's not dependent on the pm struct not changing.

Sorry it's taken so long to get it in my branch. I'll be adding other patches soon.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: Blackosx on May 12, 2010, 12:46:26 PM
Thanks for the report meklort. It's great to hear of the svn being kept up to date.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Donk on May 12, 2010, 08:41:33 PM
Thanks for the patcher. I have been supporting VMware virtualization of Mac OS X for sometime on InsanelyMac. I have added a patch for lapic.c to allow Snow Leopard to run on ESXi 4. Once I am happy with it I'll post the changes. It changes the check for the minimum version of the LAPIC to something more useful on certain VMware products.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 12, 2010, 11:04:08 PM
If you are talking about this line in the source:
      panic("Local APIC version 0x%x, 0x14 or more expected\n",
         (LAPIC_READ(VERSION)&LAPIC_VERSION_MASK));

I'd suggest just removing the panic call (replace with nops) or replacing the call with a printf instead of panic call. that is, it's be much better to remove the panic call than to change the 0x14 check to a smaller value.

I'd be happy to write a bit of code to remove it (ore replace with _printf) if you'd like.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Donk on May 13, 2010, 09:08:30 AM
That would be excellent. I have modified kernels to use printf, but the intention as with your work is to use the vanilla kernel. I have a working version and have installed 10.6 and run through to 10.6.3 on ESXi, so it is the only change plus the Chameleon 2 loader that is needed to get this running for ESXi (its virtual hardware is a little behind the other VMware products, which don't need the patch).

I have some other hacks to Chameleon for VMware only and probably not of interest to the wider audience, but will post code when happy with it.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 15, 2010, 07:54:40 PM
Well, I've updated the patching code, but I haven't tested the lapic_init patch yet. Let me know if it works.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: Eps on May 15, 2010, 10:42:31 PM
Well, I've updated the patching code, but I haven't tested the lapic_init patch yet. Let me know if it works.

I have compiled your build 155 file and found a problem.
It's hang on booting,so I take a look what's going on by verbose option.

Code: [Select]
UHCI controller [8086:27c8] at 00:1d.0 base 301(6021)
Setting Legacy USB Off on controller [8086:27c8] at 00:1d.0
Legacy USB Off Done
EHCI controller [8086:27c8] at 00:1d.0 DMA @0
UHCI controller [8086:27c9] at 00:1d.1 base 302(6041)
Setting Legacy USB Off on controller [8086:27c9] at 00:1d.1
Legacy USB Off Done
EHCI controller [8086:27c9] at 00:1d.1 DMA @0
UHCI controller [8086:27ca] at 00:1d.2 base 303(6061)
Setting Legacy USB Off on controller [8086:27ca] at 00:1d.2
Legacy USB Off Done
EHCI controller [8086:27ca] at 00:1d.2 DMA @0
UHCI controller [8086:27cb] at 00:1d.3 base 304(6081)
Setting Legacy USB Off on controller [8086:27cb] at 00:1d.3
Legacy USB Off Done
EHCI controller [8086:27cb] at 00:1d.3 DMA @0
UHCI controller [8086:27cc] at 00:1d.7 base 0(0)
Setting Legacy USB Off on controller [8086:27cc] at 00:1d.7
Legacy USB Off Done
EHCI controller [8086:27cc] at 00:1d.7 DMA @0e8284000

I think that DMA deteced at 0e8284000 is the main reason for booting hang.
But I don't know what's happend in Legacy USB Off function.
By the way,I boot my OSX from USB.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 16, 2010, 01:45:00 AM
Try r156, and if that doesn't work, try booting with USBBusFix=No
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: Eps on May 16, 2010, 02:51:52 AM
Try r156, and if that doesn't work, try booting with USBBusFix=No

r156 still hangs,and verbose following info.

Code: [Select]
EHCI controller [8086:27c8] at 00:1d.0 DMA @0
UHCI controller [8086:27c8] at 00:1d.0 base 301(6021)
Setting Legacy USB Off on controller [8086:27c8] at 00:1d.0
Legacy USB Off Done
EHCI controller [8086:27c9] at 00:1d.1 DMA @0
UHCI controller [8086:27c9] at 00:1d.1 base 302(6041)
Setting Legacy USB Off on controller [8086:27c9] at 00:1d.1
Legacy USB Off Done
EHCI controller [8086:27ca] at 00:1d.2 DMA @0
UHCI controller [8086:27ca] at 00:1d.2 base 303(6061)
Setting Legacy USB Off on controller [8086:27ca] at 00:1d.2
Legacy USB Off Done
EHCI controller [8086:27cb] at 00:1d.3 DMA @0
UHCI controller [8086:27cb] at 00:1d.3 base 304(6081)
Setting Legacy USB Off on controller [8086:27cb] at 00:1d.3
Legacy USB Off Done
EHCI controller [8086:27cc] at 00:1d.7 DMA @0e8284000
UHCI controller [8086:27cc] at 00:1d.7 base 0(0)
Setting Legacy USB Off on controller [8086:27cc] at 00:1d.7
Legacy USB Off Done

USBBusFix=No doesn't work.
It still run Legacy USB Off function whatever I added USBBusFix=No in com.apple.Boot.plist or not.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on May 16, 2010, 09:13:03 AM
Hi @Meklort, very nice patches you are playing with, besides kernel patcher.
You need to take a look at the usb_loop; the way it's done it's out of control, always runs (several times) and can't be controlled by e.g.: LegacyOff=No. As i have a usb keyboard/mouse that depends on "legacy usb", i can't have LegacyOff running or i get stuck like @Eps mentions.
Anyway, my real interest on this patch lies on the fact that, the way you implemented it also fixes a problem i have with Wait=y+UHCIreset=y.. makes me hang. UHCIreset needs the same treatment as LegacyOff:
Quote
NOTE2: This should be called after any getc() call. (aka, after the Wait=y keyworkd is used)
.. just needs to be under control. EHCIacquire=y doesn't cause the same problem.
I always use USBBusFix; "strange" random stuff happens when i don't.

Will give some more input later, about the other patches.
Thanks

Edit: and kernel patcher is not working anymore. If i revert it to e.g.: rev 146, it works.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 16, 2010, 03:36:54 PM
Yup, it needs cleaning up (I haven't tested the latest two commit, probably should have). The USB code is defaulted to on, however it *should* (but again, probably doesn't) respond to the regular usb command, I'll take a look and see why. I really should fix those typos in that comment too. The usb_loop() code is only run once, I'm not sure where you see it happening multiple times (each part in the wile loop is run for each usb device, just like it was before without my changes. Yes, it definitely needs to be able to be turned off). If you are wondering, the whole point of that usb patch is that it lets the Asus 1201n boot off of a usb drive without issues, before you had to disable usb 2.0 in the bios.

Anyways, it looks like the freeze is due to the kernel patcher as all of the usb code is run and finishes. The only code after that is asm that starts the kernel.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: Eps on May 16, 2010, 04:56:54 PM
Yup, it needs cleaning up (I haven't tested the latest two commit, probably should have). The USB code is defaulted to on, however it *should* (but again, probably doesn't) respond to the regular usb command, I'll take a look and see why. I really should fix those typos in that comment too. The usb_loop() code is only run once, I'm not sure where you see it happening multiple times (each part in the wile loop is run for each usb device, just like it was before without my changes. Yes, it definitely needs to be able to be turned off). If you are wondering, the whole point of that usb patch is that it lets the Asus 1201n boot off of a usb drive without issues, before you had to disable usb 2.0 in the bios.

Anyways, it looks like the freeze is due to the kernel patcher as all of the usb code is run and finishes. The only code after that is asm that starts the kernel.

So I have hanged in Chameleon RC4 before if USBBusFix function is enabled.
But it boots OK in your r150 build,it's odd.
Maybe it could be a kernel patcher problem.
Anyway,thank for your help.  :D
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: boot.teqs on May 16, 2010, 05:07:25 PM
hi @all, I tested the last revision (156), and I would like to test the ramdisk load at boot. But I don't know which args to pass to hdiutil to make a loadable image (Postboot.img).
I used this
Quote
hdiutil create -srcfolder /Volumes/EFI/Extra
That gave me a .dmg file, that is unloadable, perhaps because it doen't have .img extension. Also reviewed Perms, and gave it 755.
Any help for this please?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 16, 2010, 05:47:46 PM
I would like to test the ramdisk load at boot.

This is the command I use (copied form my NetbookInstaller build script, with a few modifications).

Code: [Select]
SIZE=set size here (in number of blocks)
RAMDISK=`hdiutil attach -nomount ram://$SIZE`
RAMDISK=`echo -e $RAMDISK`

newfs_hfs -v Postboot "$RAMDISK"
diskutil mount -mountPoint "${TARGET_BUILD_DIR}/Postboot" $RAMDISK
cp -rf "${TARGET_BUILD_DIR}/PostbootTmp/"* "${TARGET_BUILD_DIR}/Postboot"

diskutil unmount "$RAMDISK"
dd if="$RAMDISK" of="${TARGET_BUILD_DIR}/Postboot.img"
diskutil eject "$RAMDISK"

Do note that the ramdisk is only used to load a ramdisk using the bootloader, and have it attached to /dev/md0 in xnu. You can then mount it and use it how you like. I personally use it plus unionfs to patch the install dvd so that you don't have to run any extra commands to have a bootable system (patches install dvd to install chameleon and /Extra files during the regular install).

Eps: I'll take a look later today and see whats going on, that is after I'm finished with my adventure with wine + native kernel support (like rosetta).
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: boot.teqs on May 16, 2010, 10:31:45 PM
Thank you for the reply Meklort. Can you tell me more about ramdisks ? I was putting all the contents of V/E/E there and removed them form /V/E/E afterwards. And was hoping kexts+dsdt get loaded from Postboot.img (in /Extra) at boot time. but that didn't seem to work. Even-though, I can clearly see the .img file being loaded at boot time. Any clue ? please.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 16, 2010, 10:45:54 PM
Like I said before, the whole point of that ramdisk code is load up Postboot.img into kernel memory, and then notify xnu (the Mac OS X kernel) that it should attach said ramdisk to /dev/md0. Chameleon does *nothing* with the ramdisk other than get the memory location and length, and add it to the ioregistery.

There are two uses (that I know of at the moment) for this.
The first, and what I originally tested it with, is to load a livecd into ram and have a read / write file system. I tested the code using a 2009 puredarwin nano vmware image, and it results in the vmware image being being booted, while also allowing you to have write access to the ramdisk.

The other use, which for me is more useful, is to instead of using md0 as the root partition (root=md0), is instead to mount the /dev/md0 node later in the boot sequence. I use this by mounting it over essential system files using unionfs (the gui), and then cause my dvd patching code to modify the OSInstall.pkg file so that the final, installed, os does not need to be patched again. If you are wondering, the reason why I did it this way is because the xnu kernel cannot handle mounting another patition over / using union fs. It'll cause a kernel panic (and I really don't feel like fixing that bug at the moment).

Again, the point of this is *not* to house /Extra (there is no reason for that, it will not work, and you should just use the Preboot.dmg for that). The ramdisk code is instead useful to notify XNU that a ramdisk exists. That's it. Once XNU knows about the ramdisk, you can do whatever you like with it by messing with /dev/md0.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: boot.teqs on May 16, 2010, 10:54:46 PM
Anyway, this stuff would really expand new ideas over it. Thank you very much for your great effort.
Regards.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: Azimutz on May 18, 2010, 02:03:03 AM
Yup, it needs cleaning up (I haven't tested the latest two commit, probably should have). The USB code is defaulted to on, however it *should* (but again, probably doesn't) respond to the regular usb command, I'll take a look and see why. I really should fix those typos in that comment too. The usb_loop() code is only run once, I'm not sure where you see it   happening multiple times (each part in the wile loop is run for each usb   device, just like it was before without my changes. Yes, it definitely needs to be able to be turned off). If you are wondering, the whole   point of that usb patch is that it lets the Asus 1201n boot off of a usb drive without issues, before you had to disable usb 2.0 in the bios.

Anyways, it looks like the freeze is due to the kernel patcher as all of the usb code is run and finishes. The only code after that is asm that starts the kernel.
Hi Mek,
my post wasn't that clear so, i made more tests and took some pics. About the usb_loop; my normal experience with the USB fixes on Chameleon is this:
- i need to use USBBusFix=y or i get all sorts of usb problems.
- if i use Wait=y i get stuck, pressing any key to continue does nothing; the keyboard still works so, it's the usb bus that gets disconnected;
- i isolated the problem to the use of UHCIreset; if i use only EHCIacquire i can go on but, that alone doesn't solve the usb problems; they are maybe related to Legacy USB, i don't know; the mobo is in fact manufactured by Asus (check my sig if you get curious); it does have an option to disable Legacy USB on BIOS, but i can't use it because the keyboard/mouse need it.
- pic 1: my normal boot
- usb devices by lspci:
Code: [Select]
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
 
So, i had already realized that making the usb fixes run before Wait=y would fix the problem, but i still don't have the knowledge to do it :P As this is a problem that affects more people (though i don't see reports about this around), as soon as i saw the way you did it, it caught my attention. This is how it goes with the usb_loop on rev 156:
- pic 2: it hangs there.
- pic 3: still hangs. Why it goes further here, beats me!? The   diff is that i added USBLegacyOff=No to Boot.plist.
- pic 4: here i removed just the LegacyOff code from the loop, added a "pause()" after usb_loop call and used   Wait=y to take the pic and catch the after "Wait".  USBBusFix=No also doesn't work.

I just didn't explained my self properly; what i meant with "several times" is that the loop runs the 3 fixes on every usb device that finds; not the way it usually works (or should!?). In the last situation were i removed LegacyOff, i can boot normally so, the loop doesn't "hurt" the fixes. They should be set to "false" by default and activated at user request.
You should remove LegacyOff from USBBusFix too; well, here i can also start using the separate keys instead of USBBusFix :) not a must. LegacyOff is really of no interest for me atm, for obvious reasons.
 
About the kernel_patcher; it doesn't look like it's causing the hang! With LegacyOff removed it works.. that is, worked till rev 150. Latest fails.

Hope this is more clear and helpful :) I know i'm looking at the usb patch in a diff perspective but, it's the best compromise i can think of for this "Wait problem". Would love to see this merged to the trunk.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 22, 2010, 09:52:06 PM
I've changed the source code in svn:
- the CPU model is overridden for only Atom cpu's, panic is removed otherwise
- The lapic_init patch no longer causes a panic, I was off by one byte before
- Temporarily disabled legacy off code
- USB options are nolonger ignored, but they all enabled by default
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on May 23, 2010, 11:37:19 AM
Hi Mek,
kernel patch is working again with my Pentium D 925.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Donk on May 24, 2010, 09:33:15 AM
Can confirm the new lapic patch now works. Thanks.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on May 25, 2010, 02:07:11 AM
Azimutz:

These patches are currently 32bit only, the don't work on the 64bit kernel.

I'm also not about to change *all* unknown cpu's to a specific model. What I will do is add your specific cpu to the switch, and patch based on that if you can tell me your cpuid.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on May 25, 2010, 03:04:47 PM
@Mek,
i know these patches are 32 bit only. What i meant is, 10.6 kernel always kp's when i build it 32/64 bit;
i overseen/forgot that fact and it lead me to think the patch wasn't working.
Edit: in fact, the kp has nothing to do with architecture. The same minimal patch i use on 10.6.2/3 doesn't
work on 10.6.. can't really understand why.

Anyway, i cleaned my previuos the post to avoid more confusion.
Patch works, either by removing panic call or impersonating family/model, that's all!
Never mind the rest... let it roll ;)

p.s.: info on my cpu is on my signature->System->CPU
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: yehia2amer on June 11, 2010, 06:39:13 PM
my hp laptop need a patched kernel to work with all 4 cores although the cpu is fully supported
so can this help to edit the Bootloader and use the vanilla kernel

the problematic kernel file is "lapic.c" in the path "xnu-1504.3.12/osmfk/i386/lapic.c"
 
the code Must be changed to this (the Bold part) :
----------------------------------------------------------
/* ExtINT */
if (get_cpu_number() == master_cpu) {
value = LAPIC_READ(LVT_LINT0);
value &= ~LAPIC_LVT_MASKED;
value |= LAPIC_LVT_DM_EXTINT;
LAPIC_WRITE(LVT_LINT0, value);
}

/* NMI: ummasked, off course */
LAPIC_WRITE(LVT_LINT1, LAPIC_LVT_DM_NMI);

/* Timer: unmasked, one-shot */
LAPIC_WRITE(LVT_TIMER, LAPIC_VECTOR(TIMER));
-----------------------------------------------------------------

any help will be appreciated , hope i can run vanilla  :)
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on June 12, 2010, 10:29:25 PM
I'll take a look and see how easy it'll be to implement.

EDIT: Looks like I should be able to free up enough space in that function to add the required code, but I may have to remove the lapic_dont_panic kernel option to do so, in either case I can always for lapic_dont_panic to be true as well (well, I can remove the one panic that it affects).
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: yehia2amer on June 13, 2010, 09:57:57 PM
great news, i am ready to test anytime  ;D
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on July 26, 2010, 10:37:33 AM
Hi Meklort, back to haunt you ;D

Usb stuff fixed, thanks. On my machine the EHCI device is also only one and the last.
USBLegacyOff patch is applied last and makes my boot hang as before; just mentioning, i know it's a specific patch and i don't need it. Atm, i'm only using UHCIreset; something got fixed, maybe on latest system updates so i don't need EHCIacquire for now.

Checking "md0Ramdisk" stuff for the first time...
Ok, i understand the use of a postboot image, though i don't fully know how to use it.
Anyway, my first doubt is about the code; do you really need to look for Postboot.img on rd(0,0)?
I'm finding that strange but, that's a path to a ramdisk... if so, you should do it like this (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/boot2/drivers.c#L186) to avoid
"Failed to read boot sector from BIOS device 100h. error=1" message. Check this (http://forum.voodooprojects.org/index.php/topic,1419.0.html) topic for my adventures on the subject.

That's it, for now...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on July 26, 2010, 03:33:33 PM
I've added the check for the rd.

Yes, I absolutely *must* check for the ramdisk in rd(0,0). The md0 ramdisk is a device that the xnu kernel sets up at /dev/md0 when it detects the correct properties in the registery, it's a very different thing than chameleons ramdisk feature. It's not possible to load the md0 ramdisk from a boot cd due to having to swap it with the install DVD. Because of that, I need a way to access the Postboot.img file, hence adding it to the Preboot.dmg and reading that in before the cd is swapped.

On my machine the usb legacy off code doesn't hang anymore, I'll take a look at it again and see what's going on.

 
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on July 26, 2010, 07:32:04 PM
Just saw the update...
Right, in that case i understand the need for loading a Postboot from a Preboot. My doubt is mainly because i'm not sure how long the contents of a ramdisk (Preboot) stay available?! I've always assumed they stay available until reboot, but some stuff got me doubts... is that true? I mean, do the files loaded from a Preboot stay available on RAM until next reboot or...?

About usb legacy hang, reading through the topic now, i recalled i got it when i tested the patch before; i only mentioned it now out of curiosity. Will check it better...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic
Post by: meklort on July 26, 2010, 08:27:41 PM
Got it.

The Preboot ramdisk is only guaranteed to be available so long as chameleon is running. Once XNU starts it can and will reclaim the memory (well, it doesn't even know it was used).

The Postboot (md0) ramdisk is allocated in memory reserved for the kernel, and then the kernel is notified by a memory map not to reuse it.

I fixed the issue with the usb legacy patch before. I had it run on the uhci and ehci device, not just the ehci device which caused issues. It's been fixed (for me) since before I imported it to trunk.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on July 26, 2010, 09:50:01 PM
Aah, ok... thanks for clearing out that stuff. Thinking better i was kind of noob :P should have got to the conclusion my self, but reading it explained this way helps a lot!

The usb fixes... found what was creating the hang for me; i was using a sleep(5) right after the usb_loop call and it seems that mixing it with EHCIacquire+USBLegacyOff it's not a good idea! I was doing this to have time to see the messages on the screen; no hangs without the sleep().
To be able to check this properly i moved the usb_loop call before Wait key, which turned out to be a better idea.
The only usb fix that makes my boot hang is still UHCIreset. I was under the impression that USBLegacyOff also did the same but it's not true!
So, all seems fine. Sorry for the false alarm :)
Will be back later with some kernel patcher related stuff...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 05, 2010, 10:54:56 PM
Hi Meklort,

just to mention that, on rev 494 the kernel patcher module fails to build:
Code: [Select]
kernel_patcher.c: In function ‘patch_cpuid_set_info’:
kernel_patcher.c:391: error: expected expression before ‘<’ token
kernel_patcher.c:391: error: expected statement before ‘)’ token
kernel_patcher.c:395: error: expected expression before ‘else’
can't get rid of the last one.

Also, i just tried to build from a folder Exported by the svn client (without .svn dirs) and i get this:
Code: [Select]
svn: Path '../..' ends in '..', which is unsupported for this operation
ld: malformed version number: -final_output
here fails building symbols module.

I'll be back later with more talk.. "family busy" atm :)
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 05, 2010, 11:13:36 PM
Both should be fixed now.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 05, 2010, 11:35:31 PM
Yep, confirmed :) Thanks.
Will test 64 bit kernel patching asap... see ya later.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 06, 2010, 05:44:49 AM
In your branch I noticed you added this too boot.c:

getBoolForKey(kKPatcherKey, &patchKernel, &bootInfo->bootConfig);   
if (patchKernel == true)

If you want that, please remove it from there and add it to the module itself. Where you have it right now it really means "disable the exec kernel hook," which any module can hook into. The way you have it now, this could break them. If you add the check to the module itself, it'll let you disable just that module.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 06, 2010, 08:25:46 AM
Ok, thanks for the tip :) i had this on my list of questions. I'm not really sure of the usefulness of the key,
but if it's there it should work properly. For now it's easier than add/remove module, to boot Leo for instance, were i use
Voodoo kernel (patcher doesn't like it at all). Will work on it... will ask you if i get in trouble, but i understand what you mean.

About the kernel patcher; panic removal works fine on x86_64! I still have to patch the kernel, or i get commpage panic:
Quote
commpage no match for last, next address ffff1000
the rest of the panic is on the ugly pic attached. Kernel patcher reports this on normal verbose:
Quote
64 bit - patched kernel

0xE8 0x7B 0xC0 0xFD 0xFF
0x90 0x90 0x90 0x90 0x90
Unable to locate _commpage_stuff_routine
I checked the kernel for this symbol and it's really not present; the closest i can find is
Quote
_commpage_32_routines
_commpage_64_routines
Anyway, the obvious first question here is, what's the commpage panic the patcher is supposed to fix?
From my experience, i know this commpage panic on Pentium D, is due to the fact that although these processors have
em64t instructions, they lack Suplemental sse3 ones. The patch i use it's basically the one on the last commits on the
Voodoo kernel here (http://opensource.mercurysquad.com/voodoo-xnu-kernel/summary) (the bcopy_sse3x_64.s stuff). I assume this is not the target of the patcher as it is!?
The second question is, is it possible to apply a patch of this nature with kernel patcher?
If needed i can post a diff of the patch. I have to confess that i never tried to bypass this panic in any other way.

Just to remind, i'm on a Pentium D 925, family 15 model 6. This is detected at boot,
Quote
WARNING: ACPI_SMC_PlatformPlugin - getCPUIDInfo unknown CPU family: family 0xf, model 0x6
-- power management may be incomplete or unsupported
and by most apps after boot; only System Profiler shows C2D because of the booter.

That's it for now... be back later.


EDIT: check rev 498, about the kernel patcher key; is that fine?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 07, 2010, 05:13:13 AM
The _compage_stuff_routine patch is for a machine that I was running and had an issues, you can ignore it, I'll probably fix it to run on more kernels, but it's not a major issue for me.

you can also ignore the hex output, I had it there just for debugging.

The "commpage no match for last, next address ffff1000" panic shouldb't be there, probably has something to do with one of the patches working improperly, I ran into that once and then fixed it, but I haven't uploaded it.

As far as the ACPI_SMC_PlatformPlugin panic, the CPUID patch just removes the panic for now, I have it partially working in 64bit but it's not done yet.

Yes, other patches can be applied, some require more work than others, although I'll be writing some additional functions that'll let you do things a bit easier.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 07, 2010, 10:49:49 AM
Quote
The "commpage no match for last, next address ffff1000" panic shouldb't be there, probably has something to do with one of the patches working improperly, I ran into that once and then fixed it, but I haven't uploaded it.
If you say so :)
I can't remember if the address was always ffff1000. All i can say is that i always had this commpage kp without the patch i mentioned and the explanation i gave came from MercurySquad. I'll keep a closer eye on it.

Quote
As far as the ACPI_SMC_PlatformPlugin panic, the CPUID patch just removes the panic for now, I have it partially working in 64bit but it's not done yet.
yep.. no pressure; will test as you put out.

Quote
Yes, other patches can be applied, some require more work than others, although I'll be writing some additional functions that'll let you do things a bit easier.
This is nice. By the way, nice going with the modules support! Didn't saw that one coming ;D

Was paying a visit to Leo, remembered to try compiling the booter and was greeted with this stuff:
Code: [Select]
-MD -dependency-file /Volumes/Home/Azi/ChopShop/Booters/Chameleon/branches/meklort/obj/i386/boot2/modules.d
modules.c: In function 'parse_mach':
modules.c:452: error: 'LC_DYLD_INFO' undeclared (first use in this function)
modules.c:452: error: (Each undeclared identifier is reported only once
modules.c:452: error: for each function it appears in.)
modules.c:478: error: dereferencing pointer to incomplete type
modules.c:480: error: dereferencing pointer to incomplete type
modules.c:480: error: dereferencing pointer to incomplete type
modules.c:483: error: dereferencing pointer to incomplete type
modules.c:485: error: dereferencing pointer to incomplete type
modules.c:485: error: dereferencing pointer to incomplete type
modules.c:488: error: dereferencing pointer to incomplete type
modules.c:491: error: dereferencing pointer to incomplete type
modules.c:491: error: dereferencing pointer to incomplete type
modules.c:494: error: dereferencing pointer to incomplete type
modules.c:498: error: dereferencing pointer to incomplete type
modules.c:498: error: dereferencing pointer to incomplete type
modules.c: In function 'rebase_macho':
modules.c:529: error: 'REBASE_IMMEDIATE_MASK' undeclared (first use in this function)
modules.c:530: error: 'REBASE_OPCODE_MASK' undeclared (first use in this function)
modules.c:535: error: 'REBASE_OPCODE_DONE' undeclared (first use in this function)
modules.c:541: error: 'REBASE_OPCODE_SET_TYPE_IMM' undeclared (first use in this function)
modules.c:549: error: 'REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB' undeclared (first use in this function)
modules.c:584: error: 'REBASE_OPCODE_ADD_ADDR_ULEB' undeclared (first use in this function)
modules.c:599: error: 'REBASE_OPCODE_ADD_ADDR_IMM_SCALED' undeclared (first use in this function)
modules.c:604: error: 'REBASE_OPCODE_DO_REBASE_IMM_TIMES' undeclared (first use in this function)
modules.c:613: error: 'REBASE_OPCODE_DO_REBASE_ULEB_TIMES' undeclared (first use in this function)
modules.c:631: error: 'REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB' undeclared (first use in this function)
modules.c:646: error: 'REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB' undeclared (first use in this function)
modules.c: In function 'bind_macho':
modules.c:712: error: 'BIND_IMMEDIATE_MASK' undeclared (first use in this function)
modules.c:713: error: 'BIND_OPCODE_MASK' undeclared (first use in this function)
modules.c:718: error: 'BIND_OPCODE_DONE' undeclared (first use in this function)
modules.c:722: error: 'BIND_OPCODE_SET_DYLIB_ORDINAL_IMM' undeclared (first use in this function)
modules.c:727: error: 'BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB' undeclared (first use in this function)
modules.c:741: error: 'BIND_OPCODE_SET_DYLIB_SPECIAL_IMM' undeclared (first use in this function)
modules.c:748: error: 'BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM' undeclared (first use in this function)
modules.c:758: error: 'BIND_OPCODE_SET_TYPE_IMM' undeclared (first use in this function)
modules.c:765: error: 'BIND_OPCODE_SET_ADDEND_SLEB' undeclared (first use in this function)
modules.c:780: error: 'BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB' undeclared (first use in this function)
modules.c:813: error: 'BIND_OPCODE_ADD_ADDR_ULEB' undeclared (first use in this function)
modules.c:828: error: 'BIND_OPCODE_DO_BIND' undeclared (first use in this function)
modules.c:847: error: 'BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB' undeclared (first use in this function)
modules.c:881: error: 'BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED' undeclared (first use in this function)
modules.c:902: error: 'BIND_OPCODE_DO_BIND_ULEB_TIMES_SKIPPING_ULEB' undeclared (first use in this function)
make[2]: *** [modules.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2
Needs some tuning...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 08, 2010, 06:17:13 AM
Some headers are probably missing in 10.5, might need to install the xnu source too. If needed I can include the required #defs / header instead.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 08, 2010, 08:23:07 AM
Yep.. not missing, changed; loader.h at least. Will check in Leo...

UPDATE: it builds on Leo using loader.h from "Snow", but i get a bunch of warnings:
Code: [Select]
/Users/burro/Desktop/meklort/obj/i386/modules/.//KernelPatcher/kernel_patcher.o -o /Users/burro/Desktop/meklort/sym/i386/KernelPatcher.dylib
ld warning: codegen in _register_kernel_symbol (offset 0x0000000D) prevents image from loading in dyld shared cache
ld warning: codegen in _register_kernel_symbol (offset 0x0000007A) prevents image from loading in dyld shared cache
ld warning: codegen in _register_kernel_symbol (offset 0x00000086) prevents image from loading in dyld shared cache
ld warning: codegen in _register_kernel_symbol (offset 0x0000008D) prevents image from loading in dyld shared cache
ld warning: codegen in _register_kernel_patch (offset 0x0000000C) prevents image from loading in dyld shared cache
ld warning: codegen in _register_kernel_patch (offset 0x0000001D) prevents image from loading in dyld shared cache
ld warning: codegen in _register_kernel_patch (offset 0x0000009C) prevents image from loading in dyld shared cache
ld warning: codegen in _lookup_kernel_symbol (offset 0x0000000D) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_kernel (offset 0x0000000E) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_kernel (offset 0x0000004A) prevents image from loading in dyld shared cache
ld warning: codegen in _symbol_handler (offset 0x0000000D) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info (offset 0x0000001E) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info (offset 0x0000005B) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info (offset 0x000000AA) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info (offset 0x000000B1) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info (offset 0x000000C1) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info (offset 0x000000D2) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_cpuid_set_info_all (offset 0x0000000A) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_pmCPUExitHaltToOff (offset 0x0000000A) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_pmCPUExitHaltToOff (offset 0x00000049) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_pmCPUExitHaltToOff (offset 0x00000055) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_init (offset 0x0000000B) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_init (offset 0x00000054) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_init (offset 0x0000005E) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_init (offset 0x0000006C) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_init (offset 0x000000B5) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_init (offset 0x000000D2) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_commpage_stuff_routine (offset 0x0000000B) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_commpage_stuff_routine (offset 0x00000059) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_commpage_stuff_routine (offset 0x00000062) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_commpage_stuff_routine (offset 0x0000006A) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_commpage_stuff_routine (offset 0x000000B8) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_commpage_stuff_routine (offset 0x000000C5) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_interrupt (offset 0x0000000B) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_interrupt (offset 0x00000059) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_interrupt (offset 0x00000062) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_interrupt (offset 0x0000006A) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_interrupt (offset 0x000000B8) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_interrupt (offset 0x000000C5) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_configure (offset 0x0000000E) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_configure (offset 0x0000005C) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_configure (offset 0x00000065) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_configure (offset 0x0000006D) prevents image from loading in dyld shared cache
ld warning: codegen in _patch_lapic_configure (offset 0x000000BF) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000008) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000022) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000074) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000000C6) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000118) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000016A) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000001BC) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000020E) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000260) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000002B2) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000304) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000356) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000003A8) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000433) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000043F) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000044A) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000047B) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000004A1) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000004C7) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000004ED) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000004F9) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000504) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000538) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000544) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000054F) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000583) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000058F) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000059A) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000005CE) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000005DA) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000005E5) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000619) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000625) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000630) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000664) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x00000670) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x0000067B) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000006AF) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000006BB) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000006C6) prevents image from loading in dyld shared cache
ld warning: codegen in _KernelPatcher_start (offset 0x000006FA) prevents image from loading in dyld shared cache

/Users/burro/Desktop/meklort/obj/i386/modules/.//Symbols/Symbols.o -o /Users/burro/Desktop/meklort/sym/i386/Symbols.dylib \

ld warning: codegen in _lookup_symbol (offset 0x00000032) prevents image from loading in dyld shared cache
ld warning: codegen in _lookup_symbol (offset 0x00000057) prevents image from loading in dyld shared cache
If you need any other feedback on this, just let me know.

About the "Sync with trunk, untested" (rev 505), looks fine!
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 10, 2010, 09:35:20 PM
Hi Mek,

i'm having a doubt here (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/boot2/ramdisk.c#L32); if md0=<file>, this first open
Code: [Select]
fh = open(filename, 0);will just check current dir for filename, right!? Is this on purpose?
I ask because looking at the rest of the paths, i get the feeling that the .img file is to be kept under Extra folder.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 11, 2010, 01:14:38 AM
I've always specified the full file path when using open, I don't know what happens if you do something like open("Blah", 0);
Anyway, the only cause where that will happen is if you specify the file name with md0=filename (actually it'll probably look in at bt(0,0)/filename (or /filename) if you don't specify the full path).

Basically, it'll check the user specified filename, where ever it might be, then it'll check in /Extra, lastly, it'll fallback to a patch I use in NBI (Postboot.img).
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 11, 2010, 04:40:43 AM
Ok.. i didn't evaluated that stuff properly; forgot that if i pass a full path, the other two checks (lines 37 & 42) will not be performed at all; that is, if my path is correct. But, i still have a point; a full path like /extra/test/filename will get messed up on the other two checks; for those we should just use file name. Hence my doubt...
I'm doing some research for documentation and that stuff caught my attention.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 14, 2010, 08:58:21 AM
 :o modules all over ;D
Meklort, GraphicsEnabler is doing fine here. Going to take a look at the rest... see if i can fit AutoResolution in between;
need to check this against your Resolution stuff, some is in fact yours, edid.c/h at least. And the gma stuff is most probably based on what you have too... i think Lebidou used the stuff on Andy's or Prasys branch.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 14, 2010, 03:05:58 PM
Pretty much the only module that isn't working right now is the GUI module, It was *way* too integrated into the rest of the source code, so I had to strip that out. As it is it replaces the printf / verbose /etc routines correctly, just the gui part itself isn't working. I also need to enable the embedded theme for that.

Anyway, main reason I'm changing things to modules (other than because nobody else is), is because I need boot2 to be smaller, *much* smaller, for something I'm doing (about half the size my current branch compiles to).

Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 15, 2010, 10:18:55 AM
Quote
Pretty much the only module that isn't working right now is the GUI   module, It was *way* too integrated into the rest of the source code,...
I see what you mean..! Still editing stuff to get the feeling on the work involved just on GUI module... uff
I suppose the theme will be embedded on the module, right?

The modules i have now (GE and memory) are working perfectly, no delays, no glitches... pretty cool, this stuff!
And thinking that weeks ago we were worried with booter size, now your target is 60K+-...
Finally we will be able to include wc, kitchen, etc ;D
If i had more knowledge i'd be converting stuff atm... i need to learn more! But that won't keep me from trying.
Think i will leave GUI for now and focus on AutoResolution..?!
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 15, 2010, 03:10:06 PM
The issue with the GUI module is that the gui.maxdevices value is being set to 0 somewhere, causing a device by 0 error, and so an instant reboot. I will modify the gui module so that embedtheme works with it, right now it doesn't.

The Resolution module contains the 915resoluition code as well as the edid code.

Next thing I'm going to do is probably fixup some of the code to be more efficient space wise (drivers.c, boot.c, and a few other can easily be modified to save some space).
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 19, 2010, 03:44:21 AM
Back...
Quote
The issue with the GUI module is that the gui.maxdevices value is being set to 0 somewhere, causing a device by 0 error, and so an instant reboot.
Any progress on this? Been taking a look at it while studying this stuff but, still no luck.
Shouldn't the booter work without GUI module? or GUI=n?... cause it doesn't.

Quote
The Resolution module contains the 915resoluition code as well as the edid code.
Studying your Resolution module doesn't help much with this AutoResolution... i learn more with GUI module :)

One thing i found by chance, while checking a reported hang, supposedly caused by -f argument;
i get an instant reboot right after s/l/e drivers finish loading, if using -f and HelloWorld module. Any idea on this?
I wasn't using the module anymore; it found it's way into Modules folder because i forgot to remove it from the script i use to update the booter. Anyway, i don't even remember why i suspected of it..?!
Any reason i should keep it around, besides being an example?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 19, 2010, 05:06:19 PM
The GUI module isn't needed. Everything works fine without it (other than the gui of course). I've tested it multiple time. Without the module, you get the text screen. With the module and no theme directory, you get the text screen and the boot logo. With the module and a theme directory, you get a reboot due to a divide by zero. I haven't had time to fix the reboot issue, but it should be an easy fix..

The resolution module is simple, it just patched the video bios with the optimal resolution read from the edid. HelloWorld.dylib shouldn't be doing anything, all it does in my branch is print the address of the kernel, and then pauses. Yes, it's not needed.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 20, 2010, 05:34:03 AM
You're right about the booter running without the GUI module... i don't know were i had my mind when i tested that bit??! Sorry.

About HelloWorld module, i understand it shouldn't be causing any problem.. can't understand how it can be related with booting with -f flag!? I'm pretty sure i tested this one correctly several times, but will take another look.

Update: hum.. if i remove Memory.dylib and leave HW, booting with -f goes fine. Will test more later.. still need to catch up with latest updates on your branch.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 21, 2010, 04:02:02 AM
I've updated a few things, let me know if the GUI module works now. Also, let me know if you run into more issues with the Memory module.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 21, 2010, 06:56:31 PM
Mek,

Rev 534:
- GUI doesn't load. Else seems to work fine, embedding theme and so...

- ACPIPatcher: 2 things don't work; getting PciRootUID from dsdt (setting UID with PciRoot=1 works fine),
Code: [Select]
Read HFS+ file: [hd(0,4)/Extra/modules/Symbols.dylib] 16604 bytes.
Read HFS+ file: [hd(0,4)/Extra/modules/ACPIPatcher.dylib] 25076 bytes.
Unable to locate symbol ___udivdi3
Unable to bind symbol ___udivdi3
Unable to locate symbol getPciRootUID
Read HFS+ file: [hd(0,4)/Extra/modules/GraphicsEnabler.dylib] 35004 bytes...
and
setting SystemID (didn't tested key).
Code: [Select]
fake_efi.c: In function ‘getSmbiosUUID’:
fake_efi.c:495: warning: function returns address of local variable

Rev 535 fails to build:
Code: [Select]
/usr/bin/ld_classic: Undefined symbols:
_promptForRescanOption

About that HW+Memory+-f instant reboot, it's only on my branch; as it is, i don't get it with your branch.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 22, 2010, 04:24:01 PM
Those three issues should fixed now.

I do have an issue with the memory module on my dell mini 10v, but not on my mini 1012 (or my desktop), so I'll try to track that down (and sync it with the changes in trunk).

As far as the gui goes, I can't seam to reproduce the bug. On three of my machines the gui start up perfectly. If you wan't I can send you the compile version from my branch so that you can test if that works or doesn't work.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 23, 2010, 06:58:51 PM
Hi... sorry for the delay; been feeling sick...
Yes, at rev 541, the PciRoot UID is working fine and platform UUID is also read fine from DMI table.

GUI related...; besides the GUI not loading, i always need to boot in verbose mode; without -v i don't get "boot" screen and after login i can only see a small portion of the screen, something like 1/2 of the width and 1/3 of the eight, starting from the upper left corner of the screen. I'm guessing this can be related to the Resolution module so, i tried removing it but then i get
Quote
Unable to locate symbol _getResolution.
and an instant reboot.

Yep, maybe it's better to check against a build of your own; shouldn't make any diff since i'm compiling directly from a checkout of your branch but, one never knows. Meanwhile, will review things again on my side.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 24, 2010, 04:39:17 PM
Things should work without verbose mode now, you won't have the apple logo though, at least not yet.

I'll upload a working version (for me) tonight have you try it out.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 24, 2010, 06:18:35 PM
Gave a try to rev 548, gives me an instant reboot some were after loading drivers... need to add some pauses to get a fix on were it's really coming from. After lunch... be back later.

Update: ok, i can overcome the instant reboot with UseMemDetect=n.
But, i see that some stuff is not ready so, i'm going to wait on your input.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 25, 2010, 04:20:44 AM
Well, the good news is I was able to reproduce some of the issues you had with an asus machine. I'll try to fix the bugs soon.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 25, 2010, 08:40:20 AM
OK, nice. I'm keeping an eye on your progress... no problemo.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 26, 2010, 01:48:46 AM
Well, I've fixed at least some of the issues, let me  know if it works any better now.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on September 26, 2010, 07:49:57 AM
Status at rev 552:
- GUI still doesn't show signs of life; module loads but, that's it.
  Still needs Resolution module loaded or gives instant reboot.
- USBFix module loads, but the fixes don't work, whatever key i use.
  I do get a warning while building the module but don't think that's the problem...
  One thing is curious though; i still didn't had any usb problem while booting with your branch ???

The rest seems fine; the gray boot screen is showing without -v and no problems after login.

Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: valv on September 27, 2010, 02:20:56 PM
@Meklort,
Congrats for the heavily good job you're at. I'd like to give you some feedback after having mixed your code with mine:
- Neither GUI nor Memory modules are working.
- Still some warnings on compiling GraphicsEnabler & USBFix:
Quote
GraphicsEnabler.c: In function ‘GraphicsEnabler_start’:
GraphicsEnabler.c:24: warning: passing argument 2 of ‘register_hook_callback’ from incompatible pointer type
USBFix.c: In function ‘USBFix_start’:
USBFix.c:29: warning: passing argument 2 of ‘register_hook_callback’ from incompatible pointer type
- Other irrelevant warnings:
Quote
Memory.c: In function ‘Memory_hook’:
Memory.c:57: warning: implicit declaration of function ‘scan_memory’
Networking.c: In function ‘set_wifi_airport’:
Networking.c:132: warning: unused variable ‘temp2’
- Most important, make optionrom gives this:
Quote
/usr/bin/ranlib: file: sym/i386/libsaio.a(nbp.o) has no symbols
/usr/bin/ranlib: file: sym/i386/libsaio.a(ntfs.o) has no symbols
/usr/bin/ranlib: file: sym/i386/libsaio.a(ext2fs.o) has no symbols
ranlib: file: sym/i386/libsaio.a(nbp.o) has no symbols
ranlib: file: sym/i386/libsaio.a(ntfs.o) has no symbols
ranlib: file: sym/i386/libsaio.a(ext2fs.o) has no symbols
/usr/bin/ld_classic: Undefined symbols:
_drawColorRectangle
collect2: ld returned 1 exit status
make[2]: *** [boot] Error 1
make[1]: *** [optionrom] Error 2
make: *** [optionrom] Error 2
- make debug is no joy neither, maybe related to utils.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on September 27, 2010, 04:09:04 PM
Well, fixed the warnings and the err with make optionrom (do note that the modules won't work load correctly yet with make optionrom, it's not done).

Let me know if the gui and memory modules load in my branch, if it doesn't there's no reason trying to trace down a bug in your branch when it's a bug within mine.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: valv on September 27, 2010, 04:35:03 PM
that's funny: I was about to post how I've managed to get rid of the minor warnings (GraphicsEnabler etc..), just to find u got it already.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: valv on September 27, 2010, 05:32:44 PM
Neither GUI nor Memory are working yet. sorry!
Endless reboots when one of those 2 is into the modules folder.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on October 06, 2010, 09:54:47 PM
Status at rev 570:
we have progress :)
   
been testing this most part of the day:
- HPET.dylib still didn't gave any signs of life. I don't need it but, it doesn't hurt to check it.
- USBFix.dylib, shows some signs of life but never works properly and when it shows, never gets printed to bdmesg;
  booting with -f it's the best way to see some activity. I mentioned on my last post that i wasn't having usb problems
  with your branch, that's not true anymore, the usual problems are back.
- GUI.dylib it's finally working and it doesn't instant reboot without Resolution.dylib :)
  I also had to remove Resolution.dylib, or the resolution wouldn't let me see the prompt.
  Besides this, the only glitch is a reload of the of the guy, right after loading the kernel (check attached log).
 
The rest seems to work properly, excluding NBI & KextPatcher, which i didn't tested.

p.s.: GUI=No gives just a black screen, no Text Mode; removing the module works fine.
     
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Eps on October 09, 2010, 09:56:39 PM
Great!! Build 577 can boot into system at least in verbose mode on my HP mini 2140.
Thanks your effort!!
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on October 20, 2010, 09:44:41 PM
Hi Meklort, hope you're fine :)

I noticed one of these days that the KernelPatcher is not working with 10.6 kernel; so, after i saw your commit (rev 597) i gave a run through the kernels; tested all 10.6 kernels (even 10.6.5) except for 10.6.2...
The only one that failed was still the 10.6 one; no problem with the others both 32/64 bit; only tested 32 bit on 10.6.5 (64 bit only after source release). I tested this with the kernel patcher on "my branch", after updating with rev 597 stuff.

About your branch, last check i did was with rev 576... basically the same problems i mentioned about rev 570.
Will give a try at the latest stuff as soon as i can...

See ya...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on October 27, 2010, 10:36:42 AM
Mek,

on execKernel(), the "Kernel Start" hook needs to be moved before setupBooterLog() or anything that uses it, will not print to the log. After doing so on my working copy of your branch, i was able to check that the USBfix module is indeed working but it's only resetting 2 of my 4 uhci controllers:
Code: [Select]
UHCI controller [8086:27ca] at 00:1d.2 base 7e8(fd01)
UHCI controller [8086:27cb] at 00:1d.3 base 7e0(fc01)
instead of
Code: [Select]
UHCI controller [8086:27c8] at 00:1d.0 base 7f8(ff01)
UHCI controller [8086:27c9] at 00:1d.1 base 7f0(fe01)
UHCI controller [8086:27ca] at 00:1d.2 base 7e8(fd01)
UHCI controller [8086:27cb] at 00:1d.3 base 7e0(fc01)
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on October 27, 2010, 04:01:07 PM
I'll take a look
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on October 28, 2010, 12:04:24 AM
HPET module is also working... i spoke too soon :P needed time to check the code and enable debug.
Gave another look to USBfix; everything seems to work as expected, except for the UHCI controllers issue.

Going to try adding some more modules to my branch...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: yehia2amer on November 22, 2010, 04:13:21 PM
Hi Meklort, hope you're fine

I want to know if there is any news about a 64bit version of the lapic fix to run 64bit kernel ????

64bit will arrive sometime, probably within a week or two.

you said two weeks and it's been two months!!!???

this will really help us HP users alot

thanks alot for all your work :)
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on November 22, 2010, 11:48:14 PM
It'll get done when it gets done. It's not very high on my list (esp since it doesn't affect me), so it won't happen any time soon.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on January 24, 2011, 03:33:48 AM
Hi Meklort..
last rev i can boot is 671; is 690 still work in progress or can i call it a bug?
I had to enable debug on modules.c to get this; i get instant reboot right after all modules are loaded, when executing ModulesLoaded hook; e.g.
Code: [Select]
Attempting to execute hook ModulesLoaded
Executing ModulesLoaded with callback 0x8398EA5
Also, while modules are loading there's a constant check for a "Symbols.dylib.dylib" (yep, dylib x 2) which of course, always fails... normal?

Rev 671, has the same problems i mentioned before, mainly the uhci problem; only the last two controllers seem to be reset.

That's it.. stay safe :)
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on January 24, 2011, 06:58:35 AM
It's a work in progress. I fixed the Symbols.dylib.dylib issue (makefile bug) as well as a few other things in my last commit. At the same time i just broke a lot of things as well.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Slice on January 24, 2011, 05:02:45 PM
@meklort
Thanks for Symbols.dylib fixing. I immediately apply this to my branch and it works! I also ported back acpi_patcher so now my boot file may works alone, without any modules and without GUI.
Some other problems with my bootloader mostly common for all branches I reported at the forum.

@Azimutz
I am not understanding this assertion
Quote
"Kernel Start" hook needs to be moved before setupBooterLog()
It is very old claim. How for now?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: meklort on January 25, 2011, 04:25:16 PM
I must have missed that post / line about the boot log. I fixed the code as you mentioned.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Azimutz on January 26, 2011, 04:59:58 PM
It's a work in progress.
I see... i thought so.

I fixed the Symbols.dylib.dylib issue (makefile bug) as well as a few other things in my last commit. At the same time i just broke a lot of things as well.
yep.. with the Symbols.dylib.dylib check corrected, debug output is pretty much the same on the last commit (712) or 671; so, checking 671 boot-log, is easy to figure that the ModulesLoaded callback i mentioned is added by the GUI module; removing the module, i was able to go to boot prompt and start boot; as you mention there are still problems.. boot hangs while executing ScanMemory hook, after printing the memory modules info; these
Code: [Select]
Hook 'ScanMemory' callback executed, next is 0x0.
Hook 'ScanMemory' executed.
are never printed; it just sits there, cursor blinking, no keyboard available.
Attached is a 671 bdmesg with modules debug enabled.

I must have missed that post / line about the boot log. I fixed the code as you mentioned.
No problem... even i was already missing this :)

@Azimutz
I am not understanding this assertion
Quote
"Kernel Start" hook needs to be moved before setupBooterLog()
It is very old claim. How for now?
Slice, i'm not sure if i understand;
if you're asking "why Kernel Start hook needs to be moved before setupBooterLog()"? the answer is on the post:
Quote
...or anything that uses it, will not print to the log.
If that is not the question, you'll have to explain me :P
Anyway, Mek fixed it on rev 712.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Slice on January 28, 2011, 08:24:01 AM

if you're asking "why Kernel Start hook needs to be moved before setupBooterLog()"? the answer is on the post:
If that is not the question, you'll have to explain me :P
Anyway, Mek fixed it on rev 712.
I understand and apply Mek's correction.

About modules system I found a bug
Quote
//Slice
// ignored   first node where hooks->name == name ?!
/*      
      while(hooks->next && strcmp(name, hooks->next->name) < 0)  // <0 comparison is wrong, should be !=
      {
         hooks = hooks->next;
      }
*/      
      moduleHook_t* backHook = moduleCallbacks; //I need to remember last node in chain if next=NULL
      do {
         DBG("register_hook_callback: found = %s\n", hooks->name);
         if (strcmp(name, hooks->name) == 0) {
            break;
         }
         backHook = hooks;
         hooks = hooks->next;
      } while (hooks);
// There are only two variants: hooks found or not
// if not found then hooks=NULL so remember backHook      
Now I have a problem with GUI not started. And Memory.dylib crashes with speed=0. While before it works.

Next problem is related to klibc.dylib. Because of Symbols.dylib embedded?
I got message "Divide by 0" calculating (uint32_t)x / 50000;
What to do?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Slice on January 28, 2011, 01:30:57 PM
Mek,

on execKernel(), the "Kernel Start" hook needs to be moved before setupBooterLog() or anything that uses it, will not print to the log. After doing so on my working copy of your branch, i was able to check that the USBfix module is indeed working but it's only resetting 2 of my 4 uhci controllers:
Code: [Select]
UHCI controller [8086:27ca] at 00:1d.2 base 7e8(fd01)
UHCI controller [8086:27cb] at 00:1d.3 base 7e0(fc01)
instead of
Code: [Select]
UHCI controller [8086:27c8] at 00:1d.0 base 7f8(ff01)
UHCI controller [8086:27c9] at 00:1d.1 base 7f0(fe01)
UHCI controller [8086:27ca] at 00:1d.2 base 7e8(fd01)
UHCI controller [8086:27cb] at 00:1d.3 base 7e0(fc01)
After my corrections I see
Code: [Select]
Starting Darwin i386
UHCI controller [8086:2834] at 00:1a.0 base 379(6f21) reset
UHCI controller [8086:2835] at 00:1a.1 base 378(6f01) reset
Setting Legacy USB Off on controller [8086:283a] at 00:1a.7
Legacy USB Off Done
EHCI controller [8086:283a] at 00:1a.7 DMA @fed1c400
EHCI Acquire OS Ownership done
UHCI controller [8086:2830] at 00:1d.0 base 37c(6f81) reset
UHCI controller [8086:2831] at 00:1d.1 base 37b(6f61) reset
UHCI controller [8086:2832] at 00:1d.2 base 37a(6f41) reset
Setting Legacy USB Off on controller [8086:2836] at 00:1d.7
Legacy USB Off Done
EHCI controller [8086:2836] at 00:1d.7 DMA @fed1c000
EHCI Acquire OS Ownership done
execute_hook: Hook 'Kernel Start' executed.
That's OK.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: THe KiNG on January 28, 2011, 02:01:22 PM
Since we are on USB stuff can someone add OHCI reset?
An example is on AppleUSBOHCI.cpp -> AppleUSBOHCI::InitializeOperationalRegisters(bool fromReset)
Thanks!
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Slice on January 28, 2011, 03:30:26 PM
Since we are on USB stuff can someone add OHCI reset?
An example is on AppleUSBOHCI.cpp -> AppleUSBOHCI::InitializeOperationalRegisters(bool fromReset)
Thanks!
Already here
Code: [Select]
while(current)
{
switch (pci_config_read8(current->pciDev->dev.addr, PCI_CLASS_PROG))
{
// EHCI
case 0x20:
    if(fix_legacy) retVal &= legacy_off(current->pciDev);
    if(fix_ehci)   retVal &= ehci_acquire(current->pciDev);

break;
// OHCI
case 0x10: //same

// UHCI
case 0x00:
if (fix_uhci) retVal &= uhci_reset(current->pciDev);

break;
}

current = current->next;
}
return retVal;
}
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: THe KiNG on January 28, 2011, 03:54:14 PM
Oh, I missed that in your branch, going to try it, I really hate apple spamming my log :P
Thanks for tip.

Another question for you, does boot loader affect in any way USB on resume, after hibernate I get dead USB 2.0?
Trying to figure out who's fault is, driver, boot loader or both...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: THe KiNG on January 28, 2011, 04:16:59 PM
@ Slice is not working:
Quote
Jan 28 17:10:37 localhost kernel[0]: USBF:   4.729   AppleUSBOHCI[0x4c6d000]::InitializeOperationalRegisters Non-NULL hcDoneHead: 0xbfd9d620

Code: [Select]
UHCI controller [10de:0aa5] at 00:04.0 base 0(0)
Setting Legacy USB Off on controller [10de:0aa6] at 00:04.1
Legacy USB Off Done
EHCI controller [10de:0aa6] at 00:04.1 DMA @d3109200
UHCI controller [10de:0aa7] at 00:06.0 base 0(0)
Setting Legacy USB Off on controller [10de:0aa9] at 00:06.1
Legacy USB Off Done
EHCI controller [10de:0aa9] at 00:06.1 DMA @d3109100


I'm looking on Linux code: http://lxr.free-electrons.com/source/drivers/usb/host/pci-quirks.c
OHCI reset is not the same as UHCI one...
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: THe KiNG on January 28, 2011, 06:32:04 PM
OK, I gave up coding is not my thing, need help.
Linux code:
Code: [Select]
static void __devinit quirk_usb_handoff_ohci(struct pci_dev *pdev)
{
void __iomem *base;
u32 control;

if (!mmio_resource_enabled(pdev, 0))
return;

base = pci_ioremap_bar(pdev, 0);
if (base == NULL)
return;

control = readl(base + OHCI_CONTROL);

...

/* reset controller, preserving RWC (and possibly IR) */
writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);

/*
* disable interrupts
*/
writel(~(u32)0, base + OHCI_INTRDISABLE);
writel(~(u32)0, base + OHCI_INTRSTATUS);

iounmap(base);
}

What I did(don't laugh):
Code: [Select]
int uhci_reset (pci_dt_t *pci_dev)
{
uint32_t base, control;
#define OHCI_CTRL_MASK (1 << 9)
#define OHCI_CONTROL 0x04
#define OHCI_INTRDISABLE 0x14
#define OHCI_INTRSTATUS 0x0c

base = pci_config_read32(pci_dev->dev.addr, 0x10);
control = base + OHCI_CONTROL;

verbose("OHCI controller [%04x:%04x] at %02x:%2x.%x control %x(base %x)\n",
pci_dev->vendor_id, pci_dev->device_id,
pci_dev->dev.bits.bus, pci_dev->dev.bits.dev, pci_dev->dev.bits.func,
control, base);

/* reset controller, preserving RWC (and possibly IR) */

outl (control & OHCI_CTRL_MASK, control);
delay(10);

/*
* disable interrupts
*/
outl(~(UInt32)0, base + OHCI_INTRDISABLE);
outl(~(UInt32)0, base + OHCI_INTRSTATUS);
return 1;
}

Code: [Select]
OHCI controller [10de:0aa5] at 00:04.0 control d3108004(base d3108000)
Setting Legacy USB Off on controller [10de:0aa6] at 00:04.1
Legacy USB Off Done
EHCI controller [10de:0aa6] at 00:04.1 DMA @d3109200
OHCI controller [10de:0aa7] at 00:06.0 control d3107004(base d3107000)
Setting Legacy USB Off on controller [10de:0aa9] at 00:06.1
Legacy USB Off Done
EHCI controller [10de:0aa9] at 00:06.1 DMA @d3109100
Is not OK since I still get that damn message from apple driver, so what I did wrong?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Kabyl on January 28, 2011, 07:09:26 PM
You want to do something like this:
Code: [Select]
...
*(uint32_t *)(base + OHCI_CONTROL) = control & OHCI_CTRL_MASK;
...

Is disabling interrupts needed?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Slice on January 29, 2011, 10:42:33 AM
And before
Code: [Select]
control = *(base + OHCI_CONTROL);
Because of absence of other experience I was considering my patch is enough
Code: [Select]
execute_hook: Executing 'Kernel Start' with callback 0x83A293B.
UHCI controller [1002:4347] at 00:13.0 base 0(0) reset
UHCI controller [1033:0035] at 02:06.0 base 0(0) reset
UHCI controller [1033:0035] at 02:06.1 base 0(0) reset
Setting Legacy USB Off on controller [1033:00e0] at 02:06.2
Legacy USB Off Done
EHCI controller [1033:00e0] at 02:06.2 DMA @c0200800
EHCI Acquire OS Ownership done
execute_hook: Hook 'Kernel Start' executed.
Without the patch I see 100 messages and USB is not working during 2 minutes after start.
Now all seems to be OK. Kernel.log is clean.
My be in my case this reset is not needed.
I just need to implement cosmetics UHCI ->OHCI.
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: Slice on January 29, 2011, 02:35:27 PM
Is disabling interrupts needed?
Linux made
Code: [Select]
writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
...
writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
...
writel(~(u32)0, base + OHCI_INTRDISABLE);
Not sure it is needed in our case (OSX).

I propose the procedure should be as follow
Code: [Select]
int ohci_handsoff (pci_dt_t *pci_dev)
{
uint32_t base, control;
#define OHCI_CTRL_MASK (1 << 9)
#define OHCI_CONTROL 0x04
#define OHCI_INTRDISABLE 0x14
#define OHCI_INTRSTATUS 0x0c

base = pci_config_read32(pci_dev->dev.addr, 0x10);
msglog("OHCI controller [%04x:%04x] at %02x:%2x.%x base %x reset\n",
   pci_dev->vendor_id, pci_dev->device_id,
   pci_dev->dev.bits.bus, pci_dev->dev.bits.dev, pci_dev->dev.bits.func,
   base);

control = *(uint32_t *)(base + OHCI_CONTROL);
*(uint32_t *)(base + OHCI_CONTROL) = control & OHCI_CTRL_MASK;
return 1;
}
tests needed.

Linux also has a patch for XHCI (USB3.0?). Is it a time to implement it also?
Title: Re: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.
Post by: THe KiNG on January 30, 2011, 07:42:55 PM
Still not working:
Code: [Select]
Starting Darwin x86
OHCI controller [10de:0aa5] at 00:04.0 base d3108000 reset
OHCI controller [10de:0aa7] at 00:06.0 base d3107000 reset

Quote
Jan 30 17:07:37 localhost kernel[0]: USBF:   2.134   AppleUSBOHCI[0x4c6b000]::InitializeOperationalRegisters Non-NULL hcDoneHead: 0xbfd9d620

I will look better on what apple does to clean the hcDoneHead

L.E. Again ACPI saved me...much more easier to do it, for some reason same thing on boot loader has no effect, but it does with DSDT help.
Case closed, now I can remove USB module from boot loader.