A7000+ newfs hang/crash during installation

[David Boddie <david%boddie.org.uk@localhost>]

Hi,

I'm currently trying to install NetBSD 6.0.1 on an A7000+ with an IDE-SD card
adapter. I was initially using the released binaries to boot and start
installation but have since used binaries that I built from source and
encountered similar problems.

Booting seems to work fine once I patched the boot32 module to run without
calling OS_ReadSysInfo - this seems to be unavailable on RISC OS 3.71.

Installation seems to work until filing systems are being created. disklabel
is run successfully but newfs either crashes or hangs. If I use a shell in
the installer and run newfs then I get a crash:

  # newfs -b 16384 -f 2048 -O 0 -V 4 /dev/rwd0a
  /dev/rwd0a: 5742.4MB (11768336 sectors) block size 16384, fragment size 2048
          using 32 cylinder groups of 179.45MB, 11485 blks, 22656 inodes.
  super-block backups (for fsck_ffs -b #) at:
  panic: kernel diagnostic assertion "(pcb->pcb_tf->tf_spsr & IF32_bits) == 8" 
failed: file "/home/david/Software/NetBSD/usr/src/sys/arch/arm/arm/ast.c", line 
82
  Stopped in pid 12.1 (newfs) at  netbsd:cpu_Debugger+0x4:        mov     r15, 
r14

  db> bt
  netbsd:vpanic+0x10
          scp=0xf0141830 rlv=0xf020a3d0 (netbsd:kern_assert+0x40)
          rsp=0xf39dbe84 rfp=0xf39dbe98
          r7=0x000000ae
  netbsd:kern_assert+0x14
          scp=0xf020a3a4 rlv=0xf00010c4 (netbsd:userret+0xb0)
          rsp=0xf39dbeac rfp=0xf39dbec4
  netbsd:userret+0x10
          scp=0xf0001024 rlv=0xf01561dc (netbsd:syscall+0xe8)
          rsp=0xf39dbec8 rlp=0xf39dbf54
          r5=0x00000000 r4=0xf39dbfb4
  netbsd:syscall+0x10
          scp=0xf0156104 rlv=0xf0156394 (netbsd:swi_handler+0xc0)
          rsp=0xf39dbf58 rfp=0xf39dbfb0
          r10=0x00000000 r9=0x00000000
          r8=0x00000000 r7=0x00000001 r6=0xf024c728 r5=0xf119f540
          r4=0xf39dbfb4
  netbsd:swi_handler+0x10
          scp=0xf01562e4 rlv=0xf003c6e8 (netbsd:swi_entry+0x5c)
          rsp=0xf39dbfb4 rfp=0xefffd034
          r8=0x00000000 r7=0x00000000
          r6=0x20300000 r5=0x00000000 r4=0xf024c728

Is this known behaviour?

David