| Message ID | 20150117164709.GS18552@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 17 January 2015 at 17:47, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 09:54]: > On 17 January 2015 at 17:47, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17 January 2015 at 19:14, Tony Lindgren <tony@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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 14:41]: > On 17 January 2015 at 19:14, Tony Lindgren <tony@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 > 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 Yeah all the add on devices are a whole different project.. But if we get the basics working then at least somebody can work on that if they want to. > 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. Hmm that's a lot of accelerators.. > Once the basics work there's definitely some neat gear on these chips > to play with Yup :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 19 January 2015 at 18:29, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@gmail.com> [150121 19:20]: > On 19 January 2015 at 18:29, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 January 2015 at 17:47, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@gmail.com> [150125 00:37]: > On 23 January 2015 at 17:47, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26 January 2015 at 16:58, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Matthijs van Duin <matthijsvanduin@gmail.com> [150128 13:46]: > On 26 January 2015 at 16:58, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2 February 2015 at 18:44, Tony Lindgren <tony@atomide.com> wrote: > * Matthijs van Duin <matthijsvanduin@gmail.com> [150128 13:46]: >> On 26 January 2015 at 16:58, Tony Lindgren <tony@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- 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 0000000..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 = <0x80000000 0x40000000 /* 1 GB */ + 0xc0000000 0x40000000>; /* 1 GB */ + }; + + /* FDC6331L controlled by SD_POW pin */ + vmmcsd_fixed: fixedregulator@0 { + compatible = "regulator-fixed"; + regulator-name = "vmmcsd_fixed"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; +}; + +&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 0x04000000 0x01000000>; /* 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 0x80000>; + }; + partition@0x80000 { + label = "U-Boot"; + reg = <0x80000 0x1c0000>; + }; + partition@0x1c0000 { + label = "Environment"; + reg = <0x240000 0x40000>; + }; + partition@0x280000 { + label = "Kernel"; + reg = <0x280000 0x500000>; + }; + partition@0x780000 { + label = "Filesystem"; + reg = <0x780000 0xf880000>; + }; + }; +}; + +&mcspi1 { + pinctrl-names = "default"; + pinctrl-0 = <&mcspi1_pins>; + + m25p80@0 { + compatible = "w25x32"; + spi-max-frequency = <48000000>; + reg = <0>; + #address-cells = <1>; + #size-cells = <1>; + }; +}; + +&mmc1 { + vmmc-supply = <&vmmcsd_fixed>; +}; --- a/include/dt-bindings/pinctrl/omap.h +++ b/include/dt-bindings/pinctrl/omap.h @@ -61,6 +61,7 @@ #define OMAP3430_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25d8) (val) #define OMAP3630_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25a0) (val) #define OMAP3_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2a00) (val) +#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) #define DRA7XX_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x3400) (val)