27 July 2016

GitHub Repository

I have a repository with some experiments and useful stuff (for the braves).


It's a collection of proprietary blobs that I use on some of my tests/ports. Useful if you own one of those devices and want to port some rom or try some obscure stuff with the related hardware.

Not populated (yet) because I'm lazy.

That's a collection of UEFI firmwares (or bios files, if you're stuck in the past), DSDT (fixed and original ones) and many other things related to UEFI platform.
I've organized the directories to have the original UEFI firmware and my updated one, to be easy to identify. The updated one's have the last upgrades and fixes available for the related hardware on the pertinent motherboards (since the manufacturers doesn't give a crap to update their hardware firmware properly and fix dreadful bugs).
It's well assembled and tested by me. Works for me (doesn't mean that will work for you, so if you make a gamma ray generator using one of my custom firmwares, you're at your own).

Have fun and as well, depending on my free time, I accept patches and/or requests.

Proprietary ATI/NVIDIA + UEFI = Personal Nightmare, thanks to ATI/NVIDIA

Nah, don't come saying "omg just use bios!". UEFI is light-years better than bios with a lot of reasons (I will not enter in this details here, you can search yourself).
This isn't a real howto, is more like a safeboat.
The Problem:
Everybody knows the problems of proprietary drivers in linux, and everybody knows how sweet those companies are about that. They think someone will stole a chip idea just looking to the fucking source code of a fucking driver (well, I don't see any other reason to be less stupid than that). Well, isn't only the fact that those closed-source drivers have compatibility issues, they're broken, incomplete and incompatible MOST of time.
For example, why the binary drivers doesn't work with a lot of type of configurations? Because "fuck you" - ATI/NVIDIA says. Why the binary drivers doesn't work with EFI framebuffer, since is something that just cames from the firmware? Because "fuck you" - ATI/NVIDIA says. Really? Incompatible with EFIFB? So huge companies like ATI and NVIDIA aren't capable to make a fucking less-retarded driver that works with the goddamit EFIFB that is so common than textmode?
The Solution:
Eh.. there's no solution...Well.. sort of...
1) Making two different kernels
This is the most secure and easy way.
Make the first kernel without any framebuffer, with a different name (you know how to customize your kernel name, right?), so you can enter in single mode if something happens. Another one without any framebuffer, with your binary driver proper installed. I have this configuration in my funtoo install without any issue. However, you'll need a different approach if you use CloverEFI instead of rEFInd (nothing to hard to deal, if you're here already).
2) Don't use EFIFB at all
It's quite dangerous if something happens. But still, you can make a pendrive (or use a sdcard with at least 128Mb of space and configure some bootloader to deal nomodeset in case of some emergency).
3) Don't use proprietary drivers
Disregard the problems of proprietary drivers, the opensource drivers aren't well to use in regular basis (Yet? YET?). But the choice is yours.
1) You don't need a bootloader if you use rEFInd or CloverUEFI. Learn about EFISTUB. You can even pass a kernel cmdline using EFISTUB, but isn't necessary since rEFInd and CloverUEFI can pass kernel cmdline without any problem at all (I use rEFInd+EFISTUB with initram incorporated to vmlinuz+LVM).
2) The ATI/NVIDIA drivers make your life harder as hell when you want to use EFI.Apple devices with nvidia cards doesn't have this problem because their EFIFB ARE NvidiaFBs, no big deal. Same for some IBM devices I did some research (of course I didn't use a proprietary driver on a server). Don't know about motherboards with native ATI/NVIDIA, also don't know about notebooks with discrete cards (my notebook with a nvidia card doesn't have EFI, unfortunately).
3) I've already tried to trick using CloverUEFI and even modifying my firmware and SMBIOS. It doesn't work anyways.
4) There's some options for the kernel change on-the-fly the framebuffers drivers from EFI to any some others drivers to make a more "native" approach, mysteriously those two big companies are not able to achieve this (efifb can change on-the-fly to nouveau, nuff said).

Update 20170515: They work now, you can use efifb+proprietary drivers, don't know exactly who had the problem atm.