coreboot June 2019

coreboot@coreboot.org

56 participants
49 discussions

Debugging AGESA black box
by Jorge Fernandez Monteagudo 25 Jun '19

25 Jun '19

Hi all, 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? Thanks!

1 0

New on blogs.coreboot.org: [GSoC] Debug Bootblock Stage for ARMv8 on QEMU
by blogs.coreboot.org 24 Jun '19

24 Jun '19

1 0

Re: AM1I-A and other 16h Jaguar boards cant have a working IOMMU
by Sirsquishy 21 Jun '19

21 Jun '19

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.

2 1

AM1I-A and other 16h Jaguar boards cant have a working IOMMU
by Mike Banon 21 Jun '19

21 Jun '19

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 chip northbridge/amd/agesa/family16kb 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 https://en.wikipedia.org/wiki/Puma_(microarchitecture)#External_links - 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 time. Best regards, Mike Banon

3 3

New on blogs.coreboot.org: [GSoC] Coreboot Coverity, week 4
by blogs.coreboot.org 20 Jun '19

20 Jun '19

1 0

Porting to a new board
by Jorge Fernandez Monteagudo 20 Jun '19

20 Jun '19

Hi all, We're developing a new board based in the AMD Prairie Falcon and the closest coreboot is from amd/gardenia. We're using coreboot verion 4.9. Now we have console but we have a reset loop once the 'AmdInitPost' from src/soc/amd/common/block/pi/agesawrapper.c is called. I've modified the smbus_spd.c to display the SPD content. This is the log we get: coreboot-4.9-7f520c8fe6fc991df2c4e91f42843d4290744ebb Thu Jun 20 13:05:42 UTC 2019 bootblock starting... Family_Model: 00670f00 PMxC0 STATUS: 0x8000800 SyncFlood BIT11 CBFS @ 200 size 7ffe00 CBFS: 'Master Header Locator' located CBFS at [200:800000) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 6d04 coreboot-4.9-7f520c8fe6fc991df2c4e91f42843d4290744ebb Thu Jun 20 13:05:42 UTC 2019 romstage starting... CBFS @ 200 size 7ffe00 CBFS: 'Master Header Locator' located CBFS at [200:800000) CBFS: Locating 'smu_fw' CBFS: Found @ offset bdc00 size 12262 PSP: Load blob type 19 from @ff8bde38... OK POST: 0x37 agesawrapper_amdinitreset() entry CBFS @ 200 size 7ffe00 CBFS: 'Master Header Locator' located CBFS at [200:800000) CBFS: Locating 'AGESA' CBFS: Found @ offset 5ffdc0 size 662d4 agesawrapper_amdinitreset() returned AGESA_SUCCESS POST: 0x38 agesawrapper_amdinitearly() entry Warning - AGESA callout: platform_PcieSlotResetControl not supported Warning - AGESA callout: platform_PcieSlotResetControl not supported Warning - AGESA callout: platform_PcieSlotResetControl not supported Warning - AGESA callout: platform_PcieSlotResetControl not supported agesawrapper_amdinitearly() returned AGESA_SUCCESS POST: 0x40 agesawrapper_amdinitpost() entry DRAM clear on reset: Keep WEAK: src/soc/amd/stoneyridge/BiosCallOuts.c/mainboard_read_spd called -------------READING SPD----------- iobase: 0x00000B00, SmbusSlave: 0x000000A4, count: 512 23 11 0C 02 85 21 00 08 00 60 00 03 01 03 00 00 00 00 06 0D F8 FF 01 00 6E 6E 6E 11 00 6E F0 0A 20 08 00 05 00 A8 18 28 28 00 78 00 14 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 36 16 36 16 36 16 36 00 00 16 36 16 36 16 36 16 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9C 00 00 00 00 00 E7 00 9E 78 11 01 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 53 23 11 0C 02 85 21 00 08 00 60 00 03 01 03 00 00 00 00 06 0D F8 FF 01 00 6E 6E 6E 11 00 6E F0 0A 20 08 00 05 00 A8 18 28 28 00 78 00 14 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 36 16 36 16 36 16 36 00 00 16 36 16 36 16 36 16 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9C 00 00 00 00 00 E7 00 9E 78 11 01 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 53 -------------FINISHED READING SPD----------- And again... We only have one dimm connected, the A4. Is defined in devicetree.cb register "spd_addr_lookup" = " { { {0xA4, 0x00} }, // socket 0 - Channel 0, slots 0 & 1 }" and I've modified OemCustomize.c to set #define DIMMS_PER_CHANNEL 1 Attached is the .config I'm using... What can I check now? Any suggestion is welcome!

1 0

New on blogs.coreboot.org: [GSoC] Ghidra firmware utilities, week 4
by blogs.coreboot.org 18 Jun '19

18 Jun '19

1 0

ASUS KGPE-D16 PCI-e lane bifurcation
by U'll Be King Of The Stars 18 Jun '19

18 Jun '19

Hi all, 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! Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9

1 0

Fwd: Re: Starting the coreboot 4.10 release process
by Matt B 18 Jun '19

18 Jun '19

---------- 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 libgfxinit? If unspecified, or if the default is the vgabiosblob (or nothing at all, as above) then who knows if libgfxinit works? -Matt 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> > wrote: > > > > 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 >

2 1

BUG: Seabios choose the wrong option rom when two are available
by akjuxr3＠dismail.de 17 Jun '19

17 Jun '19

In this thread https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.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. Thanks!

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2019