SeaBIOS

seabios@seabios.org

4 participants
3800 discussions

[PATCH] - Add total usable memory to startup console output
by Damien Zammit 14 Sep '18

14 Sep '18

Hi folks, I want to put forth this patch for your review. In my opinion, it is very useful to know just after your machine has POSTed how much system RAM the machine has access to. This patch prints out to the screen just under the UUID the following line: System RAM: X MB where X is the number of whole megabytes available to the system. Since the memory map is already available to SeaBIOS, I think it makes sense to total up the sizes of regions marked as E820_RAM and print the grand total. I have tested this on a coreboot QEMU bios with custom SeaBIOS built: SeaBIOS (version rel-1.11.0-46-g18e193d) System RAM: 1022 MB When I tried flashing a compatible image to my Lenovo X220 laptop it bricked it. I'm not sure why, maybe I compiled it wrong or inserted it into my image wrongly with cbfstool. Cheers, Damien

2 1

[PATCH v3 0/3] pci: resource reserve capability found
by Jing Liu 14 Sep '18

14 Sep '18

This patch serial is about QEMU resource reserve capability finding in firmware. Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones. Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, and changes the debug level to 3 when it is non-qemu bridge. Change Log: v2 -> v1 * Add two patches for fixing small bugs v3 -> v2 * Change the debug level Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-) -- 1.8.3.1

6 12

[PATCH v2 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer
by Matt DeVillier 12 Sep '18

12 Sep '18

>From 3e41f058836cd920ab67463d361b11a11729b390 Mon Sep 17 00:00:00 2001 From: Matt DeVillier <matt.devillier(a)puri.sm> Date: Tue, 11 Sep 2018 16:54:53 -0500 Subject: [PATCH v2 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer Commit 4b42cc4 [SeaVGABios/cbvga: Advertise correct pixel format] neglected to wrap the cbfb mask size components in GET_FARVAR(), which resulted in a bogus value for bpp, breaking output on most/all devices. Fix this by adding GET_FARVAR() as appropriate. Additionally, some newer ChromeOS devices still fail even with this fix, so fall back to using the coreboot reported bit depth if the calculated valid is invalid. TEST: build/boot a variety of devices (google/[reef,eve], purism/librem_skl) using coreboot framebuffer init, verify SeaBIOS boot menu prompt visible. Signed-off-by: Matt DeVillier <matt.devillier(a)puri.sm> --- vgasrc/cbvga.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c index 859524c..438d8fd 100644 --- a/vgasrc/cbvga.c +++ b/vgasrc/cbvga.c @@ -312,11 +312,17 @@ cbvga_setup(void) } u64 addr = GET_FARVAR(0, cbfb->physical_address); - u8 bpp = cbfb->blue_mask_size + cbfb->green_mask_size - + cbfb->red_mask_size + cbfb->reserved_mask_size; + u8 bpp = GET_FARVAR(0, cbfb->blue_mask_size) + + GET_FARVAR(0, cbfb->green_mask_size) + + GET_FARVAR(0, cbfb->red_mask_size) + + GET_FARVAR(0, cbfb->reserved_mask_size); u32 xlines = GET_FARVAR(0, cbfb->x_resolution); u32 ylines = GET_FARVAR(0, cbfb->y_resolution); u32 linelength = GET_FARVAR(0, cbfb->bytes_per_line); + //fall back to coreboot reported bpp if calculated value invalid + if (bpp != 15 && bpp != 16 && bpp != 24 && bpp != 32) + bpp = GET_FARVAR(0, cbfb->bits_per_pixel); + dprintf(1, "Found FB @ %llx %dx%d with %d bpp (%d stride)\n" , addr, xlines, ylines, bpp, linelength); -- 2.17.1

1 0

[PATCH 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer
by Matt DeVillier 11 Sep '18

11 Sep '18

>From 52191d4f83fe9e3fa47ec2f9ee98aec83304a8f6 Mon Sep 17 00:00:00 2001 From: Matt DeVillier <matt.devillier(a)puri.sm> Date: Tue, 11 Sep 2018 16:54:53 -0500 Subject: [PATCH 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer Commit 4b42cc4 [SeaVGABios/cbvga: Advertise correct pixel format] neglected to wrap the cbfb mask size components in GET_FARVAR(), which resulted in a bogus value for bpp, breaking output on most/all devices. Fix this by adding GET_FARVAR() as appropriate. TEST: build/boot a variety of devices (google/fizz, purism/librem_skl) using coreboot for display init, verify SeaBIOS banner and boot menu prompt visible. Signed-off-by: Matt DeVillier <matt.devillier(a)puri.sm> --- vgasrc/cbvga.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c index 859524c..d64625e 100644 --- a/vgasrc/cbvga.c +++ b/vgasrc/cbvga.c @@ -312,8 +312,10 @@ cbvga_setup(void) } u64 addr = GET_FARVAR(0, cbfb->physical_address); - u8 bpp = cbfb->blue_mask_size + cbfb->green_mask_size - + cbfb->red_mask_size + cbfb->reserved_mask_size; + u8 bpp = GET_FARVAR(0, cbfb->blue_mask_size) + + GET_FARVAR(0, cbfb->green_mask_size) + + GET_FARVAR(0, cbfb->red_mask_size) + + GET_FARVAR(0, cbfb->reserved_mask_size); u32 xlines = GET_FARVAR(0, cbfb->x_resolution); u32 ylines = GET_FARVAR(0, cbfb->y_resolution); u32 linelength = GET_FARVAR(0, cbfb->bytes_per_line); -- 2.17.1

1 0

Re: [SeaBIOS] Failure to detect high-capacity SD card
by Kevin O'Connor 03 Sep '18

03 Sep '18

On Fri, Aug 24, 2018 at 10:45:55AM -0400, Chris wrote: > On Fri, Aug 24, 2018 at 10:28 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Fri, Aug 24, 2018 at 09:48:27AM -0400, Chris wrote: > >> On Fri, Aug 24, 2018 at 9:28 AM, Chris <coderight(a)gmail.com> wrote: > >> > So far it has worked on the first attempt every time. So it needs only > >> > the delay and nothing else. > >> > > >> > I still need to test with all my SD cards. Though I only have a 64GB > >> > Sandisk and a handful of 32GB Samsung. The question is whether or not > >> > the delay is dependent on the card type or if it's just the controller > >> > that needs to stabilize. > >> > >> OK, I tested all the cards I have and everything works. Attached is > >> the simplified patch. Hopefully someone can test other cards. I'm > >> interested to know if 128+GB and 16GB works. > > > > Thanks. If you increase SDHCI_POWER_ON_TIME instead, does that also > > work? > > > > -Kevin > > Yes. Seems to work the same so far using the same delay (5). Thanks. I committed this change. -Kevin

2 1

Error Data Hob
by zahra rahimkhani 29 Aug '18

29 Aug '18

Hello Friends , I compiled Coreboot 4.5 and seabios for Minnow board max and see this message in consol. "Memory Configure Data Hob is not present. Not updating MRC data in flash." what is Data Hob? what is MRC data؟ Cold you help me how to solve it? Best wishes , Zhara

1 0

Backport request for 8c3f57ea12
by Wei Liu 29 Aug '18

29 Aug '18

Hello I notice 1.11.2 was only released a few weeks ago so it is probably too early for another release, but can maintainers at least consider backporting 8c3f57ea12 to 1.11-stable branch? Thanks, Wei.

2 2

Re: [SeaBIOS] Error Data Hob
by Paul Menzel 29 Aug '18

29 Aug '18

Dear Zhara, On 08/29/18 19:19, zahra rahimkhani wrote: > I compiled Coreboot 4.5 and seabios for Minnow board max and see this > message in consol. > > "Memory Configure Data Hob is not present. > Not updating MRC data in flash." > > what is Data Hob? > what is MRC data؟ > Could you help me how to solve it? Unfortunately, you wrote to the wrong list. SeaBIOS is the payload, and the messages you quoted are from coreboot. Please contact the coreboot mailing list. I advise, to test the latest version 4.8 before contacting the coreboot project though. Kind regards, Paul PS: In the future, always attach the whole log.

1 0

Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device
by Marcel Apfelbaum 28 Aug '18

28 Aug '18

Hi Gerd On 08/28/2018 07:12 AM, Zihan Yang wrote: > Gerd Hoffmann <kraxel(a)redhat.com> 于2018年8月27日周一上午7:04写道： >> Hi, >> >>>> However, QEMU only binds port 0xcf8 and 0xcfc to >>>> bus pcie.0. To avoid bus confliction, we should use other port pairs for >>>> busses under new domains. >>> I would skip support for IO based configuration and use only MMCONFIG >>> for extra root buses. >>> >>> The question remains: how do we assign MMCONFIG space for >>> each PCI domain. Thanks for your comments! >> Allocation-wise it would be easiest to place them above 4G. Right after >> memory, or after etc/reserved-memory-end (if that fw_cfg file is >> present), where the 64bit pci bars would have been placed. Move the pci >> bars up in address space to make room. >> >> Only problem is that seabios wouldn't be able to access mmconfig then. >> >> Placing them below 4G would work at least for a few pci domains. q35 >> mmconfig bar is placed at 0xb0000000 -> 0xbfffffff, basically for >> historical reasons. Old qemu versions had 2.75G low memory on q35 (up >> to 0xafffffff), and I think old machine types still have that for live >> migration compatibility reasons. Modern qemu uses 2G only, to make >> gigabyte alignment work. >> >> 32bit pci bars are placed above 0xc0000000. The address space from 2G >> to 2.75G (0x8000000 -> 0xafffffff) is unused on new machine types. >> Enough room for three additional mmconfig bars (full size), so four >> pci domains total if you add the q35 one. > Maybe we can support 4 domains first before we come up > with a better solution. But I'm not sure if four domains are > enough for those who want too many devices? (Adding Michael) Since we will not use all 256 buses of an extra PCI domain, I think this space will allow us to support more PCI domains. How will the flow look like ? 1. QEMU passes to SeaBIOS information of how many extra PCI domains needs, and how many buses per domain. How it will pass this info? A vendor specific capability, some PCI registers or modifying extra-pci-roots fw_cfg file? 2. SeaBIOS assigns the address for each PCI Domain and returns the information to QEMU. How it will do that? Some pxb-pcie registers? Or do we model the MMCFG like a PCI BAR? 3. Once QEMU gets the MMCFG addresses, it can answer to mmio configuration cycles. 4. SeaBIOS queries all PCI domains devices, computes and assigns IO/MEM resources (for PCI domains > 0 it will use MMCFG to configure the PCI devices) 5. QEMU uses the IO/MEM information to create the CRS for each extra PCI host bridge. 6. SeaBIOS gets the ACPI tables from QEMU and passes them to the guest OS. Thanks, Marcel >> cheers, >> Gerd >>

4 7

Fwd: [RFC v2 0/3] Support multiple pci domains in pci_device
by Zihan Yang 28 Aug '18

28 Aug '18

CCed to the wrong mailing list... resend here ---------- Forwarded message --------- From: Zihan Yang <whois.zihan.yang(a)gmail.com> Date: 2018年8月28日周二上午4:12 Subject: Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device To: Gerd Hoffmann <kraxel(a)redhat.com> Cc: <qemu-devel(a)nongnu.org>, Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> Gerd Hoffmann <kraxel(a)redhat.com> 于2018年8月27日周一上午7:04写道： > > Hi, > > > > However, QEMU only binds port 0xcf8 and 0xcfc to > > > bus pcie.0. To avoid bus confliction, we should use other port pairs for > > > busses under new domains. > > > > I would skip support for IO based configuration and use only MMCONFIG > > for extra root buses. > > > > The question remains: how do we assign MMCONFIG space for > > each PCI domain. > > Allocation-wise it would be easiest to place them above 4G. Right after > memory, or after etc/reserved-memory-end (if that fw_cfg file is > present), where the 64bit pci bars would have been placed. Move the pci > bars up in address space to make room. > > Only problem is that seabios wouldn't be able to access mmconfig then. > > Placing them below 4G would work at least for a few pci domains. q35 > mmconfig bar is placed at 0xb0000000 -> 0xbfffffff, basically for > historical reasons. Old qemu versions had 2.75G low memory on q35 (up > to 0xafffffff), and I think old machine types still have that for live > migration compatibility reasons. Modern qemu uses 2G only, to make > gigabyte alignment work. > > 32bit pci bars are placed above 0xc0000000. The address space from 2G > to 2.75G (0x8000000 -> 0xafffffff) is unused on new machine types. > Enough room for three additional mmconfig bars (full size), so four > pci domains total if you add the q35 one. Maybe we can support 4 domains first before we come up with a better solution. But I'm not sure if four domains are enough for those who want too many devices? > cheers, > Gerd >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS