harvey/sys/src/9/kw/plug.words

global scale sheevaplug

marvell 88f6281 (feroceon kirkwood) SoC; ours are revision A0
arm926ej-s rev 1 [56251311] (armv5tejl) 1.2GHz cpu

l1 I & D VIVT caches 16K each: 4-way, 128 sets, 32-byte lines
	l1 D is write-through, l1 I is write-back
unified l2 PIPT cache 256K: 4-way, 2048 sets, 32-byte lines
	potentially 512K: 8-way

apparently the mmu walks the page tables in dram and won't look in the
l2 cache.  there is no hardware cache coherence, thus the l1 caches
need to be flushed or invalidated when mmu mappings change, but l2
only needs to be flushed or invalidated around dma operations and page
table changes, and only the affected dma buffers and descriptors or
page table entries need to be flushed or invalidated in l2.

we arrange that device registers are uncached.

be aware that cache operations act on cache lines (of CACHELINESZ
bytes) as atomic units, so if you invalidate 4 caches of a cache line,
you invalidate the entire cache line, whether it's been written back
(is clean) or not (is dirty).  mixed data structures with parts
maintained by hardware and other parts by software are especially
tricky.  we try to pad the initial hardware parts so that the software
parts start in a new cache line.

512MB of dram at physical address 0
512MB of flash
16550 uart for console
see http://www.marvell.com/files/products/embedded_processors/kirkwood/\
	FS_88F6180_9x_6281_OpenSource.pdf, stored locally as
	/public/doc/marvell/88f61xx.kirkwood.pdf

The code is fairly heavy-handed with the use of barrier instructions
(BARRIERS in assembler, coherence in C), partly in reaction to bad
experience doing Power PC ports, but also just as precautions against
modern processors, which may feel free to execute instructions out of
order or some time later, store to memory out of order or some time
later, otherwise break the model of traditional sequential processors,
or any combination of the above.

this plan 9 port is based on the port of native inferno to the
sheevaplug by Salva Peiró (saoret.one@gmail.com) and Mechiel Lukkien
(mechiel@ueber.net).

___

unfinished business:

access to nand or spi flash would be handy for nvram and small
fossils.  flash access isn't well documented.  inferno implements
these software layers: ecc, translation (for wear-levelling and bad
sectors), common flash code and specific drivers for flash chips.

___

# type this once at u-boot, replacing 00504301c49e with your plug's
# mac address; thereafter the plug will pxe boot:
setenv bootdelay 2
setenv bootcmd 'bootp; bootp; tftp 0x1000 /cfg/pxe/00504301c49e; bootp; tftp 0x800000; go 0x800000'
saveenv

# see /cfg/pxe/example-kw


	physical mem map
hex addr	size	what
----
0		512MB	sdram

80000000	512MB	pcie mem	# default
c8010000	2K	cesa sram
d0000000	1MB	internal regs default address at reset
d8000000	128MB	nand flash	# actually 512MB addressed through this
e8000000	128MB	spi serial flash
f0000000	128MB	boot rom	# default
f0000000	16MB	pcie io		# mapped from 0xc0000000 by u-boot

f1000000	1MB 	internal regs as mapped by u-boot
f1000000	64K	dram regs
f1010000	64K	uart, flashes, rtc, gpio, etc.
f1030000	64K	crypto accelerator (cesa)
f1040000	64K	pci-e regs
f1050000	64K	usb otg regs (ehci-like)
f1070000	64K	gbe regs
f1080000	64K	non-ahci sata regs
f1090000	64K	sdio regs

f8000000	128MB	boot device	# default, mapped to 0 by u-boot
f8000000	16MB	spi flash	# mapped by u-boot
f9000000	8MB	nand flash
fb000000	64KB	crypto engine
ff000000	16MB	boot rom	# u-boot

	virtual mem map
hex addr	size	what
----
0		512MB	user process address space

60000000		kzero, mapped to 0
90000000	256MB	pcie mem	# mapped by u-boot
c0000000	64KB	pcie i/o	# mapped by u-boot
...			as per physical map