Re: [OpenBIOS] Solaris anyone?

[Blue Swirl]

On Tue, Jun 14, 2011 at 8:19 AM, Bob Breuer  wrote:
> Blue Swirl wrote:
> > On Mon, Jun 13, 2011 at 2:06 AM, Bob Breuer  wrote:
> > > Nathan Kunkee wrote:
> > > > > Date: Mon, 6 Jun 2011 15:54:39 -0400
> > > > > From: [e-mail]
> > > > > To: [e-mail]
> > > > > Subject: Re: [OpenBIOS] Solaris anyone?
> > > > > > Hmmm it looks from reading the source code that QEMU doesn't actually
> > > > > > implement a proper audio device for SS-5 at all but merely provides a
> > > > > > dummy device with an empty mapped region. In that case it may be
> > > > > > possible to provide a simple mapping in OpenBIOS to match the one in
> > > > > > QEMU which may be enough to persuade Solaris to boot.
> > > > >
> > > > > Ugh. I recall that audio chip being non-trivial...
> > > > >
> > > > > It might be worth deleting that audio device from the device tree and
> > > > > see if Solaris really does get further.
> > > >
> > > > I've tried the same CD image with the SS-10 QEMU machine, which seems
> > > > to lack the audio device, and I still hang. I get the first part of
> > > > the kernel, no extra logging, and then the spinner to infinity...
> > > >
> > > > nathan@xanth:/usr/local/build/qemu$ sparc-softmmu/qemu-system-sparc
> > > > -bios openbios-builtin.elf -M SS-10 -cdrom
> > > > /local/storage/ISO/solaris-9-sparc-d1.iso -nographic
> > > >
> > > > Configuration device id QEMU version 1 machine id 64
> > > > CPUs: 1 x TI,TMS390Z55
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11
> > > >   Type 'help' for detailed information
> > > > Trying disk...
> > > > No valid state has been set by load or init-program
> > > >
> > > > 0 > boot cd:d -k -v Not a bootable ELF image
> > > > Loading a.out image...
> > > > Loaded 7680 bytes
> > > > entry point is 0x4000
> > > > bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
> > > >
> > > > Jumping to entry point 00004000 for type 00000005...
> > > > switching to new context:
> > > > Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes
> > > > SunOS Release 5.9 Version Generic_112233-12 32-bit
> > > > Copyright 1983-2003 Sun Microsystems, Inc.  All rights reserved.
> > > > Use is subject to license terms.
> > > > Ethernet address = 52:54:0:12:34:56
> > > > Using default device instance data
> > > > \
> > > >
> > > > Does anyone know what loads on a real SS after the audio device?
> > > >
> > > > Nathan
> > >
> > > For this hang, Solaris is stuck trying to set and verify a bit which is
> > > currently un-settable in qemu.  It's the MMU breakpoint action register
> > > (asi 0x4c), and if bit 12 is set, then it should continue on just like
> > > with SS-5.  After fcp0, the next thing Solaris should initialize is the
> > > network:
> > >
> > > pseudo-device: fcp0
> > > fcp0 is /pseudo/fcp@0
> > > Using RPC Bootparams for network configuration information.
> > > le0: No carrier - cable disconnected or hub link test disabled?
> > > le0: No carrier - cable disconnected or hub link test disabled?
> > > Skipping interface le0
> >
> > Would this (untested) patch to QEMU help?
>
> It does work, but ...
> > diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h
> > index 320530e..b93fdfd 100644
> > --- a/target-sparc/cpu.h
> > +++ b/target-sparc/cpu.h
> > @@ -403,6 +403,7 @@ typedef struct CPUSPARCState {
> >      uint32_t mmuregs[32];
> >      uint64_t mxccdata[4];
> >      uint64_t mxccregs[8];
> > uint64_t mmubpaction;
>
> Looks like it's less than 64 bits:
>
> ok 0 0 0 4c spaced!
> ok 0 4c spaced@ . .
> 0 0
> ok 0 not dup 0 4c spaced!
> ok 0 4c spaced@ . .
> 0 1fff
> ok 0 4c spacel@ . 4 4c spacel@ .
> 1fff 1fff
>
> Would it make sense to declare it as 32-bit, or just mask out the extra
> bits?  or not even care since almost nobody writes to that register?

Better use the correct size.
> > uint64_t mmubpregs[4];
> >      uint64_t prom_addr;
> >  #endif
> > diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
> > index b38691e..1023870 100644
> > --- a/target-sparc/op_helper.c
> > +++ b/target-sparc/op_helper.c
> > @@ -1941,7 +1941,7 @@ uint64_t helper_ld_asi(target_ulong addr, int
> > asi, int size, int sign)
> >      case 0x32: // Turbosparc page table descriptor diagnostic
> >      case 0x39: /* data cache diagnostic register */
> >      case 0x4c: /* SuperSPARC MMU Breakpoint Action register */
> > ret = 0;
> > ret = env->mmubpaction;
> >
> > break;
>
> And here, 0x39 and above should still have the ret = 0.

OK.
> > case 0x38: /* SuperSPARC MMU Breakpoint Control Registers */
> >          {
> > @@ -2304,7 +2304,9 @@ void helper_st_asi(target_ulong addr, uint64_t
> > val, int asi, int size)
> >                 // descriptor diagnostic
> >      case 0x36: /* I-cache flash clear */
> >      case 0x37: /* D-cache flash clear */
> > break;
> >
> > case 0x4c: /* breakpoint action */
> > env->mmubpaction = val;
> >
> > break;
> >      case 0x38: /* SuperSPARC MMU Breakpoint Control Registers*/
> >          {
>
> By the way, what would it take to get the space[cwLd] commands in
> OpenBIOS?  They come in handy for verifying these asi accesses.

Shouldn't be very difficult. Since on Sparc32 it's not possible to
give ASI in a register, a switch or hand assembly would be needed.