> 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 :-(.
Can you hack the code so that it prints exactly what it gets passed by
the ARC firmware?
> 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:
This isn't a bug but a problem with which convention you use to describe
a certain area of memory. I prefer to do it as in the first memory list
dump because otherwise you'll run in the problem if 0x1234 - 0x1234 is
an area of zero or one byte size?
> o MILO can never be loaded at 0x80f00000-0x80ffffff or it will
> stomp by BIOS.
Milo is linked for address 0x80600000 which is good by definition because
that's what NT does ... Ok, the real this is to do what the ARC docs
suggest which is either to include fixup information in the executable
or to use produce relocatable code. I'm working on making the later
possible because that's really required for the SNI firmware.
> 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?
Linux and an eventually loaded RAMdisk gets loaded into whatever memory
is free, then later on Milo copies all this stuff into the place where
it belongs. At that point the firmware is dead or as the ARC docs say
the machine enters "program state" which can by definition only be
left by reset.
> o MILO could pass this detailed information to Linux and Linux
> could use it to setup its initial memory maps.
Indeed, it could do so. So far I just had the problem that I found
several ARC BIOSes lying about the available memory. The Tyne with 8mb
says it has 2mb available - and another 256mb chunk of memory which
isn't installed ...
Reason enough to query the hardware where possible.
> 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 :-).
The rPC doesn't say anything about what is installed in this address
range and so you better shouldn't make any assumptions.
> 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
These are partially already implemented.
> 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 :-).
Hm... That part is usually very easy if you have NT to install on your
machine. Just ask the diagnosis program about some trivial thing like
FDC/serial interface or so and you'll find where the ports live in just
Even better - apparently NT's equivalents to Linux's inb/inw/inl/outb etc.
functions are macros compiled into NT which means that every MIPS NT
machine is assumed to have the same 1:1 mapping of ports into memory -
just the base address is different.
A weird imagination is most useful to gain full advantage
of all the features - manpage of amd(8).