On 9/23/19 4:42 AM, 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. > > 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 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 attempt to make it > work but by setting TOP_MEM to something sufficiently large... > > 3) Postcar-stage: This development goes hand in hand with relocatable > ramstage, as it easily allows to program MTRR's to set up caching cbmem. > If you tearing down CAR during romstage you need to take special care > for where you're globals are (before and after CAR). Tearing down CAR in > a separate stage, hence having a romstage with a clean program boundary, > as a solution allows to get rid of a lot of code to deal with globals. > > https://review.coreboot.org/c/coreboot/+/30064/ is an attempt to > implement it on amdfam10 > > 4) C_ENVIRONMENT_BOOTBLOCK: romcc is an unmaintained 20k+ lines of C > code in one file program, that imposes some restrictions and workarounds > in C code. On older platforms it is used to compile a bootblock that > often does nothing more than loading {normal,fallback}/romstage. The CAR > setup happens at the start of romstage. The alternative is to move the CAR > init to the bootblock and compile the bootblock with gcc. One big > functional advantage is the ability to have a separate verstage running > in CAR before romstage. This broadens the scope of what can be placed in > RW_A/B slot in a VBOOT setup. > > 5) a few minor things: coreboot often has multiple methods of achieving > more or less the same things, with newer methods being better in some > aspects. It would be great if: > - for saving the raminit timings the drivers/mrc_cache code was used > instead of the custom implementation in > northbridge/amd/amdmct/mct_ddr3/s3utils.c > - for AP init CONFIG_PARALLEL_MP were used instead of the old > cpu/x86/lapic/lapic_cpu_init.c code. > - A stage cache were set up in TSEG to ensure the OS can't trash the > ramstage in cbmem on S3 resume. > > > I hope this list provides some useful pointers to where to code can be > improved. Feel free to add me on reviews. Thanks Arthur, awesome inputs. > > > Piotr Król <piotr.k...@3mdeb.com> writes: > >> Hi all, >> we see a lot of attention around KGPE-D16 maintainership problems. >> After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb >> decided to help in maintaining that platform by organizing crowd >> founding campaign or getting founds in other ways (direct sponsors). >> >> Since we are based in Poland there is chance that even with small >> contribution from community we would be able to cover the costs. >> >> Ideal plan would be to have structure similar to what we maintain for >> PC Engines: >> https://pcengines.github.io/ >> Where we providing signed and reproducible binaries every month and >> keep as close to mainline as possible. Of course if development will >> be active, then there always would be delta of patches held in review. On my side, I'm committing to spin the need of support into Libreboot communities, open source privacy forums and in the real world in security trainings I do for organizations in the goal of promoting higher security of self hosting facilities. They will be interested, let's see in which extend.
I'm also committing in giving a margin of Insurgo profits following needs to cover part of the maintenance fees. Sorry to not have jumped in preciously (mail got blocked and never reached mailing list). I'm crazy busy with Insurgo's tasks, while also looking into international collaboration into building a distribution cooperative and my board of directors, modify Heads/QubesOS so I can be completely removable as a trustable disk image source so that the whole production chain for the PrivacyBeast x230 and other models can be completely distributed, reproducible while having their integrity verified by the user upon reception. Let me know what I can do to help on a community basis and maintenance costs to cover. I'll do my best. Thanks a bunch for showing interest into keeping that platform alive. You may be interested in bringing this ticket into the attention of people being knowledgeable enough to make u-bmc work into the AST2050 iKVM board: https://github.com/u-root/u-bmc/issues/133 Regards, Thierry/Insurgo >> > This looks very neat indeed! > > Kind regards > > Arthur Heymans _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
