SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH 1/2] kbd: Don't treat scancode and asciicode as separate values
by Kevin O'Connor 16 Jan '16

16 Jan '16

The scancode/asciicode pair can be more easily handled as a single 16bit value. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/kbd.c | 53 +++++++++++++++++++++-------------------------------- 1 file changed, 21 insertions(+), 32 deletions(-) diff --git a/src/kbd.c b/src/kbd.c index a5a1ad9..2bf7398 100644 --- a/src/kbd.c +++ b/src/kbd.c @@ -52,7 +52,7 @@ kbd_init(void) } static u8 -enqueue_key(u8 scan_code, u8 ascii_code) +enqueue_key(u16 keycode) { u16 buffer_start = GET_BDA(kbd_buf_start_offset); u16 buffer_end = GET_BDA(kbd_buf_end_offset); @@ -68,8 +68,7 @@ enqueue_key(u8 scan_code, u8 ascii_code) if (buffer_tail == buffer_head) return 0; - SET_FARVAR(SEG_BDA, *(u8*)(temp_tail+0), ascii_code); - SET_FARVAR(SEG_BDA, *(u8*)(temp_tail+1), scan_code); + SET_FARVAR(SEG_BDA, *(u16*)(temp_tail+0), keycode); SET_BDA(kbd_buf_tail, buffer_tail); return 1; } @@ -147,7 +146,7 @@ handle_1602(struct bregs *regs) static void handle_1605(struct bregs *regs) { - regs->al = !enqueue_key(regs->ch, regs->cl); + regs->al = !enqueue_key(regs->cx); } // GET KEYBOARD FUNCTIONALITY @@ -289,7 +288,7 @@ static struct scaninfo { u16 control; u16 alt; u8 lock_flags; -} scan_to_scanascii[] VAR16 = { +} scan_to_keycode[] VAR16 = { { none, none, none, none, none }, { 0x011b, 0x011b, 0x011b, 0x0100, none }, /* escape */ { 0x0231, 0x0221, none, 0x7800, none }, /* 1! */ @@ -504,48 +503,38 @@ __process_key(u8 scancode) SET_BDA(soft_reset_flag, 0x1234); reset(); } - if (scancode >= ARRAY_SIZE(scan_to_scanascii)) { + if (scancode >= ARRAY_SIZE(scan_to_keycode)) { dprintf(1, "KBD: int09h_handler(): unknown scancode read: 0x%02x!\n" , scancode); return; } - u8 asciicode; - struct scaninfo *info = &scan_to_scanascii[scancode]; + u16 keycode; + struct scaninfo *info = &scan_to_keycode[scancode]; if (flags0 & KF0_ALTACTIVE) { - asciicode = GET_GLOBAL(info->alt); - scancode = GET_GLOBAL(info->alt) >> 8; + keycode = GET_GLOBAL(info->alt); } else if (flags0 & KF0_CTRLACTIVE) { - asciicode = GET_GLOBAL(info->control); - scancode = GET_GLOBAL(info->control) >> 8; + keycode = GET_GLOBAL(info->control); } else if (flags2 & KF2_LAST_E0 && scancode >= 0x47 && scancode <= 0x53) { /* extended keys handling */ - asciicode = 0xe0; - scancode = GET_GLOBAL(info->normal) >> 8; + keycode = (scancode << 8) | 0xe0; } else if (flags0 & (KF0_RSHIFT|KF0_LSHIFT)) { /* check if lock state should be ignored because a SHIFT * key is pressed */ - - if (flags0 & GET_GLOBAL(info->lock_flags)) { - asciicode = GET_GLOBAL(info->normal); - scancode = GET_GLOBAL(info->normal) >> 8; - } else { - asciicode = GET_GLOBAL(info->shift); - scancode = GET_GLOBAL(info->shift) >> 8; - } + if (flags0 & GET_GLOBAL(info->lock_flags)) + keycode = GET_GLOBAL(info->normal); + else + keycode = GET_GLOBAL(info->shift); } else { /* check if lock is on */ - if (flags0 & GET_GLOBAL(info->lock_flags)) { - asciicode = GET_GLOBAL(info->shift); - scancode = GET_GLOBAL(info->shift) >> 8; - } else { - asciicode = GET_GLOBAL(info->normal); - scancode = GET_GLOBAL(info->normal) >> 8; - } + if (flags0 & GET_GLOBAL(info->lock_flags)) + keycode = GET_GLOBAL(info->shift); + else + keycode = GET_GLOBAL(info->normal); } - if (scancode==0 && asciicode==0) - dprintf(1, "KBD: scancode & asciicode are zero?\n"); - enqueue_key(scancode, asciicode); + if (!keycode) + dprintf(1, "KBD: keycode is zero?\n"); + enqueue_key(keycode); break; } flags2 &= ~KF2_LAST_E0; -- 2.5.0

1 2

Re: [SeaBIOS] [PATCH] biostables: Support SMBIOS 2.6+ UUID format
by Kevin O'Connor 16 Jan '16

16 Jan '16

On Tue, Jan 12, 2016 at 02:22:41PM -0500, Cole Robinson wrote: > SMBIOS 2.6+ stores the UUID in a different format, with the first 3 > fields in little endian format. This is what modern qemu delivers > and what dmidecode also handles, so let's follow suit too. More > info at this thread: > > http://www.seabios.org/pipermail/seabios/2015-November/010031.html > > The only place this affects is when reporting the UUID at startup. > > https://bugzilla.redhat.com/show_bug.cgi?id=1284259 > --- > src/fw/biostables.c | 51 ++++++++++++++++++++++++++++++++++++++++----------- > 1 file changed, 40 insertions(+), 11 deletions(-) > > diff --git a/src/fw/biostables.c b/src/fw/biostables.c > index cb74396..2e15f82 100644 > --- a/src/fw/biostables.c > +++ b/src/fw/biostables.c > @@ -306,17 +306,46 @@ display_uuid(void) > if (memcmp(uuid, empty_uuid, sizeof(empty_uuid)) == 0) > return; > > - printf("Machine UUID" > - " %02x%02x%02x%02x" > - "-%02x%02x" > - "-%02x%02x" > - "-%02x%02x" > - "-%02x%02x%02x%02x%02x%02x\n" > - , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] > - , uuid[ 4], uuid[ 5] > - , uuid[ 6], uuid[ 7] > - , uuid[ 8], uuid[ 9] > - , uuid[10], uuid[11], uuid[12], uuid[13], uuid[14], uuid[15]); > + /* > + * comment borrowed from dmidecode: > + * > + * As of version 2.6 of the SMBIOS specification, the first 3 > + * fields of the UUID are supposed to be encoded on little-endian. > + * The specification says that this is the defacto standard, > + * however I've seen systems following RFC 4122 instead and use > + * network byte order, so I am reluctant to apply the byte-swapping > + * for older versions. > + */ I find this comment confusing - how about something like: According to SMBIOS v2.6 the first three fields are encoded in little-endian format. Versions prior to v2.6 did not specify the encoding, but we follow dmidecode and assume big-endian encoding. > + if (SMBiosAddr->smbios_major_version > 2 || > + (SMBiosAddr->smbios_major_version == 2 && > + SMBiosAddr->smbios_minor_version >= 6)) { > + printf("Machine UUID" > + " %02x%02x%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x%02x%02x%02x%02x\n" > + , uuid[ 3], uuid[ 2], uuid[ 1], uuid[ 0] > + , uuid[ 5], uuid[ 4] > + , uuid[ 7], uuid[ 6] > + , uuid[ 8], uuid[ 9] > + , uuid[10], uuid[11], uuid[12] > + , uuid[13], uuid[14], uuid[15]); > + } else { > + printf("Machine UUID" > + " %02x%02x%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x%02x%02x%02x%02x\n" > + , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] > + , uuid[ 4], uuid[ 5] > + , uuid[ 6], uuid[ 7] > + , uuid[ 8], uuid[ 9] > + , uuid[10], uuid[11], uuid[12] > + , uuid[13], uuid[14], uuid[15]); > + } The above is okay to me, but I'd like to get Gerd's comments as well, as I think he had some concerns the last time it came up. -Kevin

4 4

Re: [SeaBIOS] about the 'mptable' issue
by Kevin O'Connor 15 Jan '16

15 Jan '16

CC'ing the seabios mailing list. On Thu, Jan 14, 2016 at 10:36:07AM +0000, Li, Liang Z wrote: > Correct something. > The actual parameter for QEMU in our test case is: > 'qemu-systerm-x86_64 -enable-kvm -smp 20 -m 2048 -no-acpi -monitor stdio > -drive file=/mnt/centos6u6.qcow, if=none, id=foo -device virtio-blk-pci, drive=foo' > > if there is no virtio-blk device: ' qemu-systerm-x86_64 -enable-kvm -smp 20 -m 2048 > -no-acpi -monitor stdio -drive file=/mnt/centos6u6.qcow', guest can boot successfully. > It seems something wrong which make the virtio-blk work incorrectly. > > Liang > > > > > Subject: about the 'mptable' issue > > > > Hi Kevin, > > > > We just found when starting QEMU with the '-smp 20 -no-acpi' option, the > > centos6.6 or rhel 7.2 guest failed to boot. By debugging, I found it's your > > seabios patch, the commit id '9ee2e26255661a' caused the failure. > > > > I don't know what issue your patch tried to fix, assuming it's the right fix, > > should we add some prompt to prevent users from using such an option? > > Crash the guest is not a good choice. > > > > > > Liang > The problem is that the mptable can grow too large to be stored in the 0xf0000-0x100000 region of memory. SeaBIOS allocates 2048 bytes for bios tables and other critical internal storage in that range - it will not allow the mptable to consume more than 600 bytes of that storage (patch 9ee2e262). If the code allows the mptable to grow unbounded then other critical allocations can fail with undesirable results. It is possible to allocate the mptable in memory above the first 1meg where the mptable size could be unbounded, but that causes Linux versions earlier than v2.6.30 to crash. It is unlikely that virtio-blk has any impact on this issue - the additional device probably just caused the mptable to slightly exceed 600 bytes. It is unlikely that the lack of the mptable is directly causing a Linux crash - more likely is that with neither an mptable nor an acpi table there is insufficient information for Linux to enumerate the machine's hardware. My initial reaction is to avoid -no-acpi on machines with 20+ cpus. Is there a reason to turn acpi off? -Kevin

2 1

[PATCH] coreboot: Check for unaligned cbfs header
by Kevin O'Connor 15 Jan '16

15 Jan '16

If the CBFS header is invalid and points to 0xffffffff it could cause SeaBIOS to read past the 4GB boundary and cause an exception. Check the alignment of the header pointer before attempting to access fields within the header. Reported-by: "Alex G." <mr.nuke.me(a)gmail.com> Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/fw/coreboot.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c index 3b9df14..4fe1292 100644 --- a/src/fw/coreboot.c +++ b/src/fw/coreboot.c @@ -421,6 +421,10 @@ coreboot_cbfs_init(void) return; struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4); + if ((u32)hdr & 0x03) { + dprintf(1, "Invalid CBFS pointer %p\n", hdr); + return; + } if (CONFIG_CBFS_LOCATION && (u32)hdr > CONFIG_CBFS_LOCATION) // Looks like the pointer is relative to CONFIG_CBFS_LOCATION hdr = (void*)hdr + CONFIG_CBFS_LOCATION; -- 2.5.0

1 1

Re: [SeaBIOS] Does SeaBIOS support eMMC?
by Kevin O'Connor 14 Jan '16

14 Jan '16

On Tue, Jan 12, 2016 at 05:07:08PM +0000, Scheithauer, Mario wrote: > > -----Ursprüngliche Nachricht----- > > Von: Kevin O'Connor [mailto:kevin@koconnor.net] > > Gesendet: Dienstag, 12. Januar 2016 17:15 > > An: Scheithauer, Mario > > Cc: seabios(a)seabios.org > > Betreff: Re: [SeaBIOS] Does SeaBIOS support eMMC? > > > > On Mon, Jan 11, 2016 at 03:49:19PM +0000, Scheithauer, Mario wrote: > > > First I will clone a new coreboot with an actual SeaBIOS. After that I > > > will give you a new log. > > > But second I think sdcard setup is not ready for JEDEC Standard > > > 84-B51. Maybe I'm wrong with that. > > > > I did use that JEDEC standard as a reference when writing the code. > > > > > Our eMMC flash has a size of 8GB but recognized are only 2GB and I > > > believe for switching to high-speed mode there are some more steps > > > necessary. > > > > SeaBIOS does not attempt to enable high speed mode or to enable multiple read > > data lines. The goal is just to boot the OS - the OS can then enable whatever > > optimizations it wants. > > Well, I understand. > > > The drive is showing up as an 2TB drive, so something is clearly wrong with the > > size detection. Upon attempting to boot from the drive, a read CRC error occurs. > > I wonder if the drive is not in sync with the controller on the number of data lines in > > use. > > I believe the mechanism to determine the size for eMMC4.5 devices are differently than up to now. > However, that is no problem. Yes - on v4.0 and later MMC devices SeaBIOS reads from the size from the EXT_CSD register. The log indicates that SEND_EXT_CSD was sent, so SeaBIOS is recognizing the hardware version, and the command completes without error. But the size results do look suspect. I double checked, and other users are reporting success on SeaBIOS with v4+ eMMC devices. > > How many SD/MMC devices are in this machine? In addition to the eMMC drive > > that is detected, another device starts the detection on a different controller but > > fails earlier in the process. Is that expected? > > We have two Storage Control Cluster, one for SDIO / SD and one for eMMC 4.5. > In my opinion a device should be only at the second SCC connected. > However, should the last version of Lubuntu not work with that? > Lubuntu detects an mmc block device (mmcblk0boot0 and mmcblk0boot1). > But the size is not correct. Both blocks have a size of 256kB. > Fdisk cannot install a partition and ends with the error message 'failed to write disklabel: Operation not permitted'. > Maybe we have a hardware issue, because the eMMC device is directly on the board. To verify if Linux can use the device, I suggest disabling CONFIG_SDCARD in SeaBIOS, hard poweroff the machine for a minute (and pull the battery if it is a laptop), and then boot Linux from another media. Linux should be able to detect/read/write the device. We've seen that some eMMC devices can get stuck in a bad mode, so a full power off may be needed. If Linux can't detect/read/write the device, then I suggest addressing that before looking at the SeaBIOS code. Otherwise, can you try the SeaBIOS patch below and report the additional debugging? -Kevin --- a/src/hw/sdcard.c +++ b/src/hw/sdcard.c @@ -490,6 +490,8 @@ sdcard_controller_setup(struct sdhci_s *regs, int prio) , readw(&regs->controller_version) , readl(&regs->cap_lo), readl(&regs->cap_hi)); sdcard_reset(regs, SRF_ALL); + dprintf(1, "hc1=%x hc2=%x\n" + , readb(&regs->host_control), readw(&regs->host_control2)); writew(&regs->irq_signal, 0); writew(&regs->irq_enable, 0x01ff); writew(&regs->irq_status, readw(&regs->irq_status)); @@ -515,6 +517,8 @@ sdcard_controller_setup(struct sdhci_s *regs, int prio) free(drive); goto fail; } + dprintf(1, "later hc1=%x hc2=%x\n" + , readb(&regs->host_control), readw(&regs->host_control2)); return; fail: writeb(&regs->power_control, 0);

2 2

[PATCH] biostables: Support SMBIOS 2.6+ UUID format
by Cole Robinson 13 Jan '16

13 Jan '16

SMBIOS 2.6+ stores the UUID in a different format, with the first 3 fields in little endian format. This is what modern qemu delivers and what dmidecode also handles, so let's follow suit too. More info at this thread: http://www.seabios.org/pipermail/seabios/2015-November/010031.html The only place this affects is when reporting the UUID at startup. https://bugzilla.redhat.com/show_bug.cgi?id=1284259 --- src/fw/biostables.c | 51 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 40 insertions(+), 11 deletions(-) diff --git a/src/fw/biostables.c b/src/fw/biostables.c index cb74396..2e15f82 100644 --- a/src/fw/biostables.c +++ b/src/fw/biostables.c @@ -306,17 +306,46 @@ display_uuid(void) if (memcmp(uuid, empty_uuid, sizeof(empty_uuid)) == 0) return; - printf("Machine UUID" - " %02x%02x%02x%02x" - "-%02x%02x" - "-%02x%02x" - "-%02x%02x" - "-%02x%02x%02x%02x%02x%02x\n" - , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] - , uuid[ 4], uuid[ 5] - , uuid[ 6], uuid[ 7] - , uuid[ 8], uuid[ 9] - , uuid[10], uuid[11], uuid[12], uuid[13], uuid[14], uuid[15]); + /* + * comment borrowed from dmidecode: + * + * As of version 2.6 of the SMBIOS specification, the first 3 + * fields of the UUID are supposed to be encoded on little-endian. + * The specification says that this is the defacto standard, + * however I've seen systems following RFC 4122 instead and use + * network byte order, so I am reluctant to apply the byte-swapping + * for older versions. + */ + if (SMBiosAddr->smbios_major_version > 2 || + (SMBiosAddr->smbios_major_version == 2 && + SMBiosAddr->smbios_minor_version >= 6)) { + printf("Machine UUID" + " %02x%02x%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x%02x%02x%02x%02x\n" + , uuid[ 3], uuid[ 2], uuid[ 1], uuid[ 0] + , uuid[ 5], uuid[ 4] + , uuid[ 7], uuid[ 6] + , uuid[ 8], uuid[ 9] + , uuid[10], uuid[11], uuid[12] + , uuid[13], uuid[14], uuid[15]); + } else { + printf("Machine UUID" + " %02x%02x%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x%02x%02x%02x%02x\n" + , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] + , uuid[ 4], uuid[ 5] + , uuid[ 6], uuid[ 7] + , uuid[ 8], uuid[ 9] + , uuid[10], uuid[11], uuid[12] + , uuid[13], uuid[14], uuid[15]); + } + return; } } -- 2.5.0

1 0

[PATCH v3 0/6] tpm: Fixes for physical presence and API
by Stefan Berger 13 Jan '16

13 Jan '16

Patch 1 fixes the return of a missing digest in the HashLogExtendEvent command. Beyond that the patches extend the handling of physical presence to HW physical presence and rework the showing of the TPM menu to depend on whether SW physical presence could be asserted or HW physical presence has been found to be enabled. Regards, Stefan v1->v2: Addressed Kevin's comments v2->v3: Addressed Kevin's comments Stefan Berger (6): tpm: Copy digest into HashLogExentEvent response tpm: Move assert_physical_presence and dependencies tpm: Add support for harware physical presence tpm: Rework the assertion of physical presence tpm: Remove usage of PP_CMD_ENABLE from all but one place tpm: Do not set TPM in failure mode if menu command fails src/boot.c | 4 +- src/std/tcg.h | 1 + src/tcgbios.c | 243 +++++++++++++++++++++------------------------------------- src/tcgbios.h | 2 +- 4 files changed, 90 insertions(+), 160 deletions(-) -- 2.4.3

2 8

Re: [SeaBIOS] Does SeaBIOS support eMMC?
by Kevin O'Connor 13 Jan '16

13 Jan '16

On Mon, Jan 11, 2016 at 03:49:19PM +0000, Scheithauer, Mario wrote: > First I will clone a new coreboot with an actual SeaBIOS. After that > I will give you a new log. > But second I think sdcard setup is not ready for JEDEC Standard > 84-B51. Maybe I'm wrong with that. I did use that JEDEC standard as a reference when writing the code. > Our eMMC flash has a size of 8GB but recognized are only 2GB and I > believe for switching to high-speed mode there are some more steps > necessary. SeaBIOS does not attempt to enable high speed mode or to enable multiple read data lines. The goal is just to boot the OS - the OS can then enable whatever optimizations it wants. The drive is showing up as an 2TB drive, so something is clearly wrong with the size detection. Upon attempting to boot from the drive, a read CRC error occurs. I wonder if the drive is not in sync with the controller on the number of data lines in use. How many SD/MMC devices are in this machine? In addition to the eMMC drive that is detected, another device starts the detection on a different controller but fails earlier in the process. Is that expected? -Kevin

2 1

Re: [SeaBIOS] Does SeaBIOS support eMMC?
by Kevin O'Connor 12 Jan '16

12 Jan '16

On Mon, Jan 11, 2016 at 02:59:00PM +0000, Scheithauer, Mario wrote: > Hello Kevin, Alexander, > > Attached is the boot log. > Thanks that you have a look at the eMMC initialization. > I will try the other way about both files (sdcard0, sdcard1). > I think for my case the address should be 0xd0520000 and 0xd0521000, or isn't it? The sdhci controller on your device is properly detected, so you should not do anything with the "etc/sdcard" settings. It looks like your eMMC device was detected as well (MMC drive R1J55A 2097151MiB), but then had an error during read. I need to take a closer look at the logs to try and figure out what went wrong. BTW, I noticed the build didn't pick up the seabios version - what version are you using and what build environment did you use to compile it? -Kevin

2 2

Re: [SeaBIOS] Does SeaBIOS support eMMC?
by Alexander Couzens 12 Jan '16

12 Jan '16

Hi Mario, SeaBIOS supports eMMC, but it's a bit hacky. For eMMC in ACPI mode you have to add files containing the address of the eMMC to the cbfs. No idea, if eMMC in PCI mode works out-of-box. cbfstool coreboot.rom add -n etc/sdcard0 -f /tmp/sdcard0 -t raw cbfstool coreboot.rom add -n etc/sdcard1 -f /tmp/sdcard1 -t raw Best, lynxis PS. Tested on a baytrail based chromebook. On Mon, 11 Jan 2016 08:29:48 +0000 "Scheithauer, Mario" <Mario.Scheithauer(a)siemens.com> wrote: > Hello Together, > > I play with coreboot and SeaBIOS on a BayTrail platform. We have an > 8GB eMMC flash on the board. With that combination I can boot a > Lubuntu. It seems that the current version of SeaBIOS does not > support High-speed eMMC. Could someone say something about that? > Are there some activities to expand sdcard.c for eMMC bus > initialisation? > > I would be grateful for any information. > > Thanks, > Mario > > -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS