Re: [SeaBIOS] [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?
by Carl-Daniel Hailfinger
Hi Ivan,
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.
Regards,
Carl-Daniel
3 months, 3 weeks
Use SeaBIOS as UEFI CSM
by Paul Menzel
Dear SeaBIOS folks,
Colleagues from another institute have the problem, that the PC vendors
started to remove the CSM (legacy BIOS) option from their UEFI firmware.
A lot of organizations still use the CSM (legcacy BIOS) option to deploy
their systems.
I’d like to recommend SeaBIOS to them, but I only found instruction for
doing that with OVMF [1].
Do you know of a how-to for UEFI firmware, which is shipped on hardware?
From that iPXE should be started.
Kind regards,
Paul
[1]:
https://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Supp...
6 months, 3 weeks
Re: [SeaBIOS] Seabios blocked at running option rom at c000:0003
by Kevin O'Connor
On Sun, Oct 14, 2018 at 03:32:22PM +0800, Acewind wrote:
> Dear All,
> These days I'm working on Intel IGD passthrough by qemu+vfio.
> Success on i3-6100, but failed on i3-6100U.
[...]
> Found 2 cpu(s) max supported 2 cpu(s)
> Copying PIR from 0x7ffbfca0 to 0x000f1c40
> Copying MPTABLE from 0x00006e90/7ffa8e80 to 0x000f1b10
> Copying SMBIOS entry point from 0x00006e90 to 0x000f1930
> Scan for VGA option rom
> Running option rom at c000:0003
>
> Now seabios stops and monitor shows no signal.
> I have install win10 directly on the host and it works well. Does it means
> the vga rom image is ok? What can I do for further debug? Thanks!
The "Running option rom at c000:0003" indicates a video card option
rom was found and SeaBIOS started executing it. The likely reason for
the failure is that the video option rom itself crashed. It's
difficult to debug these types of failures because it is rare to have
access to the video rom code.
-Kevin
7 months, 1 week
Seabios blocked at running option rom at c000:0003
by Acewind
Dear All,
These days I'm working on Intel IGD passthrough by qemu+vfio.
Success on i3-6100, but failed on i3-6100U.
The two cpus are both SkyLake arch.
I have successed to passthrough IGD device to Win7/Win10 on an i3-6100
machine with Fedora 25. I use legacy mode and set x-igd-gms=1 on qemu
command line.
When I work on another machine of i3-6100U with the same solution.
CPU: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz
VGA: 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520
(rev 07)
[root localhost ~]# dmesg | grep IOMMU
[ 0.000000] DMAR: IOMMU enabled
[ 0.067707] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1
[root localhost ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.8.6-300.fc25.x86_64 root=/dev/mapper/fedora-root ro
rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet intel_iommu=on
iommu=pt
After virsh create command, nothing displays on the screen, there's always
no signal.
No other graphic and video devices, only passthrough hostdev:
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</source>
<alias name='hostdev0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02'
function='0x0'/>
</hostdev>
[root localhost ~]# ps -elf | grep qemu
6 S qemu 1541 1 99 80 0 - 804613 poll_s 17:34 ? 00:04:22
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name
guest=cn_windows_10_enterprise_version_1703_updated_july_2017_x64_dvd_10925390,debug-threads=on
-S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-cn_windows_10_enterp/master-key.aes
-machine pc-i440fx-2.7,accel=kvm,usb=off -cpu
Skylake-Client,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048
-realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid
128589da-017e-412d-b807-92de81ca7a29 -display none -no-user-config
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-cn_windows_10_enterp/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard
-no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global
PIIX4_PM.disable_s4=1 -boot strict=on -device
ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2
-drive
file=/home/zwj/cn_windows_10_enterprise_version_1703_updated_july_2017_x64_dvd_10925390.qcow2,format=qcow2,if=none,id=drive-ide0-0-0
-device
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=26,id=hostnet0 -device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:86:04:cc,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -device
usb-tablet,id=input0,bus=usb.0,port=1 -device
vfio-pci,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -bios
/usr/share/seabios/bios.bin -chardev file,id=seabios,path=/tmp/bios.log
-device isa-debugcon,iobase=0x402,chardev=seabios -set
device.hostdev0.x-igd-opregion=on -set device.hostdev0.x-igd-gms=1 -msg
timestamp=on
dmesg has an error:
[五 10月 12 17:34:21 2018] Console: switching to colour dummy device 80x25
[五 10月 12 17:34:21 2018] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered blocking state
[五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered disabled state
[五 10月 12 17:34:21 2018] device vnet0 entered promiscuous mode
[五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered blocking state
[五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered listening state
[五 10月 12 17:34:22 2018] DMAR: DRHD: handling fault status reg 2
[五 10月 12 17:34:22 2018] DMAR: [DMA Write] Request device [00:02.0] fault
addr 0 [fault reason 02] Present bit in context entry is clear
[五 10月 12 17:34:22 2018] vfio_ecap_init: 0000:00:02.0 hiding ecap 0x1b 0x100
[五 10月 12 17:34:23 2018] virbr0: port 2(vnet0) entered learning state
[五 10月 12 17:34:25 2018] virbr0: port 2(vnet0) entered forwarding state
[五 10月 12 17:34:25 2018] virbr0: topology change detected, propagating
Below is log of SeaBIOS, it stops at running rom:
[root localhost ~]# cat /tmp/bios.log
SeaBIOS (version 1.9.3-1.fc25)
BUILD: gcc: (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2) binutils: version
2.26.1-1.fc25
RamSize: 0x80000000 [cmos]
Relocating init from 0x000e4080 to 0x7ffb2320 (size 56384)
Found QEMU fw_cfg
QEMU fw_cfg DMA interface supported
RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820]
Moving pm_base to 0x600
boot order:
1: /pci i0cf8/ide 1,1/drive 0/disk 0
2: HALT
=== PCI bus & bridge init ===
PCI: pci_bios_init_bus_rec bus = 0x0
=== PCI device probing ===
Found 12 PCI devices (max PCI bus is 00)
=== PCI new allocation pass #1 ===
PCI: check devices
=== PCI new allocation pass #2 ===
PCI: IO: c000 - c1cf
PCI: 32: 0000000080000000 - 00000000fec00000
PCI: map device bdf=00:03.0 bar 0, addr 0000c000, size 00000100 [io]
PCI: map device bdf=00:02.0 bar 4, addr 0000c100, size 00000040 [io]
PCI: map device bdf=00:04.0 bar 0, addr 0000c140, size 00000020 [io]
PCI: map device bdf=00:05.0 bar 4, addr 0000c160, size 00000020 [io]
PCI: map device bdf=00:05.1 bar 4, addr 0000c180, size 00000020 [io]
PCI: map device bdf=00:05.2 bar 4, addr 0000c1a0, size 00000020 [io]
PCI: map device bdf=00:01.1 bar 4, addr 0000c1c0, size 00000010 [io]
PCI: map device bdf=00:02.0 bar 0, addr fd000000, size 01000000 [mem]
PCI: map device bdf=00:03.0 bar 6, addr fe000000, size 00040000 [mem]
PCI: map device bdf=00:02.0 bar 6, addr fe040000, size 00020000 [mem]
PCI: map device bdf=00:03.0 bar 1, addr fe060000, size 00001000 [mem]
PCI: map device bdf=00:05.7 bar 0, addr fe061000, size 00001000 [mem]
PCI: map device bdf=00:02.0 bar 2, addr e0000000, size 10000000 [prefmem]
PCI: map device bdf=00:04.0 bar 4, addr f0000000, size 00800000 [prefmem]
PCI: init bdf=00:00.0 id=8086:1237
PCI: init bdf=00:01.0 id=8086:7000
PIIX3/PIIX4 init: elcr=00 0c
PCI: init bdf=00:01.1 id=8086:7010
PCI: init bdf=00:01.3 id=8086:7113
Using pmtimer, ioport 0x608
PCI: init bdf=00:02.0 id=8086:1916
Intel IGD OpRegion enabled at 0x7fffe000, size 8KB, dev 00:02.0
Intel IGD BDSM enabled at 0x7d700000, size 40MB, dev 00:02.0
PCI: init bdf=00:03.0 id=10ec:8139
PCI: init bdf=00:04.0 id=1af4:1002
PCI: init bdf=00:05.0 id=8086:2934
PCI: init bdf=00:05.1 id=8086:2935
PCI: init bdf=00:05.2 id=8086:2936
PCI: init bdf=00:05.7 id=8086:293a
PCI: init bdf=00:1f.0 id=8086:9d48
PCI: Using 00:02.0 for primary VGA
handle_smp: apic_id=1
Found 2 cpu(s) max supported 2 cpu(s)
Copying PIR from 0x7ffbfca0 to 0x000f1c40
Copying MPTABLE from 0x00006e90/7ffa8e80 to 0x000f1b10
Copying SMBIOS entry point from 0x00006e90 to 0x000f1930
Scan for VGA option rom
Running option rom at c000:0003
Now seabios stops and monitor shows no signal.
I have install win10 directly on the host and it works well. Does it means
the vga rom image is ok? What can I do for further debug? Thanks!
7 months, 2 weeks
release planning ...
by Gerd Hoffmann
Hi,
I'm wondering whenever it makes sense to switch seabios to time-based
releases, like many other projects do meanwhile.
For major releases one release per year looks reasonable to me, given
the low rate of changes we have. 1.11 was tagged in November 2017.
So maybe target 1.12 for November 2018 ?
For stable releases we could plan to create a release every one or two
months. Skip in case there are no patches queued. Or stick to the
current model which kind-of syncs stable releases to qemu releases
(which is roughly every four months).
Comments?
cheers,
Gerd
7 months, 2 weeks
[PATCH v2] pretty boot menu entry for cdrom drives
by Gerd Hoffmann
Show the volume label of bootable cdroms.
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
src/util.h | 1 +
src/boot.c | 10 ++++++++++
src/cdrom.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
diff --git a/src/util.h b/src/util.h
index 7a23b518fc..6dd080f673 100644
--- a/src/util.h
+++ b/src/util.h
@@ -50,6 +50,7 @@ struct disk_op_s;
int cdemu_process_op(struct disk_op_s *op);
void cdrom_prepboot(void);
int cdrom_boot(struct drive_s *drive_g);
+char *cdrom_media_info(struct drive_s *drive_g);
// clock.c
void clock_setup(void);
diff --git a/src/boot.c b/src/boot.c
index ff705fd47f..9f82f3ca0c 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -395,6 +395,16 @@ boot_add_hd(struct drive_s *drive, const char *desc, int prio)
void
boot_add_cd(struct drive_s *drive, const char *desc, int prio)
{
+ if (GET_GLOBAL(PlatformRunningOn) & PF_QEMU) {
+ // We want short boot times. But on physical hardware even
+ // the test unit ready can take several seconds. So do media
+ // access on qemu only, where we know it will be fast.
+ char *extra = cdrom_media_info(drive);
+ if (extra) {
+ desc = znprintf(MAXDESCSIZE, "%s (%s)", desc, extra);
+ free(extra);
+ }
+ }
bootentry_add(IPL_TYPE_CDROM, defPrio(prio, DefaultCDPrio)
, (u32)drive, desc);
}
diff --git a/src/cdrom.c b/src/cdrom.c
index 828fb3b842..577d69d812 100644
--- a/src/cdrom.c
+++ b/src/cdrom.c
@@ -274,3 +274,49 @@ cdrom_boot(struct drive_s *drive)
return 0;
}
+
+// check if media is present and the drive is bootable.
+// in case it is return the volume label.
+char*
+cdrom_media_info(struct drive_s *drive)
+{
+ ASSERT32FLAT();
+
+ struct disk_op_s dop;
+ memset(&dop, 0, sizeof(dop));
+ dop.drive_fl = drive;
+
+ int ret = scsi_is_ready(&dop);
+ if (ret)
+ return NULL;
+
+ // Read the Boot Record Volume Descriptor
+ u8 buffer[CDROM_SECTOR_SIZE];
+ dop.command = CMD_READ;
+ dop.lba = 0x11;
+ dop.count = 1;
+ dop.buf_fl = buffer;
+ ret = process_op(&dop);
+ if (ret)
+ return NULL;
+
+ // Is it bootable?
+ if (buffer[0])
+ return NULL;
+ if (strcmp((char*)&buffer[1], "CD001\001EL TORITO SPECIFICATION") != 0)
+ return NULL;
+
+ // Read the Primary Volume Descriptor
+ dop.command = CMD_READ;
+ dop.lba = 0x10;
+ dop.count = 1;
+ dop.buf_fl = buffer;
+ ret = process_op(&dop);
+ if (ret)
+ return NULL;
+
+ // Read volume id, trim trailing spaces
+ char *volume = znprintf(30, "%s", buffer + 40);
+ nullTrailingSpace(volume);
+ return volume;
+}
--
2.9.3
7 months, 3 weeks
Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains
by Gerd Hoffmann
Hi,
> > I'm curious; what does tape backup have to do with the number of PCI
> > slots/busses?
>
> I'm not very clear about how tape works in qemu, but the problem is pcie
> devices under q35. The pcie topology requires one device per bus, therefore
> the 256 bus might not be enough if we have many pcie devices.
Note that you can have multifunction pcie devices. so you can have up to
8 per pcie slot. Which allows close to 2000 devices. Limitation: They
are not individually hotpluggable.
cheers,
Gerd
7 months, 3 weeks
