Re: [coreboot] [URGENT] Full List of AMD-based boards that are going to be removed from coreboot unless people cough up a board status update
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/28/2018 02:37 PM, Mike Banon wrote:
Hi Mike,
PC Engines alix1c - AMD LX - 2017-09-17 PC Engines alix2d - AMD LX
- 2017-09-17 PC Engines apu1 - AMD Family 14h (AGESA) - 2017-09-05
PC Engines apu2 // apu3 // apu4 // apu5 - AMD 00730F01 (PI) - 2017-10-26
What is expected frequency of sending board status updates? We have all those board and even some awaiting port to coreboot.
We are committed to keep those platforms on the master but I'm not sure if I understand rules based on which platforms are planned for removal.
We maintain coreboot tree with customer specific customizations that will probably never lend in mainline, because of that we are rather interested to make coreboot work with PC Engines platforms on tagged releases and not exactly on any random commit in between. Any commit approach would require firmware validation automation which we will eventually have. So if release cycles take a lot of time then IMO delayed board status update should be allowed.
Second thing that IMO is problematic in board status is assumption that system have to boot with vanilla coreboot. This is problematic when you have to use customized version of SeaBIOS or any other payload used for booting system.
Because of long weekend we will send board status updates for boards under 3mdeb maintainership before 11 May. Please let me know if feel this is too late.
Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
This is a *personal* opinion, not supported by anyone else I suppose, but:
I don't think it's unreasonable to ask that people send in board status 2 times a year.
That's it. It makes it easier for potential users, and for people maintaining the tree.
Sound ok?
ron
Hi Piotr,
On 28.04.2018 15:16, Piotr Król wrote:
Second thing that IMO is problematic in board status is assumption that system have to boot with vanilla coreboot. This is problematic when you have to use customized version of SeaBIOS or any other payload used for booting system.
The payload doesn't matter. Only thing we'd care about is the coreboot revision that should be vanilla. Actually board status currently accepts any revision and rules weren't discussed, yet (another point why I don't think anything will happen because of missing board-status uploads).
Nico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 04/28/2018 03:48 PM, Nico Huber wrote:
Hi Piotr,
Hi Nico,
On 28.04.2018 15:16, Piotr Król wrote:
Second thing that IMO is problematic in board status is assumption that system have to boot with vanilla coreboot. This is problematic when you have to use customized version of SeaBIOS or any other payload used for booting system.
The payload doesn't matter. Only thing we'd care about is the coreboot revision that should be vanilla. Actually board status currently accepts any revision and rules weren't discussed, yet (another point why I don't think anything will happen because of missing board-status uploads).
If your payload version/repository is different you have to modify Makefile to build bootable coreboot.rom then you will get dirty tree.
If policy was not discussed, then I do not understand hype related to boards removal.
Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
On 02.05.2018 18:06, Piotr Król wrote:
On 04/28/2018 03:48 PM, Nico Huber wrote:
On 28.04.2018 15:16, Piotr Król wrote:
Second thing that IMO is problematic in board status is assumption that system have to boot with vanilla coreboot. This is problematic when you have to use customized version of SeaBIOS or any other payload used for booting system.
The payload doesn't matter. Only thing we'd care about is the coreboot revision that should be vanilla. Actually board status currently accepts any revision and rules weren't discussed, yet (another point why I don't think anything will happen because of missing board-status uploads).
If your payload version/repository is different you have to modify Makefile to build bootable coreboot.rom then you will get dirty tree.
I don't see that. You can always build your payload separately and add it with CONFIG_PAYLOAD_ELF.
If policy was not discussed, then I do not understand hype related to boards removal.
What I tried to say more subtly earlier, the hype is pure bullshit.
Nico
-
Nico Huber -
Piotr Król -
ron minnich