> 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:
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).
> 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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
