And we also need to populate the tables along the lines of 27b7d5f3cc49
(bus: omap_l3_noc: Add AM4372 interconnect error data).
I think intercon data should be in DT rather than some hardcoded table.
Do the below ranges match your JTAG results?
Yup. Based a memory dump I had done earlier,
* Matthijs van Duin matthijsvand...@gmail.com [150318 01:33]:
And we also need to populate the tables along the lines of 27b7d5f3cc49
(bus: omap_l3_noc: Add AM4372 interconnect error data).
I think intercon data should be in DT rather than some hardcoded table.
Yeah so it seems.
Do the
Matthijs van Duin matthijsvand...@gmail.com wrote:
44400500 target 11 vcp
44800100 target 18 vlynq ?
scrap these guesses: I don't think Netra has a vcp module, and I had
only filled in vlynq based on it being the only remaining target NIU.
Once the memory ranges for the targets have been
* Tony Lindgren t...@atomide.com [150202 08:15]:
* Matthijs van Duin matthijsvand...@gmail.com [150131 17:54]:
I just noticed the dm816x.dtsi says:
ocp {
compatible = ti,omap3-l3-smx, simple-bus;
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris
On 2 February 2015 at 18:44, Tony Lindgren t...@atomide.com wrote:
* Matthijs van Duin matthijsvand...@gmail.com [150128 13:46]:
On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote:
I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
to 32KiHz by looking at it
* Matthijs van Duin matthijsvand...@gmail.com [150131 17:54]:
I just noticed the dm816x.dtsi says:
ocp {
compatible = ti,omap3-l3-smx, simple-bus;
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu,
* Matthijs van Duin matthijsvand...@gmail.com [150128 13:46]:
On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote:
See earlier I was assuming copy paste issues from dm814x to dm816x
Ahh, you thought the 816x was 814x-derived... yes I can imagine that
will have led to some
I just noticed the dm816x.dtsi says:
ocp {
compatible = ti,omap3-l3-smx, simple-bus;
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
SonicsMX. (In general everything on the DM81xx seems to be
* Tony Lindgren t...@atomide.com [150123 08:54]:
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
On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote:
See earlier I was assuming copy paste issues from dm814x to dm816x
Ahh, you thought the 816x was 814x-derived... yes I can imagine that
will have led to some confusion.
I'm pretty sure I verified the that the audio_pll_clk1 is
* 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
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
* Matthijs van Duin matthijsvand...@gmail.com [150121 19:20]:
On 19 January 2015 at 18:29, Tony Lindgren t...@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
On 19 January 2015 at 18:29, Tony Lindgren t...@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
* Matthijs van Duin matthijsvand...@gmail.com [150117 14:41]:
On 17 January 2015 at 19:14, Tony Lindgren t...@atomide.com wrote:
Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
bits for MUXMODE instead of just bits [2:0]?
However, the datasheet's table of possible mux modes
* Tony Lindgren t...@atomide.com [150113 15:44]:
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
On 17 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote:
Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
Yes, ditto on dm814x but there things get even more interesting:
It has the same four config bits as am335x but moved them to bits
16-19, while bits 0-7
* Matthijs van Duin matthijsvand...@gmail.com [150117 09:54]:
On 17 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote:
Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
Yes, ditto on dm814x but there things get even more interesting:
It has the same four
On 17 January 2015 at 19:14, Tony Lindgren t...@atomide.com wrote:
Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
bits for MUXMODE instead of just bits [2:0]?
However, the datasheet's table of possible mux modes per pin has as
column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40,
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
20 matches
Mail list logo
