Subject: Archimedes page tables in 3/4 MEMC1 system

From: [email-masked] (Theo Markettos)
Date: Sun, 20 Aug 2000 21:55:43 +0100

Does Linux work on the A540 with 12 or 16MB?  The reason I ask is I'm trying
to figure out how that memory system works, but don't have a technical
reference manual.  How are the logical-physical address translators
programmed if there's more than one slave MEMC?

The MEMC databook (ARM FDM) only seems to cover the case where there's one
slave MEMC, in which case A[7] is used to choose between master and slave,
and is don't care otherwise.  But there are no other don't cares in the
address translator entry, so where does the bit to choose between MEMCs 0/1
and MEMCs 2/3 come in?  Or have Acorn done something odd in their memory
system to fudge this (but how do they squeeze the translators into the memory
map?)

Does anyone have an A540 schematic handy?

Thanks,
Theo

-- 
Theo Markettos       [email-masked]
Liphook              [email-masked]
Hampshire            
UK                   http://www.markettos.org.uk/

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 20 Aug 2000 22:57:41 +0100 (BST)

> programmed if there's more than one slave MEMC?

None of the MEMCs are in slave mode - they're all in master mode.  There is
however a PLD which controls them, and the accesses to them.  It may have
something to do with the unused bits while writing to the MEMC (14:12), but
a machine to fiddle at assembly level would be needed to work this out.

The PLD controls A22 and A7 to each MEMC, and takes A25 through A22, A14
through A12 and A7.

> system to fudge this (but how do they squeeze the translators into the memory

Yes, its very odd.

Maybe one way would be to scope the PLD, and have the assembly code go around
writing a constant code in a loop (and monitor all its outputs).  Then, change
the code its writing (thereby changing the PLDs input) and repeat.

Then build up a truth table of whats going on...

The PLD is IC39, a 20 pin device, with the following pinout:

 1 A25
 2 A24
 3 A23
 4 A22
 5 A14
 6 A13
 7 A12
 8 A7
 9 nR/W
10 GND
11 unused
12 A7 to memc in slot 3
13 A7 to memc in slot 2
14 A7 to memc in slot 1
15 A7 to memc onboard
16 A22 to memc in slot 3
17 A22 to memc in slot 2
18 A22 to memc in slot 1 
19 A22 to memc onboard
20 VCC

Feel free to discuss your findings with me.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: [email-masked] (Theo Markettos)
Date: Mon, 21 Aug 2000 20:04:34 +0100

> The PLD controls A22 and A7 to each MEMC, and takes A25 through A22, A14

OK... it sounds like they're using A7 as an enable line when writing page
tables.  As to what they're doing with A22, that's bit 7 of the logical page
number, so I have no idea why they would want to mess with that...

I don't actually have a machine to play with - my random thought was to
synthesize in a PLD or FPGA as much of a MEMC as was required to do the page
tables and DRAM refresh, and make a 16MB RAM upgrade for my A4.  Having seen
how tight space is inside the A4, and having to piggyback both MEMC and VIDC
to get the signals, it's probably not easy mechanically if it was doable
electrically.  Still, it's an interesting thought experiment...

Thanks,
Theo