| 23 May 2021 |
hoverbear | I need to make a pr for that to Linux Hackerman 's repo but I've been trying to find some optimal gcc flags which include ftree-vectorize etc | 22:28:13 |
hoverbear | * I need to make a pr for that to Linux Hackerman 's repo but I've been trying to find some optimal gcc flags which include ftree-vectorize etc... Currently waiting on Firefox to build. | 22:29:56 |
artemist 🏳️⚧️ | Okay, spi flashed
The main issue with my old uboot was that any keyboard or serial input took several seconds to register | 22:56:32 |
samueldr | right, yeah, fixed upstream | 22:56:51 |
samueldr | if you had tried UEFI and had a "console" UEFI program running like GRUB, it would also be extremely slow | 22:57:17 |
samueldr | this is because U-Boot (still does) sync the display every chars written | 22:57:38 |
artemist 🏳️⚧️ | I erased the spi flash from the serial console then booted off your installer sd card image | 22:58:01 |
samueldr | perfectly cromulent way to install | 22:58:21 |
samueldr | also a good validation check that the builds does boot on the target hardware | 22:58:36 |
samueldr | (though in practice there's enough difference in the SPI build that it could boot fine from SD but not on SPI) | 22:58:53 |
artemist 🏳️⚧️ | Do EFI variables work in Tow-boot on the pinebook pro? | 23:10:29 |
artemist 🏳️⚧️ | Or should I just rely on boota64.efi being in the right place? | 23:10:52 |
samueldr | https://nixos.wiki/wiki/NixOS_on_ARM/UEFI | 23:15:31 |
samueldr | for the time being, boota64.efi | 23:15:36 |
samueldr | though you might want to use rEFInd instead | 23:15:44 |
samueldr | such that rEFInd scans for EFI programs | 23:15:56 |
samueldr | depending on what you prefer :) | 23:16:01 |
artemist 🏳️⚧️ | Makes sense. TIL that you can use rEFInd on ARM | 23:16:08 |
artemist 🏳️⚧️ | I last used it on an ancient macbook before I corebooted it | 23:16:22 |
samueldr | but yeah, since it's U-Boot with a coat of varnish, just like U-Boot there's no efivars support just yet | 23:16:38 |
samueldr | I use rEFInd on my few computers where the UEFI implementation is bad | 23:16:56 |
samueldr | plop it at the fallback location, so when they decide to lose their efi vars, I'm not left with absolutely nothing to boot | 23:17:19 |
artemist 🏳️⚧️ | Unfortunately on the computers I've had with a bad UEFI implementation if the boot order got changed too much the system was bricked. You couldn't even get into the firmware interface or the boot menu | 23:18:14 |
artemist 🏳️⚧️ | Or boot the images you had configured | 23:18:41 |
samueldr | those I have just decide to reset themselves :) | 23:18:45 |
artemist 🏳️⚧️ | That's nice. This was a thinkpad and ended up returning it because of this issue | 23:19:03 |
samueldr | understandably :( | 23:19:25 |
samueldr | why aren't they all just using coreboot letting the user control that? | 23:19:39 |
samueldr | they can leave the security bits to be blown by enterprise users! | 23:19:59 |
samueldr | (yeah, I know why, because they can use the "enterprisey" EFI implementors service level agreements and such nonsense) | 23:20:28 |