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
# 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
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...
--- 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,