September 2018 - SeaBIOS - mail.coreboot.org

[PATCH v3 0/3] pci: resource reserve capability found
by Jing Liu Sept. 14, 2018

Sept. 14, 2018

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 Sept. 12, 2018

Sept. 12, 2018

>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 Sept. 11, 2018

Sept. 11, 2018

>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 Sept. 3, 2018

Sept. 3, 2018

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