On 19 January 2015 at 18:29, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Hmm I sort of got the idea that dm814x and dm816x were done about > the same time. Are you saying dm814x was actually done after dm816x? Well, it's hard to come up with an alternate explanation of netra's FAPLLs showing up in the terminology of centaurus' clock tree (though the amount of references to them in the TRM decreased over time) without the FAPLLs being there themselves. Of course a radical new design will have much more distance between initial development and public release than a derivative design. An interesting timeline is given by looking at JTAG partcodes, since those obviously have to be assigned somewhere during development, before the first silicon is produced (omap3/4/5 and centauroids listed): b6d6 - omap34xx 1.0 b7ae - omap34xx/35xx 2.x/3.x b81e - netra b852 - omap4430 1.0 b868 - am35xx b891 - omap36xx / dm/am37xx b8f2 - centaurus b942 - omap5430 b944 - subarctic b94e - omap4460 b95c - omap4430 2.x b96b - centaurus eve (dmva3/4 / dm38x) b975 - omap4470 b98c - aegis b990 - vayu b998 - omap5432 (The distance between the two omap543x variants suggests to me the ID is assigned early in the development, with the 5432-variant added late in the design, but that's just a guess.) > Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that > the registers are different. BTW, if you spot any piece of the documentation making it sound like port 2 is special somehow, it means port 0 instead. (The host port was port 2 in CPSW in some earlier devices, and iirc a reference to this was still somewhere in the current docs) >> There's also an interesting Security Subsystem, which houses the >> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine, >> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit, >> irq routing, and an elaborate L3 firewall instance covering both >> external and internal access. > > Hmm that's a lot of accelerators.. And there are gaps in the memory map suggesting maybe there were more submodules in earlier versions. I know it differs from Netra's security subsystem since one module offset is different... hmm, now I'm curious. I'll see if I can find a moment to brush the dust off the evm816x here and make a quick inventory. The DES module and second AES module in subarctic's memory map (and PRCM) appear to be ghost modules, but I'd suspect this means they are present on Aegis. Makes sense in combo with its magstripe card reader. BTW, someone found genuine documentation of the AES/DES/Hash accelerators: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868 [random thought] There's another interesting application of the SecSS cortex-M3: on GP devices it is (afaict) the only processor with MReqDomain=1, while this is zero for all others. This 3-bit identifier is used for security partitioning, and is something you can test on in all firewalls. It is also the "connID" for EDMA's integrated memory protection and proxied by EDMA transfers. The processor is also located in the ALWON power domain. This puts the secM3 in a unique position to act as "device hypervisor" and prevent processors and DMA engines from meddling with hardware resources they aren't supposed to meddle with. Even if security isn't a concern, this would be a good idea for the same reason memory protection is useful to separate processes. With so many initiators around, if one accidently does a bogus write and clobbers someone else's state, the resulting failure is obviously rather hard to debug. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
