coreboot September 2017

coreboot@coreboot.org

57 participants
132 discussions

Need help troubleshooting a cbmem init issue

by Keith Hui

Hi guys, 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. Any ideas? Thanks Keith

3 years, 1 month

Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?

by Nico Huber

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.) Nico > > > Zheng > > ________________________________ > 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 [1]) *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 [2]. > > 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). > > Nico > > [1] https://github.com/IntelFsp/BCT > [https://avatars1.githubusercontent.com/u/19785541?v=4&s=400]<https://github.com/IntelFsp/BCT> > > GitHub - IntelFsp/BCT: Binary Configuration Tool for Intel ...<https://github.com/IntelFsp/BCT> > github.com > BCT - Binary Configuration Tool for Intel(R) FSP > > > [2] Here is one for Kabylake (the closest I could find, might be > incompatible though): > > https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCode/… > [https://avatars1.githubusercontent.com/u/19785541?v=4&s=400]<https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCode/…> > > IntelFsp/FSP<https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCode/…> > github.com > Repository of FSP binaries posted by Intel > > >

3 years, 1 month

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

3 years, 1 month

Re: [coreboot] KGPE-D16 PCI passthrough

by Taiidan＠gmx.com

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: >>>> Hi, >>>> >>>>> I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI >>>>> to >>>>> 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? >>>>> >>>>> Iru >>>>> >>>>> 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 >>> board >>> ASpeed video card. >>> >>> Also I tried to pass the onboard USB controller to the VM, and also >>> crashed >>> 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. VFIO-PCI 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 iommu group.

3 years, 1 month

Re: [coreboot] Problems building coreboot 4.6

by Arthur Heymans

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. [1] 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 [2]. It looks like version 1.8.0 has the proper "falls trough" comment to make gcc7 happy... [1] https://review.coreboot.org/#/c/20011/ "util/cbfstool: Update lz4 to 1.7.5" [2] https://review.coreboot.org/#/c/20036/ "util/cbfstool/lz4frame.c: Add comment to fall through" Kind regards -- Arthur Heymans

3 years, 1 month

problems with kgpe-d16

by Ian Kelling

1. building 4.6 gives build error $ make crossgcc-x64 BUILDGCC_OPTIONS=-b CPUS=16 $ make ... HOSTCC cbfstool/lz4hc.o HOSTCC cbfstool/lz4frame.o /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 case dstage_storeHeader: ^~~~ 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 their locations. I can probably figure that out but if someone knows off the top of their head. -- 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

3 years, 1 month

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

by Piotr Król

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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]: 1. Mentioned by Kyösti usage of UEFI payload and MemTest86 v7 Pro Edition. I already started work on payload [2] and have ability to boot to UEFI shell, but now working storage drivers yet. 2. Use rowhammer_test mentioned in last post [1]. 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 [3]. 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 ? [1] http://pcengines.info/forums/?page=post&id=E35B5D34-262B-480E-9887-F7F2A 292E02F&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A&pageindex=2 [2] https://github.com/3mdeb/edk2/tree/apu2-uefi [3] https://review.coreboot.org/cgit/blobs.git/commit/?id=95b80508d9ba26350b 7e699decd47074f480a2f2 - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlm1l1wACgkQsu5x6Weq nkx5/Q//RUzYOC+9wkXzUbSPt05kEMS3F7bKciTQwUtaLzkkuIUCOuuXy5tGqqfc zWJmyGYzC/XceiWFdNI4+GqAdxssMNmnyh8PYlpR2IilbF8XFmPjwO6DUEIw2fkh T4J1pGxt+rl1Mj8vAShbN8BNM23GDMJRTBWPBNscnf34CrxZMwkNMblaW2AoqCdv COQSnHWgq3qNMtDhm6ig7ORiagSkNnn3OUk7XCsCw/cOPnMY6FsD3MspZIvRAU+6 mhPN7LMZIg1y59xnb7Ivdo/BgZyUs/L2rJ1dbnkUUwiei/jr82toEpE1+4ko55Q5 B2CVPvoYoBeQyE9qc53nWk694M86Qghi7cTpQSyI9CIWQPfxS0K5n16CSNJ8AYNN BLw5tMQxXw/ViLLGahIHPzDcYrGK3/j2T+mc4yD7xctcgZwXOc3jzYD4aZnqwRxl L66s2x9Tgpa6Iff8XX14raIwzmg3jvpLbTMoe6yP4zbjioyi7XUy/yuNmIJb40Qt Dbjo88u22AsQt+onsVKYRyqtXR2J2dVLi1za0dqNKDjKKomdvDk9NeV0c3aoQ403 WeV1Ma6I7cNxdbMgCmvprKmaRzlLJHTn8inHDlkifzs2w6DRnXpUY2gpTorhkqM8 1ok2M4wFUrspzB8ql21e+XFRJeFr59dVqLR65IMscr7Pxn2DQlM= =GAjv -----END PGP SIGNATURE-----

3 years, 1 month

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

by Kyösti Mälkki

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 >> different. >> 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. >> >> Kyösti > > 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. > > -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. There is no display support. Kyösti

3 years, 1 month

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

by Alberto Bursi

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 > different. > 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. > > Kyösti 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. -Alberto

3 years, 1 month

Support coreboot freelance developers (was: How is depreciating 95% of coreboot boards worth it for such minor improvements?)

by Paul Menzel

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. Thanks, Paul

3 years, 1 month

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2017