Re: KGPE-D16 maintainership

[Insurgo Technologies Libres / Open Technologies]

On September 23, 2019 8:42:04 AM UTC, Arthur Heymans  wrote:
> Hi
>
> Thanks for wanting to maintain this platform!
>
> There are a issues with the amdfam10 codebase that could be improved
> upon. I'll try to list a few of them, to give an idea of what
> maintaining this code in 2019 could mean.

Awesome points, Arthur. Thanks a bunch!
> So first and foremost:
> The amdfam10 codebase (terminology-wise this always means non-agesa
>
> in this context) suffers from a romcc romstage past. This code is
> derived from code that used to be compiled with romcc instead of
> running
> in CAR. The result of that is a big amount of romstage boilerplate code
> and lots of #include *.c in the mainboard code, that is often not
> mainboard specific. To give an example romstage spinlocks and memory
> tests are implemented in the kgpe-d16 romstage.c file while not being
> mainboard specific at all. These practices result in an unusually large
> amount of unmaintained code in mainboard dirs with a fragile inclusion
> order of headers (and *.c files!).
>
> Other issues pertain to coreboot wanting to move forward by mandating a
> few features (relocatable ramstage, postcar
> stage/no_car_global_migration, c environment bootblock): 
> 2) relocatable ramstage: This is just a Kconfig switch to build the
> ramstage as a relocatable stage instead of statically linking it to
> execute at CONFIG_RAM_BASE. Typically you want to set up some caching
> of
> where cbmem is going to be to speed up ramstage, but on amd hardware
> it's bit more complicated. Part of ramstage is to initialize AP's and
> AP's
> will eventually jump to ramstage code. On AMD hardware however there is
> a TOP_MEM MTRR that creates a boundary between ram and mmio below 4G.
> If
> this is configured to be below cbmem AP's won't execute code. I see a
> few proper solutions:
> AP's are also active during the romstage -> try to sync MTRR's at the
>
> end of romstage.
> Use the parallel mp init code and modify the relocatable SIPI vector
>
> stub to have the MTRR's as arguments instead of a pointer to the BSP
> MTRR settings, in order to copy them.
>
> https://review.coreboot.org/c/coreboot/+/30063 is an atte

On my side, I'm committing to spin the need of support into Libreboot communities and open source forums and security trainings I do for organisation for self hosting needs.

I also commit of giving a margin of Insurgo profits following needs to cover part of the maintenance fees. Sorry to not have jumped in preciously, I'm crazy busy with Insurgo tasks and looking myself for collaboration to build a cooperative business platform and modify things so I can be completely replaceable into doing the whole production chain for the PrivacyBeast x230. Both from a Heads perspective and from a QubesOS perspective.

Let me know what I can do to help on a community basis and what are the costs to cover. I'll do my best.

Thanks a bunch for showing interest into keeping that platform alive.

Thierry/Insurgo

-- Sent from /e/ Mail