harvey/sys/src/9/omap/words

beagleboard rev c3:
cortex-a8 cpu: arm v7-a arch. rev 3, 500MHz, dual-issue
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
DRAM:  256 MB
NAND:  256 MiB
Board revision C
Serial #784200230000000004013f790401d018

igepv2 board:
cortex-a8 cpu: arm v7-a arch. rev 3, 720MHz, dual-issue
OMAP3530-GP ES3.1, CPU-OPP2 L3-165MHz
IGEP v2.x rev. B + LPDDR/ONENAND
DRAM:  512 MB
Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
OneNAND version = 0x0031
Chip support all block unlock
Chip has 2 plane
Scanning device for bad blocks
Bad eraseblock 3134 at 0x187c0000
Bad eraseblock 3135 at 0x187e0000
OneNAND: 512 MB

omap3530 SoC
CORE_CLK runs at 26MHz
see spruf98d from ti.com (/public/doc/ti/omap35x.ref.spruf98d.pdf)

separate i & d tlbs, each 32 entries
	can invalidate i, d or both tlbs by { all, mva, or asid match }

i & d L1 caches, 16K each, 4 ways, 64 sets, 64-byte lines
	i is VIPT, d is PIPT
	no `test and clean D & U all' operations
	no prefetching, no cache maintenance
	can invalidate i, d or both cache but not D & U all
	can invalidate entire i-cache only
	can clean or invalidate by set and way data/unified cache
unified L2 PIPT cache, 256K, 8 ways, 512 sets, 64-byte lines
no hardware cache coherence

l3 interconnect firewalls are all off at boot time, except for a bit of
	secure ram
sram at 0x40200000 size 1MB
l4 interconnect firewalls seem to be sane at boot time

___
The state of the Beagleboard/IGEPv2 (TI OMAP35 SoC, Cortex-A8) port.

Plan 9 runs on the IGEPv2 and Gumstix Overo boards.

On the Beagleboard, Plan 9 is not yet usable but it gets as far as
trying to access the USB ethernet (since the Beagleboard has no
built-in ethernet and must use USB ethernet).

IGEP & Gumstix Ethernet

The smsc9221 ethernet consumes a lot of system time.  The design
decision to use fifos rather than buffer rings and to not incorporate
dma into the ethernet controller is probably responsible.  With only a
single core, running the 9221 consumes a lot of the available CPU
time.  It's probably worth trying to use the system dma controller again.

USB

The ohci and ehci controllers are seen, but no devices yet.

There are four USB errata that need to be looked into for the igepv2
(silicon 3.1) at least.  From the omap3530 errata (rev e):

- 3.1.1.130 only one usb dma channel (rx or tx) can be active
	at one time: use interrupt mode instead
- 3.1.1.144 otg soft reset doesn't work right
- 3.1.1.183 ohci and ehci controllers cannot work concurrently
- §3.1.3 usb limitations: all ports must be configured to identical speeds
	(high vs full/low)

Flash

access to nand flash would be handy for nvram and paqfs or sacfs file
systems.

In the flash, x-loader occupies up to 0x20000, then u-boot from
0x80000 to 0x1e0000, and there's a linux kernel after that (if you
care).  The beagle's flash chip is a micron pop 2Gb nand
mt29f2g16abdhc-et (physical marking jw256), and the igep's is a
samsung onenand.

VFPv3 Floating Point

The Cortex-A8 has VFPv3 floating point, which uses different opcodes
than 5c/5l currently generate.  New 5c or 5l is in the works.

Video

The display subsystem for omap3 (dss) is divided into 3 parts, called lcd,
video and dsi (ignoring the various accelerators).  The system only
supports the lcd via dvi interface so far because it's the only one we
have been able to test.  1280x1024x16 is the default resolution, this
might be changed.  Writing to /dev/dssctl (e.g., echo 1024x768x16
>/dev/dssctl) changes the resolution.  Currently the system does not
use the rfbi since it seems like an unnecessary optimisation at this
point.  Per Odlund wrote the first draft of the video driver for a
Google Summer of Code project.
___

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.
___

There are a few rough edges:

- the clock.c scheduling rate (HZ) is quite approximate.  The OMAP
timers are complex, but one could eventually do better (or just let
timesync compensate).

- User processes are limited to 512MB virtual (mainly by the IGEPv2 Ethernet
being at 0x2c000000), which isn't a problem since Beagleboards only
have 256MB of dram and IGEPv2s have 512MB, and we don't want to swap.

- might use ucalloc.c to allocate uncached scratch space for generated code
in coproc.c.

- the C implementation of cache primitives failed with mmu off; still true?

- unlock, setup: protect module register target APE (PM_RT) per spruf98c §1.6.7

- setup mpp (multi-purpose pins)?

___
	memory map (mostly from omap35x ref)
hex addr	size	what
----
0		16MB	physical address of flash registers, buffers
20000000	16MB	virtual address of flash registers, buffers
2c000000	?	smc 9221 ethernet
38000000	16MB	256MB (beagle) or 512MB (igep) nand flash mapped here

40000000	112K	boot rom, top of user space
40200000	64K	sram

48000000	16MB	L4 core
48002000	8K	system control (scm)
48004000	16K	clock manager
48040000	8K	L4-core config
48050000	4K	graphics
48062000	4K	usb tll
48064000	1K	usb uhh_config
48064400	1K	ohci
48064800	1K	ehci
4806a000	8K	8250 uart0
4806c000	8K	8250 uart1
48086000	4K	gptimer10
48088000	4K	gptimer11
4809c000	8K	mmc/sd goo
480ab000	8K	hs usb otg
480ad000	8K	mmc/sd goo
480b4000	8K	mmc/sd goo
480c7000		device intr controller
48200000	2K	intr ctlr (intc)

48300000	256K	L4-wakeup
48304000	4K	gptimer12
48318000	8K	gptimer1

49000000	1MB	L4 peripherals
49020000	8K	8250 uart2 (with exposed connector for console)
49032000	4K	gptimer2
49034000	4K	gptimer3
⋯
49040000	4K	gptimer9
49050000	8K	gpio2
⋯
49058000	8K	gpio6

50000000	64K	graphics accelerator

68000000	1K	L3 config (rt)
68004000	1K	L3 hs usb host
68004400	1K	L3 hs usb otg
68005400	1K	L3 graphics
68006800	1K	L4-core config
68010000		L3 protection mechanism

6e000000	?	gpmc

80000000	256MB	dram on beagle
		512MB	dram on igep

c0000000	1GB	kernel virtual space, mapped to 80000000

apparently the vector address (0 or 0xffff0000) is virtual,
so we're expected to map it to ram.