Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL
On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> +- compatible : shall be one of "ti,dm814-adpll-s-clock" or
> + "ti,dm814-adpll-j-clock" depending on the type of the ADPLL
There's still a j -> lj you missed.
Also, since the device series almost always referred to as dm814x, any
reason the x is omitted here? Based on a quick google, dm814 mostly seems
to be a moose hunting area in alaska ;-)
> +- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
The documentation and your later example calls these clkinp and clkinpulow.
In theory adpll-s has a third input (clkinphif).
Calling the input clock "clk-ref" is potentially misleading since the
documentation uses the name "refclk" for clkinp/(N+1). Also, while I'll
admit "clkinpulow" is an awful name, "clk-bypass" is also misleading since
it is merely an optional alternative bypass clock, the default being
clkinp/(N2+1).
Are you aware of any dm814x-sibling that actually uses clkinpulow, or are
you just including it for completeness or consistency with DPLL instances
in other devices like the omap4 or am335x?
> + clock-output-names = "481c5040.adpll.dcoclkldo",
> ...
> + clock-output-names = "481c5080.adpll.clkdcoldo",
I know this inconsistency comes straight out of the TRM, but may I vote for
picking one of them and sticking to it? :-)
> +#define ADPLL_CLKINPHIFSEL_ADPLL_S 19 /* REVISIT: which bit? */
Impossible to say unless a dm814x sibling shows up that actually uses it;
pll_mpu lacks the HIF clocks entirely. Note that it's quite possible bit 19
is indeed officially assigned to it, CLKINPHIFSEL and CLKOUTLDOEN do not
conflict since they apply to different PLL types.
> +static void ti_adpll_set_bypass(struct ti_adpll_data *d)
> +static void ti_adpll_clear_bypass(struct ti_adpll_data *d)
These functions relate to a specific "Idle Bypass" mode of the PLL,
which gates the refclk and sort of freezes the PLL state. Various other
control/status bits become unresponsive in this mode as a result.
I would suggest reflecting this in the name, or at least a comment,
since "bypass" refers to a much more general state. Clearing the IDLE
bit is necessary to take the PLL out of bypass, but other conditions
need to be satisfied as well. Hence, "clear_bypass" does not not
literally do what its name would seem to suggest.
> +static int ti_adpll_wait_lock(struct ti_adpll_data *d)
> ...
> + while (ti_adpll_clock_is_bypass(d)) {
Locked and bypass are not actually mutually exclusive: if you only care
about the DCO clock and not CLKOUT you can clear M2PWDNZ before enabling
the PLL, resulting in status (FREQLOCK | PHASELOCK | BYPASS) after lock.
I don't know if there's any reason to take this obscure configuration
into consideration, but I just wanted to make you aware of it.
> +static int ti_adpll_is_prepared(struct clk_hw *hw)
> ...
> + return (v & ADPLL_STATUS_PREPARED_MASK) == ADPLL_STATUS_PREPARED_MASK;
Yet here you do actually test whether the PLL is locked... why the use a
different condition here than in ti_adpll_wait_lock?
> +static unsigned long ti_adpll_recalc_rate(struct clk_hw *hw,
> ...
> + if (ti_adpll_clock_is_bypass(d))
> + return clk_get_rate(d->clocks[TI_ADPLL_N2].clk);
Bypass refers to clkout. This function calculates the DCO clock, which
is never subject to bypass: if the PLL is off, dcoclk is low.
Although I understand the reasoning behind using abstractions like
readl_relaxed() for I/O access to allow portability to platforms where
I/O is not simply memory-mapped, this concern does not exist for
platform-specific devices like this. There's really no reason in my
humble opinion this code could not simply do
/* read predivider and multiplier, shifted left 18 bits to
* accomodate the fractional multiplier */
spin_lock_irqsave(&d->lock, flags);
divider = (pll->n + 1) << 18;
rate = (pll->m << 18) + pll->frac_m;
spin_unlock_irqrestore(&d->lock, flags);
do_div(rate, divider);
instead of spending a whole paragraph of code on reading each individual
field, which I think just hurts readability.
Note btw that PLLSS is entirely memory-like and is perfectly okay with
16-bit reads/writes. Grouping the u16 n, m2, m, n2; into two 32-bit
registers in the documentation is just TI being silly.
> + frac_m += 1;
que?
> + /* Internal mux, sources from divider N2 or clkinpulow */
> + err = ti_adpll_init_mux(d, TI_ADPLL_ULOW, "ulow",
Shouldn't this just be called "bypass", since it is the bypass clock
after all. I would associate the name "ulow" only with clkinpulow.
Matthijs
--
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
Re: [PATCH 1/3] ARM: OMAP2+: Fix SoC detection for dra62x j5-eco
On 4 December 2015 at 00:11, Tony Lindgren wrote: > We can boot dra62x j5-eco using the dm814x code as the clocks and > devices are mapped in the device tree. The dra62x is also known > as jacinto 5. I'm pretty sure the "eco" in the name isn't optional. As far as I know: jacinto 5 = dra65x ~ dm814x jacinto 5 eco = dra62x ~ dm811x jacinto 5 entry = dra61x/60x ~ am335x Here ~ means equivalence modulo efuse bits. My knowledge of TI's automotive processors is limited however, as is public documentation, so perhaps someone from TI can ack or nak this. Matthijs -- 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
Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask
On 2 December 2015 at 01:46, Tony Lindgren wrote: > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? I'm in general no fan of such macros: it feels really awkward to have to make that distinction in dts when doing pin config. Note that if you're feeling really enthausiastic about putting in effort to allow inputs to be disabled while staying clear of the erratum, I think you can detect at runtime which I/O supplies are 3.3V by inspecting this register: #define CTRL_CQDETECT_STATUS0x48140e00 Matthijs -- 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
Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask
On 2 December 2015 at 01:46, Tony Lindgren wrote: > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? Can't we just keep bit 18 out of the function mask? The bootloader should already have made sure all pins have bit 18 set (and bit 19 set to correct values after ROM mucked them up, see advisory 2.1.88), so all that needs to be done is avoid touching them. Are the power savings from disabling unnecessary inputs significant enough to spend any headache on it? Matthijs -- 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
Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask
On 2 December 2015 at 00:38, Tony Lindgren wrote: > - pinctrl-single,function-mask = > <0x300ff>; > + pinctrl-single,function-mask = > <0x707ff>; Reminder that silicon revision 2.1 and older require input enabled (bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage. (Errata advisory 2.1.87) -- 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
Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx
On 2 December 2015 at 00:38, Tony Lindgren wrote: > Looks like GPIO softreset status bit on both dm8168 and dm8148 > is broken and only goes high initially. After writing to sysc > softreset bit, the resetdone bit never goes high again. The resetdone bit works fine, but it needs all clocks active to come up. You're neglecting to enable the debounce clock to the GPIO module: > # mw.l 0x4818155c 0x2 That should write 0x102 instead. You can disable the debounce clock after resetting the module if you don't need it, though I doubt there's any significant power savings there. (More likely it exists as a separate bit to allow it to stay enabled even if the module isn't, for wakeup on debounced inputs.) Matthijs -- 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
Re: Minimal support for dm814x
On 18 November 2015 at 09:26, Delio Brignoli wrote: >> This works in principle, but both minimizing the DCO and (often >> needlessly) using the fractional multiplier seem like recipes to >> maximize the clock jitter. Mind you, I don't know how much jitter >> we’re talking about here, I don't recall having seen specs about this. > > We haven’t seen any specs either but testing shows that changing DCO mode > causes > the PLL to lose lock at least temporarily. Losing lock on reconfiguration is entirely a separate matter from clock jitter. The fractional multiplier works by essentially by alternating between the nearest integer multiplier values. This will be smoothed out by the loop filter, but it's not going to vanish. To put this in perspective, some docs (I can't immediately find which one) warned that when using the fractional multiplier of DPLLS, its value needed to be at least 100 to ensure max 2.5% jitter. To put this in perspective, if I grab the datasheet of an audio DAC I find: Although the architecture of the PCM4104 is tolerant to phase jitter on the system clock, it is recommended that the user provide a low jitter clock (100 picoseconds or less) for optimal performance. For a typical 24.576 MHz audio system clock that means max 0.25% jitter. Whoops :P Now DPLLLJ will presumably do better, but without actual specs the safe option is to avoid the fractional multiplier altogether. Matthijs -- 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
Re: Minimal support for dm814x
On 13 November 2015 at 15:52, Tony Lindgren wrote: > I think this is the most recent TI git repo for dm81xx changes: > > http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary Yeah, although I usually prefer to look at the linux-ipnc-rdk-dm81xx.git and linux-dvr-rdk-dm81xx.git that descend from it since they include some fixes that the last TI kernel doesn't. (However they may also include patches specific to the ipnc/dvr hardware, so some caution is needed.) Since arago can be sluggish I just mirrored all three branches on github: https://github.com/dutchanddutch/ti81xx-linux I've also fixed an obnoxious commit in the ipnc-rdk which changed all files to mode 755, since this made comparisons rather unpleasant. The PLL code looks pretty mediocre to me. In particular, they make no effort whatsoever to configure an exact ratio. It seems their algorithm uses whatever predivider was already programmed, selects the minimum postdivider that puts the DCO clock within valid range, and then approximates the dco/refclk ratio using the fractional multiplier. This works in principle, but both minimizing the DCO and (often needlessly) using the fractional multiplier seem like recipes to maximize the clock jitter. Mind you, I don't know how much jitter we're talking about here, I don't recall having seen specs about this. I also have some concerns about the correctness of the implementation. I haven't analyzed it in any detail, but repeated occurrences of expressions of the form (unsigned long long)( foo * bar ) make me doubt whether the author realizes this is utterly pointless and will, for 32-bit arguments, still perform a 32-bit multiplication. Matthijs -- 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
Re: Minimal support for dm814x
On 13 November 2015 at 08:14, Matthijs van Duin wrote: > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL Never mind, wasn't paying attention and managed to overlook that google had found me the u-boot tree instead of the kernel tree I intended to search for. -.- Sorry about that, when I find a moment I'll locate the correct files and check those. -- 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
Re: Minimal support for dm814x
On 12 November 2015 at 18:41, Tony Lindgren wrote: > Does the old TI kernel tree driver correctly handle that? It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL -- 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
Re: Minimal support for dm814x
On 11 November 2015 at 18:40, Tony Lindgren wrote: > Well we do first try to set the rate using the divider only at least for > drivers/clk/ti/fapll.c used on dm816x. I'm thinking about doing a similar > driver for the dm814x adpll where we have a PLL and separate output clocks > in a single driver as the PLL and output control registers are all mixed in. Well the output control *is* part of the PLL block. More importantly, due to the constraints of DPLL-LJ you may need to consider the postdivider and PLL config together to produce the desired output frequency. Note BTW that afaik exactly the same two DPLL types are used in nearly all TI SoCs (with exception of DM816x, and some enhancements have been made in the latest SoCs), but since the PLLs themselves only have wires sticking out, the register interface can vary significantly between devices. Most of them also wrap a layer of abstraction around them, while it seems the DM814x just directly wired all available signals into registers, no added sugar. Another difference is that normally nearly all DPLLs are DPLL-S (aka "type A") and often only one is -LJ (aka "type B"), while the situation is reversed on the DM814x which has only one instance of DPLL-S and 12 instances of DPLL-LJ. Also unusual is that none have more than one output divider (no HSDIVIDER blocks present) and only two (HDMI and USB) make direct use of the undivided dco clock. This means that, with those two exceptions, you do have complete freedom in configuring the PLL for the needs of its single output clock. It does however also mean you can't really escape dealing with the fussiness of DPLL-LJ like you can on other devices (e.g. the am335x has only one, which is configured correctly by ROM and can't be reconfigured without breaking USB.) Matthijs -- 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
Re: Minimal support for dm814x
On 10 November 2015 at 11:23, Delio Brignoli wrote: > are you aware of section 2.1.2 of ... I am. It seems that the digital PLLs tend to produce an asymmetrical clock in general hence you need an even postdivider to get a 50% duty cycle. DPLL-S however already has an implicit /2 divider integrated, and a few peripherals seem to be fine with an asymmetrical clock (e.g. apparently the USB subsystem which is clocked by PLL_USB / 5). In the most recent SoCs they included a "DC corrector" in some PLLs to be able to symmetrize the clock without the need for postdivision. -- 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
Re: Minimal support for dm814x
On 9 November 2015 at 16:06, Tony Lindgren wrote: > The PLL support is still missing, so it relies on the bootloader > configured PLL values for now. I'm hoping to post PLL support patches over > next few weeks and then we can have that and more devices working for v4.5. Ah, yes, configuring a DPLL-LJ is fun.. figuring out how to write the desired ratio as M/(M2*(1+N)) while simultaneously satisfying all constraints on M, N, M2, refclk, and dco. :-) -- 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
Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode
On 15 September 2015 at 15:28, Lokesh Vutla wrote: > --- a/drivers/crypto/Kconfig > +++ b/drivers/crypto/Kconfig > @@ -293,6 +293,7 @@ config CRYPTO_DEV_OMAP_AES > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS > select CRYPTO_AES > select CRYPTO_BLKCIPHER > + select CRYPTO_AEAD Is it appropriate that this also selects CRYPTO_AEAD on omap2/omap3, even though they do not support GCM? > +#define AES_REG_CTRL_GCM GENMASK(17, 16) Instead of adding these definitions one bit at a time, can't we get the whole list over with at once? This thing supports: ECB, CBC, and CFB-128 encryption CTR and F8 encryption with 16/32/64/96/128-bit counter XEX (disk encryption) CBC-MAC authentication including the CMAC/OMAC/PMAC subflavors F9 authentication GCM and CCM aead (and raw GHASH, if you happen to have a use for it) -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 22:52, Tony Lindgren wrote: > OK that must be the case I've seen then. Probably that happens > when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and obviously doesn't apply to device memory. Another case where the L3 error irq may be taken first is if the bus error is asynchronous, but I don't think this combo can be produced on a dm81xx or am335x, but that's mainly due to the strictly in-order Cortex-A8 making almost every abort synchronous. I'd expect async aborts are more common on an A9. > Hmm well it should be just MT_DEVICE for anything Linux ioremaps.. Yikes, so both /dev/mem and uio are behaving unlike any device driver: both use remap_pfn_range() after running the vm_page_prot though pgprot_noncached() to set the memory type to L_PTE_MT_UNCACHED, which counterintuitively turns out to mean strongly-ordered. o.O Especially uio is acting inappropriate here imho. But this is problematic... these ranges are already mapped by the kernel, and ARM explicitly forbids mapping the same physical range twice with different memory attributes (and it's not the only architecture to do so). Hmmz... Anyhow, drifting a bit off-topic here. I'm going to some more reading and thinking about this. -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 19:58, Tony Lindgren wrote: > I think these kernels are missing the configuration for l3-noc > driver? Yup. Since I'm pretty sure I have all the necessary info I was hoping look into that... somewhere in my copious spare time... > I tried it on omap4 that has l3-noc configured, and it first produces > "Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd7000", (Though making a patch to fix that annoyingly wrong and useless message is higher on my list of priorities) > and the L3 interrupt only after that. So yeah, you're right, we can't > use the interrupts here. I somehow remembered we'd get only the L3 > interrupt if configured. The bus error is not influenced by L3 error reporting config afaik, and it will always win from the irq: even though the irq is almost certainly asserted first, it can't be taken until the load/store instruction completes, and then the fault will take precedence. While implementing L3 error reporting in my forth system I ran into a tricky scenario though: it turns out that if an irq occurs while the cpu is waiting for instruction fetch, it does allow the irq to be taken. The interrupted fetch is abandoned and any bus error it may have produced is ignored since exception entry/exit is an implicit instruction sync barrier. On return it is simply refetched... Hence, the result from attempting to execute code from an invalid address: fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] ... (repeat until watchdog expires) Anyhow, so we still have the puzzling fact that apparently neither of us was expecting device memory to use a strongly-ordered mapping, getting a bus error on a write (outside MPUSS itself) shows that it does. I've tried to read arch/arm/mm/mmu.c to find out why, but so far I'm feeling hopelessly lost there... (the multitude of ARM architecture versions/flavors supported aren't helping.) -- 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
Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep
On 1 June 2015 at 19:23, Tony Lindgren wrote:
> Ah finally you got around doing a proper patch :)
My First Linux Patch(tm) ;-)
> Also, if this is needed as a fix for the mainline kernel to avoid hardware
> damage, please let me know too ASAP.
The damaging configuration is having &rtc { system-power-controller; }
without &tps { ti,pmic-shutdown-controller; }
So 3d76be5b9 also avoids damage, but with the unfortunate side-effect
that the system doesn't power off at all anymore (it just halts). I do
recommend applying this patch (restyled as needed) before reverting
3d76be5b9.
> Hmm no ideas about that, I guess people are using gmail to send email
> with smtps though?
Hmm, setting up mutt turned out less hassle than I remembered...
(Let's hope all goes well)
> Linux usually does not use the // style comments.. Can you please change
> that? And how about have just one section of comments then the entry
> for ti,pmic-shutdown-controller?
Fresh try...
--- 8< -
Fixes: http://bugs.elinux.org/issues/143
Avoid entering "RTC-only mode" at poweroff. It is unsupported by most
versions of BeagleBone, and risks hardware damage.
Reported-by: Matthijs van Duin
Tested-by: Matthijs van Duin
Signed-off-by: Robert Nelson
Cc: Tony Lindgren
Cc: Felipe Balbi
Cc: Johan Hovold
[Matthijs van Duin: added explanatory comments]
Signed-off-by: Matthijs van Duin
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index c3255e0..c0b0c02 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -223,6 +223,24 @@
/include/ "tps65217.dtsi"
&tps {
+ /* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
+* mode") at poweroff. Most BeagleBone versions do not support RTC-only
+* mode and risk hardware damage if this mode is entered.
+*
+* For details, see linux-omap mailing list May 2015 thread
+* [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
+* In particular, messages:
+* http://www.spinics.net/lists/linux-omap/msg118585.html
+* http://www.spinics.net/lists/linux-omap/msg118615.html
+*
+* You can override this later with
+* &tps { /delete-property/ ti,pmic-shutdown-controller; }
+* if you want to use RTC-only mode and made sure you are not affected
+* by the hardware problems. (Tip: double-check by performing a current
+* measurement after shutdown: it should be less than 1 mA.)
+*/
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = "vdds_dpr";
--
2.1.4
--
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
Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep
Here's a version that attempts to address Tony's earlier request to
include some comments in the patch itself. Since I saw no way to
concisely summarize the issues, I included links to relevant messages
(and enough info to locate the thread again in case of link rot).
Since the patch itself contains more explanation, I made the commit
message more concise.
Apologies for the attachment (inline text would get fucked up by gmail)
From 4278ecc32e886d2e83bc486e6409d8f6df82a0d1 Mon Sep 17 00:00:00 2001
From: Matthijs van Duin
Date: Mon, 1 Jun 2015 06:56:24 +0200
Subject: [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
Fixes: http://bugs.elinux.org/issues/143
Avoid entering "RTC-only mode" at poweroff. It is unsupported by most
versions of BeagleBone, and risks hardware damage.
Reported-by: Matthijs van Duin
Tested-by: Matthijs van Duin
Signed-off-by: Robert Nelson
Cc: Tony Lindgren
Cc: Felipe Balbi
Cc: Johan Hovold
[Matthijs van Duin: added explanatory comments]
Signed-off-by: Matthijs van Duin
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index c3255e0..90fbbb1 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -223,6 +223,24 @@
/include/ "tps65217.dtsi"
&tps {
+ // Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
+ // mode") at poweroff. Most BeagleBone versions do not support RTC-only
+ // mode and risk hardware damage if this mode is entered.
+ //
+ // For details, see linux-omap mailing list May 2015 thread
+ // [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
+ // In particular, messages:
+ // http://www.spinics.net/lists/linux-omap/msg118585.html
+ // http://www.spinics.net/lists/linux-omap/msg118615.html
+ //
+ ti,pmic-shutdown-controller;
+ //
+ // You can override this later with
+ // &tps { /delete-property/ ti,pmic-shutdown-controller; }
+ // if you want to use RTC-only mode and made sure you are not affected
+ // by the hardware problems. (Tip: double-check by performing a current
+ // measurement after shutdown: it should be less than 1 mA.)
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = "vdds_dpr";
--
2.1.4
Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep
Sorry for the late response, I only just noticed this since I wasn't CC'd.
This "fix" was not ever Reported-By or Tested-By me as it claims. It
is in fact wrong: &rtc { system-power-controller; } needs to be
present for every variety of beaglebone (more generally every design
with a TPS65217 whose PWR_EN is connected to the PMIC_POWER_EN pin of
an AM335x).
Without a system-power-controller, the kernel has no way of turning
off the system and shutdown will leave the system halted instead.
The previously posted fix, which added &tps {
ti,pmic-shutdown-controller; } was correct, and ensures that a
poweroff makes the pmic enter "OFF-state" rather than "SLEEP-state"
(aka RTC-only sleep).
Matthijs
--
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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 17:50, Tony Lindgren wrote:
> I believe some TI kernels use strongly-ordered mappings, mainline
> kernel does not. Which kernel version are you using?
Normally I periodically rebuild based on Robert C Nelson's -bone
kernel (but with heavily customized config). I also tried a plain
4.1.0-rc5-bone3, the generic 4.1.0-rc5-armv7-x0 (the most
vanilla-looking kernel I could find in my debian package list), and
for the heck of it also the classic 3.14.43-ti-r66.
In all cases I observed a synchronous bus error (dubiously reported as
"external abort on non-linefetch (0x1818)") on an AM335x with this
trivial test:
int main() {
int fd = open( "/dev/mem", O_RDWR | O_DSYNC );
if( fd < 0 ) return 1;
void *ptr = mmap( NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0x4200 );
if( ptr == MAP_FAILED ) return 1;
*(volatile int *)ptr = 0;
return 0;
}
I even considered for a moment that maybe the AM335x has some "all
writes non-posted" thing enabled (which I think is available as a
switch on OMAP 4/5?). It seemed unlikely, but since most of my
exploration of interconnect behaviour was done on a DM814x, I
double-checked by performing the same write in a baremetal test
program (with that region configured Device-type in the MMU). As
expected, no data abort occurred, so writes most certainly are posted.
So I have trouble coming up with any explanation for this other than
the use of strongly-ordered mappings.
(Curiously BTW, omitting O_DSYNC made no difference.)
--
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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 02:58, Matthijs van Duin wrote: > It is only guaranteed to happen immediately (before the next > instruction is executed) if the error occurs before the posting-point > of the write. However, in that case the error is reported in-band to > the cpu, resulting in a (synchronous) bus error which takes precedence > over the out-of-band error irq (if any is signalled). OK, all this was actually assuming linux uses device-type mappings for device mappings, which was also the impression I got from build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a maze). A quick test however seems to imply otherwise: ~# ./bogus-dev-write Bus error So... linux actually uses strongly-ordered mappings? I really didn't expect that, given the performance implications (especially on a strictly in-order cpu like the Cortex-A8 which will really just sit there picking its nose until the write completes) and I think I recall having seen an OCP barrier being used somewhere in driver code... Well, in that case everything I said is technically still true, except the posting point is the peripheral itself. That also means the interconnect error reporting mechanism is not really useful for probing since you'll get a bus error before any error irq is delivered. So I'd say you're back at having to trap that bus error using the exception handling mechanism, which I still suspect shouldn't be hard to do. Or perhaps you could probe the device using a DMA access and combine that with the interconnect error reporting irq... ;-) -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 00:24, Tony Lindgren wrote: > Hmm I believe the interrupt happens immediately trying to access an > invalid device. But maybe I'm thinking about just errors if a device > is not powered or clocked. It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). Once the write is posted however, the cpu will receive an ack on the write and continue execution, and there's no reason to assume that an error irq will happen *immediately* after the write. Of course it typically will happen soon afterwards, possibly even before the next instruction is executed, depending a bit on how soon after the posting-point the error occurs versus how long it takes for the write-ack to reach the cpu. On the other hand, it's also possible the write, after becoming posted, gets stuck for a while due to a burst of higher-priority traffic. (I also recall reading about some situation where a request needs to wait for something to be dynamically powered up before an error response could be generated, but I think that was on the OMAP 4.) So that's the icky part: it will very likely happen almost immediately. There's however no *guarantee* that it will, and in fact it's quite tricky to absolutely make sure a write is no longer in transit. The usual solution is an "OCP barrier": a read that is known to follow the same path as the write. Normally that means a read from the same peripheral, but that would defeat the purpose in this case. Fortunately, the L4 interconnects (unlike the L3) detect firewall violations in the initiator agent rather than the target agents, hence a read from any peripheral on the same L4 interconnect suffices. -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 28 May 2015 at 18:01, Tony Lindgren wrote: > For failed device access you get an interrupt Well for failed reads you get a bus error, and "catching" those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Matthijs -- 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
Re: ARM errata 430973 on multi platform kernels
On 23 April 2015 at 12:25, Russell King - ARM Linux wrote: > And you can't detect whether you're running in secure mode or not. If not, you get an undefined instruction exception, which you could trap. This may not be convenient, but "can't detect" is an overstatement. Matthijs -- 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
Re: am335x crypto module clocks
On 13 April 2015 at 12:27, Tero Kristo wrote:
> pka/rng/des is using l4ls_gclk.
Does any instance of subarctic actually have a working DES
accelerator? Looking at the L4LS memory map, the only plausible
location for it would be 0x48315000 (sec context) / 0x48316000 (pub
context), but after enabling it manually in PRCM I still get a bus
error on attempt to read the version register (offset 0x30) through
either context.
(Of course it doesn't seem likely that anyone will miss it anyway...)
The PKA does appear to work, but it's missing from the hwmod data and
device tree. Given the TRM's (annoying) usual silence on crypto
modules, I'll summarize the relevant integration info I have:
For device-tree:
pka: pka@48318000 {
reg = <0x48318000 0x4000>;
interrupts = <110>;
};
Relevant wrapper registers:
0x1fe0 revision (highlander format)
0x1ff0 sysconfig
0x1ff4 sysstatus
0x1ff8 irq rawstatus
0x1ffc irq enabled
For sysconfig, looks like bit 0 is autoidle, bit 1 reset, bits 4-5
(oddly) seem to be idlemode, though any mode other than force-idle
(the reset default) behaves like no-idle.
Clkctrl register is at offset 0xa4.
To be honest I don't understand all the hwmod stuff well enough yet to
attempt a patch myself.
--
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
Re: ARM errata 430973 on multi platform kernels
On 10 April 2015 at 00:37, Grazvydas Ignotas wrote: > May I ask how do you perform the smc call? A point worth mentioning is that TI advises that r1-r4 may be clobbered in general, and at least on GP dm814x and am335x devices r4 is in fact clobbered, even though it is normally a callee-save register. Also, on aforementioned devices, the secure-world MMU is enabled, with translation table 0 being 1KB @ 0x402f2000, used for secure VA 0x - 0x0fff (the rest goes via translation table 1 in secure ROM). It is generally not consulted in practice since secrom locks two dTLB and two iTLB entries. The GP secure monitor doesn't actually perform any data access whatsoever, so the two dTLB can and should be unlocked considering that TLB entries are a rather scarce resource (32 per side) and a dTLB miss incurs a 24-cycle minimum penalty (compare with 8-cycle minimum penalty for L1 cache miss). Unlocking the second iTLB entry is also safe, but if both iTLB entries are unlocked, you need to preserve or repopulate the relevant translation entry (VA 0x0030 -> PA 0x) to be able to perform an SMC. Everything that happens in secure monitor mode is heavily double-checked by the SSM, so while you're free to choose a cache policy, any creativity beyond that will piss off the SSM and cause it to hit the "MPU security violation" global reset. Once appropriate fixes to the auxiliary control register have been applied, generally no further SMCs are needed hence all TLB entries can be unlocked. Since it would be reasonable for a bootloader to do this, I recommend checking whether a fix is needed and not unconditionally performing an SMC. -- 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
Re: ARM errata 430973 on multi platform kernels
On 7 April 2015 at 04:23, Tony Lindgren wrote: > Oops, sorry user error.. I was trying to clear IBE as a banked register > like L2 enable bit and of course it did not get cleared.. Clearing it > with a smc call really clears it. And in that case my test case seems to > work reliably on r3p2 without erratum 430973 enabled. So if I understand correctly, you actually had crashes which only occurred with IBE enabled and the 430973 workaround disabled? That's quite interesting, since it seems to me that can only be the result of erratum 687067, which means 1. secrom indeed fails to implement the 687067 workaround. 2. "BTB invalidate by MVA" is used somewhere in the kernel. The 430973 workaround would likely conceal this problem due to regularly flushing the whole BTB, but I'm not sure how wise it is to rely on that... > I'm now thinking the kernel should just always set the 430973 specific > cpu_v7_switch_mm for all cortex-a8 if IBE bit is set. And simply take the performance hit if secrom bogusly sets it and the bootloader doesn't fix it? Sounds reasonable enough to me, given how platform-specific the appropriate auxcr config is, as well as the means by which it can be changed. There's more secrom misconfiguration that the bootloader should fix anyhow to make optimal use of the processor... > This will work as long as we can read the aux ctrl register IBE > bit using mrc, which I believe is the case for all cortex-a8 based > omap variants. Aux control is always readable, only write is an issue. On 7 April 2015 at 05:12, Sebastian Reichel wrote: > If I understood it correctly we can simply call the BTB flush on > cortex-a8 if IBE bit is not set, since it would be translated as > nop. Indeed you can safely use the BTB-flushing context switch on any cortex-a8. There's still value in checking if IBE is set on r2p1 or later, and if so emit a warning about suboptimal performance. > So it should be safe to include the call on all cortex-a8 based > cpus. We may need a non-BTB-flushing function for non-cortex-a8 > based cpus, though. I just looked it up, apparently BTB-flushing on context switch is not needed architecturally in ARMv7 (though it was in ARMv6), so that version should probably indeed only be used for the cortex-a8. Matthijs -- 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
Re: ARM errata 430973 on multi platform kernels
* Ivaylo Dimitrov [150406 10:15]: > Why custom function, if IBE bit is zero, BTB invalidate instruction is a > NOP. Do you think that "mcr p15, 0, r2, c7, c5, 6" executed as a NOP will > put so much overhead, that it deserves a custom function? Executing them as nop is Cortex-A8 specific. On other ARMv7 CPUs, BTB invalidation on context switch may be unnecessary yet expensive. In general I think you'll want a version with and one without BTB flushing, and select depending on CPUID (ID_MMFR1, bits 28-31), with overrides for known processor issues (i.e. the cortex-a8 has a wrong value there in all cases: it reports value 2, while it should be treated as 1 or 4 depending on cpu revision). On 6 April 2015 at 19:42, Tony Lindgren wrote: > Hmm but it still seems to do something also on cortex-a8 r3p2 that > is supposedly not affected by 430973.. Based on my tests so far, at least > armhf running cpuburn-a8 in the background and doing apt-get update > segfaults constantly without flush BTAC/BTB. This seems to be the case > no matter how the aux ctrl reg bits are set.. That sounds really odd. The TRM is fairly explicit about BTB flush executing as nop when IBE is not set. Of course the TRM is not exactly flawless, but still... >> 2. For Cortex-A8 revisions affected by 430973, set IBE bit to 1, set it >>to 0 for all others. Note btw that erratum 687067 affects *all* Cortex-A8 revisions, so there's a bit of a catch-22 there. The proper workaround for it (zeroing some particular debug register) can only be done in secure privileged mode, and there's no straightforward way to check whether this has been done. However, it only affects BTB invalidate by MVA, afaik BTB invalidate all is safe. >> That should happen as soon as possible, >> otherwise kernel may crash on affected revisions if thumb-compiled. The right place to do this to be honest would be in the bootloader, but I guess that's not always convenient to arrange... Matthijs -- 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
Re: ARM errata 430973 on multi platform kernels
Cortex-A8 errata doc states in its workaround for erratum 430973: > By default, the BTB Invalidate instruction is treated as a NOP on Cortex-A8. > However, it is possible to enable the BTB Invalidate instruction such that it > actually does a full invalidate of the BTB by setting the IBE bit (bit 6) in > the CP15 Auxiliary Control Register. As a consequence of erratum 687067, the > L1 System Array Debug Register should be cleared to 0 before the IBE bit is > set using the following code sequence: > MOV r1, #0 > MCR p15, 0, r1, c15, c1, 0; write instruction data 0 register > MRC p15, 0, R1, c1, c0, 1 ; read Aux Ctl Register > ORR R1, R1 #(1 << 6) ; set IBE to 1 > MCR p15, 0, R1, c1, c0, 1 ; write Aux Ctl Register > The above code needs to be executed in Secure state. ARM Limited recommends > that this code is added to the boot monitor. The 430973 workaround code in proc-v7.S will do absolutely nothing if executed in non-secure state. Ditto for the 458693 workaround, and the 460075 workaround should trigger an undefined instruction exception. Maybe linux is started in secure mode on some targets and this code was written for one of those? I scanned DM814x secure ROM for any (ARM or Thumb) write to Instruction L1 System Array Debug Register 0, but I found none, hence my warning to watch out for erratum 687067. Adding the full set of BTB invalidates while making sure IBE is disabled on sufficiently recent Cortex-A8 revisions would be optimal for the Cortex-A8. But, apparently (based on the description of the ARMv7 CPUID registers) there are also processors which only require BTB invalidates when code is modified, but not when context-switching, so there may be performance considerations there... Matthijs -- 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
Re: ARM errata 430973 on multi platform kernels
On 5 April 2015 at 18:50, Matthijs van Duin wrote: > MRC I mean MCR of course -- 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
Re: ARM errata 430973 on multi platform kernels
On 5 April 2015 at 09:23, Ivaylo Dimitrov wrote: > Though I wonder why SMC is needed to write ACR on non-HS devices. A simple > MRC should suffice, unless I miss something. Public-world access to ACR varies per bit: bit 1 (L2EN) is documented as banked, but at least on r3p2 turns out to be common r/w. bits 30-31 are secure read-only and public RAZ. remaining bits are secure read/write and public read-only. The net effect is that doing an MRC from public world will only modify the L2EN bit. There's no bit in the non-secure access control register to affect all of this, so GP vs HS doesn't matter here (from a CPU point of view; it may matter for the availability of SM calls obviously). Matthijs -- 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
am335x crypto module clocks
Hi all, To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently lists the functional clock of the AES accelerator and other crypto modules to be the (max 26 MHz) main osc. This struck me as rather unlikely, since the AES module is clocked much higher on other devices, and such a slow clock would condemn it to being slower than a software AES implementation. As usual the TRM is silent on the crypto accelerators and their clock management, but I did some preliminary tests. The AES module turned out far from slow. I actually had a lot of trouble keeping the module continuously fed with data with a simple non-dma test from userspace, since for most modes of operation the AES module could even keep pace with a tight loop using 128-bit neon load/store without even checking its status register for readiness. Although I haven't been able to get obtain a very reliable measurement yet as a result, it appears to be clocked at ~200 MHz. This also matches the fact that it is hooked up to the L3F (which would be rather pointless if it had a separate low-rate fck). It seems very likely to me the other crypto modules will also have a unified fck/ick (L3F for the hash accelerator, L4LS for the RNG and PKA). This should preferably still be double-checked of course. Matthijs -- 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
Re: ARM errata 430973 on multi platform kernels
On 4 April 2015 at 00:52, Tony Lindgren wrote: > Right, it affects n900 for sure. My point is that it also seems to > affect 37xx versions not listed to suffer from this issue. They shouldn't... erratum 430973 only affected Cortex-A8 r1, and the dm37xx should have an r3p2 right? A word of caution though: at least on the DM814x and AM335x, secure ROM sets bit 6 (IBE) in the Auxiliary Control Register, thereby enabling BTB invalidate instructions (which normally execute as nops). This is presumably a leftover of the erratum 430973 workaround, but it means there is a risk of running afoul of erratum 687067 if BTB invalidate by MVA instructions are actually used. I would actually suggest clearing IBE if it set on Cortex-A8 r2 or later processors and a secure monitor call is available to do so (there is on the DM814x and AM335x, dunno about the 37xx), also for performance reasons: BTB invalidates are quite expensive instructions (when enabled). Matthijs -- 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
Re: patch "phy: Add a driver for dm816x USB PHY" added to linux-phy tree
On 26 March 2015 at 00:36, Kishon Vijay Abraham I wrote: > Let me know if you find any problems with this patch. I spotted a minor issue in drivers/phy/Kconfig: > + Enable this for dm81xx USB to work. This should say dm816x instead. Matthijs -- 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
Re: [PATCH] phy: Add a driver for dm816x USB PHY
On 17 March 2015 at 03:19, Tony Lindgren wrote: > Yes so it seem here too, this is dm816x rev c, what do you have? jtag ID reads 0x1b81e02f, so that would be rev 1.1 / rev A. > Anyways, I'll add a note that at least rev c does not seems to do > anything with USB_CTRL but that we follow what the TI tree is doing > in case some other revisions of the hardware use it. Another idea would be to check if it's nonzero and if so, yell loudly in the kernel log that they should mail the linux-omap list ;-) Matthijs -- 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
> Matthijs van Duin 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 determined they should be easy to identify conclusively. On 18 March 2015 at 17:54, Tony Lindgren wrote: > Oh there's a gap here and it goes all the way to 2400.. Is there > a gap on am335x too? There are indeed. See my work-in-progress spreadsheet on its L3 interconnect: http://goo.gl/miyCQw As with the memory map, there are some "ghost" modules which I'm reasonably sure don't exist, even though they have a target NIU and clkctrl registers. I haven't yet checked which initiator the sole bandwidth regulator on subarctic is attached to. Plausible options are SGX, the LCD controller, or one of the EDMA TCs. I also just noticed how *big* its statistics collectors are. o.O For comparison, the ones on netra and centaurus are 0x200 (statcoll 0 and 3) or 0x400 (statcoll 1 and 2). >> 2. Disable all L3 Target NIUs. You will temporarily lose access to all >> peripherals, OCMC ram, and on subarctic also DDR memory (I think on >> devices with a DMM you'd retain access to DDR memory). Note that the >> service network itself isn't considered an L3 target. > > Hmm well we could that in the kernel using the SRAM code as long as > it does not reset the devices. If you run with MMU disabled then you'd have to run out of the 64K internal SRAM, and catch data aborts since all writes will be non-posted. With MMU enabled, locking code and MMU translation tables into the (much larger) L2 cache makes more sense. I *think* disabling the NIU only blocks access to the module and doesn't affect the module operationally. I'd be inclined to put external RAM into self-refresh during the procedure just to be sure, in case disabling NIUs results in clock gating (which would otherwise be hard to notice). > OK the driver would have to be enabled with interrupts while scanning. Polling makes more sense, especially since nothing else can be going on at the same time anyway. I still think a separate tool that scrapes as much data as possible from the target and pours it into DT form makes more sense than doing it in a kernel driver, especially since discovered targets may often still need manual identification. Also, probing discovered targets requires you enable the clock(s) they need and if necessary release local reset. Auto-discovery of these associations may also be possible, but probably would become a rather lenghy procedure. A separate tool can also leave a record of what it's doing in SRAM and enable the watchdog to be able to recover from probes that lock up the system (and log a warning about them). Also, on HS devices, it would surprise me if you're allowed to access any interconnect registers at all. Matthijs -- 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
> 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, combined with the high
degree of similarity with centaurus and filling in the remaining
blanks with my best guess yields:
4400 host L3F
44000100 target 01 dmm port 0
44000200 target 02 dmm port 1
44000300 target 03 iva 0 sl2 ?
44000400 target 04 iva 1 sl2 ?
44000500 target 05 dsp sdma
44000600 target 06 expansion port
44000700 target 07 edma tc 0
44000800 target 08 edma tc 1
44000900 target 09 edma tc 2
44000a00 target 0a edma tc 3
44000b00 target 0b edma cc
44000c00 target 23 system mmu
44000d00 target 25 iva 2 sl2 ?
44000e00 flagmux l3f
44000f00 flagmux top
44001000 statcoll
44001400 statcoll
44001800 statcoll
44001c00 bw-regulator
44001d00 bw-regulator
44001e00 bw-regulator
44001f00 bw-regulator
44002000 bw-regulator
44002100 bw-regulator
44002200 bw-regulator
44002300 bw-regulator
44002400 bw-regulator
4440 host L3M
44400100 target 0d ducati
44400200 target 0e sgx
44400300 target 0f pcie
44400400 target 10 ocmc ram
44400500 target 11 vcp
44400600 target 12 iva config
44400700 target 13 iss
44400800 target 14 tppss
44400900 target 15 l4hs port 0
44400a00 target 16 secss
44400b00 target 24 l4hs port 1
44400c00 target 26 mmc 2
44400d00 target 1f l3_instr
44400e00 flagmux L3M
44401000 statcoll
4480 host L3S
44800100 target 18 vlynq ?
44800200 target 19 mcbsp
44800300 target 1a hdmi
44800400 target 1b l4fw
44800500 target 1c l4ls port 0
44800600 target 1d l4ls port 1
44800700 target 1e gpmc
44800800 target 20 mcasp 0
44800900 target 21 mcasp 1
44800a00 target 22 mcasp 2
44800b00 target 27 usb
44800c00 flagmux L3S
Note BTW that centaurus (in contrast with netra and subarctic)
actually has a pretty good interconnect chapter with full register
maps (except for the L3 firewals).
> That got me wondering if we can actually scan that data based
> on the ranges below as target is 00130001 and flagmux 00370001.
> We would be missing the names, but that would be still less data
> to pile up in the kernel :) If some module is disabled, then it
> should never produce errors so it seems safe to scan the data..
Note that reading invalid addresses while scanning does yield bus
errors you'd need to trap. There can be gaps, and some modules can be
larger than 0x100 (e.g. statcoll is variable in size), but other than
that it's just a matter of reading words in increments of 0x100 and
match with one of the known types:
// 13'0001 target
// 1a'0001 host
// 2c'0001 bw_limiter
// 2d'0001 rate_adapter
// 31'0001 bw_regulator
// 37'0001 flagmux
// 38'0001 pwr_discon
// 3a'0001 statcoll
The statcoll content should read as zeros after reset, so no risk in
accidently detecting a module inside it.
> Can we dig even more info?
Much can be auto-detected indeed, although it may be preferred to use
auto-detection to generate the data, assign missing names, and then
have other users use that data file.
If you know where the FlexNOC L3 intercon registers themselves are
located (called the "service network" in Vayu), then you can scan the
L3 with the following steps:
1. Detect all FlexNOC components as mentioned above. The components we
care about for now are Target NIUs and Flagmuxes, and optionally the
Host to decode errors while scanning the service network itself. In
this step you learn the association Target NIU regbase <-> Target NIU
ID since this is indicated in one of the regs. Make sure error
logging is enabled for all targets.
2. Disable all L3 Target NIUs. You will temporarily lose access to all
peripherals, OCMC ram, and on subarctic also DDR memory (I think on
devices with a DMM you'd retain access to DDR memory). Note that the
service network itself isn't considered an L3 target.
3. Probe the whole address space with reads or writes, while trapping
data aborts (or use posted writes, those won't generate a data abort
but only signal the L3 error irq). The smallest L3 ranges I've seen
so far were 64 KB, so scanning the whole address space would require
2^16 accesses. Shouldn't take too long. Ranges which are not routed to
L3 targets (e.g. the service networks themselves, or MPUSS-local
peripherals) should be manually excluded.
4. For each access, examine the Flagmux modules and Target NIU error
logs. (Then clear the error log for the next access) You should now
learn:
a. which target was reached at that address
b. to which target-local address it was mapped
c. which bit of which flagmux is used for errors from this target
d. to which bit of the top flagmux this flagmux connects
Note that usually a Target NIU will have its regs in the service
network of the L3 it belongs to, and report errors to the associated
Flagmux. Centauru
Re: [PATCH] phy: Add a driver for dm816x USB PHY
*gets increasingly confused* The datasheet (sprs614e) only contains register addresses, and they seem to match the TRM's USB chapter. The only disagreement I can spot is related to USB_CTRL register(s) in the control module (offsets 0x620 and 0x628) where * the TRM claims both exist in the control module chapter (1.16.1.3), one for each both * the TRM's USB chapter claims only one exists, and its layout (24.9.8.2) doesn't resemble the former one * the datasheet agrees only one exists (but gives no layout) * reality seems to disagree with both: I booted up our evm816x, plugged in a mouse to confirm USB is functional, and attached JTAG: both registers read as zero (contradicting both layouts) and appear to ignore writes. There doesn't seem to be any disagreement in the docs about the USBPHY_CTRL regs (offsets 0x624 and 0x62c in control module) as far as I can tell, and the documented reset values also match what I see via JTAG. > But dm814x [..] seems to be wired up like am335x. This I mentioned: the only difference is related to GPIO mode (which on the dm814x yields exactly that: GPIO, while the am335x uses it to hook up UARTs). > Yes I checked am3517 trm, and that too mentions Synopsys once Only in its ECHI/OCHI host controller, not the OTG one... Anyhow, I didn't expect this small observation to end up becoming a device archeology expedition, sorry about that ;-) >> BTW, da850? Is that yet another instance of Primus? (i.e. >> omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) > > Yes it's the arm926 based series, l-138 is da850 I believe. Ah, but there are two such series: Freon and Primus. Just to be different, their part numbers are both allocated from the omap-L1xx (arm+dsp) / tms320c674x (dsp only) / am1xxx (arm only) ranges, but distinguished by Freon having even final digit while Primus has odd final digit. Of course this doesn't hold for the da8xx parts, that would be too consistent. But you're right, da850 indeed seems to be a Freon rather than a Primus based on some more googling (apparently da850 has SATA -- Primus doesn't). Matthijs On 16 March 2015 at 17:49, Tony Lindgren wrote: > * Matthijs van Duin [150314 14:04]: >> On 13 March 2015 at 20:30, Tony Lindgren wrote: >> > Hmm OK have to check that. It could also be that dm816x documentation >> > is copy-paste from da850 or am3517 and the PHY got changed in the >> > hardware as the registers don't match the documentation. Only the >> > dm816x errata has right documentation for the USB PHY. >> >> Hmm? While I see plenty of usb errata (mostly DMA bugs), I don't see >> anything about registers being different. > > Sorry it seems to be the partially updated TRM instead, it's the > sprs614e.pdf instead. That has the USBPHY_CTRL registers right. > No mention of Synopsys in sprs614e.pdf though so who knows. It > seems something got swapped compared to the TRM as the USB_CTRL > registers totally changed. > > I'll just add a comments you mentioned earlier about it probably > being Synopsys phy. > >> I do see something curious: advisory 70, the only PHY-related erratum >> I see, is also present in the DM814x errata and even in AM335x r1.0. >> This strongly suggests the PHYs must at least be closely related... > > Hmm interesting. But dm814x has again different USB_CTRL registers, > seems to be wired up like am335x. Also there's no USBPHY_CTRL > registers on dm814x or am335x. Chances are that dm814x is wired up > the same way as am335x. > >> The dm816x TRM makes three separate mentions of the synopsys usb phy >> though, while I found no other TRMs that mention it, so if it's a >> copy-paste error (which certainly would not be exceptional) I don't >> know where from. > > Yes I checked am3517 trm, and that too mentions Synopsys once, but > has different registers. And also checked the l-138/da850 TRM, and > that does not have USB_CTRL and USBPHY_CTRL registers either.. Looks > like the copy paste errors come from tms320dm6446.pdf that has > the USB_CTRL and USBPHY_CTRL registers, but then no mention of > Synopsys. > >> I suppose it's still possible TI acquired a sufficiently permissive >> license for the synopsys phy to fork it and call it a "TI PHY" as they >> do in the AM335x docs. (No mention of its origin is made in the DM814x >> docs.) >> >> BTW, da850? Is that yet another instance of Primus? (i.e. >> omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) > > Yes it's the arm926 based series, l-138 is da850 I believe. > > 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
Re: [PATCH] phy: Add a driver for dm816x USB PHY
On 13 March 2015 at 20:30, Tony Lindgren wrote: > Hmm OK have to check that. It could also be that dm816x documentation > is copy-paste from da850 or am3517 and the PHY got changed in the > hardware as the registers don't match the documentation. Only the > dm816x errata has right documentation for the USB PHY. Hmm? While I see plenty of usb errata (mostly DMA bugs), I don't see anything about registers being different. I do see something curious: advisory 70, the only PHY-related erratum I see, is also present in the DM814x errata and even in AM335x r1.0. This strongly suggests the PHYs must at least be closely related... The dm816x TRM makes three separate mentions of the synopsys usb phy though, while I found no other TRMs that mention it, so if it's a copy-paste error (which certainly would not be exceptional) I don't know where from. I suppose it's still possible TI acquired a sufficiently permissive license for the synopsys phy to fork it and call it a "TI PHY" as they do in the AM335x docs. (No mention of its origin is made in the DM814x docs.) BTW, da850? Is that yet another instance of Primus? (i.e. omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) Matthijs -- 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
Re: [PATCH] phy: Add a driver for dm816x USB PHY
Given that the documentation mentions the actual phy used, it may be worth mentioning this also in the driver? i.e. that it's not a "dm816x phy" but a "SR70LX Synopsys USB 2.0 OTG nanoPHY" (in contrast to the dm814x and am335x which use a phy TI made themselves) USB is one of the few subsystems of the DM814x I've never really examined in any detail, but it appears nearly identical to the AM335x. (e.g. the phy registers in the control module are nearly identical, differing only in some bits related to GPIO-mode) On 9 March 2015 at 22:41, Tony Lindgren wrote: > Note that we still are missing basic support for dm814x in mainline, > I'm planning to tackle that at some point but I don't know when I'm > going to get to it.. Do ping me if you have questions. While I still don't have time to really throw myself on the task myself, and I'm still hindered by insufficient knowledge of the kernel, I do have quite a bit of experience with the processor itself. BTW, w.r.t. the old "official" TI kernel for dm81xx: there are actually two relevant forks of the unmaintained arago-omap3/ti81xx-master branch, namely: http://arago-project.org/git/projects/?p=linux-ipnc-rdk-dm81xx.git http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git which contain various bugfixes, including for usb (though also patches specific to those SDKs). -- 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
Re: Enabling DBGEN signal in GP OMAP3
On 1 March 2015 at 01:03, Grazvydas Ignotas wrote:
> On Thu, Feb 26, 2015 at 5:14 AM, Matthijs van Duin wrote:
>> If you want guaranteed reliability, modify tck_pulse() to insert
>> aforementioned barrier + an actual delay at all three points where I
>> put comments about them. usleep(50) or so should do the job.
>
> Adding just the barrier works reliably for me, even at 1GHz.
Yeah I just realized that usleep is a bit larger than I intended... by
a factor 1000. Whoops :) In fact even 50 ns would be excessive but I
wanted to be on the safe side. It doesn't surprise me that sending
(and waiting for) a ping all the way to the L4WK suffices in practice.
>> Ah, if this works then apparently the omap3 control module doesn't
>> check privilege.
>
> Yeah, even OMAP5 doesn't do it for me.
Hmm, based on a quick browse of TRMs, this restriction indeed seems specific to
centaurus, subarctic, and aegis. Curious.
>> If bit 31 isn't set, then these writes should (afaik) be equivalent to
>> just performing them directly through the interconnect instead of
>> using JTAG.
>
> I don't know about that... To enable DBGEN, I just do:
> ap_write( 0x5401d030, 0x2000 );
> and it works. Using 0xd401d030 seems to work too.
That's... unexpected.
Normally on a CoreSight debug APB, bit 31 identifies requests as
coming from the debugger. It would normally set it, but can clear it
to simulate application (= non-debug) access.
An example of this difference is that application code typically needs
to unlock access to a CoreSight debug peripheral before it can write
to them, while debuggers are exempt. This is reflected in the
LOCKSTATUS register:
1fb4: 0003 // lock present and engaged
80001fb4: // no lock present
TI SoCs don't really have a debug APB as such, instead the APB-AP
routing on e.g. centaurus and subarctic is:
if( ( addr & 0x7ff'ff'000 ) == 0x000'40'000 ) {
target = dap_cs_rom;
addr &= 0xfff;
} else {
target = l4emu;
debug = addr >> 31; // OCP MReqDebug signal
addr &= 0x3f'fff;
}
with MReqDebug mapped back to bit 31 for APB targets.
Maybe the omap3 ignores bit 31, or it might be a quirk of DAPCTL to
check the initiator id rather than MReqDebug.
(Note BTW that using the L3 address happens to work in this case
because the higher bits are ignored. It might however cause an
unsuspecting reader to not realize that the APB-AP has a very
different address space and targets outside the L4EMU are not
reachable through it.)
> Thanks again,
You're welcome!
--
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
Re: Enabling DBGEN signal in GP OMAP3
On 26 February 2015 at 02:09, Grazvydas Ignotas wrote: > And hey, it worked too with your code modified to use > USB Blaster in it's bitbang mode over libftdi. This setup also works > with openocd, but somewhat unreliably (only occasionally gets through > init, often gets register values it doesn't like). I've never had much luck with OpenOCD either... it doesn't handle ICEPick very well, nor DAP for that matter: e.g. you can't connect to DAP without also connecting to a processor, and it can't deal with WAIT responses so you need to configure it to worst-case timings (nearly impossible to estimate) or hope AP responses never get delayed due to interconnect congestion or clock speed changes. > Anyway I'm attaching my code too Ah, if this works then apparently the omap3 control module doesn't check privilege. BTW, is this comment in hw-omap3.h true? > 0x23'002100, // assert cortex-a8 DBGEN My impression was that bit 13 of DAP's tap control register either does nothing or at most enables the DAPCTL registers to be written, but that setting bit 13 of the DAP_PC_FER register would still be needed to assert DBGEN. Also, > // address of cortex-a8 debug regs on debug APB > constexpr u32 a8_debug = 0x54011'000; If bit 31 isn't set, then these writes should (afaik) be equivalent to just performing them directly through the interconnect instead of using JTAG. I should maybe have mentioned that without TDO, my example doesn't actually verify debug authentication status. It does perform a test that debug APB writes are working by using the debug communications channel, but I don't think this requires DBGEN to be asserted. -- 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
Re: Enabling DBGEN signal in GP OMAP3
On 26 February 2015 at 02:09, Grazvydas Ignotas wrote:
> I've finally got rid of nTRST pulldown (haven't connected TDO though),
> created hw-omap3.{h,cc}, but couldn't get it to do anything, until it
> came to my mind that you may be running ARM on your BBB slower that
> 1GHz that I'm using on my DM3730. So lowered the clock to 500MHz and
> voila, it worked!
I'm actually running at 1 GHz also, but I must admit I only assumed no
explicit delays would be necessary when bit-banging, I didn't actually
check to see what kind of TCK speed it produced. It's actually
slightly surprising to me that the CPU would end up the bottleneck.
Enabling TDO will also assuredly slow things down incredibly: without
it I'm just doing writes, which are posted (aka buffered / performed
asynchronously), while inserting a read will stall the cpu until it
gets an answer from the peripheral.
Thinking of it... unless the control module and relevant GPIO module
are connected to the same L4 interconnect (which they aren't in my
test case) I should actually perform at least a dummy read (aka "OCP
barrier") from the control module before accessing GPIO since
otherwise it's not even guaranteed that all writes to the control
module have completed. Joy.
If you want guaranteed reliability, modify tck_pulse() to insert
aforementioned barrier + an actual delay at all three points where I
put comments about them. usleep(50) or so should do the job.
> I guess I'll still connect TDO as it's not so much fun without it,
> going to try connecting to EMU0 too, hopefully it doesn't mess up the
> boot modes.
Note that you can use *any* gpio. I just used one of the EMU pins
because the am335x lets you reconfigure those to GPIO and it was
conveniently nearby. Anyhow, even if you do use EMU0 (or EMU1) for
this, TDO is only driven during data transfers and high-Z otherwise,
so you'd need very good aim with your power-on-reset pulse to manage
to get the EMU pin sampled low (assuming the line even has enough
capacitance to avoid being pulled up fast enough).
> My main goal is to have hardware watchpoints on the cased production
> unit without extra hardware, and it looks like I can finally have
> that, thanks!
You're welcome!
> It sure is! The only thing I do not understand is why are you using
> that process_vm_readv() call, mmap() already makes unprivileged user
> mode writable mappings.
Obviously, otherwise process_vm_readv() would give EFAULT also.
The issue here is not the MMU but the control module itself. I don't
know the situation on the omap3, but at least on recent SoCs the
control module checks the request privilege (OCP MReqSupervisor
signal) and ignores all unprivileged writes. In this case that request
flag comes from the AWPROT[0] signal of the AXI bus, which (for
uncacheable writes) is set based on the CPU processor mode with which
the store-instruction is executed.
Matthijs
--
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
Re: Enabling DBGEN signal in GP OMAP3
At least on the am335x, the trick actually works! I have a working
demo which configures ICEPick registers and even performs transactions
on the debug interconnect.
I've been lazy and imported a bunch of files from my baremetal
projects so I could easily mess with the hardware, rudely bypassing
the kernel. The whole implementation is hideous in all sorts of ways,
but it gets the job done: https://github.com/dutchanddutch/jbang
The key part, how to bitbang JTAG, is reasonably isolated from all
this in src/jbang.cc and glues onto the device-specific part via
hw-subarctic.h. You could probably also turn jbang.cc into plain C
without too much effort and discard the rest... I accept that my code
style is probably a bit of an acquired taste ;-)
For the omap3, apart from the differences in padconf details, you'll
want to change icepick_init_regs[] to just { 0x23002100 } I think and
hopefully you can then write the DAPCTL regs using ap_write().
I hope this example is of any help.
Matthijs
--
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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 18 February 2015 at 22:14, Pali Rohár wrote: > Can you help us with above problem? How to catch external abort > on non-linefetch in kernel driver and prevent kernel panic? Actually it's a synchronous bus error that you want to catch, which however is misreported by linux as "external abort on non-linefetch" (... but a bus error on a linefetch would produce exactly the same error). Also, ARM apparently uses the term "external abort" as umbrella term for aborts triggered outside the MMU, which includes not just bus errors but also (uncorrectable) parity/ECC errors. Anyhow, the core question you mean to ask is: can the "exception" mechanism current already in place to trap MMU faults in e.g. put_user() easily be extended to allow drivers to trap synchronous bus errors? My impression is that this would in fact be quite easy and I even outlined a suggested patch, but I'm still a kernel newbie so I may be way off course. Although its main use would be for auto-probing, it's maybe worth mentioning I've met at least one peripheral which also reports bus errors when writing inappropriate/unsupported *values* to a register. (Of course when using posted writes you won't get an abort anyhow in that case, it's only reported via interconnect error logs.) On 19 February 2015 at 19:20, Pali Rohár wrote: > Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch In mainline linux the same fix-up is done at runtime rather than compile time (in exceptions_init() at the bottom of fault.c). Either way, in my post of the 11th I also mentioned that it looks wrong to me. I-cache maintenance fault is really a special case in the fault decoding logic since it means "although you got here via DAbort and the relevant address is in DFAR, the exception happened on the instruction side so you need to fetch the fault status from IFSR instead." -- 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
Re: Enabling DBGEN signal in GP OMAP3
On 19 February 2015 at 03:16, Grazvydas Ignotas wrote: > It turns out 050, 054 and 058 (but only them) are actually documented > in dm3730 manual and are part of Emulation Pin Manager. 058 works as > you (and the manual) describe, however claiming and enabling EPM > registers still doesn't enable writing to 030 :( Ah, bummer. > OK thanks for all the info. I've tested a spare floating pin by muxing > it as a GPIO on my dm3730 and it works as you describe, nice. > Hopefully this also applies to jtag pins there. At least on the am335x disabling RXEN of the TMS pin rendered JTAG inoperable, which means it looks like the technique will at least work there. I'm now working on a test to see if it really works. Once done it shouldn't be too hard to adapt to the dm37xx: the padconf registers are different obviously, but the bitbang sequence will be almost the same (just a different ICEPick register), at least if setting debug-enable on DAP's tap control register suffices. If it turns out you really need to write to the DAPCTL registers themselves via JTAG, that will be a bit more work... > Ok, sounds like I need to find and get rid of that 10k resistor, or > connect the pad to 1.8V. It's just a shame that there doesn't seem to > be a way to do it purely in software so that other pandora users could > have hardware watchpoints. You can solder-blob a path from nTRST to Vref via other input pads (which all need to be high, but they should already be pulled up anyway), as long as you avoid GND and the outputs (TDO and RTCK). Though I'm not sure that's a good idea considering it looks like there's a ground plane running between the pads... Anyhow, I'm currently testing just with nTRST connected to Vref, and TDO to some GPIO for monitoring. > If you could share the programming sequence it would be great. Working on it! When you manage to get nTRST (and the other all relevant inputs: TMS, TDI, TCK) high, you can first try simple tests: (all this should be done by via INPUTENABLE of the pads): 1. nTRST low, TMS and TDI high, toggle TCK a bunch of times (at least five rising edges) and end with TCK low. 2. nTRST high, TMS low, and start toggling TCK. If all is well, sooner or later (possible right away), the processor's RTCK output should start following TCK. If this is the case, then you can pretty much start doing the victory-dance ;-) When you stop toggling, make sure you end with TCK low. 3. If you also want to see TDO in action, perform the following sequence: TMS high, one TCK pulse (high-low), TMS low again, and start toggling TCK: after two pulses the processor should start driving TDO and the 32-bit JTAG ID should emerge from it, after which TDO remains high. To exit data mode and return to idle state again, give two TCK pulses with TMS high. TDO will go high-Z again (after the first TCK pulse already in fact). 4. The final pin to test is TDI: repeat step 3, but occasionally change TDI in between clock pulses. JTAG uses shift registers for everything, so after outputting the 32-bit JTAG ID it will actually start repeating the input you provided, but with 32 cycles delay. When you exit data mode, the JTAG ID register will discard the data you provided. -- 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
Re: Enabling DBGEN signal in GP OMAP3
On 18 February 2015 at 15:54, Tony Lindgren wrote:
> From memory.. I believe the issue was that for anything needing to
> set the counter and rely on the counter interrupt things would fail
> as the counter interrupts would not always happen.
Correct, but the interrupt is just used to indicate when counters
overflow, intended to be used to correctly keep track of the counters
when they exceed 2^32 (which can happen easily when measuring across a
timespan of more than a few seconds).
However, no performance counter can increment more than twice per cpu
cycle, which means it takes at least 2^31 cpu cycles to completely
wrap a counter around. If you make sure you update local copies
(untested code below) more often than once per 2^31 cycles they should
therefore keep accurate track.
void update_perf_counters( u64 ctr[4] )
{
for( int i = 0; i < 4; i++ ) {
u32 val;
asm volatile( "mcr p15, 0, %0, c9, c12, 5" :: "r"(i) );
asm volatile( "mrc p15, 0, %0, c9, c13, 2" : "=r"(val) );
ctr[i] += (u32)( val - ctr[i] );
}
}
- Matthijs
--
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
Re: Enabling DBGEN signal in GP OMAP3
On 18 February 2015 at 00:37, Grazvydas Ignotas wrote: > On Mon, Feb 16, 2015 at 8:43 PM, Matthijs van Duin wrote: >> A dump of all non-zero registers in DAPCTL (the 4KB block at >> 0x5401d000) might be interesting. > > Attached OK, nice. I like peripherals which fault accesses to non-existent (or at least non-readable) regs, makes it easier to make an inventory of what's there :-) So, we have some standard ID regs at the end: CID = b1 05 f0 0d -- PrimeCell or system peripheral (i.e. not coresight) PID = 00 00 09 73 43 -- vendor 0x097 (TI), part 0x343, rev 0x00 and indeed no other coresight management regs. The partcode 0x343 might be a reference to the omap3430. Regs at 000 and 010 presumably revision and sysconfig. 030-040 are the core debug control regs... in fact, judging by their values and the fact you mentioned bit 13 controls DBGEN, these regs look very much like the ICEPick-D core debug control regs, which themselves are simplified versions of debug TAP control registers (for which you can find the layout in the dm3730 TRM's debug chapter). 050 and 054 are unknown, but 058 reads 0x2000 which suggests it may have an ownership claim command register there. Try writing 0x4000 to it, if that succeeds and it reads back 0x7000 then you're successfully claimed ownership which hopefully means you can then write to other regs too, although they may not take effect unless you enable the module by writing 0x8000 to the ownership claim command register, after which it should read back 0xb000. Of course it's also possible it only covers registers 050 and 054, whatever they may be... (or it might be something else altogether) If this doesn't work either, then bitbanging JTAG is plan B... >> (As a random note, on the am335x the JTAG pins have pinconf registers, >> in that case it may suffice to externally pull/drive all pins up and >> then toggle the RXEN bit in software, given that even the (warm) reset >> pin responds to such manipulation.) > > DM3730 (equivalent to OMAP3630) that I'm using also has pinconf > registers on all JTAG pins, and there are external pullups on my > board. So I guess you mean performing I/O by quickly > enabling/disabling the pulldowns? Would that satisfy any timing > requirements? I doubt pinmux register access would be fast from the > CPU (OMAP3 is known not to be a good GPIO bitbanger even). > > And what is RXEN bit? I can't find it referenced anywhere (and I'll > admit I don't have experience with hardware debuggers). RXEN == INPUTENABLE At least on the am335x, disabling it causes the processor to perceive the input as being low regardless of its actual level. Since the line itself doesn't have to change level, this can be toggled pretty fast probably. Using this to simulate an input does require the actual line level to be high obviously. Using the pull up/down to toggle an IO can definitely also work, but only if the pin is really floating since the internal pulls are really weak afaik. They're not gonna win from that 10k resistor. And obviously you then need to toggle it slow enough to allow the pull resistor to do its job. JTAG has no lower limit on clock speed, or any other timing constraints other than minimum setup/hold/cycle times, so bitbanging it using slow GPIO is no problem if you don't care about performance but only need to set some debug enable bit. > I could try the bitbang method if you think it can work, although my > board (openpandora) has a 10K pulldown resistor on nTRST that I'm not > sure OMAP's internal pullup would win over. It won't, you'll need to externally drive it up, e.g. by connecting it to the Vref pin that's also on the jtag connector. > Is there any way to check if anything works from the CPU? > Maybe I could modify my board, I could connect some spare GPIO pads to > jtag pads, but I don't know if it's even worth trying. If the ownership claim register doesn't work it may be worth a try, if you're comfortable doing that. Connecting them to GPIOs will definitely work, though just driving the inputs high and toggling INPUTENABLE via padconf *may* also work and be simpler. Pin summary: nTRST - cpu input, must be high for JTAG to work TCK - cpu input, clock, idle low TMS - cpu input, command, captured on rising TCK edge TDI - cpu input, data, captured on rising TCK edge during data xfer TDO - cpu output, useful to capture so you're not working blind RTCK - cpu output, optional to capture: it should follow TCK if all is well It's essentially SPI mode 0, but with two MOSI signals (TMS and TDI) and one MISO (TDO). RTCK is an acknowledge of TCK, and mostly relevant when connecting to older (pre-Cortex) ARM cores since they resynchronize TCK to their core clock (so if their clock can change, e.g. due to pow
Re: Enabling DBGEN signal in GP OMAP3
On 15 February 2015 at 22:30, Grazvydas Ignotas wrote: > "The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at > address 0x5401 D030 in the DAP-APB address space." The register is apparently, for some reason, called DAP_PC_FER according to some notes of mine (I have no idea anymore where I got these from) listing a few DAPCTL registers: // dap_pc_fer APB 0xd401d030 ;DAP_PC for Cortex-A8 // dap_pc_ime APB 0xd401d034 ;DAP_PC for IME // dap_pc_ilf APB 0xd401d038 ;DAP_PC for ILF // dap_pc_vlc APB 0xd401d03c ;DAP_PC for VLC // dap_pc_core APB 0xd401d040 ;DAP_PC for Core > However regardless of how hard I try the writes to that register seem > to be ignored. Just checking... it's possible of course that DAPCTL tries to be coresight-compatible and has a lock_access register at 0x5401dfb0 to which you need to write 0xc5acces5. To be safe you can first check whether 0x5401dfb4 (lock_status) reads 3 before doing so (and it should then become 1). Debuggers generally don't need to worry about it since access via APB-AP (with bit 31 / MReqDebug set) bypasses such locks. A dump of all non-zero registers in DAPCTL (the 4KB block at 0x5401d000) might be interesting. > It seems others had this problem too, and TI is as helpful as ever: > http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/30011/104527 (The reply post is weird though, since you don't need DBGEN for performance counters, but I'm not gonna bump a thread from 2009) > 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's > writeable over jtag, but not by the CPU(s). If a write is done to that address as-is (via either AHB-AP or APB-AP), rather than an APB-AP write with bit 31 set, then I think you should be able to write it from the processor too. If so, it means access is unlocked by some previous step such as my main worry, bit 13 (DEBUGENABLE) of ICEPick debug tap 3 control. You can try writing it from the cortex-a8 while a debugger is connected (if using CCS you can connect to DAP without connecting to the Cortex-A8, in which case it shouldn't get confused if you mess with DBGEN. OpenOCD doesn't support this afaik so it'll probably get confused... well so be it) If you have an FTDI-based debugger (preferably an XDS100v2) I can provide a little test tool to directly manipulate ICEPick registers to futher test this theory. (Alternatively, driving nTRST high and bit-banging TMS and TDI can do the job too, the sequence isn't very long I think) > It's quite a mysterious otherwise undocumented register Debug and crypto are two areas where the (otherwise usually quite good) public documentation of TI SoCs is unfortunately sorely lacking. This is a shame, since both are useful in nearly all application domains. My guess is that these two subjects are secretive since info about them (shouldn't but) might help people copy netflix films off their smartphone or whatever. Perhaps now that omapgeddon has come to pass they might open up on these topics, but that may just be wishful thinking. Fortunately info about these subsystems leaks out of TI all over the place, but scraping bits and pieces from many sources together and filling in the blanks with empirical science takes more time than one ought to have to spend on it. On 16 February 2015 at 18:58, Tony Lindgren wrote: > The perf counter on omap3 used to work, but is buggy at least on > 3430 because it eventually stops producing interrupts because of > some bug in the Cortex-A8 version being used. Of course the workaround of polling the counters at least once per 2^31 clock cycles to detect when they wrap (or in general keep local 64-bit copies up-to-date) is not really a huge burden. >> 0x5401D030 is referenced by some OpenOCD scripts, so I guess it's >> writeable over jtag, but not by the CPU(s). It's quite a mysterious >> otherwise undocumented register, I've noticed it's bit21 is some >> status bit related to Cortex-A8's low power states. > > Have you checked the Cortex-A8 documentation for the debugger? > It seems that's where they should be documented. DAPCTL is a TI-specific debug peripheral, it's not from ARM or related to the Cortex-A8 specifically. -- 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
Re: Enabling DBGEN signal in GP OMAP3
I don't have an OMAP3 to play with, but I wouldn't be surprised if a debug-enable bit also needs to be set in an ICEPick control register. On omap4-generation targets with ICEPick-D (e.g. dm81xx and am335x) the DBGEN signal is in fact fully controlled via ICEPick. This really sucks since without it you can't use debug monitor functionality such as hardware breakpoints and watchpoints, or have an aux core (e.g. a cortex-m3) perform halting debug on the main core. I've actually considered asking for a hardware patch on our board to allow it to self-jtag via gpio just to enable that stupid bit (basically everything else is memory-mapped). (As a random note, on the am335x the JTAG pins have pinconf registers, in that case it may suffice to externally pull/drive all pins up and then toggle the RXEN bit in software, given that even the (warm) reset pin responds to such manipulation.) -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 11 February 2015 at 13:39, Pali Rohár wrote: >> Anyhow, since checking the firewalls/APs to see if you have >> permission will probably only get you yet another fault if >> things are walled off, the robust way of dealing with this >> sort of situation is by probing the device with a read while >> trapping bus faults. This also handles modules that are >> unreachable for other reasons, e.g. being disabled by eFuse. > > It is possible to patch kernel code to mask or ignore that fault? > Can you help me with something like that? As I mentioned, I'm still learning my way around the kernel, so I don't feel very comfortable suggesting a concrete patch just yet. I've been browsing arch/arm/mm/ however and my impression is that all that would be required is editing fault.c by making a copy of do_bad but containing return user_mode(regs) || !fixup_exception(regs); and hook it onto the appropriate fault codes. However, this really needs the opinion of someone more familiar with this code. I do have an observation to make on the issue of fault decoding: the list in fsr-2level.c may be "standard ARMv3 and ARMv4 aborts" but they are quite wrong for ARMv7 which has: [ 0] - [ 1] alignment fault [ 2] debug event [ 3] section access flag fault [ 4] instruction cache maintainance fault (reported via data abort) [ 5] section translation fault [ 6] page access flag fault [ 7] page translation fault [ 8] bus error on access [ 9] section domain fault [10] - [11] page domain fault [12] bus error on section table walk [13] section permission fault [14] bus error on page table walk [15] page permission fault [16] (TLB conflict abort) [17] - [18] - [19] - [20] (lockdown abort) [21] - [22] async bus error (reported via data abort) [23] - [24] async parity/ECC error (reported via data abort) [25] parity/ECC error on access [26] (coprocessor abort) [27] - [28] parity/ECC error on section table walk [29] - [30] parity/ECC error on page table walk [31] - Some entries are patched up near the bottom of fault.c but many bogus messages remain, for example the "on linefetch" vs "on non-linefetch" is misleading since no such thing can be inferred from the fault status on v7. Also, the i-cache maintenance fault handling looks wrong to me: it should fetch the actual fault status from IFSR (even though the address still comes from DFSR) and dispatch based on that. Async external aborts (async bus error and async parity/ECC error) give you basically no info. DFAR will contain garbage hence displaying it will confuse rather than enlighten, a traceback is pointless since the instruction that caused the access is long retired, likewise user_mode() doesn't matter since a transition to kernel space may have happened after the access that cause the abort. Basically they should be treated more as an IRQ than as a fault (note they can also be masked just like irqs). In case of a bus error, it may be appropriate to just warn about it, or perhaps send a signal to the current process, although in the latter case it should have some means to distinguish it from a synchronous bus error. At least on the cortex-a8, a parity/ECC error (whether async or not) is to be regarded as absolutely fatal. Quoth the TRM: "No recovery is possible. The abort handler must disable the caches, communicate the fail directly with the external system, request a reboot." Bit 10 no longer indicates an asynchronous (let alone imprecise) fault. Apart from the debug events and async aborts (and possibly some implementation-defined aborts), all aborts listed are synchronous, and DFAR/IFAR is valid. There's no technical obstruction to make these trappable via the kernel exception handling mechanism. (Though at least in case of parity/ECC errors one shouldn't.) -- 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 2 February 2015 at 18:44, Tony Lindgren wrote:
> * Matthijs van Duin [150128 13:46]:
>> On 26 January 2015 at 16:58, Tony Lindgren wrote:
>> > 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.
>>
>> Yeah it comes straight from the "rtcdivider" so it'll produce
>> 0.0016384 * devosc.
>
> Not much about "rtcdivider" in the dm816x TRM..
> [..]
> That seems to be in the dm814x TRM. OK so it looks like in
> mainline kernel drivers/clk/ti/fapll.c we can then fix the hardcoded
> value in ti_fapll_synth_recalc_rate() to return the rate of fd->clk_ref
> multiplied 0.0016384 instead of 32768.
Ah sorry, yes, for some reason I thought you meant the dm814x one...
(which makes no sense in retrospect)
It seems however the situation is actually similar on the dm816x since
the diagram of the audio FAPLL also shows clock 1 deriving directly
from devosc, and the associated audio frequency/divider 1 registers
read as zero. Presumably it was produced by the audio PLL in some
early design but replaced by a fixed synthesizer later on, later named
"rtcdivider" in the dm814x. Note that the multiplier 0.0016384 = 32768
/ 20e6 is for the dm814x, it'll be 32768 / 27e6 on the dm816x.
I think "audio 1" should be kept out of the fapll code entirely given
that it doesn't seem to be related to the audio FAPLL anymore in any
way other than in name.
I've also been looking at the rest of Netra's 32KiHz clock tree, but
the TRM is a real mess there, often contradicting both itself and the
TI kernel. As far as I can tell they agree on:
audio_1 = devosc * (32768 / 27e6);
audio_a = audio_1 / (CM_DPLL_APA_CLKSEL + 1);
rtc_fck = { clkin32, audio_a }[CM_DPLL_SYSCLK18_CLKSEL];
but the TRM seems to suggest the mux output is the "sec_clk32k"
specifically for the RTC while the signal I called "audio_a" here is
sysclk18 provided for debouncing and as timer option. In contrast the
TI kernel considers the mux the only user of audio_a and its output
sysclk18. It does also define a secure 32k but without parent or any
apparent users.
(The audio FAPLL description (1.10.3.1.4) also claims mux option 0
selects the synthesized 32k clock, but that contradicts all other
evidence so I will ignore that.)
I'm leaning more towards believing the TI kernel since on Centaurus
(all flavors) sysclk18 definitely comes from the mux. It adds a twist
however: PRCM's clkin32 doesn't come straight from the pin but PLLSS
inserts another mux which by default *also* feeds it the synthesized
32k:
rtcdivider = devosc * (32768 / 20e6); // former audio 1
prcm_clkin32 = { rtcdivider, clkin32 }[PLLSS_SYSCLK18_CLKSRC];
sysclk18_a = rtcdivider / (CM_DPLL_RTCDIVA_CLKSEL + 1);
sysclk18 = { prcm_clkin32, sysclk18_a }[CM_DPLL_SYSCLK18_CLKSEL];
I confirmed the above on our board where clkin32 is not connected, so
I could "manually" toggle it using the internal pull up/down. This
also revealed that mux in PLLSS, unlike the PRCM one, is not
glitch-free but takes immediate effect. It also revealed the TRM's
statement that "If newly selected clock is idle, a switchover never
occurs (previously selected clock continues to pass through the mux)"
is false. Switching sysclk18 to the idle clkin32 stopped timers fed by
it (including the "synctimer32k") and switching back also proved
impossible without toggling clkin32 or having PLLSS feed it the
rtcdivider clock. This may be the reason this (otherwise redundant)
mux exists in the first place.
Finally, Centaurus also has an internal ~32kHz RC osc as option for
the watchdog and on the 811x (also known as Jacinto 5 Eco) the clkin32
is upgraded from clock input to oscillator.
--
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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
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
omap4-generation)
--
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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 31 January 2015 at 20:06, Pali Rohár wrote: > Just to note that above error output is from device where is > signed X-Loader which *enable* omap aes support. > > So it looks like it is not possible to dump registers which > should tell you if kernel has permission or not (in L3 firewall). This is hardly surprising on a HS device. If the firewalls are actively being used to enforce access control rather than being left wide open like they are by default on GP devices, the firewalls themselves will *certainly* be firewalled off. (Though they could have opted for granting read-only access to the L3 firewalls for inspection, as I mentioned it's the L4-Core firewall which matters here and these do not even have the option of providing read-only access.) On 31 January 2015 at 20:09, Pali Rohár wrote: > Do you have idea if it is possible to write such check in kernel > if address (aes@480c5000) is readable or not? Most of my experience with TI SoCs so far has actually been baremetal programming, so I have to admit I'm not yet as familiar as I'd like with how things are done in the linux kernel. But if I'm reading arch/arm/mm/fault.c right, kernel level exception handling is currently only invoked for translation faults and not for synchronous external aborts. If that were fixed, then something like a privileged version of __get_user_asm_word (arch/arm/include/asm/uaccess.h) could be used. Hmm, in fact, it appears __get_user actually performs a privileged load unless CONFIG_CPU_USE_DOMAINS is enabled... odd. My intuition is that this shouldn't be very difficult, but invoking fixup_exception for synchronous external aborts in addition to translation faults would be a semantic change with kernel-wide scope, so I don't know if this might be a big no-no for non-obvious reasons. > I have configured two testing N900 devices. One with signed > bootloader which enable omap aes support and one device with > signed bootloader which does not enable omap aes support. I'm probably missing some context here, but why not just use the one with aes support? Alternatively, one may argue that it's the bootloader's job to provide the kernel with an accurate device tree. (Though one may equally well argue that it would be nice to avoid having to customize the device tree for every feature-flavor of a processor, especially if this depends on how it's initialized.) BTW, I noticed they actually do list the A/P regions and default protection groups in the TRMs, including the "secret" ones. It's not presented in a very readable form though, so I've converted the one for L4-Core into yet another addition to my spreadsheet collection: https://docs.google.com/spreadsheets/d/1HhK3bIoaDzJoEGW1zDO5yTRQMdqC8NftWHHUCS5QVmA/view I started filling in the descriptions but then got lazy :P If anyone wants edit permissions just mail me. I already noticed one inconsistency though (it claims 48308800-FFF is valid and 48308000-7FF is not, while the TRM elsewhere claims the opposite) so it would still be better if someone with access to a GP omap34xx/omap35xx dumps the actual tables from hardware to avoid human error. -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 31 January 2015 at 12:34, Pali Rohár wrote: > [ 172.923553] Unhandled fault: external abort on non-linefetch (0x1018) at > 0xb6f87028 > [ 172.930664] In-band Error seen by MPU at address 0 Also, why is this error so uninformative? A synchronous abort should at least mention the _physical_ address, type of access, etc. Anyhow, since checking the firewalls/APs to see if you have permission will probably only get you yet another fault if things are walled off, the robust way of dealing with this sort of situation is by probing the device with a read while trapping bus faults. This also handles modules that are unreachable for other reasons, e.g. being disabled by eFuse. -- 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
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Sunday 08 December 2013 00:22:06 Tony Lindgren wrote: > * Sebastian Reichel [131207 15:04]: > > On Sat, Dec 07, 2013 at 01:11:37PM -0800, Tony Lindgren wrote: > > > > I asked Pali to send me his copy of the updated NOLO > > > > bootloader, so that I can test this. I just checked the > > > > omap documentation (I only have access to the public > > > > one) and crypto related stuff is not documented for the > > > > L3_PM_READ_PERMISSION register. There are a couple of > > > > reserved bits, which may be used for this, though. > > > > > > > > I also CC'd Joel Fernandes, since he worked on the > > > > driver before and may have access to the documentation. > > > > > > Looks like at least the 36xx public version referenced > > > here has them: > > > > > > http://www.spinics.net/lists/linux-omap/msg21857.html > > > > > > I'd assume the registers are the same for 34xx since we > > > don't have them defined separately in the kernel. > > > > I can't find it in the omap36xx documentation either. Maybe > > I search at the wrong position. I've checked a few of the oldest (in case it was later removed) and newest (in case it was later added) omap3-series public TRMs I have, none of them list the aes module or associated interconnect info. The region is either "reserved" or just silently skipped over. The practice of pretending something doesn't exist in the TRM while simultaneously releasing a linux driver continues to puzzle me. > > I tried to find something crypto related in > > > > Table 9-89. L3_PM_READ_PERMISSION_i > > Hmm maybe it's done based on the address in > L3_PM_ADDR_MATCH_k? According to the address (aes@480c5000) it's attached to the L4-Core interconnect, so why would an L3 firewall be involved? Its access control would be configured in the L4-Core AP (2KB @ 0x4804), and since they have an integrated memory map you'd automatically know which entry is responsible, assuming you can access the AP at all. -- 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 26 January 2015 at 16:58, Tony Lindgren 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 hardwwired > to 32KiHz by looking at it with a scope on the clkout pin. Yeah it comes straight from the "rtcdivider" so it'll produce 0.0016384 * devosc. The global clock structure overview in the TRM (figure 2-6) actually correctly marks the former-audio-fapll clocks (except audio5 := osc0, yielding sysclk22 after divider) but you already need to know what the hell is going on to recognize that. Oh, on the topic of PRCM, a word of caution: while the cold reset default of PM_DEFAULT_PWRSTCTRL is 0, performing _any_ write to it (regardless of value) sets it to 3 (force power-on) until next cold reset. An unfortunately side-effect I stumbled over is that a particular bus lockup that can occur in ducati (dual cortex-m3 subsystem) then becomes warm-reset-insensitive. The statement I got from TI support about the strange behaviour of this power control register was.. vague: In DM814x, complete functionality of PRCM was not used and that resulted into such requirements. This recommendations was made based on DV test cases with POWERONSTATE == ON/0x3. We didn’t do any negative testing to see the behaviour in case POWERONSTATE != ON/0x3. So I can recommend you to test your system without this requirement and see if you will have any issues. I think this requirement is not needed (POWERONSTATE == ON/0x3), as the DM814x EZSDK (u-boot, linux kernel) is working fine without it. > > 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. > > 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? You mean the modules? SecSS unfortunately doesn't have an integrated memory map like the one present in the Sonics S3220 interconnects, so I just probed it manually while making use of the knowledge I already had of SecSS on Centaurus. It helps that I already did quite a bit of exploration of SecSS on Centaurus, and it turns out to barely differ from the original one* on Netra. The differences seem to be permissions-related: the subsystem control module was split into two separate parts and there was a tiny bit of rearrangement for the benefit of being able to cover multiple modules with a single firewall region. I've updated the SecSS sheet of my memory-map spreadsheet to highlight the differences. It's not totally clear what the intentions are of the various default firewall regions. Region 0 will undoubtedly be highly restricted on all but GP devices. On centaurus region 5 looks like it'll be exclusively for the cortex-m3 on devices where it automatically boots stand-alone from ROM (EMU/HS) instead of waiting to boot into user-supplied code on request (Test/GP/EMUL/HSL). *TI's linux driver calls it "NSS" (Netra Security Subsystem) on both chips, so presumably Netra was the first to have this kind of subsystem. -- 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 23 January 2015 at 17:47, Tony Lindgren 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). 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) > > 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. 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. -- 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 19 January 2015 at 18:29, Tony Lindgren 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ARM: OMAP2+: Remove unused ti81xx platform init code
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -82,16 +82,8 @@ void __init usb_musb_init(struct omap_musb_board_data
> *musb_board_data)
> musb_plat.mode = board_data->mode;
> musb_plat.extvbus = board_data->extvbus;
>
> - if (soc_is_am35xx()) {
Was it intentional that this patch also removed a test for am35xx
(rather than am335x) ?
--
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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 17 January 2015 at 19:14, Tony Lindgren 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, 0x80. (mode 0, called "safe mode" is mentioned separately) For compatibility sake I'm personally more inclined to consider them modes 0-7 with "safe mode" being -1. Oh, and I just remembered: while 811x is mostly compatible with 814x, it has up to 12 mux modes per pin. So replace "byte-write" by "u16-write" in my previous post ;-) >> It also means you can change mode with a u16-write to avoid touching >> the upper bits > > Maybe that's why some bits got shifted :) Yes, in general bitfields seem to be grouped into separate bytes in quite a few places where it may be convenient to take advantage of the fact that both PRCM and the Control module are byte-addressable to avoid having to do a read-modify-update. (For example the omap4/5 standard layout for CLKCTRL puts modulemode in byte 0, optional fclks in byte 1, and any mux/div config the module may have in the upper bytes. Only the am335x violates this rule.) >> The overall control module layout is actually compatible across the >> whole happy family > > Got any generic naming in mind for the helper macro we could use? I've already been pondering what to call this family, since architecturally they do very clearly form a fairly close family related to, but also clearly distinct from, the omap4/5 line. As you may notice from my spreadsheet I already generally prefer to use their names (Netra, Centaurus, Subarctic, Aegis), both because names are rather more memorable and distinguishable for humans than 4-digit numbers and because each actually has a flurry of wildly different part codes depending on which subsystems happen to fail the factory test and get disabled (which may of course be a big deal featurewise but is rather irrelevant to the kernel). Still leaves four names to unify... I may be biased but I'm leaning towards "Centauroid": Centaurus (814x) seems to have a fairly central position, being memory-map compatible with the there other members (i.e. no subsystem/peripheral of Centaurus overlaps a different one of another device), while the same is not true between Netra (816x) and subarctic (335x). I suspect this may be because Centaurus and Netra form a single product line (DM81xx) iin one market segment (video) while Centaurus and Subarctic form a single product line (DRA6xx) in another market segment (automotive). > Cool, that certainly helps. To me it looks dm814x needs it's own > clock driver for the source clocks, but after that the dividers > are similar to dm816x and am33xx. Have not looked at the am814x > beyond that though. dm814x you mean... the downfeatured Sitara version got called am387x, naturally. ;-) The biggest architectural differences between three chips are indeed in PRCM, where each member has its own peculiarities: Netra and Centaurus both have the simple but clean omap4-subset PRCM. No fancy auto-management by hardware but at least a clean well-organised interface, with the biggest blemish being the register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in contrast, being organized by "sort -R", incompatibility with the omap4/5 register layouts, and a seemingly endless supply of novel ways of being inconsistent.) Netra however has the FAPLL experiment, which apparently wasn't a success so while Centaurus retained much of the clock tree it reverted to using normal PLLs by replacing the FAPLLs with its PLL subsystem containing additional clock muxes to sort of glue it onto the existing clock tree, making the clock tree a bit messier. (Especially older versions of the TRM were very confusing to those unfamiliar with this Netra-heritage since FAPLL names were still all over the place.) In line with the "fully software managed" tradition, it seems to wire *all* control/status signals of the PLLs directly into registers. They can be slightly fickle (and mucking up the MPU PLL can leave you pretty screwed, especially since the watchdog reset doesn't reset the PLLs). Also important: Centaurus has very similar Ethernet subsystem to that of subarctic, though some components are a slightly older minor revision. In violation of what a "minor revision" normally means, they are however software-incompatible thanks to moving blocks of registers around to different offsets, and some per-port settings became global or vice versa. This however seems to be a tradition for the 3-port gigabit switch subsystem: out of curiosity I examined the ones in other TI SoCs, and it turns out that literally *all* of them have different, incompatible register layouts (sometimes also extending to the switch table entries and/or DMA descriptors). Other than this, the subsystems and peripherals are mostly familiar omap4-generation stuff, but with a st
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 17 January 2015 at 17:47, Tony Lindgren 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 contains 1 << mode. The benefit is that you can also select no mode at all (high-Z or just the pull if enabled) and this is in fact the default, though I'm curious what would happen if multiple bits are set (though not curious enough to risk my hardware :P ). It also means you can change mode with a byte-write to avoid touching the upper bits, which is nice especially since slew is preconfigured per pin to match I/O timings and you're supposed to never change it (after fixing the ones ROM messed up due to bugs). Also on rev 2.x silicon you're not allowed to disable the receiver if using 3.3V I/O. > +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) The overall control module layout is actually compatible across the whole happy family; basically any register they have in common is at the same offset (with notable exception of ADC and eCAP event muxes on am335x versus c6a811x/dra62x, but the latter is a semi-mythical device anyway, not even a product brief in circulation). They often even have the same semantics, though padconf shows this isn't always true unfortunately. A similar thing is true for the overall device memory map actually: https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view -- 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
