port-mvme68k/60699: MVME177 tape boot fails with direct MVMEPROM_DSKRD, succeeds with hackprom_diskrd

["takai870%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60699
>Category:       port-mvme68k
>Synopsis:       MVME177 tape boot fails with direct MVMEPROM_DSKRD, succeeds with hackprom_diskrd
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-mvme68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 08 22:25:00 +0000 2026
>Originator:     atsushi takaira
>Release:        NetBSD11
>Organization:
parsonal
>Environment:
MVME177
>Description:
NetBSD/mvme68k 11.0 tape boot fails on a Motorola MVME177 when
bootst uses mvmeprom_diskrd() directly.

Hardware:
  Motorola MVME177
  HP C5683A DDS-4 tape drive
  
NetBSD:
  NetBSD 11.0 mvme68k
  bootst built from the NetBSD 11 source tree

The tape contains:
  1. stboot
  2. bootst
  3. netbsd-RAMDISK
  (and miniroot in the full installation tape)

With the normal tape_strategy():

        if (bugargs.cputyp == 0x147)
                ret = hackprom_diskrd(ti);
        else
                ret = mvmeprom_diskrd(ti);

the MVME177 fails while loading the RAMDISK ELF:

        Volume: NBSD
        IPL loaded at: $003F0000
        >> NetBSD/mvme68k MVME177 tapeboot [...]
        3457428read section: Unknown error: code -1

I verified that the RAMDISK ELF is not corrupted. Its ELF LOAD
segment has:

        p_offset = 0x80
        p_vaddr  = 0x8000
        p_filesz = 3457428
        p_memsz  = 3533896

I also tested a modified copy with p_filesz rounded up to the next
512-byte boundary (3457536), but direct mvmeprom_diskrd() still
failed.

I compared the NetBSD 6.0.4 and NetBSD 11 versions of:

        stand/bootst/dev_tape.c
        stand/libbug/diskrd.c
        arch/mvme68k/include/prom.h

The PROM call macros and mvmeprom_diskrd() implementation are
effectively identical.

The important test was to force bootst to use hackprom_diskrd():

        printf("\n*** FORCE HACKPROM ***\n");
        ret = hackprom_diskrd(ti);

With this change, the exact same tape/RAMDISK successfully boots
all the way to the NetBSD/mvme68k RAMDISK root environment.

Therefore, on this MVME177, hackprom_diskrd() appears to be required
for tape reads, while direct mvmeprom_diskrd() fails.

The existing hackprom_diskrd() comment says that the PROM returns
1 on end-of-file when END_OF_FILE is specified, and treats this as
a non-error. With direct mvmeprom_diskrd(), however, the observed
return value reaches tape_strategy() as ret=1 and is treated as EIO.

The current code appears to select hackprom_diskrd() only when
bugargs.cputyp == 0x147. I have not yet determined whether the
MVME177 reports a different cputyp value or whether the existing
selection logic is otherwise incorrect.

A possible workaround is to use hackprom_diskrd() for MVME177 as
well, but I would like to know the intended PROM/tape handling for
MVME177 and whether the cputyp test should be changed.
>How-To-Repeat:
See above.
>Fix:
See above.