[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments

[Mark Cave-Ayland]

Blue Swirl wrote:

> This means that the device is not mapped. Maybe this can help:
> 
> diff --git a/drivers/obio.c b/drivers/obio.c
> index 38c5f8d..d22abe3 100644
> --- a/drivers/obio.c
> +++ b/drivers/obio.c
> @@ -228,7 +228,7 @@ ob_auxio_init(uint64_t base, uint64_t offset)
>  {
>      ob_new_obio_device("auxio", NULL);
> 
> -    ob_reg(base, offset, AUXIO_REGS, 0);
> +    ob_reg(base, offset, AUXIO_REGS, 1);
> 
>      fword("finish-device");
>  }

Better, but still not quite right:

Configuration device id QEMU version 1 machine id 32
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Oct 30 2010 16:27
   Type 'help' for detailed information
Trying cdrom:d...
Not a bootable ELF image
Loading a.out image...
Loaded 7680 bytes
entry point is 0x4000
bootpath: /iommu/sbus/espdma/esp/sd at 2,0:d

Jumping to entry point 00004000 for type 00000005...
switching to new context:
device auxio address prop too big
SunOS Release 5.8 Version Generic_108528-09 32-bit
Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.

Looking closer:

Configuration device id QEMU version 1 machine id 32
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Oct 30 2010 16:27
   Type 'help' for detailed information

0 > cd /obio/auxio  ok
0 > .properties
name                      "auxio"
reg                       -- c : 00 00 00 00 00 90 00 00 00 00 00 01
address                   -- 8 : ff eb 20 00 00 00 00 04
  ok
0 >

Hmmm. It look as if this part of map_reg in drivers/obio.c is totally 
wrong, at least for SPARC32:

     if (map) {
         unsigned long addr;

         addr = (unsigned long)map_io(base + offset, size);

         PUSH(addr);
         fword("encode-int");
         PUSH(4);
         fword("encode-int");
         fword("encode+");
         push_str("address");
         fword("property");
         return addr;
     }
     return 0;

I'd probably say that based upon the output above we should probably 
remove the second PUSH() and encode-int/encode+ completely, but it must 
have been added for a reason. Blue, any ideas?


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs