tlaurion
commented
1 year ago Referencing: StarLabsLtd/firmware#104 I would like to see if Heads can be ported to the Starbook MkVI. Starlabs Coreboot firmware is located here: https://github.com/StarLabsLtd/coreboot
Already had a look over the documentation and parts of the code for Heads. Build system differences aside, Coreboot version of Heads (the latest one at least) is 4.19 while Starbook's laptops are on 8.40+ at time of writing. Is there anything stopping the version being upgraded to 8.40+?
@Hacksawfred3232:
Clicking on the link provided showed a branch of coreboot 4.19. I have not followed current upstream coreboot support of that specific board. But rule of thumb is if it is supported upstream in coreboot, then the beginning of a port is to have a known working coreboot configuration file, list all drivers needed in which version of linux kernel and have them activated in a corresponding linux config. Duplicate the closest board configuration file, have it point to the referred coreboot and linux config, cross finger and build. If it builds, then be prepared with an extrnal reprogrammer, and flash it externally after having taken a backup to properly unbrick in case its not magically working the first time.
I've noted that there are some references to a 32bit compiler, despite most modern systems being 64bit. Why is this the case?
coreboot builds its own build stack per coreboot release. There is experimental 64 bit support, but coreboot builds in 32 bits. Firmware is different here then building a kernel or an app.
I also saw that on the wiki, the maximized ROM version requires all regions to be unlocked. Why is this required? Maximized here means that those roms distribute everything that is to be flashed internally or externally. To gain near 12mb of SPI space, ME needed to be neutered, gaining 5MB of the 12mb on ivy bridge. Ivy bridge is the last known chipset for which ME can be neutered (which means, per me_cleaner docs, that most of the modules are removed) as opposed to HAP bit deactivation or other tricks that can be applied to deactivate ME, but that doesn't give back the space occupied in the chip.
What it means for newer boards is mostly all explained under #692 on top post. Newer architectures require more blobs, and one will have to either find a way to find them online in updates provided in blob format by constructor (this is what was done for ivy and sandy bridge, haswell for t440p and other ports that are currently happening)
The other solution would be to recreate what are "legacy" boards. That would mean creating a full size bios image, but having flashing only write over the BIOS partition there. Heads port for that board would need to fit in current BIOS region for that motherboard. And Heads would need to have, just as for legacy boards, a FLASHROM statement in board config stating which regions are upgrdeable, and provided, in built rom.
I have not looked at the specific platform, but I guess they provice EC, BIOS, ME region. And in the BIOS region will be FSP blobs and maybe others. Dissecting manufacturer firmware images would be an interesting first step. I have no clue what they provide, but if laptop goal is to boot also windows, I guess the firwmare image is UEFI compliant, relaying also on ED2K and maybe tianocore.
You can drop your findings here, I'm pretty sure you are not alone:
- GPU, supported under which kernel version (that is important to get rid of libgfxinit under coreboot and only depend on kernel drivers for GPU init where possible). Otherwise, that coard will rely on FSP's GOP and coreboot libgfxinit which we are trying to get rid of.
- coreboot configuration file if found from manufacturer, in full oldconfig format.
Referencing: https://github.com/StarLabsLtd/firmware/issues/104 I would like to see if Heads can be ported to the Starbook MkVI, and wondering what would need to be patched/changed in order to do so. Starlabs Coreboot firmware is located here: https://github.com/StarLabsLtd/coreboot
Already had a look over the documentation and parts of the code for Heads.
I've noted that there are some references to a 32bit compiler, despite most modern systems being 64bit. Why is this the case?
I also saw that on the wiki, the maximized ROM version requires all regions to be unlocked. Why is this required?