Device tree related changes to boot dm816x

This allows booting ti81xx boards with with when a .dts

file is in place.

Cc Brian Hutchinson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Hello.

Quoted 1 line · Tony Lindgren

This allows booting ti81xx boards with with when a .dts

So, with, with or when? :-)

Quoted 4 lines · Sergei Shtylyov

Hello.

On 1/14/2015 2:37 AM, Tony Lindgren wrote:

Quoted 3 lines

Quoted 1 line

This allows booting ti81xx boards with with when a .dts

So, with, with or when? :-)

Heh thanks will updated to:

This allows booting ti81xx boards when a .dts file is in place.

Quoted 5 lines · Tony Lindgren

Quoted 4 lines · Sergei Shtylyov

Hello.

On 1/14/2015 2:37 AM, Tony Lindgren wrote:

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

This allows booting ti81xx boards with with when a .dts

So, with, with or when? :-)

Heh thanks will updated to:

This allows booting ti81xx boards when a .dts file is in place.

This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block to avoid make randconfig build errors. Updated patch below.

Regards,

Tony

8< -----------------
From: Tony Lindgren <[email protected]>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx

This allows booting ti81xx boards when a .dts file is in place.

Cc Brian Hutchinson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Quoted 33 lines · Tony Lindgren

Quoted 5 lines · Tony Lindgren

Quoted 4 lines · Sergei Shtylyov

Hello.

On 1/14/2015 2:37 AM, Tony Lindgren wrote:

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

This allows booting ti81xx boards with with when a .dts

So, with, with or when? :-)

Heh thanks will updated to:

This allows booting ti81xx boards when a .dts file is in place.

This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block to avoid make randconfig build errors. Updated patch below.

Regards,

Tony

8< -----------------
From: Tony Lindgren <[email protected]>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx

This allows booting ti81xx boards when a .dts file is in place.

Cc Brian Hutchinson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/board-generic.c DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)") · line 146

Quoted 8 lines

arch/arm/mach-omap2/board-generic.c +2 -0

@@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
 	.dt_compat	= am3517_boards_compat,
 	.restart	= omap3xxx_restart,
 MACHINE_END
+
+static const char *const ti814x_boards_compat[] __initconst = {

should this definition be within that ifdef too ?

Quoted 34 lines · Felipe Balbi

Quoted 33 lines · Tony Lindgren

Quoted 5 lines · Tony Lindgren

Quoted 4 lines · Sergei Shtylyov

Hello.

On 1/14/2015 2:37 AM, Tony Lindgren wrote:

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

This allows booting ti81xx boards with with when a .dts

So, with, with or when? :-)

Heh thanks will updated to:

This allows booting ti81xx boards when a .dts file is in place.

This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block to avoid make randconfig build errors. Updated patch below.

Regards,

Tony

8< -----------------
From: Tony Lindgren <[email protected]>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx

This allows booting ti81xx boards when a .dts file is in place.

Cc Brian Hutchinson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Quoted 10 lines

arch/arm/mach-omap2/board-generic.c DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)") · line 146

Quoted 8 lines

arch/arm/mach-omap2/board-generic.c +2 -0

@@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
 	.dt_compat	= am3517_boards_compat,
 	.restart	= omap3xxx_restart,
 MACHINE_END
+
+static const char *const ti814x_boards_compat[] __initconst = {

should this definition be within that ifdef too ?

Oops yes totally thanks for catching that. Updated patch below.

Regards,

Tony

8< -----------------
From: Tony Lindgren <[email protected]>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx

This allows booting ti81xx boards when a .dts file is in place.

Cc Brian Hutchinson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/board-generic.c +36 -0

@@ -144,6 +144,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
 MACHINE_END
 #endif
 
+#ifdef CONFIG_SOC_TI81XX
+static const char *const ti814x_boards_compat[] __initconst = {
+	"ti,dm8148",
+	"ti,dm814",
+	NULL,
+};
+
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.map_io		= ti81xx_map_io,
+	.init_early	= ti814x_init_early,
+	.init_machine	= omap_generic_init,
+	.init_late	= ti81xx_init_late,
+	.init_time	= omap3_gptimer_timer_init,
+	.dt_compat	= ti814x_boards_compat,
+	.restart	= ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+	"ti,dm8168",
+	"ti,dm816",
+	NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.map_io		= ti81xx_map_io,
+	.init_early	= ti816x_init_early,
+	.init_machine	= omap_generic_init,
+	.init_late	= ti81xx_init_late,
+	.init_time	= omap3_gptimer_timer_init,
+	.dt_compat	= ti816x_boards_compat,
+	.restart	= ti81xx_restart,
+MACHINE_END
+#endif
+
 #ifdef CONFIG_SOC_AM33XX
 static const char *const am33xx_boards_compat[] __initconst = {
 	"ti,am33xx",

Similar to other omap variants, let's add dm816x support.

Note that this is based on generated data from the TI81XX-LINUX-PSP-04.04.00.02 patches published at:

http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html

I've verified the basic functionality, but have not been able to test all the devices on dm8168-evm.

Cc Brian Hutchinson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/boot/dts/dm816x.dtsi | 374 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 374 insertions(+)
 create mode 100644 arch/arm/boot/dts/dm816x.dtsi

arch/arm/boot/dts/dm816x.dtsi new file +163 -0

new file mode 100644
index 0000000..7d575ac
@@ -0,0 +1,374 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "ti,dm816";
+	interrupt-parent = <&intc>;
+
+	aliases {
+		i2c0 = &i2c1;
+		i2c1 = &i2c2;
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		ethernet0 = &eth0;
+		ethernet1 = &eth1;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			compatible = "arm,cortex-a8";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	pmu {
+		compatible = "arm,cortex-a8-pmu";
+		interrupts = <3>;
+	};
+
+	/*
+	 * The soc node represents the soc top level view. It is used for IPs
+	 * that are not memory mapped in the MPU view or for the MPU itself.
+	 */
+	soc {
+		compatible = "ti,omap-infra";
+		mpu {
+			compatible = "ti,omap3-mpu";
+			ti,hwmods = "mpu";
+		};
+	};
+
+	/*
+	 * XXX: Use a flat representation of the dm816x interconnect.
+	 * The real dm816x interconnect network is quite complex. Since
+	 * it will not bring real advantage to represent that in DT
+	 * for the moment, just use a fake OCP bus entry to represent
+	 * the whole bus hierarchy.
+	 */
+	ocp {
+		compatible = "ti,omap3-l3-smx", "simple-bus";
+		reg = <0x44000000 0x10000>;
+		interrupts = <9 10>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		ti,hwmods = "l3_main";
+
+		prcm: prcm at 48180000 {
+			compatible = "ti,dm816-prcm";
+			reg = <0x48180000 0x4000>;
+
+			prcm_clocks: clocks {
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+
+			prcm_clockdomains: clockdomains {
+			};
+		};
+
+		scrm: scrm at 48140000 {
+			compatible = "ti,dm816-scrm";
+			reg = <0x48140000 0x21000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x48140000 0x21000>;
+
+			scrm_clocks: clocks {
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+
+			scrm_clockdomains: clockdomains {
+			};
+		};
+
+		cm: syscon at 44e10000 {
+			compatible = "ti,am33xx-controlmodule", "syscon";
+			reg = <0x44e10000 0x800>;
+		};
+
+		edma: edma at 49000000 {
+			compatible = "ti,edma3";
+			ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+			reg =   <0x49000000 0x10000>,
+			        <0x44e10f90 0x40>;
+			interrupts = <12 13 14>;
+			#dma-cells = <1>;
+		};
+
+		elm: elm at 48080000 {
+			compatible = "ti,816-elm";
+			ti,hwmods = "elm";
+			reg = <0x48080000 0x2000>;
+			interrupts = <4>;
+		};
+
+		gpio1: gpio at 48032000 {
+			compatible = "ti,omap3-gpio";
+			ti,hwmods = "gpio1";
+			reg = <0x48032000 0x1000>;
+			interrupts = <97>;
+		};
+
+		gpio2: gpio at 4804c000 {
+			compatible = "ti,omap3-gpio";
+			ti,hwmods = "gpio2";
+			reg = <0x4804c000 0x1000>;
+			interrupts = <99>;
+		};
+
+		gpmc: gpmc at 50000000 {
+			compatible = "ti,am3352-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x50000000 0x2000>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			interrupts = <100>;
+			gpmc,num-cs = <6>;
+			gpmc,num-waitpins = <2>;
+		};
+
+		i2c1: i2c at 48028000 {
+			compatible = "ti,omap4-i2c";
+			ti,hwmods = "i2c1";
+			reg = <0x48028000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <70>;
+			dmas = <&edma 58 &edma 59>;
+			dma-names = "tx", "rx";
+		};
+
+		i2c2: i2c at 4802a000 {
+			compatible = "ti,omap4-i2c";
+			ti,hwmods = "i2c2";
+			reg = <0x4802a000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <71>;
+			dmas = <&edma 60 &edma 61>;
+			dma-names = "tx", "rx";
+		};

arch/arm/boot/dts/dm816x.dtsi new file +192 -0

+		};
+
+		mdio: mdio at 4a100800 {
+			compatible = "ti,davinci_mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x4a100800 0x100>;
+			ti,hwmods = "davinci_mdio";
+			bus_freq = <1000000>;
+			phy0: ethernet-phy at 0 {
+				reg = <1>;
+			};
+			phy1: ethernet-phy at 1 {
+				reg = <2>;
+			};
+		};
+
+		eth0: ethernet at 4a100000 {
+			compatible = "ti,dm816-emac";
+			ti,hwmods = "emac0";
+			reg = <0x4a100000 0x800
+			       0x4a100900 0x3700>;
+			clocks = <&sysclk24_ck>;
+			ti,davinci-ctrl-reg-offset = <0>;
+			ti,davinci-ctrl-mod-reg-offset = <0x900>;
+			ti,davinci-ctrl-ram-offset = <0x2000>;
+			ti,davinci-ctrl-ram-size = <0x2000>;
+			interrupts = <40 41 42 43>;
+			phy-handle = <&phy0>;
+		};
+
+		eth1: ethernet at 4a120000 {
+			compatible = "ti,dm816-emac";
+			ti,hwmods = "emac1";
+			reg = <0x4a120000 0x4000>;
+			clocks = <&sysclk24_ck>;
+			ti,davinci-ctrl-reg-offset = <0>;
+			ti,davinci-ctrl-mod-reg-offset = <0x900>;
+			ti,davinci-ctrl-ram-offset = <0x2000>;
+			ti,davinci-ctrl-ram-size = <0x2000>;
+			interrupts = <44 45 46 47>;
+			phy-handle = <&phy1>;
+		};
+
+		mcspi1: spi at 48030000 {
+			compatible = "ti,omap3-mcspi";
+			reg = <0x48030000 0x2000>;
+			interrupts = <65>;
+			ti,spi-num-cs = <2>;
+			ti,hwmods = "mcspi1";
+			dmas = <&edma 16 &edma 17
+				&edma 18 &edma 19>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		mmc1: mmc at 48060000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x48060000 0x11000>;
+			ti,hwmods = "mmc1";
+			interrupts = <64>;
+			dmas = <&edma 24 &edma 25>;
+			dma-names = "tx", "rx";
+		};
+
+		timer1: timer at 4802e000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x4802e000 0x2000>;
+			interrupts = <67>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48040000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x48040000 0x2000>;
+			interrupts = <68>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer at 48042000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x48042000 0x2000>;
+			interrupts = <69>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer at 48044000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x48044000 0x2000>;
+			interrupts = <92>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer at 48046000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x48046000 0x2000>;
+			interrupts = <93>;
+			ti,hwmods = "timer5";
+		};
+
+		timer6: timer at 48048000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x48048000 0x2000>;
+			interrupts = <94>;
+			ti,hwmods = "timer6";
+		};
+
+		timer7: timer at 4804a000 {
+			compatible = "ti,dm816-timer";
+			reg = <0x4804a000 0x2000>;
+			interrupts = <95>;
+			ti,hwmods = "timer7";
+		};
+
+		uart1: uart at 48020000 {
+			compatible = "ti,omap3-uart";
+			ti,hwmods = "uart1";
+			reg = <0x48020000 0x2000>;
+			clock-frequency = <48000000>;
+			interrupts = <72>;
+			dmas = <&edma 26 &edma 27>;
+			dma-names = "tx", "rx";
+		};
+
+		uart2: uart at 48022000 {
+			compatible = "ti,omap3-uart";
+			ti,hwmods = "uart2";
+			reg = <0x48022000 0x2000>;
+			clock-frequency = <48000000>;
+			interrupts = <73>;
+			dmas = <&edma 28 &edma 29>;
+			dma-names = "tx", "rx";
+		};
+
+		uart3: uart at 48024000 {
+			compatible = "ti,omap3-uart";
+			ti,hwmods = "uart3";
+			reg = <0x48024000 0x2000>;
+			clock-frequency = <48000000>;
+			interrupts = <74>;
+			dmas = <&edma 30 &edma 31>;
+			dma-names = "tx", "rx";
+		};
+
+		/* NOTE: USB needs a transceiver driver for phys to work */
+		usb: usb_otg_hs at 47401000 {
+			compatible = "ti,am33xx-usb";
+			reg = <0x47401000 0x400000>;
+			ranges;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ti,hwmods = "usb_otg_hs";
+
+			usb0: usb at 47401000 {
+				compatible = "ti,musb-am33xx";
+				reg = <0x47401400 0x400
+				       0x47401000 0x200>;
+				reg-names = "mc", "control";
+				interrupts = <18>;
+				interrupt-names = "mc";
+				dr_mode = "otg";
+				mentor,multipoint = <1>;
+				mentor,num-eps = <16>;
+				mentor,ram-bits = <12>;
+				mentor,power = <500>;
+			};
+
+			usb1: usb at 47401800 {
+				compatible = "ti,musb-am33xx";
+				status = "disabled";
+				reg = <0x47401c00 0x400
+				       0x47401800 0x200>;
+				reg-names = "mc", "control";
+				interrupts = <19>;
+				interrupt-names = "mc";
+				dr_mode = "otg";
+				mentor,multipoint = <1>;
+				mentor,num-eps = <16>;
+				mentor,ram-bits = <12>;
+				mentor,power = <500>;
+			};
+		};
+
+		wd_timer2: wd_timer at 480c2000 {
+			compatible = "ti,omap3-wdt";
+			ti,hwmods = "wd_timer";
+			reg = <0x480c2000 0x1000>;
+			interrupts = <0>;
+		};
+	};
+};
+

Review

Quoted 3 lines · Tony Lindgren

(quoted diff) +3 -0

+
+		mailbox: mailbox at 480c8000 {
+			compatible = "ti,omap3-mailbox";

The Mailbox IP is actually more like that of OMAP4, so the correct one would be "ti,omap4-mailbox"

Review

Quoted 5 lines

(quoted diff) +5 -0

+			reg = <0x480c8000 0x2000>;
+			interrupts = <77>;
+			ti,hwmods = "mailbox";
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <8>;

This should be 12

Review

Quoted 4 lines

(quoted diff) +4 -0

+			mbox_wkupm3: wkup_m3 {
+				ti,mbox-tx = <0 0 0>;
+				ti,mbox-rx = <0 0 3>;
+			};

This may have been copied from AM335, so is incorrect. You are better off starting with one for DSP instead of above, below are taken from the corresponding SysLink release associated with above PSP release

			mbox_dsp: mbox_dsp {
				ti,mbox-tx = <3 0 0>;
				ti,mbox-rx = <0 0 0>;
			};

For reference, the devices I've confirmed to work so far are:

- intc
- timers
- gpmc
- i2c
- ethernet and mdio
- mmc
- edma
- uart

Updated patch below with the mailbox fixed.

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

Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx

+#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)

Quoted 1 line · Tony Lindgren

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.

Quoted 3 lines

+#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

Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] bits for MUXMODE instead of just bits [2:0]?

Quoted 2 lines

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 :)

Quoted 2 lines

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?

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.

Quoted 2 lines · Tony Lindgren

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 ;-)

Quoted 1 line

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).

Quoted 4 lines

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 instead of omap4's weird custom "Tesla" DSP (although some Tesla documentation accidentally got copy-pasted into Netra's TRM). An overview of the video situation on Centaurus (afaik, I'm not deeply into the video stuff) can be found in this post, where I was also cheerleading your efforts towards mainline dm81xx support:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/246653/1396681#1396681

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. It is about as well-documented as the crypto accelerators on the am335x are :P Still, it's not hard to get it operational, and allows e.g. sequencing of composite crypto operations combined with DMA without the kernel having to micro-manage it, along with secure local key storage.

Once the basics work there's definitely some neat gear on these chips to play with

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?

Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that the registers are different.

Quoted 5 lines

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..

Quoted 2 lines · Tony Lindgren

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.)

Quoted 2 lines

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)

Quoted 6 lines

Quoted 5 lines

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.

Quoted 1 line

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.

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.

Quoted 5 lines

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

Quoted 3 lines · Tony Lindgren

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)

Quoted 9 lines

Quoted 5 lines

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.

See earlier I was assuming copy paste issues from dm814x to 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.

Quoted 3 lines

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?

Quoted 1 line · Tony Lindgren

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.

Quoted 2 lines

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.

Quoted 6 lines · Matthijs van Duin

Quoted 2 lines · Tony Lindgren

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.

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.

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)

Quoted 9 lines · Matthijs van Duin

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.

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?

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?

Quoted 2 lines

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.

Quoted 1 line

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:

44000000 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

44400000 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

44800000 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).

Quoted 5 lines

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.

Quoted 1 line

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 counter-example since for some odd reason its DMM Target NIUs regs moved to the L3M service network, even though they attach to the L3F and report errors to the L3F flagmux.

Distinguishing the top flagmux from the others, or even more general flagmux topologies, can also be deduced programmatically but I'm not sure that's worth the effort.

The target which seems to be reachable at many many address ranges, none of which documented as containing any peripheral, is your "error target" where unroutable packets are sent to to generate an error reply.

5. Reenable all target NIUs.

6. Identify the L3 targets. This will be semi-automatic at best, since there's no generally reliable way to do this. Not all peripherals have a highlander-style revision register, and even the ones that do sometimes have it at a non-zero offset or failed to pick a unique function code to identify the module. (Or split it into two 16-bit halves in consecutive 32-bit registers... nicely done, omap-i2c)

One interesting option is keeping a database of L3 targets across multiple devices and taking advantage of design reuse: if you find a target whose NIU ID and mapped memory ranges match those of a specific target in another device, then there's a good chance they are in fact the same. This is highly visible in centaurus vs subarctic for example.

7. Some targets will be other interconnects; proceed with inspecting those. (Fortunately the L4 intercons are easier to scan).

Matthijs van Duin <[email protected]> wrote:
44400500 target 11 vcp
44800100 target 18 vlynq ?

Oh there's a gap here and it goes all the way to 2400.. Is there a gap on am335x too?

Quoted 4 lines

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.

OK the driver would have to be enabled with interrupts while scanning.