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 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. Stray Interrupts IRQs 56 and 57 are I2C. 83, 86 and 94 are MMC. ___ 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.