coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Need advise updating Intel's microcode in MPInit
by Patrick Rudolph 07 Jan '21

07 Jan '21

Hi, I'm stuck at solving a problem on Intel platforms that might not be one after all. Tests showed that a HyperThreading enabled core must not update microcodes on both threads at the same time, as the UCODE silicon is shared between those threads and one update might fail. However, doing so might not cause problems on devices newer than the Pentium 4 (as stated in some SDMs). Intel's SDM requires the use of semaphores to only update one thread of a core at once. In order to follow the microcode update flow described in Intel SDM I've moved some essential parts of coreboot's MP init code (aka SIPI vector) to C code [1]. While it makes it easier to maintain and reuse existing code (especially semaphores), it doesn't follow SDM to update microcode first no matter what. I'm not sure if all the work/changes are really necessary. The questions here are: * Do we care about Intel platforms supporting FIT? Those do update the microcode on all cores before executing the reset vector anyway and thus MP init won't update microcode at all. Following Intel SDM here is pointless. * Do we care about Intel platforms not supporting FIT (aka pre Haswell)? Those could update one core at time using a spinlock whenever HyperThreading is enabled. Assuming the limited amount of logical cores on those old platforms the additional boot delay might be very low. Another option would be to update microcode in parallel without a spinlock assuming that no Pentium 4 will ever run this code. Following Intel SDM here, given the low number of cores, won't give any significant speed up while adding complex code. * Do we care about Intel platforms supporting FIT not using FIT? Following Intel SDM here, assuming a high number of cores, will give significant speed up while adding complex code. * Should the SIPI vector in general be partially moved from assembly to C? This makes it easier to add features and reuse code, but compilers might generate unsupported code. To summarize: Instead of adding a bunch of code I'd prefer to serialize MP init microcode updates on non FIT and Hyper-Threading enabled CPUs only. 1: https://review.coreboot.org/q/topic:%22mpinit_cleanup%22+(status:open%20OR%… Kind Regards, Patrick Rudolph B.Sc. Electrical Engineering System Firmware Developer 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph(a)9elements.com Phone: +49 234 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO

1 0

Segmentation error while compile Coreboot binary on branch 4.8.1
by Balázs Vinarz 06 Jan '21

06 Jan '21

Hi! Have you experienced anything like this while compiling from the branch 4.8.1? I have a fresh and a ~ 1 year old crossgcc pack, but both are end up after a make menuconfig ; make -j8 with the same way. In the latest crossgcc build, I had to apply an include string fix to binutils and a -Wl,--allow-multiple-definition to the acpica's LDFLAGS. #### $ CC=/usr/bin/gcc make -d -j8 GNU Make 4.3 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile 'Makefile'... Reading makefile '/media/ramdisk/coreboot/util/kconfig/Makefile' (search path) (no ~ expansion)... Reading makefile '/media/ramdisk/coreboot/.config' (search path) (no ~ expansion)... Reading makefile '.xcompile' (search path) (don't care) (no ~ expansion)... Reading makefile 'toolchain.inc' (search path) (no ~ expansion)... Reading makefile 'Makefile.inc' (search path) (don't care) (no ~ expansion)... Skipping submodule '3rdparty/blobs' Reading makefile 'util/crossgcc/Makefile.inc' (search path) (no ~ expansion)... . . Reading makefile 'src/vendorcode/amd/pi/00670F00/Makefile.inc' (search path) (don't care) (no ~ expansion)... Segmentation error (core dumped) #### $ dmesg | tail -1 [30582.804975] make[750110]: segfault at 7fffb5d2dff8 ip 00007fd105838cff sp 00007fffb5d2e000 error 6 in libc-2.32.so[7fd1057d3000+14d000] [30582.804983] Code: 00 00 00 48 3b 1d 51 64 13 00 0f 82 ab 00 00 00 64 8b 04 25 18 00 00 00 85 c0 0f 85 23 01 00 00 48 89 ee 48 8d 3d 01 6d 13 00 <e8> cc e2 ff ff 49 89 c0 48 85 c0 0f 84 c8 00 00 00 48 8b 40 f8 a8 #### Do you have any ideas? I'm using Arch Linux 5.9 with GCC 10.2 I had a try on another machine with Arch Linux 4.19 LTS@GCC 10.2 Thanks

2 2

Max RAM problem
by Ale 06 Jan '21

06 Jan '21

Hello everyone, I have a kgpe d16 motherboard with coreboot and seabios, and 2 opteron 6282 SE processor with 64 gb of RAM: all the modules are 16 Gb hynix HMT42GR7AFR4C - RD and all are inserted into the orange slots. The problem is, if I add 2 additional modules, inside the last 2 orange slots, the machine doesn't starts and only black screen is shown, no log is detected over COM port. Any suggestion? Maybe another RAM module configuration is needed, because I read that 192 Gb of RAM is possible to obtain (I have followed the official Asus manual for the RAM-Slots configuration) Thank you very much Best regards Ale

3 2

Asan/Ubsan for further testing
by Shawn C 06 Jan '21

06 Jan '21

Hi, coreboot have two types of sanitizers already: Ubsan and Asan. This is good starting point. I found a few catches by simply enabling CONFIG_COVERAGE, CONFIG_UBSAN and CONFIG_ASAN: https://ticket.coreboot.org/issues/288 The developer seems haven't enable them in the testing process yet. It would be better if we add those debug features by default during the development which could possibly kill more bugs in the coreboot and the sanitizers themselves. Any ideas? regards Shawn C

3 3

Reserve Device DRAM
by Bryan Angelo 04 Jan '21

04 Jan '21

I would appreciate any guidance on the proper way to reserve (arbitrary) DRAM for a MMIO device in coreboot such that the Linux driver for that device is also able to map the reserved DRAM. Based on code inspection, my attempt is to add a cbmem entry via cbmem_alloc and mark that memory as reserved via reserved_ram_resource in the read_resources operation for the device driver. static void foo_read_resources(struct device *dev) { void *buf; const unsigned long size = 0x8000; if (cbmem_entry_find(CBMEM_ID_FOO)) return; buf = cbmem_add(CBMEM_ID_FOO, size); if (!buf) return; reserved_ram_resource(dev, 0, ((unsigned long)buf) >> 10, size >> 10); } I can see that the resource is allocated during resource reading. MMIO: fd110500 resource base *8de82000* size 8000 align 0 gran 0 limit 0 flags f0004200 index 0 I then pass this resource to the linux driver via an ACPI device entry. acpigen_write_name("_CRS"); acpigen_write_resourcetemplate_header(); const struct cbmem_entry *ce = cbmem_entry_find(CBMEM_ID_FOO); if (ce) acpigen_write_mem32fixed(1, (uint32_t)cbmem_entry_start(ce), (uint32_t)cbmem_entry_size(ce)); However, the memory is presented to Linux as "type 16" instead of "reserved" in the physical RAM map. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 [ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000008de34fff] usable *[ 0.000000] BIOS-e820: [mem 0x000000008de35000-0x000000008fffffff] type 16* [ 0.000000] BIOS-e820: [mem 0x0000000090000000-0x00000000cfffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000022f33ffff] usable [ 0.000000] BIOS-e820: [mem 0x000000022f340000-0x000000022fffffff] reserved The e820 type 16 is unknown to the linux kernel, causing it to mark the region as busy. This subsequently causes devm_ioremap_resource to fail when called on the DRAM address from the ACPI device entry. Looking through the code, it seems that coreboot marks the entire cbmem as type 16 in bootmem despite my (improper, it would seem) attempt to mark the ram as reserved. What would be the proper way to reserve (arbitrary) DRAM for a MMIO device such that the memory is marked as reserved in the BIOS physical RAM map? Thanks.

4 3

Add Nuvoton NCT6797D to coreboot/util/superiotool/nuvoton.c
by Clay Daniels 02 Jan '21

02 Jan '21

I would like to add my Nuvoton NCT6797D superio chip to the coreboot utility superiotool. With the help of several nice folks on the freenode #coreboot irc channel, I have modified my local superiotool and it works well. I have never made a commit to Gerrit, but I have established Gerrit & Github accounts. I see the page to start a change request at: https://review.coreboot.org/dashboard/self However, I am not so sure of myself yet, so I'm writing to get advice. Feel free to respond , even if all you have to say is that it's not my place to propose a patch. Here are the details: coreboot/util/superiotool: Add Nuvoton NCT6797D to coreboot/util/superiotool/nuvoton.c # diff -u a/nuvoton.c b/nuvoton.c --- a/nuvoton.c 2020-12-27 22:31:01.116775121 -0600 +++ b/nuvoton.c 2020-12-27 22:31:55.900532400 -0600 @@ -567,6 +567,56 @@ {0x30,0xe0,0xe1,0xe2,0xe3,EOT}, {0x20,0x20,0x04,0x05,0x01,EOT}}, {EOT}}}, + {0xD451, "NCT6797D", { + {NOLDN, NULL, + {0x07,0x10,0x11,0x13,0x14,0x1a,0x1b,0x1c,0x1d,0x20,0x21,0x22,0x24,0x25,0x26,0x27,0x28,0x2a,0x2b,0x2c,0x2d,0x2f,EOT}, + {0x00,0xff,0xff,0x00,0x00,0x30,0x70,0x10,0x00,0xc8,0x03,0xff,0x04,0x00,MISC,0x00,0x00,0xc0,0x00,0x01,0x00,MISC,EOT}}, + {0x01, "Parallel Port", + {0x30,0x60,0x61,0x70,0x74,0xf0,EOT}, + {0x01,0x03,0x78,0x07,0x04,0x3f,EOT}}, + {0x02, "UART A", + {0x30,0x60,0x61,0x70,0xf0,0xf2,EOT}, + {0x01,0x03,0xf8,0x04,0x00,0x00,EOT}}, + {0x03, "UART B, IR", + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,EOT}, + {0x01,0x02,0xf8,0x03,0x00,0x00,0x00,EOT}}, + {0x05, "Keyboard Controller", + {0x30,0x60,0x61,0x62,0x63,0x70,0x72,0xf0,EOT}, + {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x83,EOT}}, + {0x06, "Consumer IR", + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x00,0x00,0x00,0x08,0x09,0x32,0x00,EOT}}, + {0x07, "GPIO 6, GPIO 7, GPIO 8", + {0x30,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xec,0xed,0xf4,0xf5,0xf6,0xf7,0xf8,EOT}, + {0x00,0x7f,0x00,0x00,0x00,0xff,0x00,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0x00,0x00,EOT}}, + {0x08, "WDT1, WDT_MEM, GPIO 0, GPIO 1", + {0x30,0x60,0x61,0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfe,0xff,EOT}, + {0x00,0x00,0x00,0xff,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}}, + {0x09, "GPIO 2, GPIO 3, GPIO 4, GPIO 5", + {0x30,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe8,0xe9,0xea,0xeb,0xee,0xf0,0xf1,0xf2,0xf4,0xf5,0xf6,0xf7,0xfe,EOT}, + {0x00,0xff,0x00,0x00,0x00,0x7f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0xff,0x00,0x00,0x00,0x00,EOT}}, + {0x0a, "ACPI", + {0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe9,0xec,0xed,0xee,0xf0,0xf2,0xf3,0xf4,0xf6,0xf7,0xfc,0xfe,EOT}, + {0x01,0x00,0x00,0x00,0x00,0x02,0x1a,0x00,0x00,0x00,0x00,0x00,0x10,0x5c,0x00,0x00,0x00,0xc0,0x00,0x00,EOT}}, + {0x0b, "Hardware Monitor, Front Panel LED", + {0x30,0x60,0x61,0x62,0x63,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe6,0xe7,0xf0,0xf1,0xf2,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,EOT}, + {0x00,0x00,0x00,0x00,0x00,0x00,0x7f,0x7f,0xff,0xff,0xff,0x08,0xff,0x00,0x00,0x00,0x10,0x00,0x87,0x47,0x00,0x00,0x00,EOT}}, + {0x0d, "BCLK, WDT2, WDT_MEM", + {0xe0,0xe1,0xe7,0xe8,0xeb,0xed,0xf0,0xf3,EOT}, + {0x00,MISC,0x00,0x32,0x14,0x00,0x00,0x00,EOT}}, + {0x0e, "CIR Wake-Up", + {0x30,0x60,0x61,0x70,EOT}, + {0x00,0x00,0x00,0x00,EOT}}, + {0x0f, "GPIO Push-Pull or Open-Drain selection", + {0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe9,0xf0,0xf1,0xf2,EOT}, + {0xff,0xff,0x7f,0xff,0xff,0xff,0x0f,0xff,0xff,0x9d,0x00,0x00,EOT}}, + {0x14, "Port 80 UART", + {0xe0,0xe1,0xe2,0xe3,0xe4,EOT}, + {0x80,0x00,0x00,0x10,0x00,EOT}}, + {0x16, "Deep Sleep", + {0x30,0xe0,0xe1,0xe2,0xe3,EOT}, + {0x20,0x20,0x04,0x05,0x01,EOT}}, + {EOT}}}, {0xd121, "NCT5539D", { {NOLDN, NULL, {0x10,0x11,0x13,0x14,0x1a,0x1b,0x1c,0x1d,0x22,0x24, root@MSI-7C37:~/coreboot/util/superiotool# superiotool -d superiotool r4.13-726-g7e3126dbc5 Found Nuvoton NCT6797D (id=0xd451) at 0x4e Register dump: idx 07 10 11 13 14 1a 1b 1c 1d 20 21 22 24 25 26 27 28 2a 2b 2c 2d 2f val 0b ff ff ff ff 72 80 10 10 d4 51 ff 00 00 40 00 00 58 00 01 00 02 def 00 ff ff 00 00 30 70 10 00 c8 03 ff 04 00 MM 00 00 c0 00 01 00 MM LDN 0x01 (Parallel Port) idx 30 60 61 70 74 f0 val 00 03 78 07 04 3f def 01 03 78 07 04 3f LDN 0x02 (UART A) idx 30 60 61 70 f0 f2 val 01 03 f8 04 00 00 def 01 03 f8 04 00 00 LDN 0x03 (UART B, IR) idx 30 60 61 70 f0 f1 f2 val 01 02 f8 03 00 00 00 def 01 02 f8 03 00 00 00 LDN 0x05 (Keyboard Controller) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 83 def 00 00 00 00 00 00 00 83 LDN 0x06 (Consumer IR) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 ff ff ff ff def 00 00 00 00 08 09 32 00 LDN 0x07 (GPIO 6, GPIO 7, GPIO 8) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 ec ed f4 f5 f6 f7 f8 val 02 ff 00 00 00 ff ff ff ff 00 ff ff ff ff ff ff def 00 7f 00 00 00 ff 00 00 00 00 00 ff 00 00 00 00 LDN 0x08 (WDT1, WDT_MEM, GPIO 0, GPIO 1) idx 30 60 61 e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fe ff val 01 0a 10 ff ff ff ff ff ff ff ff ff ff 00 00 00 ff 00 ff 00 00 def 00 00 00 ff 00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ee f0 f1 f2 f4 f5 f6 f7 fe val 0f 4f 90 00 00 fa 76 00 00 20 00 01 01 80 3f f0 00 fe e4 00 01 ff def 00 ff 00 00 00 7f 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 00 00 LDN 0x0a (ACPI) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 ec ed ee f0 f2 f3 f4 f6 f7 fc fe val 01 00 00 04 00 02 9a 00 00 81 01 00 10 5f 00 00 00 c0 a0 00 def 01 00 00 00 00 02 1a 00 00 00 00 00 10 5c 00 00 00 c0 00 00 LDN 0x0b (Hardware Monitor, Front Panel LED) idx 30 60 61 62 63 70 e0 e1 e2 e3 e4 e6 e7 f0 f1 f2 f5 f6 f7 f8 f9 fa fb val 01 0a 20 0a 40 00 7f 7f 7f 7f 7f 00 7f 00 00 00 00 00 87 47 00 00 ff def 00 00 00 00 00 00 7f 7f ff ff ff 08 ff 00 00 00 10 00 87 47 00 00 00 LDN 0x0d (BCLK, WDT2, WDT_MEM) idx e0 e1 e7 e8 eb ed f0 f3 val 00 20 10 00 00 00 00 00 def 00 MM 00 32 14 00 00 00 LDN 0x0e (CIR Wake-Up) idx 30 60 61 70 val 00 00 00 00 def 00 00 00 00 LDN 0x0f (GPIO Push-Pull or Open-Drain selection) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 f0 f1 f2 val f6 cf ff 7f ff ff ff ff ff 9d 04 00 def ff ff 7f ff ff ff 0f ff ff 9d 00 00 LDN 0x14 (Port 80 UART) idx e0 e1 e2 e3 e4 val 80 00 00 10 aa def 80 00 00 10 00 LDN 0x16 (Deep Sleep) idx 30 e0 e1 e2 e3 val a0 20 04 05 01 def 20 20 04 05 01 root@MSI-7C37:~/coreboot/util/superiotool# Thanks, Clay Daniels Boot_Dawg on freenode irc channels #coreboot & #flashrom

1 0

Re: Segmentation error while compile Coreboot binary on branch 4.8.1
by Balázs Vinarz 30 Dec '20

30 Dec '20

Someone's reply may have been gone. In the end, I ended up to build the crossgcc part with an Ubuntu bases Docker image. https://hub.docker.com/r/loop0br/coreboot-compile

1 0

Retroboot 20201228 beta release, 28 December 2020
by Leah Rowe 28 Dec '20

28 Dec '20

Hello coreboot community! I would like to formally announce a new project I've been working on for the last few weeks. Retroboot is based on coreboot, and today I have made an official release. This release is available from the https://retroboot.org/ with ROM images and source code provided. Please read the Retroboot documentation if you wish to learn how to use them. Support is provided at the #retroboot IRC channel on Freenode. Retroboot is a new coreboot distribution, forked from the Libreboot 20160907 build system, but allows binary blobs from coreboot and uses an up to date version of coreboot. The purpose of Retroboot is to provide pre-compiled ROM images for any system that coreboot supports. Retroboot, based on coreboot, provides hardware initialization on supported x86 computers; it sets up the hardware and boots an operating system such as GNU+Linux, BSD and Windows. Retroboot provides an automated build system that compiled coreboot, GRUB, SeaBIOS and various other required software, with specific configurations. It provides a completely automated way to build and test ROM images of coreboot, in various configurations. Each board added to Retroboot can specify a coreboot version at a specific commit ID from the coreboot Git repository, and custom patches. It can then be used with any number of coreboot payloads such as GRUB, SeaBIOS and (planned for a future release) Tianocore and linuxboot. Read the documentation on the Retroboot website for more information about each system supported in the Retroboot build system. The aim of Retroboot is to make coreboot easy to use. Coreboot is notoriously difficult to build, and very much not user friendly. Retroboot provides user focused documentation and professional support based on years of experience dealing with coreboot. I, Leah Rowe, am the founder of the Retroboot project and I am also the founder of the Libreboot project. This release, marked beta, released on 28 December 2020, supports the following machines: * ThinkPad X220 (untested at the time of release) * ThinkPad X230 (tested on a few machines at the time of release) * ThinkPad X230 Tablet (untested at the time of release, but X230 is the same board as the X230T, with minor differences, so the X230T ROMs should work) * ThinkPad T60 with ATI Mobility Radeon X1400, PCI ID 1002:7145 (tested on one machine at the time of release) NOTE: /tested/ in this context means that the machine can be observed booting a Linux kernel. Also, Windows 10 was confirmed to boot on the X230 with Intel VGA ROM and SeaBIOS payload. (we recommend the use of free operating systems like GNU+Linux). For documentation, refer to the accompnying source code release archive. Documentation is included in that archive. You can also refer to the documentation hosted directly at https://retroboot.org/ and this is more recommended due to it being more up to date. This is a public /beta/ release. The ROM images provided in this release are NOT guaranteed to boot correctly on your machine. If you install this, you should make sure that you have SPI flashing equipment (for flashing 25XX NOR flash) and, ideally, debugging equipment such as EHCI debug dongle. Extensive testing is required for all of the ROMs in this release, so user testing is highly encouraged! The plan for Retroboot is to have long, long periods of /testing/ releases, before versions are marked stable (similar to how the Debian project operates). More information about Retroboot can be found on the Retroboot website: https://retroboot.org/ Extensive documentation is provided, including for developers. I'm currently looking for people to add and maintain boards in Retroboot. The entire build system is documented here: https://retroboot.org/docs/maintain/ -- Leah Rowe, And now, a song: https://blog.vimuser.org/free-firmware-song.html

1 0

HDA Audio on Baytrail SoC
by Rao G 28 Dec '20

28 Dec '20

Hi Everyone, On the Baytrail platform with ALC262 Realtek Codec, HDA Audio is enumerated as PCI device 00 1b 00, the verb table is being programmed on HDABAR + command offset. Using uefi Payload which has PchInit -> DetectAndInitializeAzalia, there are no Errors in this path, all looks good Either Beep or Audio speakers fail to work in EFI Shell and also in Ubuntu aplay -l does not Audio ALC Codec as sound card what is missing to enumerate, FSP path\SoC Straps are enabled for Audio so they seem to be fine too Appreciate for any clues to make HDA to work on a BayTrail Platform Thanks Ranga

2 2

SeaBios getting stuck in boot menu
by Anatolii Vorobev 28 Dec '20

28 Dec '20

Dear Coreboot community, I am developing bios for my custom Apollo Lake SoC E3950 mainboard. I got to a point where SeaBios is loaded and awaits to choose a boot option. The problem is that its getting stuck while waiting for timeout or keyboard press (see log attached). I figured out that it is getting stuck on wait_irq() function. In particular, call stack looks like this: interactive_bootmenu() (/coreboot/payloads/external/SeaBIOS/seabios/src/boot.c) get_keystroke() (int scan_code = get_keystroke(menutime);) get_keystroke_full() yield_toirq() wait_irq() __stack_hop_back_wait_irq() Why can this happen? Is hardware not initialized properly during Coreboot operation or it should be done in SeaBios? Looks like interrupts from timer and keyboard are not working. I tried loading with FILO payload and keyboard was working Ok except keyboard leds were not working. Best Regards, Anatolii Vorobev

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot