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
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.
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) {
This series implements support for SMBIOS 3.0 entry points in
SeaBIOS.
The main advantage of SMBIOS 3.0 entry points is the higher limit
for total table size. The SMBIOS 2.1 64435 bytes limit can be
easily hit in QEMU if creating virtual machines with more than
720 VCPUs.
Eduardo Habkost (19):
biostables: copy_fseg_table() function
util.h: Delete unused get_smbios_entry_point() prototype
smbios: Rename code specific for SMBIOS 2.1 entry points
smbios: Generic smbios_next() function
smbios: smbios_get_tables() function
smbios: Use smbios_get_tables()/smbios_next() at display_uuid()
smbios: smbios_major_version()/smbios_minor_version() helpers
tpm: Use smbios_get_tables()
csm: Don't check SMBios21Addr before calling copy_smbios_21()
smbios: Make SMBios21Addr variable static
smbios: Use smbios_next() at smbios_romfile_setup()
smbios: Extract SMBIOS table building code to separate function
smbios: Make smbios_build_tables() more generic
smbios: smbios_21_setup_entry_point() function
smbios: Make some smbios_build_tables() arguments optional
smbios: Make smbios_build_tables() ready for 64-bit tables
smbios: copy_smbios_30() function
smbios: Support SMBIOS 3.0 entry point at copy_table()
smbios: Support SMBIOS 3.0 entry point at smbios_romfile_setup()
src/std/smbios.h | 17 ++-
src/util.h | 5 +-
src/fw/biostables.c | 259 +++++++++++++++++++++++++++++++++-----------
src/fw/csm.c | 6 +-
src/fw/smbios.c | 12 +-
src/tcgbios.c | 12 +-
6 files changed, 227 insertions(+), 84 deletions(-)
--
2.28.0
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ł
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
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.
While looking at VM bootup times, we stumbled over the fact that the NVMe
code only does I/O operations of up to 4kb at a given point in time. This
is usually ok, but if you have an OS that loads a lot of data on boot in
combination to network backed storage, it shows in bootup times.
There is no need to restrict ourselves to 4kb though. The INT13 call we
receive gives us much larger chunks which we can just map into a native
bigger NVMe I/O call if the request buffer is page aligned.
This patch implements all logic required to do the above and gives a
substantial performance boost on boot.
v1 -> v2:
- fix dprintf
- Fix bounds check on PRP list add logic
- Reduce PRP list to 15 entries embedded in the ns struct.
This reduces BIOS reserved memory footprint by 4kb.
v2 -> v3:
- new patch: nvme: Split requests by maximum allowed size
- Adjust the maximum request size to sector units. The hardware field
describes it in pages.
Alexander Graf (4):
nvme: Record maximum allowed request size
nvme: Allow to set PRP2
nvme: Pass large I/O requests as PRP lists
nvme: Split requests by maximum allowed size
src/hw/nvme-int.h | 16 ++++++-
src/hw/nvme.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 121 insertions(+), 17 deletions(-)
--
2.16.4
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
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