December 2018 - coreboot - mail.coreboot.org

Re: [coreboot] INTEL BCT tool fails to start!
by Desimone, Nathaniel L Dec. 10, 2018

Dec. 10, 2018

Hi Zoran, Intel just released a new version of BCT v3.4.0 that supports new distros, hope that helps. https://github.com/IntelFsp/BCT Regards, Nate

1 0

Re: [coreboot] Asus KGPE-D16 non-working S3 suspend with Qubes 4
by Peter Stuge Dec. 10, 2018

Dec. 10, 2018

petecb via coreboot wrote: > Does anyone know whether there is a specific coreboot/cmos option I > could be missing or if it is a Qubes configuration issue? Narrow the problem down by booting any common Linux distribution (the install media is fine) and as root suspending with echo mem > /sys/power/state ..and see if resume works there. If yes coreboot is not neccessarily off the hook, but xen/Qubes is at least involved. //Peter

7 8

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
by Peter Stuge Dec. 9, 2018

Dec. 9, 2018

petecb via coreboot wrote: > Well the good news is that I have now got this board to work with > Coreboot v4.6 with the CMOS options and SeaBIOS! :-) > > The bad news is that this obviously means a bug has crept in on the > way up to 4.8 The best news is that you can track that down, since you have both a working (good) and a failing (bad) test case. Please clone the git repo and use git bisect to find the first bad commit. This would clearly be a really valuable contribution to the project, because it is not so unlikely that more boards are affected. Thanks //Peter

1 0

AMD fam10 relocatable ramstage
by Arthur Heymans Dec. 9, 2018

Dec. 9, 2018

Hi I have been playing around with the AMD fam10 codebase as of late. It is quite different from Intel hardware is that AMD hardware starts up other AP cores whereas on Intel hardware typically only the BSP runs code. As far as I can tell the AP's are started early on. They then start running from the reset vector. The code then updates their microcode and sets a 'reasonable' TOP_MEM MTRR such that when starting the APs later on during the ramstage, it won't result in any problems given that the stack will be in that 'reasonable' range (below CONFIG_RAMTOP). After that, they are put to rest and the BSP will be doing the rest of the things during the romstage (raminit for instance). Now the cbmem_top depends on the value the BSP set's in TOP_MEM, but unless the AP's have their own TOP_MEM (not shared MTRR) synced with the BSP. This syncing only happens during the AP init. To implement relocatable ramstage this syncing needs to happen earlier, preferable during the romstage... At the moment with relocatable ramstage enabled it hangs when starting the APs as it puts their stack somewhere in CBMEM well above the 'reasonable' default value of TOP_MEM which is CONFIG_RAMTOP. Now my questions: - Is this analysis correct? - If so, how to sync TOP_MEM in romstage (is there already an example of an implementation somewhere?), is there an easy way to run code on all AP's during the romstage? - Are workarounds possible/better? like figuring out TOP_MEM saving it nvram and resetting and programming that value on AP's Kind regards Arthur Heymans

1 0

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
by Taiidan＠gmx.com Dec. 9, 2018

Dec. 9, 2018

On 12/07/2018 02:14 PM, petecb via coreboot wrote: > > Hi Taiidan, > > Thanks for your message. > > >> I am using v4.6 on my system FYI (no reason for me to update) and the >> only options I have changed are the ones I told you about before...all I >> can figure is perhaps I have a different version of the SP5100 that >> doesn't have the erratum or something to that effect. > > Is it possible for me to build v4.6 in case something has changed since then that causes my issues? When I look at the branches available on git there is no 4.6 available. Get it from the coreboot website + check signature. > >> >> FYI I saw you select build nvramcui as a secondary payload so you can >> mess with cmos options without recompiling as long as next time you shut >> off "Load default configuration values into CMOS on each boot" >> >> Since your menuconfig options look fine...shot in the dark but try using >> grub instead of SeaBIOS as I use grub. >> > > I will try building it with Grub. There is an option to include a GRUB2 runtime config file into ROM image. Should I select this? If so, what options should be in this file? I would set it to load your disk .cfg file otherwise you would have to do so via configfile (ahci0,msdos1)/grub2/grub.cfg or what not when it boots to the rescue shell. > > Kind regards, > > Pete > >

2 1

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
by Taiidan＠gmx.com Dec. 7, 2018

Dec. 7, 2018

Please keep replies on the list - I will notice them - and like I said I won't give up until it works :D I wish you had OpenBMC installed so that I could access your system remotely and try stuff myself (via VPN and a router IP whitelist for security ofc) Did your D16 come with an ASMB4 or ASMB5 module? if so I recommend installing OpenBMC and its coreboot patches - note that coreboot needs patching for them to play nice together since for some stupid reason the required patches have not been upstreamed so you would need to cherry-pick. I am using v4.6 on my system FYI (no reason for me to update) and the only options I have changed are the ones I told you about before...all I can figure is perhaps I have a different version of the SP5100 that doesn't have the erratum or something to that effect. FYI I saw you select build nvramcui as a secondary payload so you can mess with cmos options without recompiling as long as next time you shut off "Load default configuration values into CMOS on each boot" Since your menuconfig options look fine...shot in the dark but try using grub instead of SeaBIOS as I use grub.

2 1

Kontron 986LCD-M support
by Petr Cvek Dec. 6, 2018

Dec. 6, 2018

Hello, I was trying to upgrade my Kontron 986LCD-M setup to AMD Radeon RX460 and I've found the vendor BIOS lack support for the video BIOS (RX460 requires UEFI). This incompatibility leads to x16 PCIe slot disable and no graphics in linux at all. I was able to re-enable the PCIe slot until now when I tried to upgrade to 2+2 GiB DDR2 modules (little more MB and dual channel). The RAM space is shared with PCI space and limited by 32bit so the top part of RAM is eaten by the regions of PCI devices. Problem is when vendor BIOS disables the card's slot it doesn't leave a hole for my GPU and it sets the TOLUD register (top of used RAM). This causes kernel to crash in GPU initialization. There is probably no way to fix TOLUD (and ACPI tables, SMI and other stuff) or force vendor's BIOS to reserve region for GPU, so I'm considering to switch to coreboot. My question is: does anybody know advanced information about TPM and SPI connectors? In the Kontron 986LCD-M datasheet (sections 4.16 and 4.17) there are only pin names and caption "unsupported". I understand these signals are likely buses from chipset, but it would be nice to know more details. Namely if the default LPC flash chip needs to be disconnected when using these busses and which pins of the chipset are connected to SPI pins BOOT0 and BOOT1 (I suppose they are LPC/SPI/PCI priority?). Thanks for any help. Petr Cvek

2 2

Re: [coreboot] [SMSC SCH3114] Super I/O issues
by Alexander Couzens Dec. 6, 2018

Dec. 6, 2018

Hi Kkonstantin, just by any chance, do you tried to use baytrail and _not_ fsp_baytrail? best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

3 4

Testing asked, implementing POSTCAR stage
by Arthur Heymans Dec. 6, 2018

Dec. 6, 2018

Hi I'm trying to implement a few features on x86 platforms to improve coreboot. Currently I'm focusing on unifying the bootflow of x86 platforms a little better. An important aspect of that is to make sure program boundaries within stages are respected, which is mostly an issue when romstage destroys the stack+environment in which it is running. Currently many platforms work around it by having code to fetch the global variables which are either still in the CAR (before CAR tear down) or somewhere relocated in cbmem after cbmem has been set up. A better solution is to have CAR being torn down in a separate stage, which means that romstage can always access global variables where the linker initially puts them. We call this stage postcar stage. I have an implementation ready for the following platforms: * CPU_AMD_MODEL_10XXX or in mainboard terms: amd/serengeti_cheetah_fam10 asus/kfsn4-dre hp/dl165_g6_fam10 msi/ms9652_fam10 supermicro/h8dmr_fam10 supermicro/h8qme_fam10 tyan/s2912_fam10 amd/mahogany_fam10 gigabyte/ma78gm iei/kino-780am2-fam10 jetway/pa78vm5 amd/tilapia_fam10 asus/m4a78-em asus/m4a785-m asus/m4a785t-m asus/m5a88-v gigabyte/ma785gm gigabyte/ma785gmt avalue/eax-785e amd/bimini_fam10 advansus/a785e-i asus/kcma-d8 supermicro/h8scm_fam10 asus/kgpe-d16 It would be great if the following patches could be tested (i.e. does it still boot): https://review.coreboot.org/c/coreboot/+/30063/2 https://review.coreboot.org/c/coreboot/+/30064/2 preferably on a board on which ACPI S3 resume is implemented (select HAVE_ACPI_RESUME). * NORTHBRIDGE_VIA_VX900 on the VIA EPIA-M850 board https://review.coreboot.org/c/coreboot/+/30057/1 https://review.coreboot.org/c/coreboot/+/30058/3 The only remaining targets that need to be addressed before the special logic for CAR globals can be dropped are FSP1.0 platforms and geode_lx. geode_lx still has to implement EARLY_CBMEM (requirement for 4.7 and 4.9 is coming soon)... Kind regards Arthur Heymans

2 1

Preparing coreboot 4.9
by Patrick Georgi Dec. 6, 2018

Dec. 6, 2018

Hi everybody, as Martin is swamped by other work, I'm taking over as the release manager for 4.9. Based on our schedule, we should have released 4.9 in October or early November, but since those passed, I'll plan to release 4.9 two weeks from now, on December 20th. If you want, consider it an early Christmas present :-) (Why early? I'd appreciate some last minute testing of the commit I'll pick for the release, and it might be easier to drum up support for that when family functions aren't interfering.) The release after that will go back to our April/October schedule, so the 4.10 window will be rather short. Due to that, there will be no deprecations announced in 4.9. Arthur's proposals sparked some discussion that started activity to keep some affected chipsets alive, and depending on how that unfolds, we can reconsider those deprecations for the 4.10 release notes, to happen after 4.11 in late 2019. Regarding release notes: I set up an etherpad copy of the release notes we have so far at https://piratenpad.de/p/S8slYOeag. I'll collect the changes of the last 8 months there, and I appreciate any help: if you made coreboot do something new since 4.8, feel free to tell the world about it in the upcoming release notes. I chose this method over the usual gerrit workflow we use for documentation because the latter doesn't scale so well when lots of changes happen close to each other: git produces too many merge conflicts in such a case. As part of the release process I'll push the release notes into the tree. While we have no quality criterion for releases, we all like to be able to point to releases as functional on our preferred hardware. Therefore, please test the hardware you have with recent master, and maybe schedule some time on the 19th or 20th to re-test master then, and report (or better yet, fix) any issues you encounter. While testing, consider adding to the board-status repository, too :-) I guess every release needs a bit of hyperbole, so let me end this announcement with a call to make this the best coreboot release ever! Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0