Jump to content

flyingfishfinger

Members
  • Posts

    53
  • Joined

  • Last visited

Contact Methods

  • Website URL
    https://rsend.wordpress.com/

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2181 profile views

flyingfishfinger's Achievements

Sergeant

Sergeant (6/17)

1

Reputation

  1. @BronxteckTried 256MB on the latest version of Coreboot, same result. I then attempted a fairly old version of Coreboot (4.10 from late 2019, current is 4.14) and OpenCore won't even load properly, with the following error: "OCB: StartImage failed - Aborted" and then it loops back to the Picker... R
  2. How do you mean "move back to the latest" ? You mean get it to boot once on an older version then update, or something else? I'm not sure I understand how that would help - even if it does boot on older versions wouldn't it just break again after updating? I'll give the 256MB setting a shot, thanks, R
  3. Hmm, are we sure about that? In the BIOS case, I tried it with both 64MB and 32MB DVMT-prealloc, and it boots fine, with acceleration and no changes to the EFI. I've checked and adjusted the Coreboot code which sets this value (it's called IgdDvmt50PreAlloc), as well as confirmed the register value (GGC, out of here: https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol02c-commandreference-registers-part1.pdf) that should be affected by twiddling the value; it does indeed change. Any value I set results in the above KP (32MB, 64MB, 96MB, 128MB)... so I'm not sure this is the right thing. Further: Reading out the register when both are set to 64MB results in the exact same return value if done with BIOS vs Coreboot, but one boots and the other doesn't. That tells me it's gotta be something other than DVMT issues... Further #2: After going over the OC guide and setting the Booter quirks for MAT & SetupVirtualMap I'm back to the very original hang that started all this (stuck at [IGPU]), even with the new EFI from the link in my previous post. R
  4. I've seen that before. Sadly it's not very helpful, since (1) it's for Clover, which I don't want (2) some of the kexts are no longer applicable (OC guide specifically recommends against them) (3) it just boot loops on my system with Coreboot and (4) the forum thread that refers to this on Thinkpads only goes as far as Big Sur. However, I did find this instead: https://github.com/jamesfawcett/Thinkpad-X2100-51nb-OpenCore-Hackintosh The X2100 is an updated version of the machine with a 10th Gen CPU, but on a whim I tried this as-is. Interestingly, it fakes an Iris 635 instead of the actual UDH 620. I don't know why they do this.... any ideas? The result - if I use the stock BIOS, I actually get acceleration! But on Coreboot, I get the following KP... "airportd" ?? R
  5. @Baio77 Monterey boot hangs at IGPU if I use 0000C087 as a platform-ID, then KP's after a while. Like I said, so far I can ONLY boot with an invalid one, otherwise it always either hangs in this place or gets a KP. I've attached the ACPI from SysReport, and a screenshot of the KP. It starts with "10 error-reporting cores" @Syonagar the payload is Tianocore, specifically MrChromebox's build of coreboot + Tianocore: https://github.com/MrChromebox/coreboot. It works very well generally and is sometimes recommended over Coreboot master. It's based on the latest actual Coreboot release. Thanks, R Sysreport.zip
  6. Well, I guess this brings me to a question I've always sort of wondered about. Everything I've ever read about Hackintoshes always seems very "trial and error". I get that maybe for absolute beginners that could be a good approach when stuff doesn't work, but shouldn't there be ways of debugging or deriving the correct solutions a bit more analytically? Or do we really not know how Apple's black box works? For example, if there's a hang during boot because of graphics could we not use the debugging output of WEG / Lilu etc to figure out what it's not happy about? I've seen bits of that in the logs - like figuring out what Link Rates are available and whether those need to be adjusted. Or what WEG thinks of the *actual* framebuffer / device ID. Or, how to check what the actual allocated DVMT is. In-depth technical information about stuff like this is few and far between, and I sometimes wonder why... Any ideas? R
  7. @Hervé FWIW, There IS a regular BIOS that the machine comes with, I just chose not to use it. It doesn't make these graphics problems go away unfortunately - I've tried. I DO hope we can figure it out though, as Mojave runs *almost* fine with some of the "usual" frambuffer choice... R
  8. @Hervé Thanks for confirming, and sorry about it again. @Baio77 OK, will try this evening. Thanks! R
  9. Hi, @Hervé I thought I have the information about the machine in my signature for the exact reason of informing people thereof. Is it not visible? Please let me know... Apologies for that, I did not mean to annoy you. The specs of the machine, to the best of my knowledge, are as follows: - 8th Gen Kaby Lake R i7-8650u - Intel UHD 620 graphics - Internal LCD connected via eDP - miniDP port - VGA port via ... internal eDP converter chip, I think. Unsure, but I can find out. - Monterey is on a Foresee 128GB M.2 drive, which has a SATA interface (B+M key) - 16GB RAM (have to look up the make/model, if relevant) - AX200 WiFi (working fine with itlwm / bluetooth kexts, obviously not on Monterey yet though) I've been through the WEG manual many times, and have tried every frambuffer listed for KBL-R. I am aware that the framebuffer currently present in the EFI I shared is invalid, as that is the only way I have managed to get the system to boot (any invalid one will do). I've tried the ID's you mentioned as well to no avail, and my SMBIOS is already a MBP 15,2 (according to your recommendation in my InsanelyMac thread). The SMBIOS alone did not seem to have made much of a difference. @Baio77 See above, I know that the current ID was wrong - but couldn't get it to boot otherwise. Using your EFI, how should I extract the ACPI, and which log would you like to see? OC boot log? @Syonagar Coreboot lets me do other fun things, like stick an entire Linux distribution into the ROM (Check out Tinycore Linux!). The Chromebook people actually also have the same problem I have, as they use a variant of Coreboot by default - you might consider this question an aggregation of at least two other folks who can't get this to work either, but the Chromebook + Hackintosh intersection is pretty small. There's a Discord server for it, if you're interested. Apologies again for apparently missing information, I am not ignorant of the need for it and thought it is already present in my signature. Please let me know what other information I can provide that might be useful here. Thanks, Rafael
  10. Hi all- I already posted a related question over at InsanelyMac, but it was suggested elsewhere that I should check here, in particular with @Jake Lo since he seems to knowledgeable about iGPUs and I've gotten great help here in the past too. Anyway, I put the latest Coreboot on my X210, and have a (more or less) working Mojave install using OC 0.7.3. I then tried to duplicate the process to install Big Sur, but none of the frambuffer settings (or any that I can find so far) resulted in working acceleration. Out of curiosity, I tried the same thing with Monterey Beta 6 to see if anything would change, but it does not. I also updated OC to 0.7.4. Since I overwrote the Big Sur install with the Monterey one, this question should apply to the latter. As far as I can tell, my DVMT should already be at 64MB or higher (Coreboot guys tell me it's set to the max by default), and I don't need any stolenmem / fbmem lines for Mojave anyway. I've attached my current EFI, in case there's something obviously wrong - I'd love to get some ideas that I haven't tried yet, since I've seen plenty of builds with my CPU/GPU that seem to work. All the ones I've found so far have IDs that do NOT work for me, however... Cheers, R EFI.zip
  11. I have no HDMI connectors in my system at all. However, that page did get me one tiny step further; there is a particular suggestion for Kaby Lake R, which is a device-id of 16590000 . That got my listed video memory from 8MB to 14MB... on the right track perhaps? [In other news, I fixed the mouse; VoodooPS2Controller wasn't installed properly] R
  12. More information, in case it helps tweak this properly: My internal display is connected via 4 eDP lanes, and I've already set DVMT prealloc to 64MB. I also tried messing around with the WhateverGreen stuff, but manually editing the config.plist to populate all the suggested values is a little beyond me, not least because I'm not currently not sure what all the different fields even are / mean.. I also have a mini DP port and a VGA port, the latter of which is actually another DP port with a converter. Maybe this information can help with port naming / numbering. R
  13. Hi- Alright I have a semi-working very barebones install. Post-install I followed the steps from the same guide, except that I used your "x210_test" Clover folder. I still have to boot with "-igfxvesa" to avoid a kernel panic and the video memory is only 21MB (along with the associated issues...no resolution changing being the biggest one, using a 12" 3K screen at native resolution is a bit tricky). Sound works, but is very quiet (?), Bluetooth does not work at all (no hardware shown) and I still require an external mouse. Admittedly this is much closer to working than what I've gotten on a first try in several years on previous machines, so that's a plus R
  14. Ah, progress! It's much slower, but it does get to the installer screen. Mouse & keyboard don't work, but I didn't try USB ones yet. R
  15. Hello, I hope all is well, I was wondering if you guys had any further ideas for this KP... Cheers, Rafael
×
×
  • Create New...