SeaBIOS

seabios@seabios.org

4 participants
3800 discussions

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

[PATCH 0/4] RFC: add CRB TPM device
by marcandre.lureau＠redhat.com 12 Feb '18

12 Feb '18

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. Feedback welcome! Marc-André Lureau (4): x86: add readq() tpm: generalize init_timeout() tpm: use get_tpm_version() callback WIP: add TPM CRB device support src/hw/tpm_drivers.c | 226 ++++++++++++++++++++++++++++++++++++++++++++++++--- src/hw/tpm_drivers.h | 26 ++++++ src/x86.h | 5 ++ 3 files changed, 245 insertions(+), 12 deletions(-) -- 2.14.1.146.gd35faa819

5 12

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

10 Feb '18

3 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS