This patchset modifies SeaBIOS source code to be able to build a firmware for

the PA-RISC CPU architecture. This firmware can then be used to boot a virtual

PA-RISC machine with PA-Linux and HP/UX on QEMU.



Where possible existing SeaBIOS drivers and infrastructure is reused.

Since PA-RISC is native 32/64-Bit, the various segment accessors are

not needed and replaced by simple variable accesses.



Helge Deller (31):

  Add config option for PA-RISC arch

  biosvar.h: Add accessors for various BIOS data areas

  Drivers: Use get_bda_ptr() BDA accessor

  byteorder.h: Add endianess conversion functions

  farptr.h: Add FLATPTR* accessor functions for parisc

  font.c: Disable built-in x86 font on parisc

  paravirt.h: Add PORT_QEMU_CFG_CTL for parisc

  pciinit.c: Initialize PA-RISC Dino PCI chip

  shadow.c: Compile int3 inline assembly on x86 only

  Add portaddr_t typedef to specify I/O port addresses

  ata.c: Allow to boot on PA-RISC

  ata.h: Add ATA IDE port addresses for PA-RISC

  blockcmd.c: Prevent unaligned access crash on PA-RISC

  scsi: Add fields for specifying target and lun of SCSI devices

  lsi-scsi.c: Convert SCSI script to little endian

  pci.c: Add PCI ports for PA-RISC and access PCI bus in little-endian

  rtc.h: Add CMOS/RTC addresses for PA-RISC

  serialio.h: Add serial port adresses for PA-RISC

  malloc.c: Implement a PA-RISC specific malloc()

  output.c: Add PA-RISC specific output behaviour

  output.c: Make printf() capable to print 64bit int values

  romfile.c: return values are returned as little-endian

  sercon.c: Use SEROFF_IIR constant

  stacks.h: Provide replacement for thread functions when

    !CONFIG_THREADS

  version.c: Mark version strings const

  x86.h: Provide replacement functions for PA-RISC

  parisc: Add PA-RISC related code

  string.c: reimplement mem*_far() functions for PA-RISC

  boot.c: Add boot disc chooser for PA-RISC

  block.c: Allow PA-RISC to boot from ATA drives

  ata.c: Add missing endianess conversion functions



 Makefile                    |    9 +-

 Makefile.parisc             |  192 ++++

 src/Kconfig                 |   54 +-

 src/biosvar.h               |   31 +

 src/block.c                 |   10 +-

 src/block.h                 |    2 +

 src/boot.c                  |   48 +

 src/byteorder.h             |   74 ++

 src/farptr.h                |   14 +-

 src/font.c                  |    2 +

 src/fw/csm.c                |    2 +-

 src/fw/paravirt.h           |    7 +

 src/fw/pciinit.c            |   53 +-

 src/fw/shadow.c             |    2 +

 src/hw/ata.c                |   70 +-

 src/hw/ata.h                |   14 +-

 src/hw/blockcmd.c           |   17 +-

 src/hw/blockcmd.h           |    2 +-

 src/hw/esp-scsi.c           |    2 +-

 src/hw/lsi-scsi.c           |    6 +-

 src/hw/megasas.c            |    2 +-

 src/hw/mpt-scsi.c           |    2 +-

 src/hw/pci.c                |   13 +-

 src/hw/pvscsi.c             |    2 +-

 src/hw/rtc.h                |    7 +

 src/hw/serialio.c           |    2 +-

 src/hw/serialio.h           |   10 +-

 src/hw/usb-msc.c            |    2 +-

 src/hw/usb-uas.c            |    2 +-

 src/hw/virtio-scsi.c        |    2 +-

 src/malloc.c                |    4 +-

 src/malloc.h                |    8 +-

 src/output.c                |   56 +-

 src/parisc/b160l.h          |  630 +++++++++++

 src/parisc/head.S           |  319 ++++++

 src/parisc/hppa.h           |  370 +++++++

 src/parisc/hppa_hardware.h  |   49 +

 src/parisc/lasips2.c        |   66 ++

 src/parisc/lasips2.h        |   17 +

 src/parisc/malloc.c         |   91 ++

 src/parisc/pafirmware.lds.S |   69 ++

 src/parisc/parisc.c         | 1997 +++++++++++++++++++++++++++++++++++

 src/parisc/pdc.h            |  694 ++++++++++++

 src/parisc/sti.c            |  179 ++++

 src/parisc/sticore.h        |  326 ++++++

 src/parisc/stirom.c         |  652 ++++++++++++

 src/parisc/timer.c          |  103 ++

 src/post.c                  |    2 +-

 src/romfile.c               |    4 +-

 src/sercon.c                |    2 +-

 src/serial.c                |    4 +-

 src/stacks.h                |   17 +-

 src/string.c                |   27 +-

 src/types.h                 |    8 +-

 src/version.c               |    4 +-

 src/x86.h                   |    6 +

 56 files changed, 6236 insertions(+), 123 deletions(-)

 create mode 100644 Makefile.parisc

 create mode 100644 src/parisc/b160l.h

 create mode 100644 src/parisc/head.S

 create mode 100644 src/parisc/hppa.h

 create mode 100644 src/parisc/hppa_hardware.h

 create mode 100644 src/parisc/lasips2.c

 create mode 100644 src/parisc/lasips2.h

 create mode 100644 src/parisc/malloc.c

 create mode 100644 src/parisc/pafirmware.lds.S

 create mode 100644 src/parisc/parisc.c

 create mode 100644 src/parisc/pdc.h

 create mode 100644 src/parisc/sti.c

 create mode 100644 src/parisc/sticore.h

 create mode 100644 src/parisc/stirom.c

 create mode 100644 src/parisc/timer.c



-- 

2.29.2


_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

* Helge Deller <deller@gmx.de>:
> This patchset modifies SeaBIOS source code to be able to build a firmware for
> the PA-RISC CPU architecture. This firmware can then be used to boot a virtual
> PA-RISC machine with PA-Linux and HP/UX on QEMU.
>
> Where possible existing SeaBIOS drivers and infrastructure is reused.
> Since PA-RISC is native 32/64-Bit, the various segment accessors are
> not needed and replaced by simple variable accesses.

Btw, the whole patchset can be pulled on top of seabios master tree from:

	https://github.com/hdeller/seabios-hppa.git hppa-target

Helge

> Helge Deller (31):
>   Add config option for PA-RISC arch
>   biosvar.h: Add accessors for various BIOS data areas
>   Drivers: Use get_bda_ptr() BDA accessor
>   byteorder.h: Add endianess conversion functions
>   farptr.h: Add FLATPTR* accessor functions for parisc
>   font.c: Disable built-in x86 font on parisc
>   paravirt.h: Add PORT_QEMU_CFG_CTL for parisc
>   pciinit.c: Initialize PA-RISC Dino PCI chip
>   shadow.c: Compile int3 inline assembly on x86 only
>   Add portaddr_t typedef to specify I/O port addresses
>   ata.c: Allow to boot on PA-RISC
>   ata.h: Add ATA IDE port addresses for PA-RISC
>   blockcmd.c: Prevent unaligned access crash on PA-RISC
>   scsi: Add fields for specifying target and lun of SCSI devices
>   lsi-scsi.c: Convert SCSI script to little endian
>   pci.c: Add PCI ports for PA-RISC and access PCI bus in little-endian
>   rtc.h: Add CMOS/RTC addresses for PA-RISC
>   serialio.h: Add serial port adresses for PA-RISC
>   malloc.c: Implement a PA-RISC specific malloc()
>   output.c: Add PA-RISC specific output behaviour
>   output.c: Make printf() capable to print 64bit int values
>   romfile.c: return values are returned as little-endian
>   sercon.c: Use SEROFF_IIR constant
>   stacks.h: Provide replacement for thread functions when
>     !CONFIG_THREADS
>   version.c: Mark version strings const
>   x86.h: Provide replacement functions for PA-RISC
>   parisc: Add PA-RISC related code
>   string.c: reimplement mem*_far() functions for PA-RISC
>   boot.c: Add boot disc chooser for PA-RISC
>   block.c: Allow PA-RISC to boot from ATA drives
>   ata.c: Add missing endianess conversion functions
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

On Thu, Feb 11, 2021 at 11:00:34PM +0100, Helge Deller wrote:
> This patchset modifies SeaBIOS source code to be able to build a firmware for
> the PA-RISC CPU architecture. This firmware can then be used to boot a virtual
> PA-RISC machine with PA-Linux and HP/UX on QEMU.
> 
> Where possible existing SeaBIOS drivers and infrastructure is reused.
> Since PA-RISC is native 32/64-Bit, the various segment accessors are
> not needed and replaced by simple variable accesses.

Thanks.

My main high-level feedback is that this patch series has too many
#ifdefs in it.  That is, if we want to integrate the code, we'd really
need to do the work to fully integrate it.  That would mean going
through each case where parisc differs from x86 and coming up with
alternate code that works well for both architectures.  That may, for
example, involve compiling different files for different
architectures, using different include directives so that different
headers get pulled in, and code refactoring in general.  Some of this
would be possible using runtime checks (eg, if (CONFIG_X86) ), but
even that would need to be kept to only those code paths that are
architecture specific.

Similarly, there are many cases where parisc has different
implementations of similar functionality that isn't architecture
specific (eg, malloc implementation, high-level timer implementation,
a different boot menu).  If the goal is integration then I think we
would need to integrate - including the "warts".

I understand that is significantly more work, but I think it would be
necessary.  My feedback on the patches today is that it feels like
there are two notably different SeaBIOS implementations welded
together with ifdefs.  Unfortunately, that would effectively double
the ongoing maintenance costs.  I suspect seemingly innocuous changes
could break one of the architectures.  Or, alternatively, require
twice the work for developers to make similar changes in two places.
I fear developers would be unlikely to test both architectures on
every change and it would be difficult to know which changes impact
each architecture.

Separately, on the procedural side, every incremental patch would need
to be compilable and runable.  This doesn't appear to be the case for
this series - as an example, patch 18 pulls in a header file that
isn't actually added until patch 27.  It's important to order the
patches into functional chucks so that "git bisect" works properly,
should we encounter a regression.  This is particularly important for
this patch series given the magnitude of the change.

Cheers,
-Kevin
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

Hi Kevin,

On 2/24/21 2:23 AM, Kevin O'Connor wrote:
> On Thu, Feb 11, 2021 at 11:00:34PM +0100, Helge Deller wrote:
>> This patchset modifies SeaBIOS source code to be able to build a firmware for
>> the PA-RISC CPU architecture. This firmware can then be used to boot a virtual
>> PA-RISC machine with PA-Linux and HP/UX on QEMU.
>>
>> Where possible existing SeaBIOS drivers and infrastructure is reused.
>> Since PA-RISC is native 32/64-Bit, the various segment accessors are
>> not needed and replaced by simple variable accesses.
>
> Thanks.
>
> My main high-level feedback is that this patch series has too many
> #ifdefs in it.  That is, if we want to integrate the code, we'd really
> need to do the work to fully integrate it.  That would mean going
> through each case where parisc differs from x86 and coming up with
> alternate code that works well for both architectures.  That may, for
> example, involve compiling different files for different
> architectures, using different include directives so that different
> headers get pulled in, and code refactoring in general.  Some of this
> would be possible using runtime checks (eg, if (CONFIG_X86) ), but
> even that would need to be kept to only those code paths that are
> architecture specific.

Yes, agreed.

> Similarly, there are many cases where parisc has different
> implementations of similar functionality that isn't architecture

I assume you meant "...that IS architecture specific" ?

> specific (eg, malloc implementation, high-level timer implementation,
> a different boot menu).  If the goal is integration then I think we
> would need to integrate - including the "warts".

Ok.

> I understand that is significantly more work, but I think it would be
> necessary.  My feedback on the patches today is that it feels like
> there are two notably different SeaBIOS implementations welded
> together with ifdefs.  Unfortunately, that would effectively double
> the ongoing maintenance costs.  I suspect seemingly innocuous changes
> could break one of the architectures.  Or, alternatively, require
> twice the work for developers to make similar changes in two places.
> I fear developers would be unlikely to test both architectures on
> every change and it would be difficult to know which changes impact
> each architecture.

Yes, my goal was not to put additional burden on the SeaBIOS develpers,
so I did not expected everyone to do an additional build check if
by mistake the parisc target breaks.

> Separately, on the procedural side, every incremental patch would need
> to be compilable and runable.  This doesn't appear to be the case for
> this series - as an example, patch 18 pulls in a header file that
> isn't actually added until patch 27.  It's important to order the
> patches into functional chucks so that "git bisect" works properly,
> should we encounter a regression.  This is particularly important for
> this patch series given the magnitude of the change.

Sure.

Overall, thanks a lot for your feedback!!!

But, I'm not clear yet on how to continue.
Currently SeaBIOS-parisc is a fork, and I think it's easy to
still keep the fork for the time beeing.
That way there will not be additional work for the developers.

What I would prefer is if we maybe could work through at least
some of the patches and see if we could integrate them (where it makes sense),
so that my diff to upstream-seabios can get reduced.
Would that be an acceptable way forward?

If yes, I think I need clear guidance, e.g. first of all, is adding
a CONFIG_X86 and CONFIG_PARISC config option (patch #1) in the Kconfig OK ?

What about simplifying the bda accessors (patch #2 and #3, but
drop the parisc part there before applying).
Same for the patches regarding endianess (e.g. patch #4).
Trivial ones like patch #7 which adds some parisc constants?
And patch #10 which adds the portaddr_t typedef?

Would you be willing to work walk through the various patches
and give specific feedback?

Thanks for your help!
Helge
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

On Wed, Mar 03, 2021 at 05:26:23PM +0100, Helge Deller wrote:
> On 2/24/21 2:23 AM, Kevin O'Connor wrote:
> > Similarly, there are many cases where parisc has different
> > implementations of similar functionality that isn't architecture
> 
> I assume you meant "...that IS architecture specific" ?

No, I mean that the patch series introduces some code that is
different from the X86 seabios code, but does not need to be
different.  That is, it introduces different versions of some
functions that are not architecture specific.  I understand
introducing different versions of functions that are architectures
specific - that's a requirement for supporting a different
architecture - but it should not be necessary to introduce a parisc
version of a malloc function, for example.

[...]
> Overall, thanks a lot for your feedback!!!
> 
> But, I'm not clear yet on how to continue.
> Currently SeaBIOS-parisc is a fork, and I think it's easy to
> still keep the fork for the time beeing.
> That way there will not be additional work for the developers.
> 
> What I would prefer is if we maybe could work through at least
> some of the patches and see if we could integrate them (where it makes sense),
> so that my diff to upstream-seabios can get reduced.
> Would that be an acceptable way forward?

Sure - if there are ways to improve the SeaBIOS code that also make it
easier to support parisc then that's fine.

> If yes, I think I need clear guidance, e.g. first of all, is adding
> a CONFIG_X86 and CONFIG_PARISC config option (patch #1) in the Kconfig OK ?

In general, no.  It wouldn't make sense for us to maintain code or
config options for external code.  That increases maintenance costs
and is unlikely to succeed in general.  (No one will test the config
options not used locally.)

> What about simplifying the bda accessors (patch #2 and #3, but
> drop the parisc part there before applying).

We can add accessor functions like get_bda_ptr().  However, patch 2
adds a bunch of ifdefs that don't look right to me - in particular,
farvar.h already substitutes the simpler assignments when not in
"segment mode", so it should not be necessary to add in additional
ifdefs in biosvar.h .

> Same for the patches regarding endianess (e.g. patch #4).

We can improve the endianness code, but I'd prefer an approach with
less ifdefs.  Gcc should have a macro for endianness already, and we
should be able to use runtime C code to make the checks (which gcc can
optimize at compile time).

> Trivial ones like patch #7 which adds some parisc constants?

That has the issue of introducing ifdefs, and I don't think that is a
good plan for external code (as mentioned above).

> And patch #10 which adds the portaddr_t typedef?

That's a case where I'd just change the io functions to use a u32
universally.  I don't think a typedef is needed.

Cheers,
-Kevin
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org