Need some guidance. Please read.
I am porting coreboot for a "Broadwell D 1519" based motherboard which has both Memory Down as well as 2 DIMM slots. Hence, I built an image for Facebook Watson since its the closest mainboard with no code changes. The call from FSP_FSP_INIT never returns to the ChipsetFspReturnPoint( ). Probably something crashed inside the FSP or something else.
This is possibly happening because I have passed no information regarding the RAM chips (down or DIMM) from romstage_fsp_rt_buffer_callback(). I have following 2 questions :
1. How can I see the default values for FSP UDP structure, so that I get to know what I need to modify? BCT tool does not dump that info.
2. In intel/soc/fsp_broadwell/ , the save_dimm_info() is done after FSP_FSP_INIT returns. Shouldn't the SPD details have been fetched before and passed to the FSP_FSP_INIT, as it is this API that handles the memory init.
This is to continue the discussion from the coreboot leadership meeting. Thunderbolt devices are not correctly initialized by Coreboot such that the OS can boot without kernel parameters and allow for Thunderbolt hotplugging. Additional bus numbers and memory must be allocated.
I will be working on support for this for our System76 mainboards.
Here were the notes taken about it during the meeting, see 9 October 2019, PCIe Hotplug on newer Intel socs:
As of 27th November and commit  platforms using AMD binaryPI blobs
have been disabled from automatic build testing. The following are
This is inline with CAR_GLOBAL_MIGRATION deprecation as mandated by
4.11 release requirements. You should expect that the board sources
and platform support will disappear by 14th December, at latest,
unless you show interest *and* are able to provide bootlogs for the
PCEngines APU2 and variants are an exception to this, they were
converted to POSTCAR_STAGE and work away from ROMCC_BOOTBLOCK shows
You'll know me as one of the driving forces keeping our i440BX port alive.
I did see the two latest patches trying to modernize it and I swear I'll
get to it soon, because to be honest, that P2B-LS board has a special place
in my mind and is not going away, although it is not seeing much use
anymore in practice, which brings me to my next step and question.
I have three more modern boards (read: 2012 and they share the same 16GB
pair of DDR3L memory modules) with cousins already in the tree but not the
exact model. I do know I need to get some info in, but I want to get a take
on which one will have the best chance to get a working port first:
Lenovo ThinkPad X230 Tablet. This is now my daily machine. Due to some
snafu on my part I bought a second unit with only Wacom pen but no touch.
The non-tablet X230 is in the tree and there were some notes on tablet
hardware. I need to buy a test clip to access the flash chip. Now I wonder
if this guy is "already" supported.
Asus M4A785TD-M EVO. AM3, family 10h, closest cousin was m4a785t-m, but I
don't know where it went now.
Asus P8Z77-M. Closest cousin is p8z77-m_pro. Mine is not pro, but I don't
know off my head what the difference is. And I get to deal with ME.
More info once I get back to my desktop.
Hot off the heels of the previous hotfix is a fresh release based on
the newly-tagged coreboot 4.11. In addition to being rebased on the
latest version of coreboot, this release features a host of
improvements and fixes:
* fixed issue with NVRAM being corrupted by Windows
* new/improved UEFI Boot Options/Settings screens
* improved header layout
* simplified menu options
* more descriptive naming for SATA, NVMe, and USB drives in boot menu
* easier to make changes to and save bootorder entries
* open-source coreboot native graphics init (libgfxinit) now used for
Haswell, Broadwell, and Skylake devices instead of closed-source GOP
* better scaling of boot splash/menus for HiDPI displays
This MrChromebox release offers coreboot/Tianocore images for close to
70 Chromebooks/Chromeboxes as well as all Purism Librem laptops, all
easily flashed using my ChromeOS Firmware Utility Script ; a full
list of supported devices can be found on my site .
All other devices supported by the coreboot 4.11 release can easily
take advantage of the improvements in my tree by cloning my coreboot
repo and building as usual.
All changes on the Tianocore side have already been merged and are
available to anyone using the default coreboot repo.
As usual, the full list of changes can be found on my github repos:
Could a Coreboot Coverity admin please re-run the scan against master?
Looks like the last analyzed version was from Sep 24, 2019. I would like
to see what AGESA issues remain.
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots
this is an attempt to improve firmware testing by using the
infrastructure and knowledge of the kernelci community. If you think
this is not the right place, please point me in the right direction.
I'm a coreboot developer trying to make sure that the master
branch doesn't regress. Currently there's no public firmware
testing, only internal validation suites used by some companies that
lack direct and automated feedback before a commit is actually merged.
As this isn't a coreboot only topic, but applies to all open source
"bios vendors", I added the u-boot project in CC as well.
For me firmware testing looks pretty similar to kernel testing:
* flash firmware to test
* boot a known good linux kernel
* run tests in userspace and verify hardware/software works as expected
On the hardware side we have boards in our lab that allow remote power
cycling and firmware flashing. It is attached to self hosted stock
LAVA2018. But as we are firmware engineers, we don't want to deal with
the administration of servers.
Here are a few questions for you:
* Would it make sense to also cover open source firmware tests on kernelci?
* Do you build the linux images yourself?
* Would you accept firmware images generated by a third party?
* Can anybody get an account for the LAVA server to run firmware test?
* What communication channels do you recommend?
* Will there be meetings or conferences to get in contact with the
community to talk about this?
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Phone: +49 234 / 68 94 188
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 13207
Geschäftsführung: Eray Basar, Sebastian Deutsch