Hi,
I use the simple coreboot config
https://github.com/merge/skulls/blob/master/x230/free-defconfig-555419f356
on today's coreboot master branch HEAD (403f433238), using SeaBIOS 1.12.1.
When choosing memtest86+ in SeaBIOS' menu, "Booting from CBFS" gets
printed but nothing else happens.
Booting into nvramcui or coreinfo works though.
(earlier, at least on coreboot 555419f356, using the same version of
SeaBIOS, things were fine).
Can you imagine why?
thanks,
martin
Hello,
this is my attempt to address the review comments I got for v2:
- Gerd pointed out that cbvesa should only use the modes where memmodel
== MM_DIRECT.
- Kevin noted that reading global variables need the GET_GLOBAL
wrapper. (I would have expected that the compiler does the right
thing here. Probably I'm still to wet behind the ears here :-)
Note this is only compile tested.
Uwe Kleine-König (2):
cbvga: reuse svga modes definitions from svgamodes.c
Add additional resolutions for 16:9 displays: 1600x900 and 2560x1440
vgasrc/cbvga.c | 80 ++++++----------------------------------------
vgasrc/svgamodes.c | 8 +++++
2 files changed, 17 insertions(+), 71 deletions(-)
--
2.20.1
v1:
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56 SPT (sectors per track).
No matter what QEMU will guess - SeaBIOS, for large enough disks - will
use LBA translation, which will report 63 SPT instead.
In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
report more than 16 physical heads when moved to an IDE controller, the
ATA spec allows a maximum of 16 heads - this is an artifact of
virtualization.
By supplying the logical geometies directly we are able to support such
"exotic" disks.
We will use fw_cfg to do just that.
v2:
Fix missing parenthesis check in
"hd-geo-test: Add tests for lchs override"
v3:
* Rename fw_cfg key to "bios-geometry".
* Remove "extendible" interface.
* Add cpu_to_le32 fix as Laszlo suggested or big endian hosts
* Fix last qtest commit - automatic docker tester for some reason does not have qemu-img set
v4:
* Change fw_cfg interface from mixed textual/binary to textual only
v5:
* Fix line > 80 chars in tests/hd-geo-test.c
v6:
* Small fixes for issues pointed by Max
* (&conf->conf)->lcyls to conf->conf.lcyls and so on
* Remove scsi_unrealize from everything other than scsi-hd
* Add proper include to sysemu.h
* scsi_device_unrealize() after scsi_device_purge_requests()
Sam Eiderman (8):
block: Refactor macros - fix tabbing
block: Support providing LCHS from user
bootdevice: Add interface to gather LCHS
scsi: Propagate unrealize() callback to scsi-hd
bootdevice: Gather LCHS from all relevant devices
bootdevice: Refactor get_boot_devices_list
bootdevice: FW_CFG interface for LCHS values
hd-geo-test: Add tests for lchs override
bootdevice.c | 148 ++++++++--
hw/block/virtio-blk.c | 6 +
hw/ide/qdev.c | 7 +-
hw/nvram/fw_cfg.c | 14 +-
hw/scsi/scsi-bus.c | 16 ++
hw/scsi/scsi-disk.c | 12 +
include/hw/block/block.h | 22 +-
include/hw/scsi/scsi.h | 1 +
include/sysemu/sysemu.h | 4 +
tests/Makefile.include | 2 +-
tests/hd-geo-test.c | 582 +++++++++++++++++++++++++++++++++++++++
11 files changed, 773 insertions(+), 41 deletions(-)
--
2.23.0.187.g17f5b7556c-goog
Good day,
A have a Samsung Series 3 Chromebox on which I installed SeaBIOS (version 181214_15:29-johnlewis.ie) a few years ago.
I then installed Linux Mint, along with a GRUB.
I would like to know how to access the BIOS settings, i.e. which key or combination of keys do I press at boot time?
SeaBIOS displays "press ESC for boot menu" at boot time, but this just gives me the GRUB menu, not the BIOS settings.
The main reason that I need to access the BIOS settings is because it is not prioritising booting from USB over the hard drive (which is SSD).
Kind regards,
Chris
v1:
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56 SPT (sectors per track).
No matter what QEMU will guess - SeaBIOS, for large enough disks - will
use LBA translation, which will report 63 SPT instead.
In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
report more than 16 physical heads when moved to an IDE controller, the
ATA spec allows a maximum of 16 heads - this is an artifact of
virtualization.
By supplying the logical geometies directly we are able to support such
"exotic" disks.
We will use fw_cfg to do just that.
v2:
Fix missing parenthesis check in
"hd-geo-test: Add tests for lchs override"
v3:
* Rename fw_cfg key to "bios-geometry".
* Remove "extendible" interface.
* Add cpu_to_le32 fix as Laszlo suggested or big endian hosts
* Fix last qtest commit - automatic docker tester for some reason does not have qemu-img set
v4:
* Change fw_cfg interface from mixed textual/binary to textual only
v5:
* Fix line > 80 chars in tests/hd-geo-test.c
Sam Eiderman (8):
block: Refactor macros - fix tabbing
block: Support providing LCHS from user
bootdevice: Add interface to gather LCHS
scsi: Propagate unrealize() callback to scsi-hd
bootdevice: Gather LCHS from all relevant devices
bootdevice: Refactor get_boot_devices_list
bootdevice: FW_CFG interface for LCHS values
hd-geo-test: Add tests for lchs override
bootdevice.c | 148 +++++++++---
hw/block/virtio-blk.c | 6 +
hw/ide/qdev.c | 7 +-
hw/nvram/fw_cfg.c | 14 +-
hw/scsi/scsi-bus.c | 15 ++
hw/scsi/scsi-disk.c | 14 ++
include/hw/block/block.h | 22 +-
include/hw/scsi/scsi.h | 1 +
include/sysemu/sysemu.h | 4 +
tests/Makefile.include | 2 +-
tests/hd-geo-test.c | 582 +++++++++++++++++++++++++++++++++++++++++++++++
11 files changed, 774 insertions(+), 41 deletions(-)
--
2.13.3
[cross posting QEMU & SeaBIOS]
Hello,
I'v been looking at a QEMU bug report [1] which bisection resulted in a
SeaBIOS commit:
4a6dbcea3e412fe12effa2f812f50dd7eae90955 is the first bad commit
commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955
Author: Nikolay Nikolov <nickysn(a)users.sourceforge.net>
Date: Sun Feb 4 17:27:01 2018 +0200
floppy: Use timer_check() in floppy_wait_irq()
Use timer_check() instead of using floppy_motor_counter in BDA for the
timeout check in floppy_wait_irq().
The problem with using floppy_motor_counter was that, after it reaches
0, it immediately stops the floppy motors, which is not what is
supposed to happen on real hardware. Instead, after a timeout (like in
the end of every floppy operation, regardless of the result - success,
timeout or error), the floppy motors must be kept spinning for
additional 2 seconds (the FLOPPY_MOTOR_TICKS). So, now the
floppy_motor_counter is initialized to 255 (the max value) in the
beginning of the floppy operation. For IRQ timeouts, a different
timeout is used, specified by the new FLOPPY_IRQ_TIMEOUT constant
(currently set to 5 seconds - a fairly conservative value, but should
work reliably on most floppies).
After the floppy operation, floppy_drive_pio() resets the
floppy_motor_counter to 2 seconds (FLOPPY_MOTOR_TICKS).
This is also consistent with what other PC BIOSes do.
This commit improve behavior with real hardware, so maybe QEMU is not
modelling something or modelling it incorrectly?
Regards,
Phil.
PD: How to reproduce:
- Download Windows 98 SE floppy image from [2]
- Run QEMU using the 'isapc' machine:
$ qemu-system-i386 -M isapc \
-fda Windows\ 98\ Second\ Edition\ Boot.img
SeaBIOS (version rel-1.11.0-11-g4a6dbce-prebuilt.qemu.org)
Booting from Floppy...
Boot failed: could not read the boot disk
[1] https://bugs.launchpad.net/qemu/+bug/1840719
[2] https://winworldpc.com/download/417d71c2-ae18-c39a-11c3-a4e284a2c3a5
Hi all-
I've found only vague references to doing this (
https://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Suppor…),
and no real guides / examples.
Before I go on a wild goose chase, has anyone tried this before?
I've tried the other way around, loading DUET from SeaBIOS, but all I get
is a brief message that's too short to read properly (but it looks like
it's loading memory locations, didn't see any errors), then I land back at
SeaBIOS.
Any pointers would be appreciated!
Cheers,
R
