coreboot September 2019

coreboot@coreboot.org

52 participants
37 discussions

Trying to check potential compatibility of intel server board
by Matt B 29 Sep '19

29 Sep '19

Hello, I'm trying to check the potential compatibility of the s1200kp intel server board. [1] It's mini-itx and supports ECC ram, making it attractive for use in a NAS device. (cases with multiple hotswap bays and room for an itx board abound, but few itx boards have ECC capability) The chipset is listed as the C206, which is part of cougar point. The socket is FCLGA1155 and I've seen the board with an i3-3220 (3rd gen ivy bridge). However, I'm having a really hard time finding information … [View More]

4 4

(no subject)
by Matt B 29 Sep '19

29 Sep '19

Hello, Shifting away from the focus of [1] I'm interested in how hard it would be to port coreboot to the AM1M-A. This board seems to be a larger version of the supported AM1I-A and is known to officially support ECC. (the manuals for the AM1I-A [2] and AM1M-A [3]) The porting guide at [4] is very detailed on information gathering but is scant on details when it comes to making changes. (see "Adjusting the contents of the new board directory") I have the opportunity to obtain this board … [View More]

1 0

Aspirant for contributing to coreboot project during google summer of code 2020
by Ajay Paddayuru Shreepathi 28 Sep '19

28 Sep '19

Hi, I am Ajay, pursuing my Master's in Computer Science at Stonybrook university, NewYork. I am interested in OS, Firmware, Compiler development and also being part of open source community. I would like to understand coreboot project and contribute to the project during GSOC 2020. As a part of preparation, I would like to know how can I go about understanding and contribute to coreboot project? Thank you, Ajay Paddayuru Shreepathi

1 0

Fixing Hidden PCI devices on Intel common SoCs
by Matt DeVillier 28 Sep '19

28 Sep '19

Commit 903b40a [soc/intel: Replace uses of dev_find_slot()] replaced calls to dev_find_slot() with calls to pcidev_path_on_root() for all Intel common SoCs, but it seems unclear exactly what problem this was intended to fix, and has created problems with locating hidden PCI devices. Commit f2ac0137 [soc/intel: Fix regression with hidden PCI devices] fixed this partially by creating a debug version of pcidev_path_on_root() which falls back on dev_find_slot(), but did not apply it to all devices … [View More]

6 13

Re: KGPE-D16 maintainership
by Insurgo 28 Sep '19

28 Sep '19

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 … [View More]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.krol(a)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 [View Less]

1 0

ASUS AM1I-A and AM1M-A, ECC
by Matt B 26 Sep '19

26 Sep '19

Greetings, The AM1I-A [1] is supported by Coreboot, while the AM1M-A [2] is not. The latter seems to be a larger version of the first, with more expansion options. For the smaller 'I' not much is stated in the manual [3] except to check the "qualified vendor list" on ASUS' site. It does list sizes for unbuffered, non-ecc memory though. I've also read from people testing it that the board doesn't post with ECC installed under the proprietary bios. According to the manual [4], the larger board … [View More]

3 6

Comet Lake FSP Released
by Desimone, Nathaniel L 26 Sep '19

26 Sep '19

Hi All, Intel is pleased to announce that Comet Lake FSP is now available on https://github.com/IntelFsp/FSP. With Best Regards, Nate

1 0

Beaglebone Black support
by Vijai Kumar K 25 Sep '19

25 Sep '19

Hi All, I see that we can build coreboot for Beaglebone. Has anyone successfully booted it. I copied over the MLO generated but no logs on UART. Any help is appreciated. BTW, I have a BBB RevC. Thanks, Vijai Kumar K

1 0

HP-Compaq DC7700CMT
by garablaszlo21＠gmail.com 24 Sep '19

24 Sep '19

Hello, I have overflashed my machine and bought a second one to copy the BIOS onto the first one. Unfortunatelly, it does not work because of the serial numberization of the BIOS and hardware. Additionally, the mainboard has some damage, too. HP does not give any support, probably because they do not want to develop the issue; so I can see to install anything on the machine as of they do not respond. I can see as the only and best solution is using coreboot: it is public, no strictions, I can … [View More]

4 4

Re: KGPE-D16 maintainership
by Insurgo Technologies Libres / Open Technologies 23 Sep '19

23 Sep '19

On September 23, 2019 8:42:04 AM UTC, Arthur Heymans <arthur(a)aheymans.xyz> 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: >1) The amdfam10 codebase (terminology-wise this always means non-agesa >in … [View More]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 [View Less]

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2019