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
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...
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
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
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
