Thanks Peter,
It doesn't sound half as bad I feared it would, honestly. The way I see it, this is what I can and should do:
- Acquire the Ultra 40 M2 machine (just bite the bullet, as there's no other way around.), to be able to run the tests in a first place;
- Buy a couple of blank BIOS chips for that particular board, to use them for flashing various versions of coreboot BIOS images; if anything goes terribly wrong (workstation misbehaves, with any given coreboot image flashed), I can still use the computer with proprietary BIOS.
- Try with the last stable release, where my board is listed as supported (4.8?), then stick to it if all works well;
- Post the test results for functionalities (hmm, where . through mailing list ?), that were marked as >Untested</ >Not working</ >WIP<, as listed in the last update of the table, with a status summary of the board functionalities, or . ?
As you can see, I'm fumbling around and stumbling quite a bit, being overwhelmed by the maze of available information on one hand, and the lack of encouraging up-to-date hints and proofs for the future on the other hand. I suppose this is where the proverbial line >welcome to the moment< comes into play.
Kind regards,
Bostjan
Hi Bostjan,
On Thu, Jul 19, 2018 at 12:47 PM, Bostjan Kravcar via coreboot coreboot@coreboot.org wrote:
Thanks Peter,
It doesn't sound half as bad I feared it would, honestly. The way I see it, this is what I can and should do:
- Acquire the Ultra 40 M2 machine (just bite the bullet, as there's no other
way around…), to be able to run the tests in a first place;
- Buy a couple of blank BIOS chips for that particular board, to use them
for flashing various versions of coreboot BIOS images; if anything goes terribly wrong (workstation misbehaves, with any given coreboot image flashed), I can still use the computer with proprietary BIOS.
- Try with the last stable release, where my board is listed as supported
(4.8?), then stick to it if all works well;
- Post the test results for functionalities (hmm, where … through mailing
list ?), that were marked as »Untested«/ »Not working«/ »WIP«, as listed in the last update of the table, with a status summary of the board functionalities, or … ?
You've got the right idea :-)
For testing we use a script (board_status) that you can run on your test machine after successfully booting: https://www.coreboot.org/Board_Status.
The script will obtain some basic information (configs and logs) and upload it to a git repository. That info will be made publicly viewable at https://coreboot.org/status/board-status.html. As Peter mentioned, this is how we know that a board will work with a particular version of coreboot. Boards that do not get tested are eventually removed from the head of the master branch, though they are still available in the history and release branches.
This gives users a better idea of what boards are known to work in a given release, and helps developers to maintain and make progress on boards that are actively being tested and developed.
As you can see, I'm fumbling around and stumbling quite a bit, being overwhelmed by the maze of available information on one hand, and the lack of encouraging up-to-date hints and proofs for the future on the other hand. I suppose this is where the proverbial line »welcome to the moment« comes into play.
Welcome!
Please feel free to point out where things get confusing - It's really appreciated. Sometimes it's easy to overlook problems that newcomers face.
-
Bostjan Kravcar -
David Hendricks