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
_______________________________________________
SeaBIOS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
