Now there is no convenient way to set the version number
in the required format if we build SeaBIOS from the repository.
It is proposed first of all to get the version number from
the .version file if it exists, if it is absent, from git.
This approach will allow you to safely specify the version
manually and will not affect existing builds.
Alexey Kirillov (1):
build: increase .version priority over git
scripts/buildversion.py | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--
2.17.1
This patch aimed to avoid problem with uninitialized virtio-blk and
virtio-scsi boot devices.
Currently, 12 KiB of memory is allocated for each virtio-blk/scsi, so
no more than about 10 devices can be initialized. If the device is not
initialized, we cannot boot from it. So, if we have more than 10 devices,
we can't boot from any of the following (11, 12, etc.).
We can initialize only bootable devices, i.e. listed in boot order list,
that this patch does.
Alexey Kirillov (2):
boot: Detect strict boot order (HALT record) in function
virtio: Do not init non-bootable devices
src/boot.c | 5 +++++
src/hw/virtio-blk.c | 11 ++++++++++-
src/hw/virtio-scsi.c | 11 ++++++++++-
src/util.h | 1 +
4 files changed, 26 insertions(+), 2 deletions(-)
--
2.17.1
This patch aimed to avoid problem with uninitialized virtio-blk and
virtio-scsi boot devices.
Currently, 12 KiB of memory is allocated for each virtio-blk/scsi, so
no more than about 10 devices can be initialized. If the device is not
initialized, we cannot boot from it. So, if we have more than 10 devices,
we can't boot from any of the following (11, 12, etc.).
We can initialize only bootable devices, i.e. listed in boot order list,
that this patch does.
Alexey Kirillov (2):
boot: Detect strict boot order (HALT record) in function
virtio: Do not init non-bootable devices
src/boot.c | 5 +++++
src/hw/virtio-blk.c | 11 ++++++++++-
src/hw/virtio-scsi.c | 11 ++++++++++-
src/util.h | 1 +
4 files changed, 26 insertions(+), 2 deletions(-)
--
2.17.1
Hallo All,
I have a proprietary application running on Debian9 with hardcoded NIC "eno1".
If I would like to use virtualization I need to have the NIC show up as onboard NIC so systemd will name it eno1.
I dont have access to the OS Debian9 to change anything.
is there a way to have the Bios report the NIC as onboad eno1?
Thanks a lot
Hi Michael & Lists,
I'd like to ask for ideas with the following problem we have.
(1) There is a functional iPXE + WDS setup, with iPXE built as a
traditional BIOS PCI option ROM, using CONFIG=qemu. Accordingly the
platform is qemu, with SeaBIOS, and the NIC is virtio-net-pci.
I don't know anything about the particulars of the WDS setup at this
point, only that the boot loader program it exposes is WDSNBP.COM.
(2) The setup works fine when iPXE is built at commit 4e85b2708fa0
("[virtio] Use host-specified MTU when available", 2017-01-23).
(3) When iPXE is built at commit 133f4c47baef ("[build] Handle
R_X86_64_PLT32 from binutils 2.31", 2018-09-17), the setup breaks.
The symptom is that iPXE fetches WDSNBP.COM just fine, but WDSNBP.COM,
rather than doing whatever it does otherwise, keeps PXE-booting itself
(3+ times), and finally aborts.
Consider the following log output (my undertanding is that all this is
logged by WDSNBP.COM):
> Downloaded WDSNBP...
>
> Press F12 for network service boot
> Architecture: x64
> WDSNBP started using DHCP Referral.
> Contacting Server: ... (Gateway: ...)
> Contacting Server: ...
> TFTP Download: boot\x86\wdsnbp.com
This block repeats approx. 3 times, after which the following is
displayed:
> Windows Deployment Services: PXE Boot Aborted.
> Could not boot image: Error 0x7f8d8101 (http://ipxe.org/7f8d8101)
> No more network devices
>
> No bootable device
My understanding is that the first line from this last block is printed
by WDSNBP.COM, the second line by iPXE (in pxe_start_nbp()), the third
line also by iPXE, and the last one by SeaBIOS.
This seems to indicate that WDSNBP.COM exits with an error code, and
pxe_start_nbp() logs it as "Error 0x7f8d8101".
(4) Now, after a bit of searching the web, I've found the following
articles, which indicate that the WDS (= server side) setup is
incorrect:
(4a) "disable NetBios over TCPIP, on the WDS server"
https://techthoughts.info/pxe-booting-wds-dhcp-scope-vs-ip-helpers/#comme...https://social.technet.microsoft.com/Forums/ie/en-US/f3883e8b-1039-477d-9...
(4b) "cover all combinations of forward and backwards slashes in
ReadFilter, on the WDS server"
http://ipxe.org/appnote/chainload_wds#tftp_loops
However: the regression appears to be a function of *only* the git
commit at which we build iPXE. It seems so deterministic that we
bisected commit range 4e85b2708fa0..133f4c47baef. (Hence we have not
captured the network traffic yet, nor have we investigated the WDS
server config.)
The "culprit" commit is ea29122a70c6 ("[http] Include error messages for
4xx and 5xx response codes", 2017-12-28).
(5) Which makes no sense to me, unfortunately. :(
Commit ea29122a70c6 adds the "http_errors" array to the code. According
to
src/include/ipxe/tables.h
and the build artifact
src/bin/1af41000.rom.tmp.map
this new array is placed in a new section called
.textdata.tbl.errortab.01
Trying to retro-fit those facts to the symptom encountered, I came up
with the idea that *maybe* the new array (or section) causes a memory
allocation failure in WDSNBP.COM -- due to increased memory footprint of
iPXE. Which then leads to the misbehavior of WDSNBP.COM.
After all, WDSNBP.COM is a 16-bit real-mode program:
https://support.microsoft.com/en-us/help/4468601/pxe-boot-in-configuratio...
so it could be susceptible to the size & fragmentation of the RAM that
is under 640KB.
(6) Unfortunately, this "low RAM exhaustion" idea doesn't seem to hold
water. There are at least two counter-arguments:
(6a) if I revert commit ea29122a70c6 on top of commit 133f4c47baef, then
the issue does *not* go away.
(The issue also does not go away if I remove the "netdev_errors" array,
also on top of commit 133f4c47baef -- that's a larger array.)
(... In theory anyway, this might not necessarily disprove the memory
exhaustion idea. What if the iPXE footprint grows, over the
ea29122a70c6..133f4c47baef so much, for independent reasons, that
reverting ea29122a70c6 at the end cannot compensate for that increase?)
(6b) I added "DEBUG=pxe_call:1" to the "make" command, and compared the
debug messages printed by pxe_start_nbp(), between 4e85b2708fa0 and
133f4c47baef. Alas, the debug messages are identical:
> PXE NBP starting with netdev net0, code 9c6c:0802, data 9cf0:2ce0
which to me suggests that there is no change in the amount of memory
that is made available to WDSNBP.COM -- its code and data continue to
start at 0x9_CEC2 and 0x9_FBE0, respectively.
Any hints as to what could be going wrong?
Thanks!
Laszlo
This patch aimed to avoid problem with uninitialized virtio-blk and
virtio-scsi boot devices.
Currently, 12 KiB of memory is allocated for each virtio-blk/scsi, so
no more than about 10 devices can be initialized. If the device is not
initialized, we cannot boot from it. So, if we have more than 10 devices,
we can't boot from any of the following (11, 12, etc.).
We can initialize only bootable devices, i.e. listed in boot order list,
that this patch does.
Alexey Kirillov (1):
virtio: do not init non-bootable devices
docs/Runtime_config.md | 1 +
src/hw/virtio-blk.c | 10 ++++++++++
src/hw/virtio-scsi.c | 10 ++++++++++
3 files changed, 21 insertions(+)
--
2.17.1
On physical hardware, some PCI devices are not detectable when UEFI
BIOS invokes our InitializeYourself() function. But they are
guaranteed to be available before UEFI invokes our PreparToBoot()
function. So in the case of running CSM on physical hardware, we execute
pci_probe_devices() at PrepareToBoot() stage.
Signed-off-by: Bin Gao <gaobin(a)amazon.com>
---
src/fw/csm.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 8359bcb..82d375c 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -63,7 +63,9 @@ static void
csm_maininit(struct bregs *regs)
{
interface_init();
- pci_probe_devices();
+
+ if (CONFIG_CSM && CONFIG_QEMU_HARDWARE)
+ pci_probe_devices();
csm_compat_table.PnPInstallationCheckSegment = SEG_BIOS;
csm_compat_table.PnPInstallationCheckOffset = get_pnp_offset();
@@ -143,6 +145,13 @@ handle_csm_0002(struct bregs *regs)
return;
}
+ // On physical hardware, some PCI devices are not detectable when
+ // UEFI invokes our InitializeYourself() function. But they
+ // are guaranteed to be available before UEFI invokes our
+ // PreparToBoot() function.
+ if (CONFIG_CSM && !CONFIG_QEMU_HARDWARE)
+ pci_probe_devices();
+
dprintf(3, "PrepareToBoot table %04x:%04x\n", regs->es, regs->bx);
struct e820entry *p = (void *)csm_compat_table.E820Pointer;
--
2.17.1
