coreboot June 2021

coreboot@coreboot.org

36 participants
29 discussions

tianocore only showing 2gb of 8gb installed ram
by J c 08 Jun '21

08 Jun '21

Any ideas? thanks https://www.reddit.com/r/coreboot/comments/nuf2qh/coreboot_wtianocore_on_t4… I have this problem too. ESC key shows 8GB, Memmap in efi shell shows 2gb. Osx says 8gb. Ubuntu says 2gb (macbookpro10,1) uefipayload.. do u need the hw_probe info? Can I ask in tiancore.buzilla ? fastly is down why the 6gb ram is reserved?? (Reserved 0000000100000000-000000027C5FFFFF 000000000017C600 000000000000000F`) 1558016 pages RT_Data 000000007FF41000-000000007FF41FFF 0000000000000001 800000000000000F BS_Data 000000007FF42000-000000007FF42FFF 0000000000000001 000000000000000F Reserved 0000000000000000-0000000000000FFF 0000000000000001 000000000000000F Reserved 00000000000A0000-00000000000FFFFF 0000000000000060 000000000000000F Reserved 000000007FF43000-00000000829FFFFF 0000000000002ABD 000000000000000F Reserved 00000000F0000000-00000000F3FFFFFF 0000000000004000 000000000000000F Reserved 00000000FED90000-00000000FED91FFF 0000000000000002 000000000000000F Reserved 0000000100000000-000000027C5FFFFF 000000000017C600 000000000000000F Reserved : 1,585,445 Pages (6,493,982,720 Bytes) LoaderCode: 580 Pages (2,375,680 Bytes) LoaderData: 0 Pages (0 Bytes) BS_Code : 1,239 Pages (5,074,944 Bytes) BS_Data : 8,252 Pages (33,800,192 Bytes) RT_Code : 77 Pages (315,392 Bytes) RT_Data : 239 Pages (978,944 Bytes) ACPI_Recl : 1 Pages (4,096 Bytes) ACPI_NVS : 2 Pages (8,192 Bytes) MMIO : 0 Pages (0 Bytes) MMIO_Port : 0 Pages (0 Bytes) PalCode : 0 Pages (0 Bytes) Available : 513,607 Pages (2,103,734,272 Bytes) Persistent: 0 Pages (0 Bytes) -------------- Total Memory: 2,046 MB (2,146,291,712 Bytes) (Grub 2 is fine, ubuntu detects 8gb) [ 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-0x000000007ff44fff] usable [ 0.000000] BIOS-e820: [mem 0x000000007ff45000-0x000000007fffffff] type 16 [ 0.000000] BIOS-e820: [mem 0x0000000080000000-0x00000000829fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed90000-0x00000000fed91fff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000027c5fffff] usable [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000027c5fffff] usable coreboot cbmem says 10. 0000000100000000-000000027c5fffff: RAM from uefipayload tianocore 8. 0000000100000000 - 000000027C5FFFFF [01] buildhob: base = 0x100000000, size = 0x17C600000, type = 0x0 ConvertPages: failed to find range 100000000 - 27C5FFFFF (I hope the enable tianocore logging in cbmem is useful here..)

1 0

Re: link time optimization testing - Was: Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
by Branden Waldner 08 Jun '21

08 Jun '21

On 5/25/21, Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > Dear Branden, > > > Am 22.05.21 um 20:03 schrieb Branden Waldner: >> On 5/21/21, Arthur Heymans <arthur(a)aheymans.xyz> wrote: > >>> Thanks for sharing your findings. The flash is 256K big, which is quite >>> small these days. >>> When building coreboot with default settings but without a payload I >>> find >>> that there is 69K empty space left for payloads. >>> >>> Some future developments I have been working on might give a bit more >>> breathing space. >>> - I want to make romstage optional and include the sources in the >>> bootblock: That should shave off roughly 10K of romstage. >>> - I have compressing postcar working (maybe you can also disable the >>> postcar console to reduce size). That's also 2-3k size gains >>> at likely the const of a tiny bit of boot performance on this platform. >>> - I also have some WIP code to merge postcar into ramstage which would >>> save >>> 15k. >>> >>> Maybe on coreboot release 4.15 you will have a better time building a >>> fully >>> working image with the default configuration. > >> I didn't realize there was development going on to save rom space, >> that's good to know. > > I just built the asus/p2b from commit d981c490 (mb/google/mancomb: > Enable some PCIe power saving features) with the Debian sid/unstable > toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110). > > There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. > Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot > image built fine. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/romstage 0x80 stage 17336 none > cpu_microcode_blob.bin 0x44c0 microcode 83968 none > fallback/ramstage 0x18d00 stage 53376 LZMA > (112168 decompressed) > build_info 0x25e00 raw 89 none > fallback/dsdt.aml 0x25e80 raw 5514 none > cmos_layout.bin 0x27440 cmos_layout 704 none > fallback/postcar 0x27740 stage 16888 none > fallback/payload 0x2b980 simple elf 69886 none > (empty) 0x3cac0 null 1956 none > bootblock 0x3d280 bootblock 11088 none > ``` > > Building with Jacob’s link time optimization changes [1], which he > thankfully rebased, saved 13 kB, so the configuration file would fit in > too. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/romstage 0x80 stage 14752 none > cpu_microcode_blob.bin 0x3ac0 microcode 83968 none > fallback/ramstage 0x18300 stage 46277 LZMA > (95496 decompressed) > build_info 0x23840 raw 89 none > fallback/dsdt.aml 0x238c0 raw 5514 none > cmos_layout.bin 0x24e80 cmos_layout 704 none > fallback/postcar 0x25180 stage 14872 none > fallback/payload 0x28c00 simple elf 69886 none > (empty) 0x39d40 null 15012 none > bootblock 0x3d800 bootblock 9664 none > ``` > > (If you have a recovery option and some spare time, it’d be great if you > tested the LTO patches.) I could probably test them out, though I'm not sure I'll get around to it right away. Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options. Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both? My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet. I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket. I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples. > > Kind regards, > > Paul > > > [1]: https://review.coreboot.org/c/coreboot/+/40815/ > (whole series) > Branden

5 11

DiskonChip 2000 testing (& old coreboot_v1/linux_bios)
by Branden Waldner 08 Jun '21

08 Jun '21

Well, I'm finally getting around to writing this, though I'm still not all that comfortable bringing it up. I purchased a diskonchip 2000 266mb a while ago just to mess around with. It took a long time in shipping though and then it took me a while to actually try to test it out. I had thought I could just use it as a large flash chip or maybe for trying to test the original linux_bios/coreboot_v1 on a motherboard I have with a supported chip set (specifically sis 630), but it hasn't worked out well for me. In the first place, I think my assumption of it exposing a large rom was wrong, it looks like they only actually only expose a small amount as regular bios boot rom space. While that sounds annoying, it would probably still be workable though. The real problem is that I can't seem to get it to work at all and I am not sure if what I am trying is supposed to work or if the chip is bad. The seller does/did specify a doa guarantee, but I'm not even sure if it is actually bad or if what I'm trying to do is unsupported. Going by the "HOWTO" documentation in the coreboot_v1 branch I figured I could just hotswap it and load the diskonchip kernel module, but I can't find any information about whether that actually supports the diskonchip 2000 or has been tested recently. It just returned unable to detect device (or something similiar). I tried the dos utils on freedos as well and couldn't get them to detect it either. It took a bit of effort just to find the dos utils, since the site I managed to find them on wasn't showing up on most of the searches I tried and there doesn't seem to be any other mirror of them. It would have been nice if they were properly on the internet archive, but there is just documentation on there. I'm hoping that somebody still remembers a bit about them and maybe knows something about how I can get the chip working, confirm that it's not working, or just tell me I'm doing it wrong. I'm also hoping that it's not too off topic. I know the old wiki did mention sending a message to the mailing list about working on forward porting old supported chips, but I never felt comfortable about it. I've actually never managed to get very far with programming in general, never mind what is needed for low level bootstrapping. Though I have long since figured out what it was I having problems with in the past and how to fix them, I've had too much other stuff going on to get in to it again. Branden

3 3

Installing coreboot to listed motherboards
by Павел 07 Jun '21

07 Jun '21

Hello. I've typed `git checkout <hash>` and `git submodule update --checkout` and git updated files and switch to this hash. But the config file did not appear in the directory. Is that how it should be? Do I have to download the configuration myself (from https://review.coreboot.org/plugins/gitiles/board-status/) and place it in the directory?

2 1

IO resources with base == 0/LPC decode
by Paul Menzel 06 Jun '21

06 Jun '21

Dear coreboot folks, Arthur provided change-set *sb/amd/hudson: Skip setting up LPC decode for base < 0x20* [1] fixing a hang when doing `outb(0, DMA1_RESET_REG)` on the Asus F2A85-M PRO with Nuvoton NCT6779D: > In some board ports SuperIO chips in the devicetree are not properly > set up with some IO ranges being unassigned which ends up being base= > 0. It's not an issue as long as the LPC bridge does not end up > decoding those IO ports. Doing so would conflict with ISA DMA > registers (0-0x1f). Writing to those DMA registers then causes a hang. I am moving the discussion to the mailing list. A big thank you to all reviewers: Michał commented: > I wouldn't say it is not properly set up. Some LDNs on e.g. on > Nuvoton chips have two IO register pairs and one does not always want > to enable them both. Anyway this was a bug, glad that you found it. Additionally the discussion below happened: Nico/Arthur/Nico: >>> Isn't this just covering up bugs in the mainboard ports? >> >> I don't think so. Are there mainboard ports where decoding LPC on >> port 0-0x1f is expected? > > I expect all knows resources to be decoded. > >> Unassigned and unused io ports on SIO devices get port 0 assigned >> with the expectation that LPC won't be decoding that range. > > Only by accident I guess? > >> It looks like a pretty implicit assumption though. This does not >> present itself on intel hardware as variable IO decode ranges are >> often set manually in the devicetree. > > That's also just a way to work around bugs. IMO, any devicetree entry > that says `on` and assigns `0` as i/o-port is inconsistent. > > We also don't pick individual resources of PCI devices and then hack > the bridge config to make things work. Why should LPC be treated > differently? > > I also wonder if the `0` setting is still necessary? i.e. can't the > allocator do it now? if not, why? Arthur: >> What do you suggest? Adding a child 'DMA' to LPC (0-0xfff is for the >> LPC bridge iirc) that reserves 0-0x1F such that no conflicts occur? >> >> IO0 is the HWM on nuvoton nct6779d >> For IO1: "These two registers select the SB-TSI base address <100h : >> FFEh> along a two-byte boundary." So I assume that if it's set < >> 0x100 this does not get decoded. How would you go about not enabling >> the SB-TSI range but enabling HWM?> >> Do you think https://review.coreboot.org/c/coreboot/+/54686 [2] is a better approach? Nico: > We usually assign all resources of enabled devices. So I would simply > not not enable SB-TSI. If the resource assignment triggers something > special in this chip, this chip's driver should handle it, IMHO (and not > the devicetree by assigning false resources). Angel: > The coreboot code should not report the SB-TSI resource if its base > is out of that <100h : FFEh> range. Optionally complain about an > invalid base if it's not zero (what would possess anyone to assign a > non-zero but invalid value?) Michał: > Which Super I/O chip driver really checks allowed boundaries > specified in its datasheet? None. Each mainboard's devicetree is > created with an assumption that unassigned io/irq resource is just > disabled resource. > 1. The Super I/O drivers should start checking the resources in terms > of boundaries (and maybe resource existence, i.e. whether devicetree > sets it) > 2. The PNP driver which assigns resources should also understand that > zero resources are disabled resources if we don't do it in the point 1. What do others think, and how can we move this forward? The alternative CB:54686 ([RFC]device/pnp_device: Disable IO resources if base == 0) does not work on the Asus F2A85-M PRO (yet). Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/54669 "sb/amd/hudson: Skip setting up LPC decode for base < 0x20" [2]: https://review.coreboot.org/c/coreboot/+/54686 "[RFC]device/pnp_device: Disable IO resources if base == 0"

1 0

[coreboot - Bug #311] (New) T410 PCIe Endpoints missing after flashing coreboot
by coreboot＠fe80.eu 03 Jun '21

03 Jun '21

Issue #311 has been reported by Johannes Roith. ---------------------------------------- Bug #311: T410 PCIe Endpoints missing after flashing coreboot https://ticket.coreboot.org/issues/311 * Author: Johannes Roith * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- After flashing coreboot on my Thinkpad T410, I realized the Mini PCIe Wifi card was no longer detected by my system. I have tried a second Intel Mini PCIe Wifi Card, I had lying around, but it was not recognized ether. So I reflashed the original BIOS and checked lspci for devices (attached in PCIe_Bus/lenovo). The Wifi Card was found again. After comparing it to my lspci outputs with coreboot (PCIe_Bus/coreboot, it seems five devices (including the Bridge to Mini PCIe) are not detected with coreboot. On the old coreboot documentation site, I found the result of lspci on the page of the T410 (https://www.coreboot.org/Board:lenovo/t410) and the Wifi Card is missing, too. Do you have any idea, how to get the bridge to Mini PCIe working with coreboot, so I can use the Wifi Card? As far as I have understood, coreboot does not a full PCIe Enumeration. If so, can I force a full enumeration in coreboot or by changing a parameter in grub? Or is there already a workaround? I have attached my coreboot configuration, too. I have used the ME_Cleaner to remove some parts of the Intel ME. I have tested it with Linux Mint and Fedora 34. ---Files-------------------------------- T410.zip (6.05 KB) .config (24.8 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #310] (New) Coreboot 4.14 fails on a Lenvovo T440p
by coreboot＠fe80.eu 02 Jun '21

02 Jun '21

Issue #310 has been reported by David Hoelscher. ---------------------------------------- Bug #310: Coreboot 4.14 fails on a Lenvovo T440p https://ticket.coreboot.org/issues/310 * Author: David Hoelscher * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- Hi all, coreboot 4.14 dies on early boot. The T440p ended with led blinking and beep sound. This was my first try - so i think it was maybe a problem with mrc.bin or vga.rom. But if I skip back to version 4.13, everything works fine (4.13 working config is appended). I don't know how to get debug information on this early stage of boot. Does anyone has a hint? A Raspberry Pi as an external flasher is available. Further - is it possible to flash only the 4 MB BIOS chip? This IC is very easy accessible. I am afraid to disassemble the complete backplate to access the other 8MB chip again. Initially I flashed the complete Rom without ME on both chips. ---Files-------------------------------- Coreboot_4.13.config (23.6 KB) descriptor.bin (4 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[Part 2] Dell OptiPlex and coreboot BIOS - a story about porting cursed hardware
by Mike Banon 02 Jun '21

02 Jun '21

Great news: we at 3mdeb have advanced in porting Dell Optiplex 7010⁄9010 to coreboot! And, if you would like to see what it takes to add coreboot support for the cursed hardware - from a coreboot developer's point of view! - here's a new highly entertaining blog post by Michal Zygowski: https://blog.3mdeb.com/2021/2021-06-01-optiplex_part2/ -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

cgit on review.coreboot.org
by Julius Werner 01 Jun '21

01 Jun '21

Hi Patrick, Martin, I just noticed that we seem to have dropped support for cgit on the coreboot Gerrit. I don't exactly remember how it worked, but I seem to have been able to get a link like https://review.coreboot.org/cgit/qc_blobs.git/plain/sc7180/qtiseclib/libqti… some time last year. Now that just redirects to Gitiles. The problem with Gitiles is it's impossible to just get a direct download link to a file -- you can only see source files in the browser view (with the Gitiles UI on the side), but you can't download the raw file exactly as it is in the repo. This is especially problematic for binary files where there is (as far as I can tell? Maybe I just can't find it...) no way to get their contents at all without downloading a whole tarball of a directory and extracting it (which is pretty cumbersome). Do you guys know why this happened and is there any chance we could get cgit back? Thanks, Julius

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2021