Coreboot and Libreboot newly supported HP EliteBook 820 G2 sometimes soon in heads?

[fhvyhjriur]

There are few people who do not like the screen of the X230 and are also not happy with the CPU speed and other things. Some people have build because of this the eDP screen coreboot images for the x230 to use modern screens. Also some people soldered a quadcore CPU into the X230.
The X240 that have already the modern display connector never got support by coreboot and for a better screen you have to take a bigger T440p or even go big and heavy like the W541. There was no good solution for people who need a small and portable device without heavy modifications required to the X230.

Since some months there is now support for the HP EliteBook 820 G2. Sadly it involves one more binary blob that is required to run and have of course not a Thinkpad keyboard. But maybe when more people get to this CPU platform, there would be someone who would reverse engineer the binary blobs. And hopefully the Thinkpad series with the same CPU get supported by coreboot also at some time later.

To get more people into this CPU generation that could potentially be able to run with as much free software as the x230, are there any plans adding heads support for this device? The build in TPM chip there is the SLB 9660.

More information available here:
https://libreboot.org/docs/hardware/hp820g2.html
https://github.com/coreboot/coreboot/tree/main/src/mainboard/hp/elitebook_820_g2
https://review.coreboot.org/c/coreboot/+/46630

[tlaurion]

@fhvyhjriur I followed the work on the coreboot port, and this is amazing work. On libreboot, it's easy enough as using seabios+grub as a payload on top of coreboot. This is reductionnism. But this is what it is. On older platforms, there is not plenty of spi space, and for most (get outside of your shoes) soldering a replacement spi chip of 16mb is not an option, unless you sell soldering as a service yourself, you should consider that switching to coreboot alone generates anxiety to most, and is a coreboot accessibility barrier. If you solder yourself 16mb spi chips, then you could flash coreboot as a service. Those don't exist enough.

If you were to become a reseller of such coreboot/libreboot (now équivalent of Maximized platforms) platforms, we would talk about monetary compensation as well as a get go, since those board inclusion inside of Heads would generate profit and you do not seem to be technical enough to do the port yourself, so someone else has to do it for your benefit, owning that hardware first then making it work without everyone bricking their boards, prior of end users not being considered as beta testers. So soldering is not an option. Unless someone out there can do it for you, it doesn't make much sense to support platforms only for them to require soldering as entry barrier, which nobody does but niche of niche of niche people. That's not sustainable for me to do a port for free. Maintain it for free. For niche of niche of niche use cases. Not that this is relevant to this board particularly, but we have to stop going in circles over the years redoing the same discussions.

---

A reminder: the Heads project is a community-driven effort.

The general idea here is that a more technical board owner/business venture explorer is responsible for trying to learn how to port an existing and maintained upstream coreboot port to Heads. There are multiple examples of such boards in the current board directory. On these boards, the git blame feature (which GitHub allows you to see visually) will lead you to the respective commits and pull requests where efforts were made to bring those boards to Heads, most of the time with really detailed discussions about how they were enabled and ready to be duplicated to other boards.That board owner needs to be motivated, at least minimally, to engage in such a port for their own personal or business interests. That board owner is then responsible for becoming a willing tester when important changes happen under Heads, so that pull requests that may cause regressions or bricks when internally flashing, as opposed to the master branch, are tested before being merged to not cause frustrations to end users who are not technical enough nor own an external programmer.

The boards marked UNTESTED under the board directory will also link to pull requests that were untested by those previously board owners who were responsible for testing those boards due to personal interests and gives clear warning from users that those boards are not currently properly tested, which then moved to UNMAINTAINED because the effort to bring them par to other boards becomes too big effort for non technical board owners: they have bitrot.

The unmaintained directory shows boards that were moved there because they were untested for too long by disengaged interested board owners, requiring too much time from me, the maintainer, to poke those people in time to no avail, which was needed before merging pull requests that then bitrot, which need to be rebased and have conflicts resolved, etc which I won't do anymore. I've learned. So they were moved to UNMAINTAINED directory until someone personally interested jumps in and is willing to collaborate to bring that board back to being maintained and tested under Heads.

I have nothing against bringing platforms without discrete TPM (dTPM) that would use Basic boot mode (not so relevant to be brought to Heads honestly, but if one is motivated to consent to testing in time, it will be maintained). The same applies to any board, including this proposition.

You lurked into Heads for a long time. You seem to have time. You seem to own many boards. But you don't reply in time and don't seem to consent to testing in time in my prior efforts for the x200, etc, which you own. Reconsidered my decision to not bring those boards because missing security premises and spi size were deficient. You continue to believe changing spi chips and soldering, which is niche, is a valid reason to reject maintaining boards while others, ready to use after buying, and where external flashing alone is a barrier to many. I did the work, still. That was untested even if that worked on my x200 that I wouldn't use for nothing else then booting stateless tails (the other side of Heads). But complied and did that work 3 times with nobody showing up as willing tester, answering in proper delays without PR bit rotting. I won't do this again.

Therefore, I wait for a basic PR to be created and give willing testers being board owners and interested into using those platforms (basic consent here, everyone should agree) a chance to learn how to fish (understand basics of Heads porting), as opposed to providing unlimited supplies of fish (without monetary compensation, without code contributions given back, without personal involvement in bringing those platforms supported: a never-ending impossible contract for any maintainer).

If you are not technical enough, then you can contribute in the downstream communities to find such board owner/willing tester who would consent to bringing that board supported upstream(create pull request), testing pull requests requiring testing because of the chances of changes bricking the platform, and then yiu, being an happy end user of such a platform.

I do not own all the platforms. I don't intend to own all the platforms, and I do not intend to test all the platforms myself.

This is why this is a community-driven project, with people having personal interests involving themselves into bring those boards supported enough to test important changes without end users risking to brick their machines following basic documentation guidelines, explaining how to flash, limitations of the platform, disassembling guide, unbricking guide and so on.

Does that make sense?

[tlaurion]

@fhvyhjriur i followed and this is amazing work.

A reminder: Heads project is community effort driven.

The general idea here is that a more technical board owner is responsible to try to learn how to port a coreboot existing and maintained upstream port to Heads. There are multiple examples of such boards in the current board directory, on which git blame feature (github permits to see this visually) will lead you to respective commits and pull requests where effort was made to bring those boards on Heads.

That board owner needs to be motivated at least minimally to engage in such port for his own personal or business interests. That board owner is then responsible to become a willing tester when important changes happen under Heads so that the pull requests, maybe causing regression or bricks as opposed to master are tested before merge.

The boards marked UNTESTED under the board directory will also link to pull requests that were untested by such previously responsible to test those boards by personal interests.

The unmaintained directory shows boards that were moved there because untested for way too long by interested board owners, requiring way too much time from me, the maintainer, to poke people around before merging pull requests, which otherwise are rebased, conflicts needing resolving etc. So they were loved to unmaintained until someone personally interested jumps in and is willing to collaborate into bringing that board back maintained and tested under Heads.

I have nothing against bringing platforms like without discrete TPM (dTPM) that would use Basic boot mode (not so relevant to be brought to Heads honestly, but if one is motivated to consent into testing in time, it will be maintained.

The same applies to any board. Including this proposition.

You lurked into Heads for a long time. You seem to have time. You seem to own many boards. But. You don't reply in time and don't seem to consent into testing in time in my prior efforts for the x200 etc. Therefore. I wait for a basic PR to be created and give a can to learn how to fish, as opposed to provide unlimited supplies of fish (without money compensation, without code contributions given back, without personal involvement into bringing those platforms supported.)

If you are not technical enough, then you can contribute in the downstream communities to find such board owner that would consent into bringing that board supported, test pull requests requiring testing because chances of bricking, and then be a happy user of such platform.

I do not own all the platforms. I don't intend to own all the platforms. And I do not intend to test all the platforms myself. This is why this is a community driven project, with people having personal interests involving themselves to bring those boards supported.

Does that make sense?
But yes, those boards are interesting and pertinent alternatives to Lenovo boards for all reasons you mentioned.

Now wainting for such board owner to be willing to resolve open issue with above mentioned social contract.