Dear SeaBIOS developers,
a few years back I forked the SeaBIOS sources to create a SeaBIOS firmware for usage with the parisc/hppa architecture. This fork is on github: https://github.com/hdeller/seabios-hppa
Main goal of this fork was to provide a firmware which can be used to boot a virtual parisc machine with qemu. This firmware reuses most of the SeaBIOS/x86 drivers and infrastructure and works quite well today.
Now I would prefer to merge back my changes into the official seabios git tree, if people here agree.
Of course there are some patches which touches the generic code, e.g. parisc doesn't need segments and uses 32bit addresses for I/O and serial ports, which I've addressed with generic #ifdefs and typedefs, e.g.:
#if CONFIG_X86 typedef u16 portaddr_t; #else typedef unsigned int portaddr_t; #endif
I think all code can be merged back in a way that it neither affects runtime behaviour, build environment or code generation of x86, which I understand is the most important goal.
My main question is now: Do you agree that it's worth and useful to merge the code back in? If so, how should I proceed? Send in first initial patches which could be applied, step by step?
Generally I'd prefer if I could work privately with one or two seabios core developers to speed it up too...
Just as a *reference*, I've created two patches which show the changes. Those will be then split it up into small logical parts before committing into the SeaBIOS tree:
This patch touches only the generic existing seabios code: http://backup.parisc-linux.org/qemu/seabios-short-patch.txt
Same patch as above, but including all new files I added to the new "src/parisc" directory: http://backup.parisc-linux.org/qemu/seabios-full-patch.txt
Looking forward to your feedback, Helge
On Tue, Feb 02, 2021 at 03:31:56PM +0100, Helge Deller wrote:
Dear SeaBIOS developers,
a few years back I forked the SeaBIOS sources to create a SeaBIOS firmware for usage with the parisc/hppa architecture. This fork is on github: https://github.com/hdeller/seabios-hppa
Interesting.
Main goal of this fork was to provide a firmware which can be used to boot a virtual parisc machine with qemu. This firmware reuses most of the SeaBIOS/x86 drivers and infrastructure and works quite well today.
So, the parisc/hppa platform is not an X86 machine and doesn't require backwards compatibility with old DOS applications, but you are using SeaBIOS as a bootloader? That is, for its device drivers and firmware setup?
Can you elaborate on which parts of SeaBIOS you rely on and which parts are not used?
Now I would prefer to merge back my changes into the official seabios git tree, if people here agree.
Of course there are some patches which touches the generic code, e.g. parisc doesn't need segments and uses 32bit addresses for I/O and serial ports, which I've addressed with generic #ifdefs and typedefs, e.g.:
#if CONFIG_X86 typedef u16 portaddr_t; #else typedef unsigned int portaddr_t; #endif
I think all code can be merged back in a way that it neither affects runtime behaviour, build environment or code generation of x86, which I understand is the most important goal.
My main question is now: Do you agree that it's worth and useful to merge the code back in?
It's pretty quiet here - we haven't added major functionality to SeaBIOS in a couple of years. That said, I don't see a problem with merging the code.
One thing I did notice is there seems to be many #ifdefs added - as I'm sure you've noticed, the SeaBIOS coding style tries to avoid use of #ifdefs.
If so, how should I proceed? Send in first initial patches which could be applied, step by step?
Indeed, in order to merge it would be necessary to break up the patches into relatively small functional parts. As we look at each functional part, I'm sure there will be questions and discussion on alternatives.
Generally I'd prefer if I could work privately with one or two seabios core developers to speed it up too...
Just as a *reference*, I've created two patches which show the changes. Those will be then split it up into small logical parts before committing into the SeaBIOS tree:
This patch touches only the generic existing seabios code: http://backup.parisc-linux.org/qemu/seabios-short-patch.txt
Same patch as above, but including all new files I added to the new "src/parisc" directory: http://backup.parisc-linux.org/qemu/seabios-full-patch.txt
Cheers, -Kevin
On 2/9/21 12:21 AM, Kevin O'Connor wrote:
On Tue, Feb 02, 2021 at 03:31:56PM +0100, Helge Deller wrote:
Dear SeaBIOS developers,
a few years back I forked the SeaBIOS sources to create a SeaBIOS firmware for usage with the parisc/hppa architecture. This fork is on github: https://github.com/hdeller/seabios-hppa
Interesting.
Thanks!
Main goal of this fork was to provide a firmware which can be used to boot a virtual parisc machine with qemu. This firmware reuses most of the SeaBIOS/x86 drivers and infrastructure and works quite well today.
So, the parisc/hppa platform is not an X86 machine
Correct. parisc/hppa is the "old" processor which was used for HP-UX machines from HP, before they switched to IA-64 processors.
and doesn't require backwards compatibility with old DOS applications, but you are using SeaBIOS as a bootloader? That is, for its device drivers and firmware setup?
Correct. SeaBIOS for hppa is the same as a BIOS on x86. It starts up the machine, has functions to access the discs, serial ports, initializes graphics and so on. After bootup the Linux kernel calls some of those functions, e.g. to get the current clock (RTC), or retrieve where various hardware is located (similiar to DMI info).
Can you elaborate on which parts of SeaBIOS you rely on and which parts are not used?
Main parts used from SeaBIOS x86: - SCSI sym53c8xx - SCSI disc/cdrom layer - PCI bridge - Serial/paralell port drivers - fw_cfg interface - in future possibly the virtio drivers
Now I would prefer to merge back my changes into the official seabios git tree, if people here agree.
Of course there are some patches which touches the generic code, e.g. parisc doesn't need segments and uses 32bit addresses for I/O and serial ports, which I've addressed with generic #ifdefs and typedefs, e.g.:
#if CONFIG_X86 typedef u16 portaddr_t; #else typedef unsigned int portaddr_t; #endif
I think all code can be merged back in a way that it neither affects runtime behaviour, build environment or code generation of x86, which I understand is the most important goal.
My main question is now: Do you agree that it's worth and useful to merge the code back in?
It's pretty quiet here - we haven't added major functionality to SeaBIOS in a couple of years. That said, I don't see a problem with merging the code.
That's great.
One thing I did notice is there seems to be many #ifdefs added - as I'm sure you've noticed, the SeaBIOS coding style tries to avoid use of #ifdefs.
In some cases I couldn't avoid it. Clearly, when code gets merged it should be clean.
If so, how should I proceed? Send in first initial patches which could be applied, step by step?
Indeed, in order to merge it would be necessary to break up the patches into relatively small functional parts. As we look at each functional part, I'm sure there will be questions and discussion on alternatives.
Ok, I'll send a first initial patch soon.
Generally I'd prefer if I could work privately with one or two seabios core developers to speed it up too...
Just as a *reference*, I've created two patches which show the changes. Those will be then split it up into small logical parts before committing into the SeaBIOS tree:
This patch touches only the generic existing seabios code: http://backup.parisc-linux.org/qemu/seabios-short-patch.txt
Same patch as above, but including all new files I added to the new "src/parisc" directory: http://backup.parisc-linux.org/qemu/seabios-full-patch.txt
Thanks Kevin! Helge
-
Helge Deller -
Kevin O'Connor