I have come across a puzzling issue with my EARLY_CBMEM_INIT work.
This now normally works and can boot all the way into Linux, but if I
detach all hard drives so seabios have nothing to boot from, after it
forces a hard reset and coreboot restarts, it would fail to decompress
the ramstage and hang.
Attached is a boot log of the issue on asus/p2b-ls, but I also tested
on asus/p3b-f and have the same problem.
On 10.08.2017 16:36, Zheng Bao wrote:
> Thanks. Your advice is quite helpful.
> I got the BMP and BSF, created a vBIOS which enables the DDI2 as DP. The vBIOS has been
> validated by IBV(AMI) BIOS.
> But the VBIOS can not enable DDI2 in Coreboot. I assume I still miss something.
There used to be a priority list which display is preferably initia-
lized. It was in a weird notation LFP (local flat panel) would be
the eDP port and EFP2 (external flat panel 2) might be DDI2. Some-
where you have to set that EFP2 is preferred, I suppose. (All what
I remember from an Ivy Bridge VBT.)
> From: Nico Huber <nico.h(a)gmx.de>
> Sent: Wednesday, August 9, 2017 6:29 PM
> To: Zheng Bao; coreboot(a)coreboot.org
> Subject: Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?
> On 08.08.2017 05:39, Zheng Bao wrote:
>> In text mode,
>> only one display can be enabled.
>> Can this enabled display port be DDI1 or DDI2?
>> I just extracted VBIOS from BIOS provided on board. I assume the display ports are enabled based on the board settings.
>> Can I just set register "gpu_panel_port_select" = "2" to enable DDI1?
> No, unfortunately not. This setting only affects the panel power sequen-
> cer (i.e. which port needs special care because it hosts a panel whose
> power is controlled by us). It shouldn't affect the VBIOS.
> Again, the VBIOS has many options, set in the binary. I know free tools
> to dump them partially, but none to set them. The regular way is to ask
> Intel for their Binary Modification Program (BMP, may be compatible with
> Intel's Binary Configuration Tool ) *and* a description file for the
> Video BIOS Table format (.bsf IIRC). That .bsf file is specific to the
> chipset generation (I can't find one for Broadwell, sadly), though, one
> for another generation might work too. Sometimes these files can be
> found in graphics driver packages or FSP .
> If you happen to get the Intel tool running, I advice to double check
> the result in a hex editor (e.g. there should be only the change you
> made, plus about two checksums).
>  https://github.com/IntelFsp/BCT
> GitHub - IntelFsp/BCT: Binary Configuration Tool for Intel ...<https://github.com/IntelFsp/BCT>
> BCT - Binary Configuration Tool for Intel(R) FSP
>  Here is one for Kabylake (the closest I could find, might be
> incompatible though):
> Repository of FSP binaries posted by Intel
On 09/08/2017 02:12 AM, Iru Cai wrote:
> On Fri, Sep 8, 2017 at 2:02 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>> On 09/08/2017 12:44 AM, Iru Cai wrote:
>> On Fri, Sep 8, 2017 at 11:42 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>>> On 09/07/2017 11:21 PM, Iru Cai wrote:
>>>>> I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI
>>>>> USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
>>>>> video card and the LSI 1394a controller. I try to pass them all to a VM,
>>>>> but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.
>>>>> Does anyone with KGPE-D16 have this problem?
>>>>> You are attempting to pass the primary video device to a VM which hardly
>>>> ever works, I tried the same thing and it didn't work (I wanted my PCI
>>>> sound card in the VM, and as PCI doesn't support ACS and all the PCI
>>>> devices on the D16 are behind the same bridge they are in the same IOMMU
>>>> group so I had to do that - I ended up buying a USB sound adapter)
>>>> Now I'm using GTX 650 as my primary video device and not using the on
>>> ASpeed video card.
>>> Also I tried to pass the onboard USB controller to the VM, and also
>>> the kernel.
>> Damn :[
>> FYI you forgot to reply all - please re post this to the list :]
>> Hmm can I have dmesg logs and your libvirt or w/e VM config files? for the
>> new config you are trying.
>> I am playing games right now with my pass thru usb ports.
> So are you using vfio-pci or pci-stub? I don't know if I can use pci-stub
> in libvirt, but vfio-pci will require all devices
> in an IOMMU group passed to a VM, and I don't use a modded kernel.
I pass thru my video card, an onboard nic and an onboard usb controller
(all three usb subdevices) - works great and they're all in their own
Julius Werner <jwerner(a)chromium.org> writes:
>> The error is fixed by commit
>> 54fd92bc (util/cbfstool/lz4frame.c: Add comment to fall through).
> Looks like I'm too late for that commit, but in general, please do not
> just hack around in the LZ4 files. That code was pulled in verbatim
> from the upstream source -- if there are issues with it, please
> instead send a patch to https://github.com/lz4/lz4 and resync our code
> base to there once it has landed.
 Tried to update lz4 files but needed the same 'fix' for gcc7
(comment was 'pass-through' instead of 'fall-through'), so it
was dropped in favor . It looks like version 1.8.0 has the proper
"falls trough" comment to make gcc7 happy...
 https://review.coreboot.org/#/c/20011/ "util/cbfstool: Update lz4 to
 https://review.coreboot.org/#/c/20036/ "util/cbfstool/lz4frame.c:
Add comment to fall through"
1. building 4.6 gives build error
$ make crossgcc-x64 BUILDGCC_OPTIONS=-b CPUS=16
/nocow/t/coreboot-4.6/util/cbfstool/lz4/lib/lz4frame.c: In function 'LZ4F_decompress':
/nocow/t/coreboot-4.6/util/cbfstool/lz4/lib/lz4frame.c:1092:33: error: this statement may fall through [-Werror=implicit-fallthrough=]
dctxPtr->dStage = dstage_storeHeader;
/nocow/t/coreboot-4.6/util/cbfstool/lz4/lib/lz4frame.c:1095:9: note: here
cc1: all warnings being treated as errors
util/cbfstool/Makefile.inc:133: recipe for target 'build/util/cbfstool/lz4frame.o' failed
make: *** [build/util/cbfstool/lz4frame.o] Error 1
2. built from git master (588ccaa9), crossgcc without -b this time as
the build didn't complain about it. seabios doesn't detect my hard
drive. I have an older coreboot seabios build that does, so it's
probably a software issue.
3. building 4.5 gives build error
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
I can probably figure that out but if someone knows off the top of their
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
On 09/10/2017 01:04 PM, Kyösti Mälkki wrote:
Hi Kyösti, Alberto,
> At this very moment apu2/apu3 4GB models are marketed without ECC
> support. Latest available binaryPI build (which contains a fix for
> ECC) is otherwise not compatible. You can thank AMD for not even
> allowing their commercial customers, who have access to said PI
> sources under NDA, to distribute fixed builds.
We planned get back to ECC issue in coming month by exercising 2 ideas
from forum :
1. Mentioned by Kyösti usage of UEFI payload and MemTest86 v7 Pro
Edition. I already started work on payload  and have ability to
boot to UEFI shell, but now working storage drivers yet.
2. Use rowhammer_test mentioned in last post .
But it looks I completely forget mentioned bug. I assume above
scenarios will not work in light of mentioned bug ?
We know which version of AGESA breaks apu2/3. It is . We tried to
disable graphics in various ways, but nothing helps.
@Kyösti, maybe it is related to PspMboxBiosCmdDramInfo and
PspMboxBiosCmdExitBootServices commands and PSP support in coreboot ?
Embedded Systems Consultant
https://3mdeb.com | @3mdeb_com
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
On Sun, Sep 10, 2017 at 1:53 PM, Alberto Bursi <alberto.bursi(a)outlook.it> wrote:
> On 09/07/2017 01:24 PM, Kyösti Mälkki wrote:
>> On Thu, Sep 7, 2017 at 1:40 PM, Nico Huber <nico.h(a)gmx.de> wrote:
>>> Hello Alberto,
>>> On 09/06/2017 09:30 PM, Alberto Bursi wrote:
>>>> I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based
>>>> "industrial" mini-itx motherboard) on ebay and since it is supported by
>>>> Coreboot I was considering about purchasing it.
>>>> The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can
>>>> find them), while of course the Asrock site does not say anything about
>>>> ECC support (how unexpected).
>>> it's rather unlikely that a board supports it when the manufacturer
>>> doesn't mention it. ECC support needs additional traces on the main-
>>> board (as the bus is 72 bits wide instead of 64 bits). So just having
>>> compatible chips doesn't suffice.
>> See JEDEC Module 4.20.18 vs 4.20.21 standards.
>> SODIMM 204-pin socket pinout for 64bit non-ECC vs 72bit ECC is already
>> Some ground pins have been sacrificed to fit those extra ECC bits in the socket.
>> In other words: no amount of open source will give you ECC SO-DIMM support when
>> PCB was designed otherwise.
>> That board is one of eKabini reference desings, schematics check tells me ECC
>> pins of the APU SOC part are not connected.
> Thanks a lot for the information! :)
> I had some suspicions about socket/board support too as I think also
> DIMMs have the same issue.
> Since I really wanted ECC capability, I'll probably get a PCEngines APU
> with 4GB of RAM, which was designed for ECC and seems to have it enabled
> in their stock firmware (coreboot-based) from the feedback I saw.
> From the schematics https://pcengines.ch/schema/apu2c.pdf it seems they
> have one screen port connected to a pinout on the board, although stock
> firmware disables it to use less power. Can do without screen too if I
> can't hack it, it's main usage will be network infrastructure anyway.
> Was just a nice bonus.
At this very moment apu2/apu3 4GB models are marketed without ECC support.
Latest available binaryPI build (which contains a fix for ECC) is otherwise not
compatible. You can thank AMD for not even allowing their commercial customers,
who have access to said PI sources under NDA, to distribute fixed builds.
There is no display support.
On 09/07/2017 01:24 PM, Kyösti Mälkki wrote:
> On Thu, Sep 7, 2017 at 1:40 PM, Nico Huber <nico.h(a)gmx.de> wrote:
>> Hello Alberto,
>> On 09/06/2017 09:30 PM, Alberto Bursi wrote:
>>> I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based
>>> "industrial" mini-itx motherboard) on ebay and since it is supported by
>>> Coreboot I was considering about purchasing it.
>>> The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can
>>> find them), while of course the Asrock site does not say anything about
>>> ECC support (how unexpected).
>> it's rather unlikely that a board supports it when the manufacturer
>> doesn't mention it. ECC support needs additional traces on the main-
>> board (as the bus is 72 bits wide instead of 64 bits). So just having
>> compatible chips doesn't suffice.
> See JEDEC Module 4.20.18 vs 4.20.21 standards.
> SODIMM 204-pin socket pinout for 64bit non-ECC vs 72bit ECC is already
> Some ground pins have been sacrificed to fit those extra ECC bits in the socket.
> In other words: no amount of open source will give you ECC SO-DIMM support when
> PCB was designed otherwise.
> That board is one of eKabini reference desings, schematics check tells me ECC
> pins of the APU SOC part are not connected.
Thanks a lot for the information! :)
I had some suspicions about socket/board support too as I think also
DIMMs have the same issue.
Since I really wanted ECC capability, I'll probably get a PCEngines APU
with 4GB of RAM, which was designed for ECC and seems to have it enabled
in their stock firmware (coreboot-based) from the feedback I saw.
From the schematics https://pcengines.ch/schema/apu2c.pdf it seems they
have one screen port connected to a pinout on the board, although stock
firmware disables it to use less power. Can do without screen too if I
can't hack it, it's main usage will be network infrastructure anyway.
Was just a nice bonus.
Dear coreboot folks,
Am Mittwoch, den 23.08.2017, 20:42 -0600 schrieb Aaron Durbin:
> On Wed, Aug 23, 2017 at 8:31 PM, Kyösti Mälkki <kyosti.malkki at gmail.com> wrote:
> > On Thu, Aug 24, 2017 at 12:29 AM, Taiidan at gmx.com <Taiidan at gmx.com> wrote:
> > > Ah I see thanks for explaining.
> > >
> > > I had read all the AGESA boards were going to be removed, besides the asus
> > > D8/D16 those are the last and best owner controlled x86 boards.
> > > Is there a current list of boards to be removed?
> > The work for LATE -> EARLY CBMEM transition for AGESA has been
> > available for review since February 2017. It's probably announced or
> > mentioned only briefly on the mailing list, but certainly very visible
> > on gerrit.
> > Unfortunately people currently working on AMD platforms did not show
> > much interest to review that work. Luckily, devs from chromeos team
> > (who had no commercial interest, but maybe strings attached) stepped
> > in the reviews so that the groundwork of AGESA interface changes got
> > done and reviewed. What's left is merging the individual board
> > changes, which I am about to do very soon now. Some regressions
> > expected, most of the old defects remain unfixed.
> > I should thank the couple individuals and companies that contributed
> > by covering some costs of this development. Still, that does not
> > magically turn all these boards into status of "maintained".
> > Now, this applies to everyone: please push status updates for the
> > boards you have access to, otherwise majority of AGESA boards just hit
> > that deprecation in the next cycle of board removals. Also, when you
> > create a board port and you go through all the trouble of getting it
> > past (my strict or someone else's less strict) review policy, is it
> > REALLY that hard to run board_status script? You know who you are. Is
> > there something we need to do better here? Provide OS boot images just
> > for this purpose?
> > As for binaryPI boards, those are at EARLY_CBMEM_INIT starting from August 2.
> > As for K8/K10, your help is needed in testing. This is particularly
> > for boards with multiple CPU packages (nodes).
> I do want to thank Kyösti for putting in the development effort in
> this area for these platforms. He's been actively maintaining and
> developing for a lot of platforms that have lost some love over the
> years. I know there are others who contribute as well, but I did want
> to call attention Kyösti's contribution as I've been following it
> fairly closely. It's very much appreciated.
I can only second that. I like to remind a lot of the coreboot users
out there to get in contact with the coreboot developers doing the work
for your board, and ask them how you can support them. Some of them
accept donations. Some can even give you invoices.
So please, support free software, and “pay for it” to keep the freedom
free software gives you.