Another try after
https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/KBHQU4…
The only change is the removal of `Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf`
since 699a4e5d6919cc8eae5342443025ceb6909dc276
("ldnoexec: Add script to remove ET_EXEC flag from intermediate build objects")
has done the same thing.
For your convenience, the patch series is available on https://github.com/MaskRay/seabios/tree/lld
Re-sending. I posted this 3 days but got …
[View More]bounced.
I have now ensured there is my email address record on
(previously not) https://mail.coreboot.org/postorius/lists/seabios.seabios.org/
as well as https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/
Fangrui Song (4):
romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr
Make rom16.o linkable with lld
romlayout32flag.lds: Use `. +=` instead of `. =`
test-build.sh: Delete unneeded LD capability test
scripts/layoutrom.py | 8 +++++++-
scripts/test-build.sh | 42 +-----------------------------------------
src/romlayout.S | 2 +-
3 files changed, 9 insertions(+), 43 deletions(-)
--
2.37.0.144.g8ac04bfd2-goog
[View Less]
Hi Gerd.
Thanks for your reply. Sorry for the delay, was swamped
with other things.
>> Currently I don't know what to recommend, because I
>> don't understand the other side of the INT 13H/14H,
>> only the OS side.
> Well, the other side talks to the hardware,
> and needs drivers to do so. See src/hw
> Surely one can write a serial driver which connects to a remote place
> using some bluetooth protocol instead of talking to a 16550. That'll
> be *alot* of …
[View More]work though, you basically have to implement both
> bluetooth stack and hardware driver.
I expected to assemble, rather than write, such a thing.
If not from the Linux source code, then FreeBSD or
ReactOS.
If for some reason (what would that be?) no-one has
abstracted bluetooth to have a clean interface that I
could have trivially reused, then I will put aside my
bluetooth dreams and switch to a different technology.
How about Wifi? Does that exist in a state usable for
my purposes?
>> Sure. For now, I want PDOS/386 to remain traditional.
>> When I have exhausted everything that is possible
>> via the BIOS, I will consider adding UEFI support.
> If you want your firmware provide drivers to you for modern hardware you
> are in a *much* better position with UEFI.
Well, on some/many/most modern machines there is
absolutely no other choice - the BIOS doesn't exist,
even as CSM.
> There is a bluetooth
> protocol specification for example, although I'm not sure how common it
> is to find an actual uefi driver for bluetooth hardware in the firmware.
> Talking to ethernet using the firmware-provided uefi driver shouldn't be
> much of a problem though b/c network boot is a rather standard feature.
Ok, maybe in the medium term I should use a hardware
device, forget the name, that turns ethernet into Wifi.
So then the problem is reduced to me needing to provide
a BOOTX64.EFI that converts INT 14H into UEFI ethernet
calls.
>> But I'd like to transport all of that software, designed for
>> that environment, and change nothing at all, and have
>> it work on a new environment that includes Wifi, bluetooth
>> and maybe ethernet, and maybe infrared, and maybe
>> other things I don't know about, but make sense (at
>> some level) to be accessed via INT 14H.
> Well. In the server world it is rather common to provide access to the
> serial line over the network for system management purposes.
> One approach for that is to have a separate management controller (bmc),
> and the serial port of the machine is linked to the management
> controller instead of a D9 socket. You can then connect to the bmc to
> manage the machine, and one of the options available is to get serial
> console access.
Ok, this would allow me to have a BBS.
But not allow me to have a "virtual modem" so that I can
dial out.
> Another approach is to have a virtual 16550 provided by the firmware.
> Accessing the virtual 16550 will trap into SMM mode where the firmware
> emulates a serial device and allows to access the serial port remotely
> over the network, roughly comparable to how qemu provides an virtual
> 16550 to virtual machines.
Ok, but in the case of qemu I have the same issue - at the end
of the day I want to drive a modem, so with qemu I can get it
to talk to a "virtual modem". If the firmware is providing the
serial to network conversion, I also need to stick in a virtual
modem there. And that's what I was hoping SeaBIOS would
allow me to do.
> Note that both approaches work at hardware level not int14h level,
> because modern operating systems use int14h services in bootloaders
> only if at all.
My operating system, PDOS/386, may not be considered "modern",
even though it is in active development, but I do wish to use
INT 14H, as that was the traditional BIOS service provided, and I
wish to maintain contact with the original 80386 machines.
I expect a modern environment to have the CPU, memory etc
required to support this basic interface.
BFN. Paul.
[View Less]
Dear Michael,
Am 23.08.22 um 16:30 schrieb Michael Bacarella:
> On Tue, Aug 23, 2022 at 12:06 AM Paul Menzel wrote:
>> Am 22.08.22 um 21:23 schrieb Michael Bacarella:
>>> On Sat, Aug 20, 2022 at 11:45 PM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote:
>>
>>>> Thank you for implementing this. If you send a patch, I can test on real
>>>> hardware.
>>
>> […]
>>
>>> Patch attached. I replied here rather than with a new …
[View More]email with a PATCH subject
>>> because I don't consider it ready to merge, more like a POC.
>>>
>>> Also I'm using gmail, hope I don't embarrass myself.
>>
>> Unfortunately, Gmail wraps lines after 72(?) characters so the diff is
>> malformed. Maybe attach the file generated by `git format-patch -1`?
>
> My apologies. Attached here.
I noticed another thing, that GIFs created by ImageMagick’s convert
cannot be decoded. With your converted example image [1]
$ dpkg -l imagemagick
[…]
ii imagemagick 8:6.9.11.60+dfsg-1.3+b3 amd64 image
manipulation programs -- binaries
$ convert bootsplash.gif -resize 1280x1024+32 bootsplash2.gif
$ identify bootsplash2.gif
bootsplash2.gif[0] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 0.000u
0:00.001
bootsplash2.gif[1] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 0.000u
0:00.000
bootsplash2.gif[2] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c
2.05915MiB 0.000u 0:00.000
or bb.gif [2]
$ identify bb.gif
bb.gif[0] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[1] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[2] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[3] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[4] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[5] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[6] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000
bb.gif[7] GIF 100x100 100x100+0+0 8-bit sRGB 2c 1446B 0.000u 0:00.000
I get:
Decoding bootsplash.gif
invalid GIF signature
gif_decode failed with return code -1...
Kind regards,
Paul
[1]: https://michael.bacarella.com/bootsplash.gif
[2]: https://www.opensourcecook.in/sites/default/files/bb.gif
[View Less]
Dear Michael,
Am 23.08.22 um 16:30 schrieb Michael Bacarella:
> On Tue, Aug 23, 2022 at 12:06 AM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote:
>> Am 22.08.22 um 21:23 schrieb Michael Bacarella:
>>> On Sat, Aug 20, 2022 at 11:45 PM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote:
>>
>>>> Thank you for implementing this. If you send a patch, I can test on real
>>>> hardware.
>>
>> […]
>>
>>> Patch attached. I …
[View More]replied here rather than with a new email with a PATCH subject
>>> because I don't consider it ready to merge, more like a POC.
>>>
>>> Also I'm using gmail, hope I don't embarrass myself.
>>
>> Unfortunately, Gmail wraps lines after 72(?) characters so the diff is
>> malformed. Maybe attach the file generated by `git format-patch -1`?
>
> My apologies. Attached here.
No problems. Thank you for providing the patch. I tried it on the ASUS
F2A85-M PRO, and the GIF you provided [1], and got the results below.
$ identify bootsplash.gif
bootsplash.gif[0] GIF 640x480 640x480+0+0 8-bit sRGB 256c 0.000u
0:00.000
bootsplash.gif[1] GIF 640x480 640x480+0+0 8-bit sRGB 256c 0.000u
0:00.012
bootsplash.gif[2] GIF 640x480 640x480+0+0 8-bit sRGB 256c 640039B
0.000u 0:00.012
Checking for bootsplash
Copying romfile 'bootsplash.gif' (len 640039)
Copying data 640039@0xff8c07a8 to 640039@0x5ed93b70
start showing bootsplash
VESA 3.0
VENDOR: (C) 1988-2010, Advanced Micro Devices, Inc.
PRODUCT: DVST
Decoding bootsplash.gif
Finding vesa mode with dimensions 640/480
Unable to find vesa video mode dimensions 640/480
failed to find a videomode with 640x480 24bpp (0=any).
According to `videoinfo` from GRUB (MBR), the video modes from the Video
BIOS/VGA Option ROM seem to be:
```
List of supported video modes:
Legend: mask/position=red/green/blue/reserved
Adapter `Cirrus CLGD 5446 PCI Video Driver':
No info available
Adapter `Bochs PCI Video Driver':
No info available
Adapter `VESA BIOS Extension Video Driver':
VBE info: version: 3.0 OEM software rev: 15.31
total memory: 16384 KiB
0x100 640 x 400 x 8 ( 640) Paletted
0x101 640 x 480 x 8 ( 640) Paletted
0x103 800 x 600 x 8 ( 832) Paletted
0x105 1024 x 768 x 8 (1024) Paletted
0x107 1280 x 1024 x 8 (1280) Paletted
0x110 640 x 480 x 16 (1280) Direct color, mask: 5/5/5/0 pos: 10/5/0/0
0x111 640 x 480 x 16 (1280) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x113 800 x 600 x 16 (1664) Direct color, mask: 5/5/5/0 pos: 10/5/0/0
0x114 800 x 600 x 16 (1664) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x116 1024 x 768 x 16 (2048) Direct color, mask: 5/5/5/0 pos: 10/5/0/0
0x117 1024 x 768 x 16 (2048) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x119 1280 x 1024 x 16 (2560) Direct color, mask: 5/5/5/0 pos: 10/5/0/0
0x11a 1280 x 1024 x 16 (2560) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x163 1280 x 960 x 8 (1280) Paletted
0x165 1280 x 960 x 16 (2560) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x166 1280 x 960 x 32 (5120) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
0x121 640 x 480 x 32 (2560) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
0x122 800 x 600 x 32 (3328) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
0x123 1024 x 768 x 32 (4096) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
* 0x124 1280 x 1024 x 32 (5120) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
0x143 1400 x 1050 x 8 (1408) Paletted
0x145 1400 x 1050 x 16 (2816) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x146 1400 x 1050 x 32 (5632) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
0x173 1600 x 1200 x 8 (1600) Paletted
0x175 1600 x 1200 x 16 (3200) Direct color, mask: 5/6/5/0 pos: 11/5/0/0
0x176 1600 x 1200 x 32 (6400) Direct color, mask: 8/8/8/0 pos: 16/8/0/0
EDID version: 1.3
No preferred mode available
Adapter `VGA Video Driver':
No info available
```
So no 640 x 480 x 24 mode is in there. I never tried bootsplash before,
so no idea, if misconfigured something, or just need a different GIF.
Kind regards,
Paul
[1]: https://michael.bacarella.com/bootsplash.gif
[View Less]
Hello,
I've added animated GIF bootsplash support to SeaBIOS.
Demo: https://www.youtube.com/watch?v=0mmMk40uDJk
Is this only of interest to me, or should I submit a patch for
consideration?
I adapted this public domain gif decoder https://github.com/lecram/gifdec
It is my understanding that the patents that were encumbering GIF use in
open source have long since expired so there should not be regulatory
blockers.
Thank you kindly.
qemu-x86-64 v7.0.0 hangs on reboot (as shown below) without kvm when
using bios.bin before commit:
0177400 reset: force standard PCI configuration access
qemu on master uses bios.bin at v1.16.0:
commit d877ada1b8c768d10c39b63bb70c9e5ed1c0a4bc
Author: Gerd Hoffmann <kraxel(a)redhat.com>
Date: Fri Mar 4 15:27:59 2022 +…
[View More]0100
update seabios binaries to 1.16.0
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
I was able successfully reboot by checkingout 0177400, make-ing, and
using the bios.bin using "-bios <path/to/bios.bin> to qemu-x86-64.
Is it possible to create a release that contains the above commit which
the qemu and yocto (https://www.yoctoproject.org/) community will be
able to use?
Sincerely,
Sakib
---------------------------------------------------------------------------------------------
root@qemux86-64:~# reboot
Broadcast message from root@qemux86-64 (ttyS0) (Wed Aug 17 19:45:13 2022):
The system is going down for reboot NOW!
INIT: Switching to runlevel: 6
INIT: Sending processes configured via /etc/inittab the TERM signal
Stopping syslogd/klogd: stopped syslogd (pid 269)
stopped klogd (pid 272)
done
Unmounting remote filesystems...
Deconfiguring network interfaces... ifdown: interface lo not configured
done.
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Deactivating swap...
Unmounting local filesystems...
[ 27.350393] EXT4-fs (vda): re-mounted. Quota mode: disabled.
Rebooting... [ 27.615867] reboot: Restarting system
[ 27.616288] reboot: machine restart
[View Less]
SeaBIOS can be used for booting legacy OS and also Linux is still using
CMOS address 0x10 to configure floppy controller. Under these assumptions
it makes sense to allow boot from CMOS defined floppy drives.
Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com>
---
src/Kconfig | 7 +++++++
src/hw/floppy.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/Kconfig b/src/Kconfig
index 3a8ffa1..42b9614 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -227,6 +227,13 @@ …
[View More]menu "Hardware support"
default y
help
Support floppy drive access.
+ config LEGACY_FLOPPY
+ depends on FLOPPY && COREBOOT
+ bool "Get floppy type from CMOS"
+ default n
+ help
+ Support boot from CMOS defined floppy. Used by legacy OSes
+ on IBM PC compatible machine under coreboot.
config FLASH_FLOPPY
depends on DRIVES
bool "Floppy images from CBFS or fw_cfg"
diff --git a/src/hw/floppy.c b/src/hw/floppy.c
index 9e6647d..40af360 100644
--- a/src/hw/floppy.c
+++ b/src/hw/floppy.c
@@ -155,7 +155,7 @@ floppy_setup(void)
return;
dprintf(3, "init floppy drives\n");
- if (CONFIG_QEMU) {
+ if (CONFIG_QEMU || CONFIG_LEGACY_FLOPPY) {
u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE);
if (type & 0xf0)
addFloppy(0, type >> 4);
--
2.37.0
[View Less]
ASPI2DOS.SYS and KEYB.COM from Win 98 SE installation CD (and most likely
other DOS versions too) depend on I/O port 0x61 bit 4 to be toggled. This
requires timer 1 (I/O 0x41, legacy DRAM refresh) to be correctly set.
Also Intel ICH7 Family Datasheet, chapter 5.8 states:
Programming the counter to anything other than Mode 2 will result in
undefined behavior for the REF_TOGGLE bit.
Failing to have the timer 1 configured indeed causes affected OSes to
freeze during the boot.
Signed-off-by: …
[View More]Petr Cvek <petrcvekcz(a)gmail.com>
---
src/hw/timer.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/hw/timer.c b/src/hw/timer.c
index b6f102e..b272f44 100644
--- a/src/hw/timer.c
+++ b/src/hw/timer.c
@@ -280,4 +280,10 @@ pit_setup(void)
// maximum count of 0000H = 18.2Hz
outb(0x0, PORT_PIT_COUNTER0);
outb(0x0, PORT_PIT_COUNTER0);
+
+ // timer1: binary count, 16bit count, mode 2
+ outb(PM_SEL_TIMER1|PM_ACCESS_WORD|PM_MODE2|PM_CNT_BINARY, PORT_PIT_MODE);
+ // maximum count of 0012H = 66.3kHz
+ outb(0x12, PORT_PIT_COUNTER1);
+ outb(0x0, PORT_PIT_COUNTER1);
}
--
2.37.0
[View Less]
This patch series adds support for all the standard resolutions as
listed on Wikipedia.
I've fixed the issue Gerd pointed out and rebased onto master.
I also see that Gerd himself has recently put out a patch for 4K
resolutions, however, my own ultrawide resolution of 3440x1440 remains
unsupported by SeaBIOS. I've heard from some others that they have
unique resolutions that are still not in SeaBIOS but they should be with
this patch so I hope we can get it in.
Regarding 24 bpp, probably yes,…
[View More] most software doesn't care about it but
for maximal compatability (and because Windows has been finicky in my
experience), I think we should include it. Also, there's still the
chance that some people may want to use it in some unlikely scenarios
which they should be able to do without recompilation. One last thing to
consider is that we would then have to decide at what point do the
resolutions being added with this patch become modern/new enough that it
no longer makes sense to keep the 24 bpp variants. It seems like we
would basically just have to draw an arbitrary line in the sand.
However, if you would still like to remove 24 bpp variants then please
provide me with a cut off point and I'll put it in the next patch
version.
Again, if we could get this in that would be fantastic because I've
personally had people raise this issue with me in regards to an issue
they're having in relation to one of my projects.
Thanks,
Elliot
Elliot Killick (2):
svgamodes: Add support for all standard resolutions
svgamodes: Improve formatting
vgasrc/svgamodes.c | 225 ++++++++++++++++++++++++++++-----------------
1 file changed, 141 insertions(+), 84 deletions(-)
-- 2.34.3
[View Less]