Re: port-sgimips/53539: irisboot (I named) Yet another sgimips bootloader

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

[redirected from PR port-sgimips/53539 http://gnats.NetBSD.org/53539 ]

I know it's better to keep discussion about PR in Gnats (and netbsd-bugs@).
However I would like to share progress of bootloaders with standalone
SCSI driver for Indigo R3K (and other poor BIOS) machines.


> >Synopsis:       irisboot (I named) Yet another sgimips bootloader
 :
> Background:
> NetBSD does not support booting from disk on systems lacking an ARCS
> compatible firmware.
> (presently supported systems include Personal IRIS and IRIS Indigo R3000)
> Because existing NetBSD/sgimips bootloader is dependent on ARCBIOS.
 :
> Approach:
> This patch don't use ARCBIOS routine, but use zs(Z8530 serial interface
> driver) and wdsc(Western Digital WD33c93 SCSI Bus Interface Controller
> driver).
> https://github.com/nullnilaki/NetBSD_irisboot/blob/master/irisboot.diff
 :
> Additional functions:
> It would be possible to boot Indigo R4000 or Indy if to edit
> PRE_ARCS(bootiris/Makefile) and INDIGO_R3K_MODE(common/iris_machdep.h).
> https://github.com/nullnilaki/NetBSD_irisboot/blob/master/irisboot.diff#L88
> https://github.com/nullnilaki/NetBSD_irisboot/blob/master/irisboot.diff#L918

I have just tried this irisboot modified for my R5000 Indy
and it just works, i.e. a bootloader with standalone wd33c93 driver
is functional. It's really great!

I've also put your bootiris (and other sgimips stand sources) for review:
 https://github.com/tsutsui/NetBSD_irisboot/commits/master

My local changes in the github:

* misc cleanup (KNF, whitespace etc.)
 https://github.com/tsutsui/NetBSD_irisboot/commit/d7433be593c17b997bbbe2ac8f0e28cf7827c704
 https://github.com/tsutsui/NetBSD_irisboot/commit/fc487fe906715cccd82e6218ae7ca4da17e3f316
 https://github.com/tsutsui/NetBSD_irisboot/commit/022b9f1bbbd212e6edd97bcf0d083643f8e1b06b
* merge DELAY macro
 https://github.com/tsutsui/NetBSD_irisboot/commit/a7ae14d9477dff5ae0f48a122850adcb6814d5d3

I would also like to confirm some SCSI implementation.


(1) scsi_test_unit_rdy()

I think you pulled MI SCSI disk command code from sys/arch/hp300/stand/sd.c
and you also used sys/dev/ic/wd33c93.c for chip dependent SCSI state
handling. It looks some inconsistency between them.

It looks the original hp300's test_uni_rdy() returns SCSI status
passed from the SCSI target device in STATUS_PHASE.

On the other hand, test_unit_rdy() in bootiris returns
a return value of wd33c93_go() in iris_scsi.c and it returns 1
on error and 0 on normal completion.

wd33c93_go() is called from scsi_test_unit_rdy(), scsi_readx25(),
and scsi_readx28() in iris_scsictl.c, and it looks also derived from
hp300/stand/common/scsi.c (scsi_read_capacity() and scsi_tt_read()).

wd33c93_go() itself seems derived from wd33c93_go() (and
wd33c93_scsi_request()) in sys/dev/ic/wd33c93.c.

It looks sc->sc_status read from GET_SBIC_tlun() register
has the SCSI status, but I have not checked wd33c93 specifications.

The original code just check if it's STS_CHECKCOND and wait to spin up
the target disk, so I guess we don't have to check it strictly,
but I wonder if we should a common API for it.
(It might be simpler to just check stat != 0 as CHECKCOND)


(2) function names

As noted in the above, there are scsi_readx25(), scsi_readx28(), and
scsi_readx2A() functions in iris_scsictl.c.
What is your intention about these names?

I guess 0x25 is SCSI disk READ_CAPACITY, 0x28 is SCSI disk READ_10, and
0x2A is SCSI disk WRITE_10, but command names is simpler, IMO.


(3) scsi message macro

It looks common/iris_scsimsg.h is almost same as MI
<dev/scsipi/scsi_message.h> so I also changed to use it
raher than a local copy.


(4) copyright notice

It looks several files are based on existing sources:
>> iris_disk.c: * Most of the following was adapted from /sys/arch/hp300/stand/common/sd.c.
>> iris_scsireg.h: * Most of the following was adapted from sys/dev/ic/wd33c93reg.h.
>> iris_zs.c: * Most of the following was adapted from /sys/arch/sgimips/dev/zs.c.

Maybe it's better to keep the copyright notices in the original files
(though some of them include annoying ad clause leftovers).


Anyway, I'm really happy to see your great work.
(MI standalone SCSI is one of my longstanding todo list items :-)

Thanks again!

---
Izumi Tsutsui