On September 23, 2019 8:42:04 AM UTC, Arthur Heymans <arthur(a)aheymans.xyz> wrote:
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:
1) 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
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
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
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.
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.
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.
-- Sent from /e/ Mail