Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

[Tony Lindgren <tony@atomide.com>]

* Matthijs van Duin <matthijsvanduin@gmail.com> [150121 19:20]:
> On 19 January 2015 at 18:29, Tony Lindgren <tony@atomide.com> 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.)

That's interesting info thanks :) Yeah it seems dm814x was done after
dm816x and that clears at least some of the clockdomain confusion
that I though was TRM copy-paste issue. 
 
> > 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.

Should be usable for NFSroot with all the patches I've sent using the
ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
Linux next though, I'll push a current testing branch at some point
today. The mainline u-boot was at least missing the davinci_emac
support the last time I tried.
 
> 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

Oh OK. 
 
> [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.

Yeah could be handy :)

Regards,

Tony