* Matthijs van Duin [off-list ref] [150125 00:37]:

On 23 January 2015 at 17:47, Tony Lindgren [off-list ref] wrote:

quoted

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.

Well it is in some sense still a copy-paste issue when e.g.
CM_SYSCLK18_CLKSEL refers to the "Audio PLL generated 32 Khz Clock"
when there is none (it means the "Audio PLL A divider" output, which
itself is in fact fed by the rtcdivider).

Sounds like that's a copy paste issue from dm816x to dm814x then :)
See earlier I was assuming copy paste issues from dm814x to dm816x
before you confirmed dm816x was done before dm814x. On the dm816x
I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
to 32KiHz by looking at it with a scope on the clkout pin.
 

Probably the sillyest copy-paste error is section 1.3.2.2.1 on the DSP
interrupt controller, whose list of interrupts is from Freon/Primus
(omap-L13x) which is not even remotely similar to the actual list in
section 1.7.3.  Which reminds me, I also have a centaurus irqs
spreadsheet which may be more convenient than the lists in the PDF and
includes some that were censored from public docs:
https://docs.google.com/spreadsheets/d/1O3IFMdAfLMWVBQ8rzLPexMbi4LDD5ECfpVYGF6HMv_0/view
(note however that I consistently use 0-based indexing, regardless of
the TRM which tends to vary on that)

Heheh that should be also helpful.
 

quoted

quoted

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

With "make a quick inventory" I meant peeking and poking around in the
subsystem using JTAG, which is generally better done without any OS
running on the target :-)  I don't actually have any real motivation
to run linux on the evm816x; we selected the DM814x for our target
(before it became clear support for it had basically dropped like a
brick), though it may still take a bit before I have time to see how
far I can get with booting Linux on it.

Oh OK. Yeah it sounds like you could generate the required dm814x .dts
entries with a few macros from your spreadsheets :) 
 

The inventory of SecSS on Netra yielded exactly the same list of
accelerators and other peripherals as on Centaurus btw. The only
changes seem to be in subsystem control stuff. I was not succesful in
attaching to the secM3 via JTAG though, but this may have been an
issue with the target config since Code Composer was being more
annoying than usual about it.

What are you using to identify the devices? The device revision
register? Or are there actually some populated interconnect data
available with device info that could be used for a real scannable
bus?

Regards,

Tony