SeaBIOS February 2018

seabios@seabios.org

20 participants
37 discussions

Mysterious "is VARVERIFY32INIT but used from" problem while trying to improve SeaBIOS
by Mike Banon 25 Feb '18

25 Feb '18

Friends, I need your help. While trying to improve SeaBIOS I got stuck at this very strange problem - which does not appear when you do a standalone build of SeaBIOS but it happens when you try building a coreboot together with SeaBIOS. Steps to reproduce: add this innocent looking function to the beginning of ./coreboot/payloads/external/SeaBIOS/seabios/src/fw/coreboot.c : int // doesn't matter if static or not testfunc(void) { int *c = malloc_tmp(sizeof(int)); // doesn't matter if _tmp or _tmphigh // free(c); // <--- commented out because doesn't affect the results return 0; } and try calling it from "cbfs_copyfile" function of the same file: static int cbfs_copyfile(struct romfile_s *file, void *dst, u32 maxlen) { ... void *temp = malloc_tmphigh(size); ... int ret = ulzma(dst, maxlen, temp, size); testfunc(); // <--- added ... } Then I get this problem while building a coreboot with together SeaBIOS : ... Compiling whole program out/code32seg.o Compiling whole program out/ccode16.o Compiling to assembler out/src/asm-offsets.s Generating offset file out/asm-offsets.h Compiling (16bit) out/romlayout.o Building ld scripts ERROR: .data.varinit.. is VARVERIFY32INIT but used from ['.text.runtime..', '.text.do_boot', '.text.malloc_tmp'] Makefile:162: recipe for target 'out/romlayout16.lds' failed make[2]: *** [out/romlayout16.lds] Error 1 Makefile:80: recipe for target 'build' failed make[1]: *** [build] Error 2 payloads/external/Makefile.inc:73: recipe for target 'payloads/external/SeaBIOS/seabios/out/bios.bin.elf' failed make: *** [payloads/external/SeaBIOS/seabios/out/bios.bin.elf] Error 2 However, if I try adding this function to the end of "coreboot_cbfs_init" function I don't get such an error: void coreboot_cbfs_init(void) { ... process_links_file(); testfunc(); // <--- works OK there } What is a difference between "cbfs_copyfile" and "coreboot_cbfs_init" that affects this behaviour? And why it is OK to call "malloc_" from inside the "cbfs_copyfile" function --- void *temp = malloc_tmphigh(size); --- but we couldn't call there our testfunc() which calls "malloc_" without running into this problem? Best regards, Mike Banon

1 0

Bug report for 'vga none' qemu option not working any more
by Sergey Aleynikov 23 Feb '18

23 Feb '18

I'm running a lot of qemu + kvm + seabios VMs and after upgrade to Debian 9 I found that some of them stopped booting. After trying to change kernel/qemu/seabios versions, I've nailed down the cause to the following: # VM definition qemu-system-x86_64 \ -enable-kvm \ -machine q35 \ -m 512 \ -nodefaults \ -cpu host \ -smp 1,sockets=1,cores=1,threads=1 \ -bios /opt/seabios/out/bios.bin \ -device virtio-scsi-pci,id=scsi \ -drive file="disk.img",id=disk,format=raw,if=none,cache=unsafe,aio=threads \ -device scsi-hd,drive=disk,bus=scsi.0,removable=off \ -device virtio-net-pci,netdev=net0,mac=$("../qemu-mac-hasher.py" "test") \ -netdev tap,id=net0,script="../ifup.sh",downscript="../ifdown.sh" \ -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios \ -vga none \ -nographic This VM doesn't boot with modern seabios, but it used to work. And now, if I change 'vga none' to 'vga std' in it, it starts booting again. I've performed git bisect on the seabios repository and found the following commit to break the old setup: 1d9e87b937d646be1950695f9ead35100d5ebbe6 is the first bad commit commit 1d9e87b937d646be1950695f9ead35100d5ebbe6 Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Fri Jun 26 09:44:00 2015 +0200 virtio: run drivers in 32bit mode virtio version 1.0 registers can (and actually do in the qemu implementation) live in mmio space. So we must run the blk and scsi virtio drivers in 32bit mode, otherwise we can't access them. This also allows to drop a bunch of GET_LOWFLAT calls from the virtio code in the following patches. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> :100644 100644 f97b1bd9f91df7417e7bd5a1ebd7182098a43296 e287530d0008e1d876a0bb9f9ff8a43266d7e1bd M Makefile :040000 040000 70b419ced4f58a39143c92897097a08b5548cbf4 93f7d4d939b5e0a14102a3cb718b1be5a2f12e60 M src Here're links to a full successful boot log (with 'vga std') and some portion of a failing boot log (as it just loops eternally): https://gist.github.com/dur-randir/80b7d9a84cbdb8591ec05abe2fc62604 https://gist.github.com/dur-randir/52c31d2abe3150759abd3e8ca140959a Those logs were obtained from seabios 1d9e87b937 - the first broken revision, but I can provide them for master, as it's still broken. Best regards, Sergey Aleyinkov

1 0

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

23 Feb '18

On Fri, Feb 23, 2018 at 07:06:24AM -0500, Chris wrote: > On Fri, Feb 23, 2018 at 12:24 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > This looks to be very similar to the issue Matt raised back in > > October. It seems the card needs to run at 1.8 volt (instead of 3.3 > > volt), but it seems to shutdown before telling seabios that. > > > > Can you apply the patch at: > > > > https://mail.coreboot.org/pipermail/seabios/2017-October/011892.html > > > > set the seabios debug level to 3, and send the log again? > > Yes, I believe we're using the same hardware. > > With the patch it still fails. > > During boot devices were: > * mmcblk0 internal 64GB SSD (detected). > * mmcblk1 internal card reader with 64GB bootable card in it (fails to > be detected). > * External USB reader that has 2 slots, one is empty, the other has a > 1GB microsd (detected). > > Log: > https://pastebin.com/L0dhPN8G > > Looks like the same problem where the card won't respond and times out. Yes - the card stops responding early in the process, which is odd. What does the patch below report? -Kevin diff --git a/src/hw/sdcard.c b/src/hw/sdcard.c index 6410340..44082bf 100644 --- a/src/hw/sdcard.c +++ b/src/hw/sdcard.c @@ -66,6 +66,7 @@ struct sdhci_s { #define SC_SEND_OP_COND ((1<<8) | SCB_R48o) #define SC_ALL_SEND_CID ((2<<8) | SCB_R136) #define SC_SEND_RELATIVE_ADDR ((3<<8) | SCB_R48) +#define SC_IO_SEND_OP_COND ((5<<8) | SCB_R48o) #define SC_SELECT_DESELECT_CARD ((7<<8) | SCB_R48b) #define SC_SEND_IF_COND ((8<<8) | SCB_R48) #define SC_SEND_EXT_CSD ((8<<8) | SCB_R48d) @@ -123,6 +124,17 @@ struct sdhci_s { #define SRF_DATA 0x04 // SDHCI result flags +#define SR_OCR_VDD_165_195 (1<<7) +#define SR_OCR_VDD_27_28 (1<<15) +#define SR_OCR_VDD_28_29 (1<<16) +#define SR_OCR_VDD_29_30 (1<<17) +#define SR_OCR_VDD_30_31 (1<<18) +#define SR_OCR_VDD_31_32 (1<<19) +#define SR_OCR_VDD_32_33 (1<<20) +#define SR_OCR_VDD_33_34 (1<<21) +#define SR_OCR_VDD_34_35 (1<<22) +#define SR_OCR_VDD_35_36 (1<<23) +#define SR_OCR_S18R (1<<24) #define SR_OCR_CCS (1<<30) #define SR_OCR_NOTBUSY (1<<31) @@ -181,7 +193,7 @@ static int sdcard_pio(struct sdhci_s *regs, int cmd, u32 *param) { u32 state = readl(&regs->present_state); - dprintf(9, "sdcard_pio cmd %x %x %x\n", cmd, *param, state); + dprintf(1, "sdcard_pio cmd %x %x %x\n", cmd, *param, state); if ((state & SP_CMD_INHIBIT) || ((cmd & 0x03) == 0x03 && state & SP_DAT_INHIBIT)) { dprintf(1, "sdcard_pio not ready %x\n", state); @@ -203,7 +215,7 @@ sdcard_pio(struct sdhci_s *regs, int cmd, u32 *param) writew(&regs->irq_status, SI_CMD_COMPLETE); // Read response memcpy(param, regs->response, sizeof(regs->response)); - dprintf(9, "sdcard cmd %x response %x %x %x %x\n" + dprintf(1, "sdcard cmd %x response %x %x %x %x\n" , cmd, param[0], param[1], param[2], param[3]); return 0; } @@ -302,13 +314,13 @@ sdcard_set_power(struct sdhci_s *regs) u32 cap = readl(&regs->cap_lo); u32 volt, vbits; if (cap & SD_CAPLO_V33) { - volt = 1<<20; + volt = SR_OCR_VDD_32_33 | SR_OCR_VDD_33_34; vbits = SPC_V33; } else if (cap & SD_CAPLO_V30) { - volt = 1<<18; + volt = SR_OCR_VDD_29_30 | SR_OCR_VDD_30_31; vbits = SPC_V30; } else if (cap & SD_CAPLO_V18) { - volt = 1<<7; + volt = SR_OCR_VDD_165_195; vbits = SPC_V18; } else { dprintf(1, "SD controller unsupported volt range (%x)\n", cap); @@ -399,11 +411,11 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio) if (ret) return ret; // Let card know SDHC/SDXC is supported and confirm voltage - u32 hcs = 0, vrange = (volt >= (1<<15) ? 0x100 : 0x200) | 0xaa; + u32 hcs = 0, vrange = (volt >= SR_OCR_VDD_27_28 ? 0x100 : 0x200) | 0xaa; param[0] = vrange; ret = sdcard_pio(regs, SC_SEND_IF_COND, param); if (!ret && param[0] == vrange) - hcs = (1<<30); + hcs = SR_OCR_CCS | (1<<28); // Verify SD card (instead of MMC or SDIO) param[0] = 0x00; ret = sdcard_pio_app(regs, SC_APP_SEND_OP_COND, param); @@ -414,8 +426,17 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio) if (ret) return ret; drive->card_type |= SF_MMC; - hcs = (1<<30); + hcs = SR_OCR_CCS; + } else { + // Check for SDIO + param[0] = 0x00; + ret = sdcard_pio(regs, SC_IO_SEND_OP_COND, param); + dprintf(1, "Ignoring SDIO response %d\n", ret); } + // XXX + if (volt == (SR_OCR_VDD_32_33 | SR_OCR_VDD_33_34) + && hcs && readl(&regs->cap_lo) & SD_CAPLO_V18) + hcs |= SR_OCR_S18R; // Init card u32 end = timer_calc(SDHCI_POWERUP_TIMEOUT); for (;;) { @@ -434,6 +455,10 @@ sdcard_card_setup(struct sddrive_s *drive, int volt, int prio) } msleep(5); // Avoid flooding log when debugging } + if (param[0] & SR_OCR_S18R) { + dprintf(1, "Card requests 1.8 volt\n"); + return -1; + } drive->card_type |= (param[0] & SR_OCR_CCS) ? SF_HIGHCAPACITY : 0; // Select card (get cid, set rca, get csd, select card) param[0] = 0x00;

2 1

Re: [SeaBIOS] Failure to detect high-capacity SD card
by Paul Menzel 23 Feb '18

23 Feb '18

Dear Chris, On 02/23/18 13:06, Chris wrote: > On Fri, Feb 23, 2018 at 12:24 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> This looks to be very similar to the issue Matt raised back in >> October. It seems the card needs to run at 1.8 volt (instead of 3.3 >> volt), but it seems to shutdown before telling seabios that. >> >> Can you apply the patch at: >> >> https://mail.coreboot.org/pipermail/seabios/2017-October/011892.html >> >> set the seabios debug level to 3, and send the log again? > > Yes, I believe we're using the same hardware. > > With the patch it still fails. > > During boot devices were: > * mmcblk0 internal 64GB SSD (detected). > * mmcblk1 internal card reader with 64GB bootable card in it (fails to > be detected). > * External USB reader that has 2 slots, one is empty, the other has a > 1GB microsd (detected). > > Log: > https://pastebin.com/L0dhPN8G Thank you for testing this. For the future, could you please attach log files, so that they can be looked in the inbox when offline. > Looks like the same problem where the card won't respond and times out. > > I still need to see if I can get some debugging information from a > Linux kernel because everything works fine there. I'm not sure how to > go about turning it on. Kind regards, Paul

1 0

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

23 Feb '18

On Thu, Feb 08, 2018 at 10:12:40AM -0500, Chris wrote: > On Wed, Feb 7, 2018 at 3:14 AM, Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > > Please tell us what SeaBIOS version you use, and attach the debug logs from > > a working and non-working setup. > > I switched to the SeaBIOS git HEAD code just in case that made a > difference (it did not). > > The machine has mmc0 as the internal 64GB SSD, mmc1 is the internal > card reader, then an external USB card reader (64GB) is attached as > well. This looks to be very similar to the issue Matt raised back in October. It seems the card needs to run at 1.8 volt (instead of 3.3 volt), but it seems to shutdown before telling seabios that. Can you apply the patch at: https://mail.coreboot.org/pipermail/seabios/2017-October/011892.html set the seabios debug level to 3, and send the log again? -Kevin

2 1

Re: [SeaBIOS] Confirm the status about BZ#1377575
by Laszlo Ersek 16 Feb '18

16 Feb '18

Hello Shouta-san, On 02/14/18 05:48, Shouta.Uehara(a)jp.yokogawa.com wrote: > Dear SeaBIOS development members, > > I'm Shota Uehara work for Yokogawa Electric Corporation. > I would like to confirm the status about a bug fixing of BZ#1377575. > > I use Windows Server 2016 virtual machine on qemu-kvm with CentOS 7. > And now I attempt to add a dedicated virtual device to qemu-kvm, and develop its device driver for WS2016. > > For debugging the windows driver I want to get a crash dump on WS2016, however it doesn't be created. > According to RedHat knowledge base, that is a Windows incompatibility issue to SeaBIOS, as known BZ#1377575. > <https://access.redhat.com/articles/2470791#known-issues-14> > > Therefore, I have 2 questions as follows; > (1) Could you tell me the current status about a bug fixing of BZ#1377575 ? > (2) If possible, could you tell me the work-around to avoid such bug and realize to get a crash dump ? Please refer to the following blog post by my (then-)colleague Ladi Prosek, who worked around the Windows issue (BZ#1377575) in the RHEL7 SeaBIOS package: https://ladipro.wordpress.com/2016/10/21/windows-vga-bug/ As stated in the blog post, both abandoning Cirrus video, and patching SeaBIOS, are necessary for working around the Windows issue. The SeaBIOS patch was sent to the SeaBIOS mailing list; please see the discussion thread at: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug https://www.coreboot.org/pipermail/seabios/2016-October/010963.html The thread seems to have petered out back then. For using an upstream SeaBIOS build, you might have to apply the patch manually. However, when using SeaBIOS from CentOS 7, the issue should already be fixed: - in 7.3.z, starting with seabios-1.9.1-5.el7_3.1 (BZ#1392028, <https://rhn.redhat.com/errata/RHBA-2017-0079.html>), - in 7.4, starting with seabios-1.10.1-1.el7 (BZ#1377575, <https://access.redhat.com/errata/RHBA-2017:1855>). Can you check if you are using a CentOS 7 SeaBIOS package that is at least this recent? ... In fact, I see a private (Red Hat only) reminder under the Knowledge Base article that we should update the "Known Issues" text, regarding BZ#1377575, once the related updates are out. Given that both BZs above are in CLOSED ERRATA status, I'm going to ping our docs guys now. :) ... Additionally, I've found a note in BZ#1377575 that Windows 10 RS2, version 1703+ (possibly earlier), should no longer have this bug. Not sure how (or if) that maps to Windows Server 2016. Thank you! Laszlo

2 1

[PATCH v2 1/5] floppy: hold the DOR reset bit low for 4 microseconds, when resetting
by Nikolay Nikolov 15 Feb '18

15 Feb '18

Signed-off-by: Nikolay Nikolov <nickysn(a)users.sourceforge.net> --- src/hw/floppy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/hw/floppy.c b/src/hw/floppy.c index 3012b3a..16989c2 100644 --- a/src/hw/floppy.c +++ b/src/hw/floppy.c @@ -328,6 +328,8 @@ floppy_enable_controller(void) dprintf(2, "Floppy_enable_controller\n"); // Clear the reset bit (enter reset state), but set 'enable IRQ and DMA' floppy_dor_mask(FLOPPY_DOR_RESET, FLOPPY_DOR_IRQ); + // Real hardware needs a 4 microsecond delay + usleep(4); // Set the reset bit (normal operation) and keep 'enable IRQ and DMA' on floppy_dor_mask(0, FLOPPY_DOR_IRQ | FLOPPY_DOR_RESET); int ret = floppy_wait_irq(); -- 2.14.3

2 5

Re: [SeaBIOS] Confirm the status about BZ#1377575
by Igor Skochinsky 14 Feb '18

14 Feb '18

Hi, It seems BZ#1377575 refers to Red Hat's Bugzilla bug which is restricted: https://bugzilla.redhat.com/show_bug.cgi?id=1377575 You should contact Red Hat support for details. Since we can't see the bug details, it's not clear what the problem is and if there is a fix or workaround. >Среда, 14 февраля 2018, 5:50 +01:00 от Shouta.Uehara(a)jp.yokogawa.com: > >Dear SeaBIOS development members, > >I'm Shota Uehara work for Yokogawa Electric Corporation. >I would like to confirm the status about a bug fixing of BZ#1377575. > >I use Windows Server 2016 virtual machine on qemu-kvm with CentOS 7. >And now I attempt to add a dedicated virtual device to qemu-kvm, and develop its device driver for WS2016. > >For debugging the windows driver I want to get a crash dump on WS2016, however it doesn't be created. >According to RedHat knowledge base, that is a Windows incompatibility issue to SeaBIOS, as known BZ#1377575. > < https://access.redhat.com/articles/2470791#known-issues-14 > > >Therefore, I have 2 questions as follows; >(1) Could you tell me the current status about a bug fixing of BZ#1377575 ? >(2) If possible, could you tell me the work-around to avoid such bug and realize to get a crash dump ? > >Sincerely, > >Shota Uehara >----- >CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful. > >_______________________________________________ >SeaBIOS mailing list >SeaBIOS(a)seabios.org >https://mail.coreboot.org/mailman/listinfo/seabios -- WBR, Igor mailto:skochinsky@mail.ru

1 0

Confirm the status about BZ#1377575
by Shouta.Uehara＠jp.yokogawa.com 14 Feb '18

14 Feb '18

Dear SeaBIOS development members, I'm Shota Uehara work for Yokogawa Electric Corporation. I would like to confirm the status about a bug fixing of BZ#1377575. I use Windows Server 2016 virtual machine on qemu-kvm with CentOS 7. And now I attempt to add a dedicated virtual device to qemu-kvm, and develop its device driver for WS2016. For debugging the windows driver I want to get a crash dump on WS2016, however it doesn't be created. According to RedHat knowledge base, that is a Windows incompatibility issue to SeaBIOS, as known BZ#1377575. <https://access.redhat.com/articles/2470791#known-issues-14> Therefore, I have 2 questions as follows; (1) Could you tell me the current status about a bug fixing of BZ#1377575 ? (2) If possible, could you tell me the work-around to avoid such bug and realize to get a crash dump ? Sincerely, Shota Uehara ----- CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful.

1 0

Re: [SeaBIOS] [PATCH 0/4] RFC: add CRB TPM device
by Stefan Berger 12 Feb '18

12 Feb '18

On 02/12/2018 01:17 PM, Marc-Andre Lureau wrote: > Hi > > On Sun, Feb 11, 2018 at 5:53 PM, Stefan Berger > <stefanb(a)linux.vnet.ibm.com> wrote: >> On 10/06/2017 10:33 AM, marcandre.lureau(a)redhat.com wrote: >>> From: Marc-André Lureau <marcandre.lureau(a)redhat.com> >>> >>> Hi, >>> >>> The following series implements a limited TPM CRB driver. The TIS >>> device with a TPM 2.0 seems to be ignored by Windows 10, so I >>> implemented a simple CRB device that I will send shortly on the >>> qemu-devel. With the CRB device, Windows 10 correctly recognized and >>> exchange with a TPM 2.0. >>> >>> As long as the device isn't in qemu, I suppose this series should >>> remain RFC. >> >> I think you can repost it now... > Indeed, the device is now in qemu. However, I don't have much time / > priority to work on seabios support for now. Since you have additional > patches on top, and you are experienced with that, perhaps you could > send the whole series including my patches (adding your reviewed-by / > signed-off and some text if you modified my patches)? I suppose that > would work for Kevin too? Fine by me. Stefan

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS February 2018