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. Centaurus is a
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Matthijs van Duin matthijsvand...@gmail.com [150318 01:33]: And we also need to populate the tables along the lines of 27b7d5f3cc49 (bus: omap_l3_noc: Add AM4372 interconnect error data). I think intercon data should be in DT rather than some hardcoded table. Yeah so it seems. Do the 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 Oh there's a gap here and it goes all the way to 2400.. Is there a gap on am335x too? 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 OK that's great, thanks for the data! 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). OK that's good to hear. 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. Hmm well we could that in the kernel using the SRAM code as long as it does not reset the devices. 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. OK the driver would have to be enabled with interrupts while scanning.
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
Matthijs van Duin matthijsvand...@gmail.com wrote: 44400500 target 11 vcp 44800100 target 18 vlynq ? scrap these guesses: I don't think Netra has a vcp module, and I had only filled in vlynq based on it being the only remaining target NIU. Once the memory ranges for the targets have been determined they should be easy to identify conclusively. On 18 March 2015 at 17:54, Tony Lindgren t...@atomide.com 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
* Tony Lindgren t...@atomide.com [150202 08:15]:
* Matthijs van Duin matthijsvand...@gmail.com [150131 17:54]:
I just noticed the dm816x.dtsi says:
ocp {
compatible = ti,omap3-l3-smx, simple-bus;
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
SonicsMX. (In general everything on the DM81xx seems to be
omap4-generation)
Good catch, yes it seems it's mostly omap4. Looks like we
should also add it for am33xx.dtsi while at it.
I'll also check the devices one more time if I have some as
compatible with omap3 instead of omap4.
Hmm this is also broken on am33xx, and the following patch is needed.
And we also need to populate the tables along the lines of 27b7d5f3cc49
(bus: omap_l3_noc: Add AM4372 interconnect error data).
Do the below ranges match your JTAG results? I scanned them in u-boot
using md for the ranges where I found some related data.
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..
Can we dig even more info based on the RX port address at offset
0x10? That's the L3_TARG_STDHOSTHDR_NTTPADDR_0.
Or got any good ideas for populating the names?
Regards,
Tony
8 --
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -105,7 +105,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = simple-bus;
+ compatible = ti,am335-l3-noc, simple-bus;
+ reg = 0x4400 0x1200
+ 0x4480 0x1000;
+ interrupts = 9 10;
#address-cells = 1;
#size-cells = 1;
ranges;
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -58,8 +58,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = ti,omap4-l3-noc, simple-bus;
- reg = 0x4400 0x1;
+ compatible = ti,dm816-l3-noc, simple-bus;
+ reg = 0x4400 0x1200
+ 0x4440 0x1200
+ 0x4480 0x1000;
interrupts = 9 10;
#address-cells = 1;
#size-cells = 1;
--
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 t...@atomide.com wrote:
* Matthijs van Duin matthijsvand...@gmail.com [150128 13:46]:
On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote:
I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
to 32KiHz by looking at it 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
* Matthijs van Duin matthijsvand...@gmail.com [150131 17:54]:
I just noticed the dm816x.dtsi says:
ocp {
compatible = ti,omap3-l3-smx, simple-bus;
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
SonicsMX. (In general everything on the DM81xx seems to be
omap4-generation)
Good catch, yes it seems it's mostly omap4. Looks like we
should also add it for am33xx.dtsi while at it.
I'll also check the devices one more time if I have some as
compatible with omap3 instead of omap4.
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 4/4] ARM: dts: Add minimal support for dm8168-evm
* Matthijs van Duin matthijsvand...@gmail.com [150128 13:46]: On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote: See earlier I was assuming copy paste issues from dm814x to dm816x Ahh, you thought the 816x was 814x-derived... yes I can imagine that will have led to some 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. Not much about rtcdivider in the dm816x TRM.. 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. 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. And we probably should add what you're explaining to the comments also to make some sense out of it :) 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 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: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Tony Lindgren t...@atomide.com [150123 08:54]: Should be usable for NFSroot with all the patches I've sent using the ti u-boot and and appended DTB uImage. Sorry not all of it is yet in Linux next though, I'll push a current testing branch at some point today. The mainline u-boot was at least missing the davinci_emac support the last time I tried. Seems to be all in today's Linux next and I just verified that 3.19.0-rc6-next-20150128-06478-g30720bbe is booting on 8168-evm. 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 4/4] ARM: dts: Add minimal support for dm8168-evm
On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote: See earlier I was assuming copy paste issues from dm814x to dm816x Ahh, you thought the 816x was 814x-derived... yes I can imagine that will have led to some confusion. I'm pretty sure I verified the that the audio_pll_clk1 is 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
* Matthijs van Duin matthijsvand...@gmail.com [150125 00:37]: On 23 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote: That's interesting info thanks :) Yeah it seems dm814x was done after dm816x and that clears at least some of the clockdomain confusion that I though was TRM copy-paste issue. Well it is in some sense still a copy-paste issue when e.g. CM_SYSCLK18_CLKSEL refers to the Audio PLL generated 32 Khz Clock when there is none (it means the Audio PLL A divider output, which itself is in fact fed by the rtcdivider). Sounds like that's a copy paste issue from dm816x to dm814x then :) See earlier I was assuming copy paste issues from dm814x to dm816x before you confirmed dm816x was done before dm814x. On the dm816x I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired to 32KiHz by looking at it with a scope on the clkout pin. Probably the sillyest copy-paste error is section 1.3.2.2.1 on the DSP interrupt controller, whose list of interrupts is from Freon/Primus (omap-L13x) which is not even remotely similar to the actual list in section 1.7.3. Which reminds me, I also have a centaurus irqs spreadsheet which may be more convenient than the lists in the PDF and includes some that were censored from public docs: https://docs.google.com/spreadsheets/d/1O3IFMdAfLMWVBQ8rzLPexMbi4LDD5ECfpVYGF6HMv_0/view (note however that I consistently use 0-based indexing, regardless of the TRM which tends to vary on that) Heheh that should be also helpful. And there are gaps in the memory map suggesting maybe there were more submodules in earlier versions. I know it differs from Netra's security subsystem since one module offset is different... hmm, now I'm curious. I'll see if I can find a moment to brush the dust off the evm816x here and make a quick inventory. Should be usable for NFSroot with all the patches I've sent using the ti u-boot and and appended DTB uImage. Sorry not all of it is yet in Linux next though With make a quick inventory I meant peeking and poking around in the subsystem using JTAG, which is generally better done without any OS running on the target :-) I don't actually have any real motivation to run linux on the evm816x; we selected the DM814x for our target (before it became clear support for it had basically dropped like a brick), though it may still take a bit before I have time to see how far I can get with booting Linux on it. Oh OK. Yeah it sounds like you could generate the required dm814x .dts entries with a few macros from your spreadsheets :) The inventory of SecSS on Netra yielded exactly the same list of accelerators and other peripherals as on Centaurus btw. The only changes seem to be in subsystem control stuff. I was not succesful in attaching to the secM3 via JTAG though, but this may have been an issue with the target config since Code Composer was being more annoying than usual about it. What are you using to identify the devices? The device revision register? Or are there actually some populated interconnect data available with device info that could be used for a real scannable bus? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 23 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote: That's interesting info thanks :) Yeah it seems dm814x was done after dm816x and that clears at least some of the clockdomain confusion that I though was TRM copy-paste issue. Well it is in some sense still a copy-paste issue when e.g. CM_SYSCLK18_CLKSEL refers to the Audio PLL generated 32 Khz Clock when there is none (it means the Audio PLL A divider output, which itself is in fact fed by the rtcdivider). 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
* Matthijs van Duin matthijsvand...@gmail.com [150121 19:20]: On 19 January 2015 at 18:29, Tony Lindgren t...@atomide.com wrote: Hmm I sort of got the idea that dm814x and dm816x were done about the same time. Are you saying dm814x was actually done after dm816x? Well, it's hard to come up with an alternate explanation of netra's FAPLLs showing up in the terminology of centaurus' clock tree (though the amount of references to them in the TRM decreased over time) without the FAPLLs being there themselves. Of course a radical new design will have much more distance between initial development and public release than a derivative design. An interesting timeline is given by looking at JTAG partcodes, since those obviously have to be assigned somewhere during development, before the first silicon is produced (omap3/4/5 and centauroids listed): b6d6 - omap34xx 1.0 b7ae - omap34xx/35xx 2.x/3.x b81e - netra b852 - omap4430 1.0 b868 - am35xx b891 - omap36xx / dm/am37xx b8f2 - centaurus b942 - omap5430 b944 - subarctic b94e - omap4460 b95c - omap4430 2.x b96b - centaurus eve (dmva3/4 / dm38x) b975 - omap4470 b98c - aegis b990 - vayu b998 - omap5432 (The distance between the two omap543x variants suggests to me the ID is assigned early in the development, with the 5432-variant added late in the design, but that's just a guess.) That's interesting info thanks :) Yeah it seems dm814x was done after dm816x and that clears at least some of the clockdomain confusion that I though was TRM copy-paste issue. Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that the registers are different. BTW, if you spot any piece of the documentation making it sound like port 2 is special somehow, it means port 0 instead. (The host port was port 2 in CPSW in some earlier devices, and iirc a reference to this was still somewhere in the current docs) There's also an interesting Security Subsystem, which houses the crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine, 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit, irq routing, and an elaborate L3 firewall instance covering both external and internal access. Hmm that's a lot of accelerators.. And there are gaps in the memory map suggesting maybe there were more submodules in earlier versions. I know it differs from Netra's security subsystem since one module offset is different... hmm, now I'm curious. I'll see if I can find a moment to brush the dust off the evm816x here and make a quick inventory. Should be usable for NFSroot with all the patches I've sent using the ti u-boot and and appended DTB uImage. Sorry not all of it is yet in Linux next though, I'll push a current testing branch at some point today. The mainline u-boot was at least missing the davinci_emac support the last time I tried. The DES module and second AES module in subarctic's memory map (and PRCM) appear to be ghost modules, but I'd suspect this means they are present on Aegis. Makes sense in combo with its magstripe card reader. BTW, someone found genuine documentation of the AES/DES/Hash accelerators: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868 Oh OK. [random thought] There's another interesting application of the SecSS cortex-M3: on GP devices it is (afaict) the only processor with MReqDomain=1, while this is zero for all others. This 3-bit identifier is used for security partitioning, and is something you can test on in all firewalls. It is also the connID for EDMA's integrated memory protection and proxied by EDMA transfers. The processor is also located in the ALWON power domain. This puts the secM3 in a unique position to act as device hypervisor and prevent processors and DMA engines from meddling with hardware resources they aren't supposed to meddle with. Even if security isn't a concern, this would be a good idea for the same reason memory protection is useful to separate processes. With so many initiators around, if one accidently does a bogus write and clobbers someone else's state, the resulting failure is obviously rather hard to debug. Yeah could be handy :) Regards, Tony -- 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 t...@atomide.com wrote: Hmm I sort of got the idea that dm814x and dm816x were done about the same time. Are you saying dm814x was actually done after dm816x? Well, it's hard to come up with an alternate explanation of netra's FAPLLs showing up in the 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 4/4] ARM: dts: Add minimal support for dm8168-evm
* Matthijs van Duin matthijsvand...@gmail.com [150117 14:41]: On 17 January 2015 at 19:14, Tony Lindgren t...@atomide.com wrote: Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] bits for MUXMODE instead of just bits [2:0]? However, the datasheet's table of possible mux modes 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 ;-) Luckily those can be defined which ever way in pinctrl single just by changing the pinctrl-single,register-width entry. 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). Well sounds like no need to start messing with the existing ti81xx defines excemt maybe rename cpu_is_ti81xx to soc_is_dm81xx and so on. There are only very few places referencing that now. 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. ;-) Yes I mean dm814x sorry :) 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.) Uhh yeah. 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). 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? 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). Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that the registers are different. Other than this, the subsystems and peripherals are mostly familiar
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Tony Lindgren t...@atomide.com [150113 15:44]:
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Here's this one updated with spi-nor detected and a minimal
pinctrl-single configuration. No partition info yet configured
though. Also looks like the PULL_ENA bit is inverted on dm816x
like on am33xx so at some point we probably want to have
a arch/arm/boot/dts/include/dt-bindings/pinctrl/dm816x.h.
Regards,
Tony
8 -
From: Tony Lindgren t...@atomide.com
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add minimal support for dm8168-evm
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 000..857d028
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,129 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dm816x.dtsi
+
+/ {
+ model = DM8168 EVM;
+ compatible = ti,dm8168-evm, ti,dm8168;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000/* 1 GB */
+ 0xc000 0x4000; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+};
+
+dm816x_pinmux {
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins =
+ DM816X_IOPAD(0x0a94, PIN_INPUT | MUX_MODE0) /*
SPI_SCLK */
+ DM816X_IOPAD(0x0a98, PIN_OUTPUT | MUX_MODE0)/*
SPI_SCS0 */
+ DM816X_IOPAD(0x0aa8, PIN_INPUT | MUX_MODE0) /*
SPI_D0 */
+ DM816X_IOPAD(0x0aac, PIN_INPUT | MUX_MODE0) /*
SPI_D1 */
+ ;
+ };
+};
+
+i2c1 {
+ extgpio0: pcf8575@20 {
+ compatible = nxp,pcf8575;
+ reg = 0x20;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+};
+
+i2c2 {
+ extgpio1: pcf8575@20 {
+ compatible = nxp,pcf8575;
+ reg = 0x20;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+};
+
+gpmc {
+ ranges = 0 0 0x0400 0x0100; /* CS0: 16MB for NAND */
+
+ nand@0,0 {
+ linux,mtd-name= micron,mt29f2g16aadwp;
+ reg = 0 0 4; /* CS0, offset 0, IO size 4 */
+ #address-cells = 1;
+ #size-cells = 1;
+ ti,nand-ecc-opt = bch8;
+ nand-bus-width = 16;
+ gpmc,device-width = 2;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-on-ns = 0;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+ partition@0 {
+ label = X-Loader;
+ reg = 0
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 17 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote: Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx Yes, ditto on dm814x but there things get even more interesting: It has the same four config bits as am335x but moved them to bits 16-19, while bits 0-7 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
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Matthijs van Duin matthijsvand...@gmail.com [150117 09:54]: On 17 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote: Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx Yes, ditto on dm814x but there things get even more interesting: It has the same four 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 ). Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] bits for MUXMODE instead of just bits [2:0]? 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. Maybe that's why some bits got shifted :) +#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. Got any generic naming in mind for the helper macro we could use? A similar thing is true for the overall device memory map actually: https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view 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. 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 4/4] ARM: dts: Add minimal support for dm8168-evm
On 17 January 2015 at 19:14, Tony Lindgren t...@atomide.com wrote: Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] bits for MUXMODE instead of just bits [2:0]? However, the datasheet's table of possible mux modes per pin has as column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 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 standard C674x DSP
[PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dm8168-evm.dts | 105 +++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/dm8168-evm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..fe15c7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 000..9acd4ff
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,105 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dm816x.dtsi
+
+/ {
+ model = DM8168 EVM;
+ compatible = ti,dm8168-evm, ti,dm8168;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000/* 1 GB */
+ 0xc000 0x4000; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+};
+
+i2c1 {
+ extgpio0: pcf8575@20 {
+ compatible = nxp,pcf8575;
+ reg = 0x20;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+};
+
+i2c2 {
+ extgpio1: pcf8575@20 {
+ compatible = nxp,pcf8575;
+ reg = 0x20;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+};
+
+gpmc {
+ ranges = 0 0 0x0400 0x0100; /* CS0: 16MB for NAND */
+
+ nand@0,0 {
+ linux,mtd-name= micron,mt29f2g16aadwp;
+ reg = 0 0 4; /* CS0, offset 0, IO size 4 */
+ #address-cells = 1;
+ #size-cells = 1;
+ ti,nand-ecc-opt = bch8;
+ nand-bus-width = 16;
+ gpmc,device-width = 2;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-on-ns = 0;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+ partition@0 {
+ label = X-Loader;
+ reg = 0 0x8;
+ };
+ partition@0x8 {
+ label = U-Boot;
+ reg = 0x8 0x1c;
+ };
+ partition@0x1c {
+ label = Environment;
+ reg = 0x24 0x4;
+ };
+ partition@0x28 {
+ label = Kernel;
+ reg = 0x28 0x50;
+ };
+ partition@0x78 {
+ label = Filesystem;
+ reg = 0x78 0xf88;
+ };
+ };
+};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
--
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
