I'm trying to use coreboot on a custom board based on the stoneyridge AMD SOC. I'm
reusing the mainboard/amd/gardenia code. We have serial console and I've been able
to trace down to 'AmdInitPost(PostParams);' called from 'src/soc/amd/common/block/pi/agesawrapper.c'
to the responsible to make the board reset. Maybe we have some hardware problem related
to the DIMM area.
Then, there is some way to get some callback, trace, etc from the AGESA blackbox code? Any
chance to use the Integrated Debug Services (IDS)? Any recommendation to solve this?
This has been an issue since before AM2+, but AM2+ is when I first started
to deal with it. For AMD IOMMU does not fully work behind the DMI. If you
break out IOMMU from the CPU lanes You can generally get it working anyway
you want. But if you try and break out DMI attached devices (PCIE,
Onboard, other) the Groups are generally broken and do not work. Have tried
this with many HyperVisors and some will just give up the ghost after a
while due to sharing violations. So this is not exactly new and I wouldnt
expect a proper fix.
I tried force enabling IOMMU for ASUS AM1I-A by changing
" #define BLDCFG_IOMMU_SUPPORT FALSE "
to TRUE at ./src/mainboard/asus/am1i-a/buildOpts.c and adding
" device pci 0.2 on end # IOMMU "
line to ./src/mainboard/asus/am1i-a/devicetree.cb :
device domain 0 on
subsystemid 0x1043 0x8623 inherit
device pci 0.0 on end # Root Complex
device pci 0.2 on end # IOMMU
- because that's usually where AMD IOMMU PCI device resides.
However, even after doing that, I got " PCI: Static device PCI:
00:00.2 not found, disabling it. " Googling for other people's lspci
did not give any results for IOMMU at 16h Jaguar platforms. Then I
checked the datasheets at
- and discovered that Puma's datasheet contains a lot of IOMMU
references, while Jaguar's - only a few.
So: after 15h - which had IOMMU - this IOMMU has been temporarily
removed from early 16h Jaguar (except from a few related bits as
accidental leftovers), before being returned with late 16h Puma -
together with the appearance of AMD PSP! My wild guess is that AMD
needed some time to remake IOMMU for 16h to function together with AMD
PSP (Platform Security Processor), and maybe they intended to
implement PSP at early 16h as well - but it wasn't ready in time for
early 16h so they removed IOMMU from it too.
In any case, it seems that IOMMU is impossible at AM1I-A because it is
16h Jaguar. And I tested this on the latest available CPU for AM1
socket, ultra rare Athlon 5370 (slightly faster than Athlon 5350 but
no major differences). Hope this report helps to save some of your
I'm considering adding two M.2 22110 NVMe x4 SSD's in software RAID1 to
a D16 using one dual-M.2 adapter card. Most likely it would go in an x8
slot, I guess.
Does the D16 with blobless coreboot support simple PCI-e lane
bifurcation (x8 = x4 + x4)?
Or do I need an adapter card that has a PLX switch? Thanks!
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
---------- Forwarded message ---------
From: Matt B <matthewwbradley6(a)gmail.com>
Date: Mon, Jun 3, 2019 at 7:19 PM
Subject: Re: [coreboot] Re: Starting the coreboot 4.10 release process
To: Mike Banon <mikebdp2(a)gmail.com>
On a side note, when more than one option is possible, it's good to know
which the tester used.
Hypothetical example: did someone test the X230 with a vgabios blob or with
If unspecified, or if the default is the vgabiosblob (or nothing at all, as
above) then who knows if libgfxinit works?
On Mon, Jun 3, 2019 at 4:21 PM Mike Banon <mikebdp2(a)gmail.com> wrote:
> Okay, I returned your boards but added a note that "no board_status
> report yet". Hopefully you could submit them in the near future, at
> least for the archival purposes. And there's a similar question to
> someone else who added "Asus P8H61-M Pro" despite that the latest
> report for it is one year ago.
> > The default config should always be a known good config, unless the
> > board isn't well maintained. Needing a specific "good config" is a
> > sign of unattended bugs.
> Not necessarily: it could be that a default config is bootable for
> some board but still somehow inferior. For example, it may boot but
> without showing anything on a display, because no VGABIOS specified or
> provided. Or i.e. it may be hard to convince the people to enable some
> config by default despite it being useful, e.g. a coreinfo secondary
> payload. So board_status report is a great way to promote your nice
> config, and hopefully the people would share them more
> On Mon, Jun 3, 2019 at 5:28 PM Matt DeVillier <matt.devillier(a)gmail.com>
> > I added those devices, all of which I have in my possession and were
> tested over the weekend with TOT. I'd not yet had a chance to upload board
> status for them, but figured knowing a good range of platforms/boards were
> known working just prior to release was useful (and the purpose of the list)
> > On Mon, Jun 3, 2019 at 9:14 AM Mike Banon <mikebdp2(a)gmail.com> wrote:
> >> Just noticed that someone included i.e. some Purism Librem devices to
> >> a " Recently tested mainboards: " section - but, when I check
> >> https://review.coreboot.org/cgit/board-status.git/log/purism , the
> >> latest board status for Purism happened even before 4.9 ! And without
> >> a recent enough _public_ "board status" report - containing the
> >> important info about your build and its' complete configuration - I
> >> don't think we could include them to a "recently tested" list, since
> >> the other users won't have a chance to reproduce your build by using
> >> your configuration. Same question regarding some other of these
> >> additions, so removing them from a " Recently tested mainboards: "
> >> list, but of course they could be re-added if someone will submit a
> >> board_status reports from them.
> >> We would like to encourage the board status reporting, and relying on
> >> the word of users ( "I tested X board and it worked" ) would not help
> >> us to collect the known good configs at our coreboot/board_status
> >> repository.
> >> To submit a board status report for your board, please run a
> >> ./coreboot/util/board_status/board_status.sh script on it.
> >> Removed:
> >> * Purism Librem 13 v1
> >> * Purism Librem 15 v2
> >> * Purism Librem 13 v2/v3
> >> * Purism Librem 15 v3
> >> * Purism Librem 13 v4
> >> * Purism Librem 15 v4
> >> * Samsung Chromebook 3 (google/celes)
> >> * Acer Chromebook R11 (google/cyan)
> >> * Google Chromebook Pixel 2013 (google/link)
> >> * Toshiba Chromebook 2 (2014) (google/swanky)
> >> * Dell Chromebook 13 7310 (google/lulu)
> >> * Dell Inspiron Chromebook 14 (google/nami)
> >> * Acer Chromebook 14 (google/edgar)
> >> * HP Chromebook 13 G1 (google/chell)
> >> * Asus Chromebox CN60 (google/panther)
> >> * Asus Chromebox CN62 (google/guado)
> >> * Asus Chromebox CN65 (google/fizz)
> coreboot mailing list -- coreboot(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
In this thread https://firstname.lastname@example.org/thread/FTHN… we found a bug in seabios. Its choosing the wrong option rom in the case when for example on a Intel G41 board you have the internal Intel GPU and have added a external PCIe GPU. Then coreboot switches over to the external GPU for the graphical output but seabios use the option rom for the Intel G41 GPU. In case of x4x/G41 this results in no ability to have a graphical boot mode and thus its not possible to boot some linux live images.
In the linked thread a workaround is been found: "In the "Devices" menu of coreboot, set "Graphics initialization" to "None" ".
This breaks the functionality to have coreboot output with the internal GPU when you pull out the PCIe GPU. The switch should happen automaticly and without the need to recompile/reconfigure coreboot. Changes like https://review.coreboot.org/c/coreboot/+/18504 was made to make this happen.
Would be great if this seabios issue could be fixes.