SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] [Qemu-devel] [Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xiao Guangrong 17 Jul '17

17 Jul '17

On 07/17/2017 11:13 AM, Xulei (Stone) wrote: > |--virtio_queue_empty > > Then, kmod falls in infinite loop in handle EPT_MISCONFIG. > As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return > from mmio write and wait for virtio backend(qemu) to handle this mmio writing. > What puzzles me: > 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. From the trace in L1 guest, it did not hang in KVM, as it went into guest mode normally. > 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related > with vmware? > It is the issue in vmware, i guess the RIP register is not handled correctly. BTW, does kvm unit tests run well on nested vmware?

2 1

[Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xulei (Stone) 17 Jul '17

17 Jul '17

Hello all, Recently, I met a werid question when i run a VM in the following platfrom: Vmware Vsphere 6.0/6.5 |-- centos 7.3 nested VM (with qemu 2.8, kmod 4.4.11, seabios 1.10) |-- VM (with virtio-scsi controller, modern mode) VM MUST hang in seabios when try to mmio write during virtio-scsi init. I deeply analyze the code, and i found that: Seabios calltrace: scsi_drive_setup |-- cdb_get_inquiry |-- virtio_scsi_process_op |-- vring_kick |-- writew (hang here, mmio write, never return...) Kmod calltrace: handle_EPT_MISCONFIG |--kvm_io_bus_write |-- kvm_iodevice_write (fast mmio through ioeventfd to trigger qemu) |-- vcpu_run |-- vcpu_enter_guest Qemu calltrace: os_host_main_loop_wait |--glib_pollfds_poll |-- aio_dispatch |-- vritio_scsi_handle_cmd_vq |--virtio_scsi_pop_req |-- virtqueue_pop |--virtio_queue_empty Then, kmod falls in infinite loop in handle EPT_MISCONFIG. As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return from mmio write and wait for virtio backend(qemu) to handle this mmio writing. What puzzles me: 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related with vmware? Looking forward for directions... Attached Kmod ftrace: CPU 0/KVM-9435 [008] .... 241968.479572: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479573: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479573: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479583: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479589: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479589: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479599: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479600: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479601: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479610: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479616: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479617: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479627: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479628: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479628: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479638: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479644: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479644: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479655: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479656: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479656: kvm_entry: vcpu 0 ________________________________

1 0

Re: [SeaBIOS] [PATCH] Support multiple hard disks in boot list.
by Gaurav Poothia 14 Jul '17

14 Jul '17

Hi Kevin, I also tried this patch to fallback from non bootable SCSI disk to bootable SCSI disk with Windows installed. That worked too. So while we cannot see the Windows bootloader source it sure seems to be honoring the DL values other than 0x80 Thanks Gaurav On Mon, Jul 10, 2017 at 1:49 PM, Gaurav Poothia <gaurav.poothia(a)gmail.com> wrote: > Hi Kevin, > Thanks for your response! > > I have tested this successfully against grub (specifically GRUB 2) > Since you asked I went digging for the relevant code in grub - here is > the line of code that will validate range of acceptable DL values and > if acceptable jump ahead to boot from that disk and skip hardcoding DL > to 0x80: > https://github.com/coreos/grub/blob/master/grub-core/boot/i386/pc/boot.S#L2… > > So for example if bios were to set DL to 0x81 (by fallback logic in > the patch) that will be acceptable to grub > > On Fri, Jul 7, 2017 at 7:55 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Fri, Jun 30, 2017 at 08:48:27PM -0400, Gaurav Poothia wrote: >>> If multiple disks in boot order and first is unbootable >>> then fallback to other disks in list. >> [...] >>> @@ -731,7 +736,10 @@ do_boot(int seq_nr) >>> break; >>> case IPL_TYPE_HARDDISK: >>> printf("Booting from Hard Disk...\n"); >>> - boot_disk(0x80, 1); >>> + if (ie->hdid == -1) >>> + boot_disk(0x80 , 1); >>> + else >>> + boot_disk(0x80 + ie->hdid, 1); >>> break; >>> case IPL_TYPE_CDROM: >>> boot_cdrom((void*)ie->vector); >> >> Ultimately, what this patch does is set the DL register to something >> other than 0x80. I tested this approach a few years ago, and at the >> time I could not find a single bootloader that used DL. What >> bootloaders did you test with this, and which ones worked and did not >> work? >> >> -Kevin > > > > -- > Kiva.org - Loans That Change Lives -- Kiva.org - Loans That Change Lives

1 0

Re: [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages
by Ivan Ivanov 11 Jul '17

11 Jul '17

Maybe you are correct - it is hard to fill a page (get 18 entries) during the normal usage scenario - when not adding a lot of slightly different versions of payload for debug purposes... However, at least one person except me (Gerd Hoffmann) thought its a nice feature to have, so I decided to spend some time to implement and test it. If all the devices fit at 1 page - there will be no changes at user interface, no paging enabled. This paging enables by itself only when more than 18 entries are detected - only when it is necessary, all the other time this code is inactive If I remember correctly, applying this whole patch (with paging included) increases seabios rom size just by ~250 bytes, removing the paging wouldn't give any noticeable benefit in size. So personally I don't see any downsides and will continue using this patch at its' current version ;) 2017-07-12 2:16 GMT+03:00 Ivan Ivanov <qmastery16(a)gmail.com>: > Maybe you are correct - it is hard to fill a page (get 18 entries) > during the normal usage scenario - when not adding a lot of slightly > different versions of payload for debug purposes... However, at least > one person except me (Gerd Hoffmann) thought its a nice feature to > have, so I decided to spend some time to implement and test it. If all > the devices fit at 1 page - there will be no changes at user > interface, no paging enabled. This paging enables by itself only when > more than 18 entries are detected - only when it is necessary, all the > other time this code is inactive > > If I remember correctly, applying this whole patch (with paging > included) increases seabios rom size just by ~250 bytes, removing the > paging wouldn't give any noticeable benefit in size. So personally I > don't see any downsides and will continue using this patch at its' > current version ;) > > > 2017-07-07 17:51 GMT+03:00 Kevin O'Connor <kevin(a)koconnor.net>: >> On Sun, Jul 02, 2017 at 12:38:00AM +0300, Ivan Ivanov wrote: >>> Recently I discovered another area where this "35 devices" patch is useful. >>> When you need to debug a payload on the real coreboot-supported hardware, >>> to speed up the development you could include a lot of slightly different >>> versions of the same payload to your coreboot ROM, and then >>> could test them all after a single flashing, saving your time and >>> reducing the wearing out of SPI flash >> >> Sorry for the delay in responding. >> >> I think it would be useful to support more than 10 devices in the boot >> menu. I'm not convinced we need a paging menu though. I suspect that >> increasing the count to 20 (or whatever fits on a page) should be >> sufficient for now. >> >> -Kevin

1 0

cbfstool without cloning the whole repository? Use script for <2M download
by Ivan Ivanov 11 Jul '17

11 Jul '17

Dear friends, sometimes you need to do a few operations with coreboot.rom (e.g. update its' payload) without changing coreboot.rom's main code. If you have bad Internet connection or just want to quickly get the latest version of cbfstool without cloning the whole coreboot/vboot repositories - my bash script below will really help you! It downloads only the files required for the successful compilation of cbfstool - whole ./util/cbfstool directory (93 files, ~1,3M size) and all the dependencies: ./src/commonlib - 20 files, ~152K ./src/vendorcode/intel/edk2/uefi_2.4/ - 26 files, 272K ./src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h - ~4K ((( I don't understand what Intel is doing here, but I can't build without these files! ))) ./3rdparty/vboot/firmware/2lib/ - 17 files, 170K ./3rdparty/vboot/firmware/include/vb2_api.h - ~1K In total, its 158 files and just 1.9M - less than 2M ! And it builds OK. Hope it will be useful for you ;-) ### SCRIPT BEGIN ### wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/ wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \ --exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \ --reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\ fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\ timestamp_serialized.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/ed… wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fs… wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \ --reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\ 2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\ 2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h cd ./util/cbfstool/ make all ### SCRIPT END ###

1 0

[PATCH] virtio: IOMMU support
by Jason Wang 11 Jul '17

11 Jul '17

Since we don't enable IOMMU at all, we can then simply enable the IOMMU support by claiming the support of VIRITO_F_IOMMU_PLATFORM. This fixes booting failure when iommu_platform is set from qemu cli. Signed-off-by: Jason Wang <jasowang(a)redhat.com> --- src/hw/virtio-blk.c | 3 ++- src/hw/virtio-ring.h | 1 + src/hw/virtio-scsi.c | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index dca7855..901b8f5 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -118,13 +118,14 @@ init_virtio_blk(void *data) struct vp_device *vp = &vdrive->vp; u64 features = vp_get_features(vp); u64 version1 = 1ull << VIRTIO_F_VERSION_1; + u64 iommu_platform = 1ull << VIRTIO_F_IOMMU_PLATFORM; u64 blk_size = 1ull << VIRTIO_BLK_F_BLK_SIZE; if (!(features & version1)) { dprintf(1, "modern device without virtio_1 feature bit: %pP\n", pci); goto fail; } - features = features & (version1 | blk_size); + features = features & (version1 | iommu_platform | blk_size); vp_set_features(vp, features); status |= VIRTIO_CONFIG_S_FEATURES_OK; vp_set_status(vp, status); diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h index 7665fd5..8604a01 100644 --- a/src/hw/virtio-ring.h +++ b/src/hw/virtio-ring.h @@ -18,6 +18,7 @@ /* v1.0 compliant. */ #define VIRTIO_F_VERSION_1 32 +#define VIRTIO_F_IOMMU_PLATFORM 33 #define MAX_QUEUE_NUM (128) diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c index 7490ec0..4eea5c3 100644 --- a/src/hw/virtio-scsi.c +++ b/src/hw/virtio-scsi.c @@ -163,12 +163,13 @@ init_virtio_scsi(void *data) if (vp->use_modern) { u64 features = vp_get_features(vp); u64 version1 = 1ull << VIRTIO_F_VERSION_1; + u64 iommu_platform = 1ull << VIRTIO_F_IOMMU_PLATFORM; if (!(features & version1)) { dprintf(1, "modern device without virtio_1 feature bit: %pP\n", pci); goto fail; } - vp_set_features(vp, version1); + vp_set_features(vp, features & (version1 | iommu_platform)); status |= VIRTIO_CONFIG_S_FEATURES_OK; vp_set_status(vp, status); if (!(vp_get_status(vp) & VIRTIO_CONFIG_S_FEATURES_OK)) { -- 2.7.4

3 2

[PATCH] Support multiple hard disks in boot list.
by Gaurav Poothia 10 Jul '17

10 Jul '17

If multiple disks in boot order and first is unbootable then fallback to other disks in list. Signed-off-by: Gaurav Poothia <gaurav.poothia(a)gmail.com> --- src/block.c | 3 ++- src/block.h | 2 +- src/boot.c | 30 +++++++++++++++++++----------- 3 files changed, 22 insertions(+), 13 deletions(-) diff --git a/src/block.c b/src/block.c index d104f6d..5c78533 100644 --- a/src/block.c +++ b/src/block.c @@ -238,7 +238,7 @@ add_drive(struct drive_s **idmap, u8 *count, struct drive_s *drive) } // Map a hard drive -void +int map_hd_drive(struct drive_s *drive) { ASSERT32FLAT(); @@ -252,6 +252,7 @@ map_hd_drive(struct drive_s *drive) // Fill "fdpt" structure. fill_fdpt(drive, hdid); + return hdid; } // Map a cd diff --git a/src/block.h b/src/block.h index f03ec38..68f2f32 100644 --- a/src/block.h +++ b/src/block.h @@ -109,7 +109,7 @@ extern u8 *bounce_buf_fl; struct drive_s *getDrive(u8 exttype, u8 extdriveoffset); int getDriveId(u8 exttype, struct drive_s *drive); void map_floppy_drive(struct drive_s *drive); -void map_hd_drive(struct drive_s *drive); +int map_hd_drive(struct drive_s *drive); void map_cd_drive(struct drive_s *drive); struct int13dpt_s; int fill_edd(struct segoff_s edd, struct drive_s *drive_gf); diff --git a/src/boot.c b/src/boot.c index 59623fb..9b9cf91 100644 --- a/src/boot.c +++ b/src/boot.c @@ -527,16 +527,16 @@ interactive_bootmenu(void) struct bev_s { int type; u32 vector; + // Applicable to hard disks only + int hdid; }; static struct bev_s BEV[20]; static int BEVCount; static int HaveHDBoot, HaveFDBoot; static void -add_bev(int type, u32 vector) +add_bev(int type, u32 vector, int hdid) { - if (type == IPL_TYPE_HARDDISK && HaveHDBoot++) - return; if (type == IPL_TYPE_FLOPPY && HaveFDBoot++) return; if (BEVCount >= ARRAY_SIZE(BEV)) @@ -544,12 +544,15 @@ add_bev(int type, u32 vector) struct bev_s *bev = &BEV[BEVCount++]; bev->type = type; bev->vector = vector; + bev->hdid = hdid; } + // Prepare for boot - show menu and run bcvs. void bcv_prepboot(void) { + int hdid = -1; if (! CONFIG_BOOT) return; @@ -563,28 +566,30 @@ bcv_prepboot(void) switch (pos->type) { case IPL_TYPE_BCV: call_bcv(pos->vector.seg, pos->vector.offset); - add_bev(IPL_TYPE_HARDDISK, 0); + add_bev(IPL_TYPE_HARDDISK, 0, -1); break; case IPL_TYPE_FLOPPY: map_floppy_drive(pos->drive); - add_bev(IPL_TYPE_FLOPPY, 0); + add_bev(IPL_TYPE_FLOPPY, 0, -1); break; case IPL_TYPE_HARDDISK: - map_hd_drive(pos->drive); - add_bev(IPL_TYPE_HARDDISK, 0); + hdid = map_hd_drive(pos->drive); + add_bev(IPL_TYPE_HARDDISK, 0, hdid); + HaveHDBoot++; break; case IPL_TYPE_CDROM: map_cd_drive(pos->drive); // NO BREAK default: - add_bev(pos->type, pos->data); + add_bev(pos->type, pos->data, -1); break; } } // If nothing added a floppy/hd boot - add it manually. - add_bev(IPL_TYPE_FLOPPY, 0); - add_bev(IPL_TYPE_HARDDISK, 0); + add_bev(IPL_TYPE_FLOPPY, 0, -1); + if (HaveHDBoot == 0) + add_bev(IPL_TYPE_HARDDISK, 0, -1); } @@ -731,7 +736,10 @@ do_boot(int seq_nr) break; case IPL_TYPE_HARDDISK: printf("Booting from Hard Disk...\n"); - boot_disk(0x80, 1); + if (ie->hdid == -1) + boot_disk(0x80 , 1); + else + boot_disk(0x80 + ie->hdid, 1); break; case IPL_TYPE_CDROM: boot_cdrom((void*)ie->vector); -- 1.8.3.1

2 2

Re: [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages
by Kevin O'Connor 07 Jul '17

07 Jul '17

On Sun, Jul 02, 2017 at 12:38:00AM +0300, Ivan Ivanov wrote: > Recently I discovered another area where this "35 devices" patch is useful. > When you need to debug a payload on the real coreboot-supported hardware, > to speed up the development you could include a lot of slightly different > versions of the same payload to your coreboot ROM, and then > could test them all after a single flashing, saving your time and > reducing the wearing out of SPI flash Sorry for the delay in responding. I think it would be useful to support more than 10 devices in the boot menu. I'm not convinced we need a paging menu though. I suspect that increasing the count to 20 (or whatever fits on a page) should be sufficient for now. -Kevin

1 0

Re: [SeaBIOS] [PATCH] ahci: Disable Native Command Queueing
by Kevin O'Connor 02 Jul '17

02 Jul '17

On Fri, Jun 23, 2017 at 07:18:04AM +0000, Zeh, Werner wrote: > The AHCI driver currently sets the NCQ bit for every command that is > issued to the SATA drive. This is not needed as there is always > only one command active at a time and in turn can lead to a hanging > AHCI controller (true for Marvel 88SE9170). The following patch > disables the usage of NCQ completely. With this patch the Marvel > AHCI controller works just fine without any issues. Thanks. I committed this patch. -Kevin

1 0

Re: [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages
by Ivan Ivanov 01 Jul '17

01 Jul '17

Recently I discovered another area where this "35 devices" patch is useful. When you need to debug a payload on the real coreboot-supported hardware, to speed up the development you could include a lot of slightly different versions of the same payload to your coreboot ROM, and then could test them all after a single flashing, saving your time and reducing the wearing out of SPI flash Best regards, Ivan Ivanov aka qmastery 2017-06-13 11:00 GMT+03:00 Ivan Ivanov <qmastery16(a)gmail.com>: > 2017-06-12 22:04 GMT+03:00 Kevin O'Connor <kevin(a)koconnor.net>: >> On Sun, Jun 11, 2017 at 12:41:22AM +0300, Ivan Ivanov wrote: >>> Extend boot menu: make it possible to select the boot menu entries >>> with ID larger than 10 by pressing a corresponding letter key. If >>> there are more than 18 devices, then a boot menu splits into two >>> pages; you can switch between the pages by pressing the ENTER key. >>> NOTE: now to access the TPM you need to press the M key. It makes more >>> sense, because Trusted is adjective while Module is noun - and adds >>> more convenience, because M letter is at the end of keyboard's 3rd row >>> of letters, not in the middle of them >> >> Thanks. Can you describe a real-world situation where one would have >> more than 10 boot devices and one would be using the boot menu? >> >> -Kevin > > In addition to boot devices, payloads are also taking the menu entries > > Current situation at my laptop: > two floppy ramdisks - floppy operating systems KolibriOS and MenuetOS, > one CD/DVD drive, one HDD, 6 payloads (filo,memtest,tint,nvramcui, > coreinfo,iPXE) . Even without USB flash drives its already 10 payloads > > And this is just a laptop, which has just 2 SATA menu entries. > Meanwhile, desktop motherboards usually have 6-8 SATA ports, > and a pretty typical situation for power user is 4 hard drives, > one SSD and one CD/DVD drive - at least 6 reserved boot menu entries. > In my case that would have been at least 14 boot menu entries total, > even without any USBs > > At SeaBIOS mailing list (December 2016 - January 2017) there already > was a discussion about this problem (copied below) but it is 6 months > after your patch request and nobody has submitted , - so here i am! ;) > > Probably the easiest way to test my patch is to add a lot of fake > boot entries with different print messages - all inside boot.c file - > and test in QEMU with various amounts of fake entries commented out. > If you would like, I could send my altered boot.c for test purposes > > However, if for some reason my patch cannot be included to SeaBIOS, > I will still be using it locally, at least for me it is very useful :) > > === > Аладышев Константин aladyshev at nicevt.ru - Dec 28 2016 > Is it possible in SeaBIOS to have working boot menu with amount of > boot devices more than 9? I mean in this case we have boot device > numbers with two digits, which is impossible to select. If I want to > select string 12 and try to enter "12", SeaBIOS recognizes "1" and > boot from device "1"... > > Kevin O'Connor kevin at koconnor.net - Dec 29 2016 > The internal code can handle more than 9 devices, but unfortunately > the menu code would need to be updated to display meaningful keys and > to check for them on entry. > > Аладышев Константин aladyshev at nicevt.ru - Dec 29 2016 > Will there be such a patch in the near future? Or this isn't in a plan > right now? Anyway, what is the right way to deal with this situation? > Display letters or symbols after "9"? Or deal with two digit numbers? > > Dennis Guse dennis.guse at alumni.tu-berlin.de - Dec 29 2016 > I like your letters idea! > > Kevin O'Connor kevin at koconnor.net - Dec 30 2016 > Someone would need to submit a patch to make it work. In the mean > time, 0 should work for 10, - for 11, = for 12, tab for 13 - see the > scan_to_keycode table in kbd.c for the rest. > > Gerd Hoffmann kraxel at redhat.com - Jan 3 2017 > Using letters is neat, we can continue to work with single key strokes > and can handle up to 36 entries. Well, in practice more like 24 > entries because vga text mode has 25 lines only. Supporting more than > 24 entries in a reasonable manner is more complex as we will need > support for scrolling the boot menu then. > === > > Best regards, > Ivan Ivanov aka qmastery

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS