* Matthijs van Duin <matthijsvand...@gmail.com> [150125 00:37]: > On 23 January 2015 at 17:47, Tony Lindgren <t...@atomide.com> wrote: > > 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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
