coreboot February 2019

coreboot@coreboot.org

51 participants
43 discussions

by Johnny Sorocil

(I didn't get your reply on mail, so I am replying this way) >> I am using CoreBoot with SeaBIOS as a payload for ThinkPad T430s to boot >> FreeBSD (but with Linux problem is same). >> DSDT provided by CoreBoot is missing battery charge start (BCTG, BCCS) and >> stop (BCSG, BCSS) thresholds. > > https://review.coreboot.org/c/coreboot/+/23178 (needs a rebase) > implements the things you are asking for. Nice :) It is not merged, so cherry pick needs to be used, but anyway, great that is already in review. Also, when seeing patchset, it is definitively over my ACPI skillset. > Just wondering is this a > mainline driver in FreeBSD? Linux got one quite recently. It is not yet merged but I suppose it will be soon: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234403 Tested and it works :) % sysctl dev.acpi_ibm.0.bat0_charge_{start,stop} dev.acpi_ibm.0.bat0_charge_start: 20 dev.acpi_ibm.0.bat0_charge_stop: 81 Thank you all for great work! Additional question (still related to ThinkPad EC): - is it possible to make some sound/tone when battery is at critical charge and/or charger is disconnected? There is "low_battery_beep" and "power_management_beeps" but I didn't manage to get it working on T430s

2 years

AMD FHC for G-series SOCs (GX-412TC)

by Enrico Weigelt, metux IT consult

Hi folks, I'm currently writing Linux drivers for AMD FCH GPIO. It's currently running fine on an APUv2 board (based on some examples I've found in the net, including coreboot APUv2 code) but for mainline it should be more generic. Yet lacking automatic probing / configuration (don't like hardcoding so much) My problem now is finding out which FCH it is exactly and find the corresponding specs. There seem to be two FCH types: Bolton and hudson. For Bolton, I've found some specs that seem to fit, but other sites indicate, the GX-412TC had an Hudson - unfortunately didn't find any register specs for this one yet. Does anybody here have some more detailed information on that ? --thx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

2 years

4.9: Payload is not running

by Zvi Vered

Hello, I got the following output via RS232 console: ------------------------------------------------------------------------------ coreboot-4.9-539-gde3ace0-dirty Mon Jan 28 13:44:10 UTC 2019 romstage starting (log level: 7)... RTC Init Starting the Intel FSP (early_init) CBFS: 'Master Header Locator' located CBFS at [200:200000) CBFS: Locating 'cpu_microcode_blob.bin' CBFS: Found @ offset 7940 size cc00 microcode: sig=0x30679 pf=0x1 revision=0x90a PM1_STS = 0x2100 PM1_CNT = 0x0 GEN_PMCON1 = 0x45008 prev_sleep_state = S5 Configure Default UPD Data PcdMrcInitSPDAddr1: 0xa0 (default) PcdMrcInitSPDAddr2: 0xa2 (default) PcdSataMode: 0x01 (set) PcdLpssSioEnablePciMode: 0x01 (default) PcdMrcInitMmioSize: 0x800 (default) PcdIgdDvmt50PreAlloc: 0x02 (default) PcdApertureSize: 0x02 (default) PcdGttSize: 0x02 (default) SerialDebugPortAddress: 0x3f8 (default) SerialDebugPortType: 0x01 (default) PcdMrcDebugMsg: 0x00 (default) PcdSccEnablePciMode: 0x01 (default) IgdRenderStandby: 0x00 (default) TxeUmaEnable: 0x00 (default) PcdOsSelection: 0x04 (default) PcdEMMC45DDR50Enabled: 0x01 (default) PcdEMMC45HS200Enabled: 0x00 (default) PcdEMMC45RetuneTimerValue: 0x08 (default) PcdEnableIgd: 0x01 (default) AutoSelfRefreshEnable: 0x00 (default) APTaskTimeoutCnt: 0x00 (default) GTT Size: 2 MB Tseg Size: 8 MB Aperture Size: 256 MB IGD Memory Size: 64 MB MMIO Size: 2048 MB MIPI/ISP: Disabled Sdio: Enabled Sdcard: Enabled SATA: Enabled SIO Dma 0: Enabled SIO I2C0: Enabled SIO I2C1: Enabled SIO I2C2: Enabled SIO I2C3: Enabled SIO I2C4: Enabled SIO I2C5: Enabled SIO I2C6: Enabled Azalia: Enabled SIO Dma1: Enabled Pwm0: Enabled Pwm1: Enabled Hsuart0: Enabled Hsuart1: Enabled Spi: Enabled Lpe: Disabled eMMC Mode: eMMC 4.5 SATA Mode: AHCI Xhci: Enabled ----------------------------------------------------------------------------------------- And then - nothing. It seems payload is not running. Currently SeaBIOS is enabled. My goal it to boot vanilla linux with grub (or grub2) via RS232 console only. With the original BIOS I got from vendor, I used knoppix to burn grub on the SATA disk. If coreboot is running grub, how should I burn grub ? Is it part of coreboot image ? Thank you, Zvika

2 years

Problem with Kconfig: warning: defaults for choice values not supported ?

by Mike Banon

I am trying to enable FRAMEBUFFER_SET_VESA_MODE for G505S at its' Kconfig ( ./src/mainboard/lenovo/g505s/Kconfig ) and also set the VESA mode to 0x118 instead of default 0x117 setting, by inserting the following lines to G505S Kconfig: config FRAMEBUFFER_SET_VESA_MODE bool default y config FRAMEBUFFER_VESA_MODE_118 bool default y config FRAMEBUFFER_VESA_MODE hex default 0x118 However, when I'm trying to run "make menuconfig" it complains with "Kconfig:[line_number]:warning: defaults for choice values not supported" message and I could see that the default setting is still 0x117. Could you please advise the working way of changing this "choice" setting by default? I thought of something like choice prompt "framebuffer graphics resolution" default FRAMEBUFFER_VESA_MODE_117 if !BOARD_LENOVO_G505S default FRAMEBUFFER_VESA_MODE_118 if BOARD_LENOVO_G505S help This option sets the resolution used for the coreboot framebuffer (and bootsplash screen). at ./coreboot/src/device/Kconfig, and it should work, however this isn't pretty (and also I prefer that board-specific options stay at board's Kconfig and don't spread across the tree) so it would be really helpful if you know a good alternative workaround Best regards, Mike Banon

2 years

[EC] ACPI DSDT not complete

by Johnny Sorocil

First thank you all for good work, is pretty impressive to have (as it is possible to be) open source version of firmware for modern x86 black box. Not sure if this is right mailing list, if not, please redirect me to the correct one. I am using CoreBoot with SeaBIOS as a payload for ThinkPad T430s to boot FreeBSD (but with Linux problem is same). DSDT provided by CoreBoot is missing battery charge start (BCTG, BCCS) and stop (BCSG, BCSS) thresholds. I have tried to boot OS with OEM DSDT table (either included on flash or OS override of the default DSDT found in RAM) and that doesn't work - USB timeouts, no cpu frequency scalling, and other problems. I have tried to patch CoreBoot provided DSDT but without success - ACPI is a little too much for me: I don't know how to implement missing methods nor how to connect EC registers with ACPI methods. Can someone push me in the right direction? Some addition questions related to embedded controller: - How to get/set keyboard backlight? - How to get/set LCD backlight level? - Is it possible to play some tones when charges is connected/disconnected or battery is at critical charge?

2 years

SecureBoot Keys

by galla rao

Hi All, Good Morning! would like to know from coreboot community a query on Secureboot keys! Is there a standard way to add SECUREBOOT keys into coreboot build process? Typically to sign & authenticate any UEFI application or OS loader, Keys need to be enrolled into BIOS. Shed some knowledge, if not available can we create a standard mechanism to integrate the keys into build process through CONFIG options Regards Ranga

2 years

Re: [RFC] Fix undefined behavior with left shifts in whole code base

by Nico Huber

Hi, sorry for reviving this old thread (it wasn't long though). The topic came up again in IRC today. On 03.04.18 18:47, ron minnich wrote: > So I would actually be in favor of what paul is advocating, but not the > inconistency. To keep it consistent, I don't see that just using 1U > everywhere is that huge a deal. C is not that pretty any more, so this > little bit of ugliness doesn't strike me as a big deal. Bugs from stuff > like 3<<31 scare me more. What I just noticed, and what Julius already told us (and we'd have probably paid more attention if we weren't topic posting). The warning in question `-Wshift-overflow=2` explicitly only checks the sign bit problem, e.g. 1 << 31. The bug variant 3 << 31 is already covered by the sane `-Wshift-overflow`. So there is absolutely nothing to gain from the =2 version by defi- nition. Should we enable more warnings? yes! Should we enable warnings that are discouraged by their authors? probably not. Nico PS. This is actually not as bad as what I have seen people doing to scripts because of shellcheck. But that thought reminds me that such tools, and excessive compiler warnings, can harm software quality.

2 years

Menu time-out missing when GRUB is loaded quickly and `at_keyboard`

by Paul Menzel

Dear GRUB folks, When the module `at_keyboard` is directly into the GRUB image (`--modules`), and GRUB is loaded really quickly, then the timer, which, after counting down to 0 (`GRUB_TIMEOUT`), starts the selected entry, is not shown. I noticed this issue on the ASRock E350M1 with coreboot and a small GRUB payload, and a PS/2 keyboard connected. Due to the missing time-out, I manually have to confirm the selected entry. By chance, the keyboard wasn’t connected setting up the system somewhere else, and that made it work as expected. So, it looks like, it’s related to `at_keyboard`, and some race, because the bigger default GRUB payload also does not show the problem. Luckily, it’s easily reproducible with GRUB’s standard `default_payload.elf` and QEMU. Please find the instructions below to reproduce the issue. $ git clone https://review.coreboot.org/coreboot $ cd coreboot $ # save attached grub.cfg in the directory $ util/scripts/config -e PAYLOAD_GRUB2 grep: .config: Datei oder Verzeichnis nicht gefunden $ util/scripts/config -e GRUB2_INCLUDE_RUNTIME_CONFIG_FILE $ util/scripts/config -e GRUB2_MASTER $ util/scripts/config -e CONFIG_COREBOOT_ROMSIZE_KB_2048 # default of 512 KB too small for GRUB payload $ util/scripts/config -e ANY_TOOLCHAIN $ # or: make crossgcc-i386 CPUS=`nproc` $ make olddefconfig $ make -j`nproc` $ qemu-system-x86_64 --version QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-2+b1) Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers $ qemu-system-x86_64 -M pc -bios build/coreboot.rom -serial stdio *No* time-out is shown. Telling QEMU to emulate a USB keyboard, indirectly disabling the PS/2 keyboard, the time-out *is* shown. $ qemu-system-x86_64 -M pc -bios build/coreboot.rom -serial stdio \ -usb -device usb-kbd Not including `at_keyboard` directly in GRUB’s “core image”, modules loaded automatically, the time-out is also shown. `set debug=at_keyb` did not show anything interesting. Can you reproduce that, and see what the problem is? Kind regards, Paul PS: Please find the instructions to build GRUB as a coreboot payload done by coreboot’s Kconfig system automatically, and how put it into the coreboot filesystem CBFS. ``` $ git clone https://git.savannah.gnu.org/git/grub.git/ $ cd grub $ git describe --tags --dirty grub-2.02-238-ga791dc0e3 $ ./autogen.sh $ ./configure --with-platform=coreboot $ make default_payload.elf # this includes `at_keyboard` $ cp default_payload.elf my/coreboot/folder/ $ cd my/coreboot/folder/ $ build/cbfstool build/coreboot.rom print $ build/cbfstool build/coreboot.rom remove -n fallback/payload $ build/cbfstool build/coreboot.rom add-payload -f payload.elf -n fallback/payload -c lzma ``` Kind regards, Paul

2 years

Intel Minnowmax gpio init bug? (fsp_baytrail)

by Konstantin Novikov

Dear, coreboot community! I'm found some parts of code in gpio init for Intel Minnowmax, that looks strange for me. This is gpio_to_pad struct from soc/intel/fsp_baytrail/gpio.c: static const u8 gpscore_gpio_to_pad[GPSCORE_COUNT] = { 85, 89, 93, 96, 99, 102, 98, 101, /* [ 0: 7] */ 34, 37, 36, 38, 39, 35, 40, 84, /* [ 8: 15] */ 62, 61, 64, 59, 54, 56, 60, 55, /* [16: 23] */ 63, 57, 51, 50, 53, 47, 52, 49, /* [24: 31] */ 48, 43, 46, 41, 45, 42, 58, 44, /* [32: 39] */ 95, 105, 70, 68, 67, 66, 69, 71, /* [40: 47] */ 65, 72, 86, 90, 88, 92, 103, 77, /* [48: 55] */ 79, 83, 78, 81, 80, 82, 13, 12, /* [56: 63] */ 15, 14, 17, 18, 19, 16, 2, 1, /* [64: 71] */ 0, 4, 6, 7, 9, 8, 33, 32, /* [72: 79] */ 31, 30, 29, 27, 25, 28, 26, 23, /* [80: 87] */ 21, 20, 24, 22, 5, 3, 10, 11, /* [88: 95] */ 106, 87, 91, 104, 97, 100 }; /* [96:101] */ I see many elements in 0..106 range. We're need this struct when calculating regmmio-value in this line: regmmio = (u32 *)(bank->pad_base + 16 * bank->gpio_to_pad[gpio]); When gpio_to_pad[41] equals 105, we're trying to get element #105 from soc_gpio_map gpscore_gpio_map struct (it's defined in mainboard/minnowmax/gpio.c), we're getting error, because size of this array equals 102. So, is it bug or I just don't get the details? Thanks for all your attention! Novikov Konstantin.

2 years

Fwd: FOSDEM stand info

by Carl-Daniel Hailfinger

Hi everyone, TL;DR: - Our stand is in building Aw https://fosdem.org/2019/schedule/buildings/#aw - Stand buildup has to be finished Saturday 10:00 - Stand duty on Saturday ends 19:00 - Stand duty on Sunday starts 9:00 - Stand teardown starts at Sunday 17:00 - If you bring something, please tell me via email - I will bring wired ethernet (if we're lucky and get soemthing to plug in)+power - If you volunteer for stand duty, please tell me via email or show up sometime on Saturday so we can plan Sunday shifts. Have a great FOSDEM! Thanks! Carl-Daniel -------- Forwarded Message -------- From: Pieter De Praetere <pieter(a)fosdem.org> Subject: [FOSDEM standholders] Practical information for your FOSDEM stand To: standholders(a)lists.fosdem.org Dear FOSDEM stand organisers, Welcome to FOSDEM! We are very happy to welcome your project this year. Please take your time to read through this information sheet and the Code of Conduct (https://fosdem.org/2019/practical/conduct/). Stands are located in three buildings on the campus: the upper (+2) and lower (+1) corridors of the K building, the lower floor of H and the corridors of AW. The list of stands with their location is on the FOSDEM website (https:// fosdem.org/2019/stands/). Note that the exact location (in the building) will only be known closer to the event. During FOSDEM, the stands team and the building coordinators can be reached via the H or K infodesk. If it is very urgent, an emergency phone number is available: +32 2 788 74 74. Build-up ------------ Before the conference begins on Saturday, you will have time to set up your stand. We ask that you start around 8:30 with building up your stand and finish around 10:00 so all stands are ready by the time our visitors arrive. We will provide each stand with a table, chairs and a power cord. While we try to provide every stand with an individual power socket (Belgian E type - http://www.worldstandards.eu/electricity/plugs-and-sockets/), the layout of the building makes this sometimes impossible, so some stands will share a power cord. WiFi (best-effort) will be present in all buildings, but we cannot provide fixed (ethernet) internet. Please do not move the tables or chairs; the position of stands has to be agreed beforehand with ULB for fire safety reasons, so we have very little flexibility there. For the same reason, we cannot provide extra tables. To prevent damage to the buildings, please do not attach anything to the walls, windows etc. You can bring anything else (e.g. roll banners, a new, branded, table cloth, demo items etc.), as long as it fits on your table (180x80 cm). During the event ------------------------- For security reasons, we ask that there is always someone from the project present at your stand. This also gives visitors a more pleasant experience, as there will always be somebody at hand to answer questions. We ask that you do not distribute food or drinks; we do not have permission from the ULB to do so. Small quantities (e.g. cookies) are OK, but large-scale distribution or the selling of large amounts of food or drink is not allowed. You must vacate the building by 19:00 on Saturday. Buildings are closed during the night, but not guarded. You can store your valuable items in the cloak room during the night (after 18:00); but you should take your items out before 8. Sunday is a very busy day for the because many people will leave their luggage in the cloak room. Please keep the vicinity of your stand clean; life is better for everybody if the conference is nice and clean. Tear-down ---------------- When the event ends on Sunday, please clear up your stand and the immediate vicinity. There is a person responsible for every building, and they will be able to help you with any questions you might have regarding tear-down. The clean-up starts when the devrooms close, usually around 17:00. By 17:30, everything should be packed up so we can clean and close the buildings. All items you brought, you should take back. So all posters, stickers, banners etc. that you used to decorate your stand, or did not hand out to visitors, you should take with you or throw in the trash. You would make the clean-up volunteers very happy if you take the time to gently sweep the surroundings of your stand. Every building has a central "Collection point" where you should bring chairs, tables and all other FOSDEM equipment. You will also find brooms and garbage bags there. Please put chairs and tables on the correct carts, and all other FOSDEM equipment in the labeled boxes. It will save us a lot of time afterwards if everything is nicely packed up. We hope you will have a pleasant experience at FOSDEM and that your project will benefit from having a stand. Should you have any more questions or remarks, don't hesitate to contact us via stands(a)fosdem.org. Kind regards, The FOSDEM stands team

2 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2019