SeaBIOS

seabios@seabios.org

2 participants
3799 discussions

Re: [PATCH 28/31] string.c: reimplement mem*_far() functions for PA-RISC
by Valentine 13 Feb '21

13 Feb '21

> +#if CONFIG_X86 I understand that Helge adapted sources for PA-RISC, but will not it be more convenient to use#if CONFIG_PA_RISC So that by default SeaBIOS would compile as usual? Best regards,Valentine ---From: Helge DellerDate: 12.02.2021 1:08 (GMT+03:00)Subject: [SeaBIOS] [PATCH 28/31] string.c: reimplement mem*_far() functions for PA-RISC

2 1

[PATCH 20/31] output.c: Add PA-RISC specific output behaviour
by Helge Deller 11 Feb '21

11 Feb '21

On PA-RISC call an own screenc() implementation which doesn't use int10, prevent the Intel-specific \r newline when printing \n and don't output to serial debug port. Signed-off-by: Helge Deller <deller(a)gmx.de> --- src/output.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/output.c b/src/output.c index 0184444..6141fb6 100644 --- a/src/output.c +++ b/src/output.c @@ -18,6 +18,9 @@ #include "stacks.h" // call16_int #include "string.h" // memset #include "util.h" // ScreenAndDebug +#if CONFIG_PARISC +#include "parisc/sticore.h" +#endif struct putcinfo { void (*func)(struct putcinfo *info, char c); @@ -44,7 +47,8 @@ debug_putc(struct putcinfo *action, char c) qemu_debug_putc(c); if (!MODESEGMENT) coreboot_debug_putc(c); - serial_debug_putc(c); + if (!CONFIG_PARISC) + serial_debug_putc(c); } // Flush any pending output to debug port(s). @@ -74,6 +78,7 @@ static struct putcinfo debuginfo = { debug_putc }; static void screenc(char c) { +#if CONFIG_X86 if (!MODESEGMENT && GET_IVT(0x10).segoff == FUNC16(entry_10).segoff) // No need to thunk to 16bit mode if vgabios is not present return; @@ -84,6 +89,9 @@ screenc(char c) br.al = c; br.bl = 0x07; call16_int(0x10, &br); +#else + parisc_screenc(c); +#endif } // Handle a character from a printf request. @@ -92,7 +100,7 @@ screen_putc(struct putcinfo *action, char c) { if (ScreenAndDebug) debug_putc(&debuginfo, c); - if (c == '\n') + if (CONFIG_X86 && c == '\n') screenc('\r'); screenc(c); } -- 2.29.2

1 11

PCIe (x4) M.2 slot does not see NVME disks at SeaBIOS boot menu.
by dponamorev＠gmail.com 10 Feb '21

10 Feb '21

Hi! Custom motherboard on Intel Atom C3338 with PCIe (x4) M.2 slot does not see NVME disks at SeaBIOS boot menu. (SeaBIOS (version rel-1.13.0-1-g3ab38b1)) Does not load the operating system from these drives. If you boot from another media, then the NVME disk is seen in the system and works fine. In the logs there is a warning at "void *pci_enable_membar" function in the "coreboot/payloads/external/SeaBIOS/seabios/src/hw/pcidevice.c" file line 186. Warning message: WARNING - internal error detected at pci_enable_membar:186! // Verify a memory bar and return it to the caller void * pci_enable_membar(struct pci_device *pci, u32 addr) { wait_preempt(); u32 bar = pci_config_readl(pci->bdf, addr); if (bar & PCI_BASE_ADDRESS_SPACE_IO) { warn_internalerror(); return NULL; } if (bar & PCI_BASE_ADDRESS_MEM_TYPE_64) { u32 high = pci_config_readl(pci->bdf, addr+4); if (high) { dprintf(1, "Can not map memory bar over 4Gig\n"); return NULL; } } bar &= PCI_BASE_ADDRESS_MEM_MASK; if (bar + 4*1024*1024 < 20*1024*1024) { // Bar doesn't look valid (it is in last 4M or first 16M) warn_internalerror(); =========================================>WARNING! return NULL; } pci_config_maskw(pci->bdf, PCI_COMMAND, 0, PCI_COMMAND_MEMORY); pci->have_driver = 1; return (void*)bar; } Some values: for Samsung NVME disk 0x144d:0xa804; bdf: 0x200 bar: 0x4 at (u32 bar = pci_config_readl(pci->bdf, addr)) bar: 0x0 at (bar &= PCI_BASE_ADDRESS_MEM_MASK) have_driver = 0. If you boot from another media, then the NVME disk is seen in the system and works fine. lspci: 02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 fdisk: Disk /dev/nvme0n1: 232,9 GiB, 250059350016 bytes, 488397168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5107186e Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 * 2048 1126399 1124352 549M 7 HPFS/NTFS/exFAT /dev/nvme0n1p2 1126400 488394751 487268352 232,4G 7 HPFS/NTFS/exFAT Tried with different NVME drives with different controllers. What could be the reason? Driver needed? Best regards, Dmitry Ponamorev

2 1

Possibility to merge the SeaBIOS-parisc tree?
by Helge Deller 09 Feb '21

09 Feb '21

Dear SeaBIOS developers, a few years back I forked the SeaBIOS sources to create a SeaBIOS firmware for usage with the parisc/hppa architecture. This fork is on github: https://github.com/hdeller/seabios-hppa Main goal of this fork was to provide a firmware which can be used to boot a virtual parisc machine with qemu. This firmware reuses most of the SeaBIOS/x86 drivers and infrastructure and works quite well today. Now I would prefer to merge back my changes into the official seabios git tree, if people here agree. Of course there are some patches which touches the generic code, e.g. parisc doesn't need segments and uses 32bit addresses for I/O and serial ports, which I've addressed with generic #ifdefs and typedefs, e.g.: #if CONFIG_X86 typedef u16 portaddr_t; #else typedef unsigned int portaddr_t; #endif I think all code can be merged back in a way that it neither affects runtime behaviour, build environment or code generation of x86, which I understand is the most important goal. My main question is now: Do you agree that it's worth and useful to merge the code back in? If so, how should I proceed? Send in first initial patches which could be applied, step by step? Generally I'd prefer if I could work privately with one or two seabios core developers to speed it up too... Just as a *reference*, I've created two patches which show the changes. Those will be then split it up into small logical parts before committing into the SeaBIOS tree: This patch touches only the generic existing seabios code: http://backup.parisc-linux.org/qemu/seabios-short-patch.txt Same patch as above, but including all new files I added to the new "src/parisc" directory: http://backup.parisc-linux.org/qemu/seabios-full-patch.txt Looking forward to your feedback, Helge

2 2

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS