SeaBIOS

seabios@seabios.org

3775 discussions

Unable to Debug out/rom.o(seabios) with GDB in x86_64 system?
by 2405700533＠qq.com 04 Feb '21

04 Feb '21

## Question Once l input `run` in `gdb out/rom.o` command prompt, The progrem will crash with error `During startup program terminated with signal SIGSEGV, Segmentation fault.` ## Reproduce As what the website(https://www.seabios.org/Debugging) said, I add '-s -S' to the QEMU command line and start qemu-system-x86_64. And then, I open another terminal to run `gdb out/rom.o`. Once in gdb, after l input `target remote localhost:1234`, the gdb have warning(warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 && warning: Architecture rejected target-supplied description). I set a break point `b do_boot`, and input `run`. To my surprise, the gdb command prompt throws a error `During startup program terminated with signal SIGSEGV, Segmentation fault.` ``` The first terminal # /usr/bin/qemu-system-x86_64 \ -name guest=VM,debug-threads=on \ -bios /root/qemu/out/bios.bin \ -S -s\ -machine pc-i440fx-5.0,accel=kvm,usb=off,dump-guest-core=off \ -cpu Broadwell-IBRS,vmx=off \ -m size=2097152k,slots=64,maxmem=268435456k \ -overcommit mem-lock=off \ -smp 3,maxcpus=4,sockets=2,dies=1,cores=2,threads=1 \ -numa node,nodeid=0,cpus=0-1,cpus=3,mem=1365 \ -numa node,nodeid=1,cpus=2,mem=683 \ -uuid bee8da7f-b699-4f20-9e82-091e809b6e47 \ -no-user-config \ -nodefaults \ -rtc base=utc \ -no-shutdown \ -boot strict=on \ -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x3 \ -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0x4 \ -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ -device usb-ehci,id=usb1,bus=pci.0,addr=0x8 \ -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x9 \ -device ich9-usb-ehci1,id=usb3,bus=pci.0,addr=0xa.0x7 \ -device ich9-usb-uhci1,masterbus=usb3.0,firstport=0,bus=pci.0,multifunction=on,addr=0xa \ -device ich9-usb-uhci2,masterbus=usb3.0,firstport=2,bus=pci.0,addr=0xa.0x1 \ -device ich9-usb-uhci3,masterbus=usb3.0,firstport=4,bus=pci.0,addr=0xa.0x2 \ -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x7 \ -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0xb \ -device ide-cd,bus=ide.1,unit=1,id=ide0-1-1,bootindex=1 \ -device floppy,unit=0,id=fdc0-0-0 \ -blockdev '{"driver":"iscsi","portal":"{ip1}:{port1}","target":"{lun}","lun":1,"transport":"tcp","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=2,write-cache=on \ -spice port=5903,addr=::0.0.0.0,image-compression=lz,streaming-video=all,seamless-migration=on \ -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios ``` ``` The Second Terminal # gdb out/rom.o GNU gdb (GDB) Red Hat Enterprise Linux 8.2-12.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from out/rom.o...done. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 warning: Architecture rejected target-supplied description Remote 'g' packet reply is too long (expected 312 bytes, got 608 bytes): 000000000000000000000000000000000000000000000000d206030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000200000000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 (gdb) b do_boot Breakpoint 1 at 0xf0f31: file ./src/boot.c, line 975. (gdb) r Starting program: /root/qemu/out/rom.o During startup program terminated with signal SIGSEGV, Segmentation fault. (gdb) ``` ## some env info ``` # cat /etc/redhat-release CentOS Linux release 8.2.2004 (Core) # uname -a Linux TOS-1048 4.18.0-167.el8.x86_64 #9 SMP Mon Jul 20 16:03:29 CST 2020 x86_64 x86_64 x86_64 GNU/Linux # gdb --version GNU gdb (GDB) Red Hat Enterprise Linux 8.2-12.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. # /usr/bin/qemu-system-x86_64 --version QEMU emulator version 5.0.0 Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers ```

1 1

[PATCH 1/4] pci: Allow scanning pci bus number up to 255 in CSM mode
by Bin Gao 27 Jan '21

27 Jan '21

On real hardware especially server platforms, there might be multiple root buses, thus pci bus number could run up to 255. This patch fixed pci_probe_devices() by allowing to scan all 256 pci bus numbers(0-255). Signed-off-by: Bin Gao <gaobin(a)amazon.com> --- src/hw/pcidevice.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/hw/pcidevice.c b/src/hw/pcidevice.c index 8853cf7..8d9c401 100644 --- a/src/hw/pcidevice.c +++ b/src/hw/pcidevice.c @@ -26,6 +26,14 @@ pci_probe_devices(void) struct hlist_node **pprev = &PCIDevices.first; int extraroots = romfile_loadint("etc/extra-pci-roots", 0); int bus = -1, lastbus = 0, rootbuses = 0, count=0; + + // There might be multiple PCI root buses on physical hardware especially + // server platforms, thus bus number could run up to the top value, + // i.e. 0xff. Setting extraroots to 0xff to ensure we can enumerate all + // PCI bus numbers. + if (CONFIG_CSM) + extraroots = 0xff; + while (bus < 0xff && (bus < MaxPCIBus || rootbuses < extraroots)) { bus++; int bdf; -- 2.17.1

5 18

CDOS 386 keyboard handling
by LE LIEGARD, Stephane 07 Jan '21

07 Jan '21

Hello, Host : centos 7 Guest : Concurrent DOS 386 v3.00 (problem also happen on DOS 3.0) QEMU : v5.1.0 Virtualbox : v6.1.14 Seabios : seabios-rel-1.13.0 I first started to run some tests to debug the alt-gr behavior, and I ended up noticing something strange. This issue is the same as this one: https://bugs.launchpad.net/qemu/+bug/1574246 So I have an old computer with CDOS installed directly on it (i486-DX2 processeur), and I have to virtualize it with QEMU. Lets call this computer “antique”. When I run the command ‘n’ in cdos, I select French and I install AZERTY 102 keys 8 bit keyboard. Then when i press alt-gr + 3, on antique and vbox it display ‘#’, but on QEMU ,it doesn’t, it print the gibberish ^@ sequence. So VBox handle keyboard input properly, but not qemu. I investigated to see if the problem was how QEMU interpret the alt-gr, and I thought it was, because the flags set in registers AH and AL when I press alt-gr are the same as when I press Alt (AH=0x2, AL=0x8) according to this site: http://helppc.netcore2k.net/table/bda : AH – 40:18 AL – 40:17 So I launched qemu and vbox in debug mode, with gdb for qemu and the included debbuger for vbox. By breaking on 0xF000:0xFFF0 and inspecting the IVT, I could see that CDOS replaces the IRQ handler because the address stored at 0x24 (irq 9) change after I resume execution, and when I inspect the machine code at 0xAF:0x618 (address of the IRQ 9 stored in 0x24 after cdos has started), it’s the same on qemu and vbox. The behavior and scancodes received are the same on QEMU and VBox in the CDOS irq 1 handler. I break on the respective BIOS irq 1 handler, called from the CDOS irq 1 handler, and at this point the byte read on 0x60 differs. Exemple for alt-gr, so 0xE038: * … * %000000000000113f e4 60 in AL, 060h // CDOS read 0xE0 from port 0x60 * … * CDOS call bios handler * … * %00000000000fe987 e4 60 in AL, 060h // VBOX bios read 0xE0, QEMU bios read 0x38 * … I didn’t see any command from CDOS irq 1 handler that would tell the PS2 controller to refeed the last byte read on the port 0x60, and all the BIOS does before the read is to deactivate the keyboard by writing 0xAD to port 0x64, so I think the issue could be from how the ps2 controller is emulated on QEMU. Somehow, VBOX knows that it has to keep the value in it’s output buffer after the first read, or maybe some kind of timer, idk. I join to this mail the asm of the CDOS irq 1 handler that I extracted from the debugger. If someone could help me to create a fix, even not official, that we could use on our project. Thanks a lot. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

2 2

[PATCH] Support booting USB drives with a write protect switch enabled
by Mike Banon 27 Dec '20

27 Dec '20

At least some USB drives with a write protect switch (e.g. Netac U335) could report "MEDIUM NOT PRESENT" for a while if a write protection is enabled. Instead of stopping the initialization attempts immediately, stop only after getting this report for 3 times, to ensure the successful initialization of such a "broken hardware". Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c index 1f15081..6b6fea9 100644 --- a/src/hw/blockcmd.c +++ b/src/hw/blockcmd.c @@ -144,8 +144,9 @@ scsi_is_ready(struct disk_op_s *op) dprintf(6, "scsi_is_ready (drive=%p)\n", op->drive_fl); /* Retry TEST UNIT READY for 5 seconds unless MEDIUM NOT PRESENT is - * reported by the device. If the device reports "IN PROGRESS", + * reported by the device 3 times. If the device reports "IN PROGRESS", * 30 seconds is added. */ + int tries = 3; int in_progress = 0; u32 end = timer_calc(5000); for (;;) { @@ -167,8 +168,11 @@ scsi_is_ready(struct disk_op_s *op) // Sense succeeded. if (sense.asc == 0x3a) { /* MEDIUM NOT PRESENT */ - dprintf(1, "Device reports MEDIUM NOT PRESENT\n"); - return -1; + tries--; + dprintf(1, "Device reports MEDIUM NOT PRESENT - %d tries left\n", + tries); + if (!tries) + return -1; } if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {

2 4

Open Source Firmware and Bootloader devroom CFP
by Michał Żygowski 04 Dec '20

04 Dec '20

Hi, The Open Source Firmware, BMC and Bootloader devroom will take place on Sunday, 7th February 2021 at FOSDEM, virtual. Call for Participation ---------------------- We are opening the call for participation to our devroom, with the deadline for talk proposals set to Sunday, 20th December 2020 23:59:59 UTC. Devroom Scope ------------- The devroom will focus on various topics related to the open source firmware, BMC and bootloaders including security issues. It will help to get together all interested people in one place, present and discuss current developments and issues haunting the community. Additionally, it will foster awareness among attendees about pre-OS topics. Possible topics: GRUB, TrustedGRUB, iPXE, TrenchBoot, coreboot, LinuxBoot, SeaBIOS, UEFI, OVMF, TianoCore, hostboot, IPMI, OpenBMC, u-bmc, TPM, attestation, security of firmware, BMC, bootloaders and related topics and technologies. Ideal submissions are actionable and opinionated. Submissions may be in the form of 25 or 45 minutes talks, panel sessions or round-table discussions. Dates ----- Submission Deadline: 20-Dec-2020 @ 23:59:59 UTC Acceptance Notification: 31-Dec-2020 Final Schedule Posted: 31-Dec-2020 Recording and uploading presentations: 04-Jan-2021 - 16-Jan-2021 Processing, reviewing, fixing videos: 17-Jan-2021 - 31-Jan-2021 How to submit -------------- Visit https://penta.fosdem.org/submission/FOSDEM21 1) If you do not have an account, create one here 2) Click "Create Event" 3) Enter your presentation details 4) Be sure to select the Open Source Firmware, BMC and Bootloader devroom track! 5) Submit What to include --------------- - The title of your submission - A 1-paragraph abstract - A longer description including the benefit of your talk to your target audience, including a definition of your target audience - Approximate length/type of submission (talk, BoF, ...) - Links to related websites/blogs/talk material (if any) Administrative Notes -------------------- Since the FOSDEM21 is going virtual, the talks will be prerecorded. We will be streaming the recordings and performing live Q&A of the Open Source Firmware, BMC and Bootloader devroom. Presenting at FOSDEM implies permission to record your session and distribute the recording afterwards. All videos will be made available under the standard FOSDEM content license (CC-BY). If you have any questions, feel free to contact the devroom organizers: Daniel Kiper (daniel.kiper at oracle.com) and Michał Żygowski (michal.zygowski at 3mdeb.com). Daniel & Michał

1 0

Re: [coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?
by Mike Banon 17 Nov '20

17 Nov '20

Hi Nico, thank you very much for your kind help, it really helped to advance! Please could you answer a small question: While cleaning up some code I noticed there are Misc,Misc0,Misc1,Misc2 interrupts - with the following "magic" values respectively: mainboard_picr_data: [0x08] = 0x5A,0xF1,0x00,0x00, mainboard_intr_data: [0x08] = 0x00,0x00,0x00,0x00, I tried replacing all these values by 0x1F ("unused") : the _intr_data 0x1F values got reverted to 0x00 during the boot time, while the _picr_data 0x1F values stayed - but caused a SeaBIOS to hang while booting (so I had to unbrick a laptop). Do you have any guess: from where these 0x5A,0xF1,0x00,0x00 values for Misc interrupts come from, and why are they essential for a SeaBIOS to work? Bolton FCH BIOS Dev Guide doesn't tell anything about them, just mentions their offsets. Best regards, Mike On Wed, Nov 11, 2020 at 2:43 AM Nico Huber <nico.h(a)gmx.de> wrote: > > Hi Mike, > > On 10.11.20 19:22, Mike Banon wrote: > > Thank you very much for your advice, dear Naresh, I will try matching > > the UEFI routing. > > I wouldn't expect too much. If things are configurable in the chipset > (they usually are these days) it's possible that coreboot configures > them differently and then the tables have to differ too. > > >> this old "getpir" utility may help you ;) > >> You may have to run: > >> coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677 > > > > What I already discovered: > > *) To activate the irq_tables.c / intel_irq_routing_table code, I need > > to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I > > don't see it having any visible effect on the IRQ routing: instead, > > maybe this intel_irq_routing_table is supposed to be a reflection of > > this routing? > > I would only give these things a look if you are 200% sure that you need > it. Basically no major OS has used these in two decades, hence most of > it in coreboot is untested and broken. I wouldn't be surprised if there > isn't a single case of correct PIRQ tables in the tree. > > You should check what KolibriOS actually uses. If it's not ACPI there > are these three options (that I know about): > > * MP table > * PIRQ tables > * INT_LINE registers in each PCI device' configuration space > > The latter is both exceptionally simple and fragile. It ignores that > the OS could make any changes at runtime. The expected IRQ number for > each PCI device is simply written into that register by the firmware. > It's ignored by the hardware but can be read by the OS. Here's a > simple example: > > * Assuming there's a device PCI 03:00.0 triggering PCI INTA. > * The chipset is configured to translate that to PIRQ_B. > * PIRQ_B is configured to trigger IRQ 4. > * Then coreboot would just write 4 into INT_LINE of 03:00.0. > > The OS could then pick that 4 up and it would work as long as nothing > changes the PIRQ configuration. As all the PIRQ information is lost, > the OS can't optimize things; but KolibriOS probably wouldn't want to? > > > *) By adding to mainboard.c / mainboard_pirq_data structure these lines > > {NB_PCIE_PORT3_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* > > x4 PCIe: 02.3 */ /* 0:04.00 / 2:00.00 - IRQ 3 */ > > {NB_PCIE_PORT4_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* > > x4 PCIe: 02.4 */ /* 0:05.00 / 3:00.00 - IRQ 3 */ > > I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00 > > devices, which are behind the 0:04.00 and 0:05.00 bridges > > respectively. And this assignment is even visible by KolibriOS now! > > But I don't know if it's normal that a lot of devices are sharing the > > same IRQ 3 now, is it bad? > > If sharing is bad depends on the type of devices. As long as they > are all PCI devs, it should work (maybe not at maximum efficiency). > But if, for instance, it's shared with a legacy UART port, that > couldn't work (different mode of IRQ, level vs. edge triggered). > > I'm not 100% sure, but it seems that with these lines you can > control how an interrupt INTA (/B/C/D) message (PCIe always uses > in-band messages) is interpreted by the chipset. It looks like > you tell it INTA (the most used one) will trigger PIRQ_A, INTB > PIRQ_B, etc. If it's really configurable (otherwise I don't see > why there should be such a table), you could try to shuffle these > around. e.g. > > { NB_PCIE_PORT4_DEVFN, { PIRQ_B, PIRQ_C, PIRQ_D, PIRQ_A } }, > > > > Hope that helps, > Nico

1 0

Re: [PATCH] nvme: Clean up nvme_cmd_readwrite()
by David Woodhouse 16 Nov '20

16 Nov '20

On Wed, 2020-11-04 at 23:27 +0000, Graf (AWS), Alexander wrote: > > Am 31.10.2020 um 00:49 schrieb David Woodhouse <dwmw2(a)infradead.org>: > > > > From: David woodhouse <dwmw(a)amazon.co.uk> > > > > This ended up with an odd mix of recursion (albeit *mostly* tail-recursion) > > and interation that could have been prettier. Make it prettier by making > > nvme_build_prpl() return the number of blocks it consumes, and just > > looping. > > > > If nvme_build_prpl() doesn't want to play, just fall through to the > > original loop. > > > > Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> > > Please don't merge just yet. I think we found a bug with this patch, > but need to find out where exactly. Found both of them :) > > @@ -725,34 +726,28 @@ nvme_cmd_readwrite(struct nvme_namespace *ns, struct disk_op_s *op, int write) > > { > > int res = DISK_RET_SUCCESS; > > u16 const max_blocks = NVME_PAGE_SIZE / ns->block_size; > > - u16 i; > > + u16 i, blocks; > > > > - /* Split up requests that are larger than the device can handle */ > > - if (op->count > ns->max_req_size) { > > - u16 count = op->count; > > + while (op->count && ((blocks = nvme_build_prpl(ns, op)) > 0)) { 1. If nvme_build_prpl() returns -1 that becomes (u16)0xFFFF and that's >0. > > + res = nvme_io_readwrite(ns, op->lba, ns->prp1, blocks, write); > > + dprintf(5, "ns %u %s lba %llu+%u: %d\n", ns->ns_id, write ? "write" > > + : "read", > > + op->lba, blocks, res); > > > > - /* Handle the first max_req_size elements */ > > - op->count = ns->max_req_size; > > - if (nvme_cmd_readwrite(ns, op, write)) > > + if (res != DISK_RET_SUCCESS) > > return res; > > > > - /* Handle the remainder of the request */ > > - op->count = count - ns->max_req_size; > > - op->lba += ns->max_req_size; > > - op->buf_fl += (ns->max_req_size * ns->block_size); 2. We can't do this. Callers expect op->count to contain the number of blocks of I/O actually performed... > > - return nvme_cmd_readwrite(ns, op, write); > > - } > > - > > - if (!nvme_build_prpl(ns, op)) { > > - /* Request goes via PRP List logic */ > > - return nvme_io_readwrite(ns, op->lba, ns->prp1, op->count, write); > > + op->count -= blocks; > > + op->lba += blocks; > > + op->buf_fl += (blocks * ns->block_size); ... which means that when my cleanup made it happen unconditionally instead of only in the case where the max size had been exceeded and it actually had to recurse, it started showing up in the test runs. But commit 94f0510dc has the problem already. Running another full test set now, will post the fixed patch when it completes.

2 3

Universal Payload Project
by Paul Menzel 29 Oct '20

29 Oct '20

Dear coreboot, GRUB, and SeaBIOS folks, In #coreboot(a)irc.freenode.net somebody mentioned the Universal Payload Project [1]. > The goal of this project is to define an interface between a first > stage platform initialization bootloader and a second stage payload. As there also is a specification [2], I just wanted to make you aware of it, in case you have comments. Please keep in mind, that I do not know more details, so please do not jump to conclusions. Kind regards, Paul [1]: https://github.com/universalpayload/Introduction [2]: https://universalpayload.github.io/documentation/spec/spec.html

1 0

[PATCH] usb boot: add xhci mmio example
by Gerd Hoffmann 15 Oct '20

15 Oct '20

Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/boot.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/boot.c b/src/boot.c index bd78fb907c5a..1effd802ce06 100644 --- a/src/boot.c +++ b/src/boot.c @@ -423,7 +423,9 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int lun) { if (!CONFIG_BOOTORDER) return -1; - // Find usb - for example: /pci@i0cf8/usb@1,2/storage@1/channel@0/disk@0,0 + // Find usb - examples: + // pci: /pci@i0cf8/usb@1,2/storage@1/channel@0/disk@0,0 + // mmio: /sysbus-xhci@00000000fe900000/storage@1/channel@0/disk@0,0 char desc[256], *p; if (usbdev->hub->cntl->pci) -- 2.27.0

2 2

[PATCH 0/3] usb/xhci: add support for mmio host adapters (via acpi).
by Gerd Hoffmann 13 Oct '20

13 Oct '20

Gerd Hoffmann (3): usb: add boot prio support for mmio host adapters usb/xhci: split xhci setup into generic and pci parts usb/xhci: add support for mmio host adapters (via acpi). src/hw/usb.h | 1 + src/boot.c | 10 ++++++- src/hw/usb-xhci.c | 71 ++++++++++++++++++++++++++++++++++++++--------- 3 files changed, 68 insertions(+), 14 deletions(-) -- 2.27.0

2 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS