linux-mips-fnet
[Top] [All Lists]

Deskstation rPC44 and Milo 0.27

To: linux-mips@fnet.fr
Subject: Deskstation rPC44 and Milo 0.27
From: Warner Losh <imp@village.org>
Date: Sun, 01 Sep 1996 15:10:10 -0600
Looks like at least pandora can boot and run on the Deskstation
rPC44.  I've found two minor problems, and have a fix for one.

The first, without a fix, is that I always get a usage message from
pandora complaining that ';' isn't a valid argument.  I run it via the
run program menu, so maybe that is why, but I kinda doubt it.  A quick
hack to usage so that it doesn't always exit puts me back on the air.
I've not included this because it is a bandaid to another bug.  Then
again, I've never had the boot parameters work for me at all, maybe
this is a bug in my BIOS ROMs :-(.

The second problem is that the memory command has a fencepost error in
it.  Here's the current output from it on my machine:

#    start    - end       size     type

  0: 80000000 - 80001000  00001000 ExceptionBlock
  1: 80001000 - 80002000  00001000 SystemParameterBlock
  2: 80002000 - 800a0000  0009e000 FreeMemory
  3: 800a0000 - 800e0000  00040000 BadMemory
  4: 80020000 - 80600000  00520000 FreeMemory
  5: 80f00000 - 81000000  00100000 FirmwarePermanent
  6: 81000000 - 82000000  01000000 FreeMemory
  7: 80600000 - 8060d000  0000d000 LoadedProgram
  8: 8060d000 - 80f00000  008f3000 FreeMemory

As you can see, all the end addresses are off by one.  Patch is
appended to this message.  Here's the correct output from it on my
machine:

#    start    - end       size     type

  0: 80000000 - 80000fff  00001000 ExceptionBlock
  1: 80001000 - 80001fff  00001000 SystemParameterBlock
  2: 80002000 - 8009ffff  0009e000 FreeMemory
  3: 800a0000 - 800dffff  00040000 BadMemory
  4: 80020000 - 805fffff  00520000 FreeMemory
  5: 80f00000 - 80ffffff  00100000 FirmwarePermanent
  6: 81000000 - 81ffffff  01000000 FreeMemory
  7: 80600000 - 8060cfff  0000d000 LoadedProgram
  8: 8060d000 - 80efffff  008f3000 FreeMemory

Looking at this table, I've learned the following that I think
everyone would be interested in knowing:

        o MILO can never be loaded at 0x80f00000-0x80ffffff or it will
          stomp by BIOS.
        o Linux can be loaded in that range, if need be, since we've
          killed the ROMs by then.  I don't think they last past the
          flushing of the tlb, right?
        o MILO could pass this detailed information to Linux and Linux
          could use it to setup its initial memory maps.
        o What's in the range 0xe0000-0xfffff on a PC?  Why would the
          rpc claim they are free?  The only thing that I can think of
          is that the BIOS of the PC lives in that range and no
          hardware is listening on those address ranges to that memory
          is safe to use.  Or it is a minor bug in the rPC memory
          reporting routines :-).

Useful commands that pandora could implement:
        A way to dump the system parameter block.
        A way to dump the firmware table
        A way to dump the vendor table
        A way to disassemble functions in these tables
        A way to dump a range of memory to disk for offline
                disassembly/decomilation :-)
        A way to dump the configuration tree

Had I known about the system parameter block before milo 0.27 was able
to release that information, I'd have known how to do things like
writes to i/o ports sooner because the first few instructions of my
boot roms do just that :-).

BTW, is there a good source for the ARC BIOS manual, now that we've
had some luck with SNI or whoever so we could release the full MILO
sources?  I'd really like to have one, since I still don't know as
much about my machine as I'd like to...  I'd be happy to foot the bill
for shipping, photocopying, printing, etc to get my hands on one.  I'd
pay as much as $100 for it, even if I had to go directly to MS or SNI
to get one.  Any contact info on this stuff?

Thanks a bunch...

Warner


--- src/arcmemory.c.org Sun Sep  1 14:58:10 1996
+++ src/arcmemory.c     Sun Sep  1 14:58:13 1996
@@ -56,7 +56,7 @@
 
       base = 0x80000000 | (memdesc->BasePage << 12);
       size = memdesc->PageCount << 12;
-      end = base + size;
+      end = base + size - 1;
       typename = typenames[memdesc->MemoryType];
       printf ("%3d: %08lx - %08lx  %08lx %s\r\n", i, base, end, size, 
typename);
       i++;

<Prev in Thread] Current Thread [Next in Thread>