: Can you hack the code so that it prints exactly what it gets passed by
: the ARC firmware?
Yes. I was going to do that to see what is going on with the args,
since I'm really wanting to start to use them...
: > 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.
Hmmm. I know that the rPC44 is happy to report correct information
(or nearly so) about the memory. Is it just the Tyne (which is a
known rogue in many respects), or are there others as well. I'd
suspect the PICA also, since that was an early board, or maybe the
Magnum, since it is just a stripped down pica (or more accurately a
pica is a built up magnum).
Too bad I don't have hardware docs on the rPC, or I'd know how to ask
the hardware directly. There doesn't seem to be a R4030 controller
chip like the PICA has on my motherboard to ask (or is that integrated
into the R4400PC and I've just not stumbled across references to it
: 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.
I've seen something similar when disassembling code from NT. I think
that the pica port in NetBSD and the arc port in OpenBSD do the same