| Message ID | 20160112000917.GC12777@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Tony, Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>: > * Tony Lindgren <tony@atomide.com> [160111 12:27]: >> >> OK so the issue is that the twl msecure pin should be high to enable >> the RTC registers. We used to have that code with platform_data, but >> no longer have it with device tree based booting. I'll send a patch >> for that. >> >> Curiously setting jumper j5 on beagle-x15 that controls what used to >> be the msecure and now is powerhold, does the opposite.. The >> device boots automatically but RTC is stopped? > > And here's a fix the issue for omap5. Beagle-x15 needs to be > investigated more. > > Care to test it with your RTC enabling patch? yes, I will test asap. Reminds me on some issues we did have with msecure and twl4030 rtc some years ago. BR, Nikolaus > > Regards, > > Tony > > 8< --------------- > From: Tony Lindgren <tony@atomide.com> > Date: Mon, 11 Jan 2016 14:35:24 -0800 > Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes > > The palmas PMIC has some control lines that need to be muxed properly > for things to work. The sys_nirq pin is used for interrupts, and msecure > pin is used for enabling writes to some PMIC registers. > > Without these pins configured properly things can fail in mysterious > ways. For example, we can't update the RTC registers on palmas PMIC > unless the msecure pin is configured. And this is probably the reason > why we had RTC missing from the omap5 dts file. > > According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)" > swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to > configure it as a GPIO pin. > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- a/arch/arm/boot/dts/omap5-board-common.dtsi > +++ b/arch/arm/boot/dts/omap5-board-common.dtsi > @@ -213,6 +213,12 @@ > >; > }; > > + palmas_msecure_pins: palmas_msecure_pins { > + pinctrl-single,pins = < > + OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */ > + >; > + }; > + > usbhost_pins: pinmux_usbhost_pins { > pinctrl-single,pins = < > 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */ > @@ -278,6 +284,12 @@ > &usbhost_wkup_pins > >; > > + palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins { > + pinctrl-single,pins = < > + OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */ > + >; > + }; > + > usbhost_wkup_pins: pinmux_usbhost_wkup_pins { > pinctrl-single,pins = < > 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */ > @@ -345,6 +357,8 @@ > interrupt-controller; > #interrupt-cells = <2>; > ti,system-power-controller; > + pinctrl-names = "default"; > + pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>; > > extcon_usb3: palmas_usb { > compatible = "ti,palmas-usb-vid"; -- 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
Hi Tony, Am 12.01.2016 um 14:30 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > Hi Tony, > > Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>: > >> * Tony Lindgren <tony@atomide.com> [160111 12:27]: >>> >>> OK so the issue is that the twl msecure pin should be high to enable >>> the RTC registers. We used to have that code with platform_data, but >>> no longer have it with device tree based booting. I'll send a patch >>> for that. >>> >>> Curiously setting jumper j5 on beagle-x15 that controls what used to >>> be the msecure and now is powerhold, does the opposite.. The >>> device boots automatically but RTC is stopped? >> >> And here's a fix the issue for omap5. Beagle-x15 needs to be >> investigated more. >> >> Care to test it with your RTC enabling patch? > > yes, I will test asap. > > Reminds me on some issues we did have with msecure and twl4030 rtc some years ago. Ok, works for me on OMAP5432EVM. Thanks for spotting the issue. > > BR, > Nikolaus > >> >> Regards, >> >> Tony >> >> 8< --------------- >> From: Tony Lindgren <tony@atomide.com> >> Date: Mon, 11 Jan 2016 14:35:24 -0800 >> Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes >> >> The palmas PMIC has some control lines that need to be muxed properly >> for things to work. The sys_nirq pin is used for interrupts, and msecure >> pin is used for enabling writes to some PMIC registers. >> >> Without these pins configured properly things can fail in mysterious >> ways. For example, we can't update the RTC registers on palmas PMIC >> unless the msecure pin is configured. And this is probably the reason >> why we had RTC missing from the omap5 dts file. >> >> According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)" >> swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to >> configure it as a GPIO pin. >> >> Signed-off-by: Tony Lindgren <tony@atomide.com> >> >> --- a/arch/arm/boot/dts/omap5-board-common.dtsi >> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi >> @@ -213,6 +213,12 @@ >> >; >> }; >> >> + palmas_msecure_pins: palmas_msecure_pins { >> + pinctrl-single,pins = < >> + OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */ >> + >; >> + }; >> + >> usbhost_pins: pinmux_usbhost_pins { >> pinctrl-single,pins = < >> 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */ >> @@ -278,6 +284,12 @@ >> &usbhost_wkup_pins >> >; >> >> + palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins { >> + pinctrl-single,pins = < >> + OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */ >> + >; >> + }; >> + >> usbhost_wkup_pins: pinmux_usbhost_wkup_pins { >> pinctrl-single,pins = < >> 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */ >> @@ -345,6 +357,8 @@ >> interrupt-controller; >> #interrupt-cells = <2>; >> ti,system-power-controller; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>; >> >> extcon_usb3: palmas_usb { >> compatible = "ti,palmas-usb-vid"; > -- 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 01/12/2016 03:27 PM, H. Nikolaus Schaller wrote: > Hi Tony, > > Am 12.01.2016 um 14:30 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > >> Hi Tony, >> >> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>: >> >>> * Tony Lindgren <tony@atomide.com> [160111 12:27]: >>>> >>>> OK so the issue is that the twl msecure pin should be high to enable >>>> the RTC registers. We used to have that code with platform_data, but >>>> no longer have it with device tree based booting. I'll send a patch >>>> for that. >>>> >>>> Curiously setting jumper j5 on beagle-x15 that controls what used to >>>> be the msecure and now is powerhold, does the opposite.. The >>>> device boots automatically but RTC is stopped? >>> >>> And here's a fix the issue for omap5. Beagle-x15 needs to be >>> investigated more. >>> >>> Care to test it with your RTC enabling patch? >> >> yes, I will test asap. >> >> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago. > > Ok, works for me on OMAP5432EVM. > > Thanks for spotting the issue. > http://pastebin.ubuntu.com/14480852/ Works for me as well ( https://patchwork.kernel.org/patch/7954341/ + http://pastebin.ubuntu.com/14480852/)
* Nishanth Menon <nm@ti.com> [160112 13:38]: > On 01/12/2016 03:27 PM, H. Nikolaus Schaller wrote: > >> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>: > >>> Care to test it with your RTC enabling patch? > >> > >> yes, I will test asap. > >> > >> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago. > > > > Ok, works for me on OMAP5432EVM. > > > > Thanks for spotting the issue. OK thanks. > http://pastebin.ubuntu.com/14480852/ > Works for me as well ( https://patchwork.kernel.org/patch/7954341/ + > http://pastebin.ubuntu.com/14480852/) OK thanks for testing, will apply both to omap-for-v4.5/fixes to get RTC working on omap5. 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
Hi Tony, Am 12.01.2016 um 22:27 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > Hi Tony, > > Am 12.01.2016 um 14:30 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > >> Hi Tony, >> >> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>: >> >>> * Tony Lindgren <tony@atomide.com> [160111 12:27]: >>>> >>>> OK so the issue is that the twl msecure pin should be high to enable >>>> the RTC registers. We used to have that code with platform_data, but >>>> no longer have it with device tree based booting. I'll send a patch >>>> for that. >>>> >>>> Curiously setting jumper j5 on beagle-x15 that controls what used to >>>> be the msecure and now is powerhold, does the opposite.. The >>>> device boots automatically but RTC is stopped? >>> >>> And here's a fix the issue for omap5. Beagle-x15 needs to be >>> investigated more. >>> >>> Care to test it with your RTC enabling patch? >> >> yes, I will test asap. >> >> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago. > > Ok, works for me on OMAP5432EVM. Yes, it works, but I didn't look into the code yet. > > Thanks for spotting the issue. > >> >> BR, >> Nikolaus >> >>> >>> Regards, >>> >>> Tony >>> >>> 8< --------------- >>> From: Tony Lindgren <tony@atomide.com> >>> Date: Mon, 11 Jan 2016 14:35:24 -0800 >>> Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes >>> >>> The palmas PMIC has some control lines that need to be muxed properly >>> for things to work. The sys_nirq pin is used for interrupts, and msecure >>> pin is used for enabling writes to some PMIC registers. >>> >>> Without these pins configured properly things can fail in mysterious >>> ways. For example, we can't update the RTC registers on palmas PMIC >>> unless the msecure pin is configured. And this is probably the reason >>> why we had RTC missing from the omap5 dts file. >>> >>> According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)" >>> swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to >>> configure it as a GPIO pin. >>> >>> Signed-off-by: Tony Lindgren <tony@atomide.com> >>> >>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi >>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi >>> @@ -213,6 +213,12 @@ >>> >; >>> }; >>> >>> + palmas_msecure_pins: palmas_msecure_pins { >>> + pinctrl-single,pins = < >>> + OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */ I wonder now what MODE1 is. In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved". Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15? And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software). This one >>> OMAP5_IOPAD(0x180, PIN_INPUT _PULLUP | MUX_MODE6) /* gpio8_234 used for sys_drm_msecure */ works for me on the OMAP5 EVM as well. BR, Nikolaus >>> + >; >>> + }; >>> + >>> usbhost_pins: pinmux_usbhost_pins { >>> pinctrl-single,pins = < >>> 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */ >>> @@ -278,6 +284,12 @@ >>> &usbhost_wkup_pins >>> >; >>> >>> + palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins { >>> + pinctrl-single,pins = < >>> + OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */ >>> + >; >>> + }; >>> + >>> usbhost_wkup_pins: pinmux_usbhost_wkup_pins { >>> pinctrl-single,pins = < >>> 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */ >>> @@ -345,6 +357,8 @@ >>> interrupt-controller; >>> #interrupt-cells = <2>; >>> ti,system-power-controller; >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>; >>> >>> extcon_usb3: palmas_usb { >>> compatible = "ti,palmas-usb-vid"; >> > -- 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 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote: [...] >>>> >>>> Signed-off-by: Tony Lindgren <tony@atomide.com> >>>> >>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi >>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi >>>> @@ -213,6 +213,12 @@ >>>> >; >>>> }; >>>> >>>> + palmas_msecure_pins: palmas_msecure_pins { >>>> + pinctrl-single,pins = < >>>> + OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */ > > I wonder now what MODE1 is. > > In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved". > > Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15? > > And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software). Good catch. This one is interesting. If my memory serves me right, MSECURE signal from SoC is triggered in secure mode (trustzone) - the requirement was that certain PMIC modifications should only be done in secure mode for certain product applications. What this means is that certain functions of the PMIC will be unavailable when the SoC is running in "untrusted" mode. Instead, the usual mode of operation is to set it up as GPIO (as Nikolas pointed below) and either use GPIO HOG or default weak pull to keep it in the required state. I think it is better to set it as GPIO than as DRM_MSECURE. This is probably also the reason why this mode is NOT in public TRM - all security related topics are probably in the NDA only secure TRM addendum. I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we are not doing any HS OMAP5 at least in public domain :) ). > > This one > >>>> OMAP5_IOPAD(0x180, PIN_INPUT _PULLUP | MUX_MODE6) /* gpio8_234 used for sys_drm_msecure */ > > > works for me on the OMAP5 EVM as well. > [...]
On 01/13/2016 04:55 PM, Nishanth Menon wrote: > On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote: > [...] > >>>>> >>>>> Signed-off-by: Tony Lindgren <tony@atomide.com> >>>>> >>>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi >>>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi >>>>> @@ -213,6 +213,12 @@ >>>>> >; >>>>> }; >>>>> >>>>> + palmas_msecure_pins: palmas_msecure_pins { >>>>> + pinctrl-single,pins = < >>>>> + OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */ >> >> I wonder now what MODE1 is. >> >> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved". >> >> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15? >> >> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software). > > > Good catch. This one is interesting. If my memory serves me right, > MSECURE signal from SoC is triggered in secure mode (trustzone) - the > requirement was that certain PMIC modifications should only be done in > secure mode for certain product applications. What this means is that > certain functions of the PMIC will be unavailable when the SoC is > running in "untrusted" mode. > > Instead, the usual mode of operation is to set it up as GPIO (as Nikolas > pointed below) and either use GPIO HOG or default weak pull to keep it > in the required state. > > I think it is better to set it as GPIO than as DRM_MSECURE. > > This is probably also the reason why this mode is NOT in public TRM - > all security related topics are probably in the NDA only secure TRM > addendum. > > > I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we > are not doing any HS OMAP5 at least in public domain :) ). Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi) and, again if i remember correctly, someone reported that sys_drm_msecure might have different values on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality was always modeled using GPIO.
* Grygorii Strashko <grygorii.strashko@ti.com> [160113 07:15]: > On 01/13/2016 04:55 PM, Nishanth Menon wrote: > > On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote: > >> > >> I wonder now what MODE1 is. > >> > >> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved". > >> > >> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15? The 5430 data manual I listed in the commit states mode 1 is for msecure. It is unlikely it got changed for 5432 as the mux registers tend to stay the same for most part across a SoC generation with just devices being enabled or disabled. For beagle-x15, the msecure is now called "powerhold" and seems to have some additional or different functionality in the PMIC. So that's a separate issue from this one. > >> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software). > > > > Good catch. This one is interesting. If my memory serves me right, > > MSECURE signal from SoC is triggered in secure mode (trustzone) - the > > requirement was that certain PMIC modifications should only be done in > > secure mode for certain product applications. What this means is that > > certain functions of the PMIC will be unavailable when the SoC is > > running in "untrusted" mode. > > > > Instead, the usual mode of operation is to set it up as GPIO (as Nikolas > > pointed below) and either use GPIO HOG or default weak pull to keep it > > in the required state. > > > > I think it is better to set it as GPIO than as DRM_MSECURE. Well we do have the data manual saying it's the msecure pin, and we are muxing it to msecure for omap4 in twl6030_omap4.dtsi. And a TI commit has used msecure mode for GP omap5 evm at least here: https://gitlab.com/ubuntu-omap/u-boot-omap5/commit/dcc5279ffe880e874abb4d7f95302a34ab4968ca I've added Keerthy to Cc, maybe he knows how this should be handled in the long run? So if we start changing things to GPIO mode, we really need some further explanations and neeed to handle the GPIO pin properly in the TWL driver. And it should be done in a separate patch for all of the TWL SoCs. > > This is probably also the reason why this mode is NOT in public TRM - > > all security related topics are probably in the NDA only secure TRM > > addendum. Right, probably the msecure pin has been set reserved in the public TRM because of whatever NDA reasons there might be to not allow writes to RTC. > > I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we > > are not doing any HS OMAP5 at least in public domain :) ). > > Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi) > and, again if i remember correctly, someone reported that sys_drm_msecure might have different values > on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality > was always modeled using GPIO. Care to dig up some more information on that? I don't have anything against adding GPIO handling to the TWL driver so it can be optionally specified. But that's clearly a separate patch and should be done by somebody who knows more about the issue and has a test case needing the GPIO logic for this pin. 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 01/13/2016 06:48 PM, Tony Lindgren wrote: > * Grygorii Strashko <grygorii.strashko@ti.com> [160113 07:15]: >> On 01/13/2016 04:55 PM, Nishanth Menon wrote: >>> On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote: >>>> >>>> I wonder now what MODE1 is. >>>> >>>> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved". >>>> >>>> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15? > > The 5430 data manual I listed in the commit states mode 1 is for > msecure. It is unlikely it got changed for 5432 as the mux registers > tend to stay the same for most part across a SoC generation with just > devices being enabled or disabled. > > For beagle-x15, the msecure is now called "powerhold" and seems to > have some additional or different functionality in the PMIC. So > that's a separate issue from this one. > >>>> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software). >>>http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208 >>> Good catch. This one is interesting. If my memory serves me right, >>> MSECURE signal from SoC is triggered in secure mode (trustzone) - the >>> requirement was that certain PMIC modifications should only be done in >>> secure mode for certain product applications. What this means is that >>> certain functions of the PMIC will be unavailable when the SoC is >>> running in "untrusted" mode. >>> >>> Instead, the usual mode of operation is to set it up as GPIO (as Nikolas >>> pointed below) and either use GPIO HOG or default weak pull to keep it >>> in the required state. >>> >>> I think it is better to set it as GPIO than as DRM_MSECURE. > > Well we do have the data manual saying it's the msecure pin, and > we are muxing it to msecure for omap4 in twl6030_omap4.dtsi. And a > TI commit has used msecure mode for GP omap5 evm at least here: > > https://gitlab.com/ubuntu-omap/u-boot-omap5/commit/dcc5279ffe880e874abb4d7f95302a34ab4968ca > > I've added Keerthy to Cc, maybe he knows how this should be handled > in the long run? > > So if we start changing things to GPIO mode, we really need some > further explanations and neeed to handle the GPIO pin properly in > the TWL driver. And it should be done in a separate patch for all > of the TWL SoCs. > >>> This is probably also the reason why this mode is NOT in public TRM - >>> all security related topics are probably in the NDA only secure TRM >>> addendum. > > Right, probably the msecure pin has been set reserved in the public TRM > because of whatever NDA reasons there might be to not allow writes to RTC. > >>> I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we >>> are not doing any HS OMAP5 at least in public domain :) ). >> >> Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi) >> and, again if i remember correctly, someone reported that sys_drm_msecure might have different values >> on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality >> was always modeled using GPIO. > > Care to dig up some more information on that? i can't find this report, sry - as i remember there was difference between some OMAP4 HS and GP SoCs. But links on commits for old 3.4 kernel below: http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208 http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a > > I don't have anything against adding GPIO handling to the TWL driver > so it can be optionally specified. But that's clearly a separate patch > and should be done by somebody who knows more about the issue and has > a test case needing the GPIO logic for this pin. >
On 01/13/2016 10:48 AM, Tony Lindgren wrote: > * Grygorii Strashko <grygorii.strashko@ti.com> [160113 07:15]: >> On 01/13/2016 04:55 PM, Nishanth Menon wrote: >>> On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote: >>>> >>>> I wonder now what MODE1 is. >>>> >>>> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved". >>>> >>>> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15? > > The 5430 data manual I listed in the commit states mode 1 is for > msecure. It is unlikely it got changed for 5432 as the mux registers > tend to stay the same for most part across a SoC generation with just > devices being enabled or disabled. Again - it depends on NDA or non-NDA version of the TRM being refered to. > > For beagle-x15, the msecure is now called "powerhold" and seems to > have some additional or different functionality in the PMIC. So > that's a separate issue from this one. powerhold is NOT the same as msecure. the PMICs for X15 and O5, though they share the same pedigree, are NOT the same. there are distinct changes done in both PMIC definition, functionality and markets being targeted by the PMIC. > >>>> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software). >>> >>> Good catch. This one is interesting. If my memory serves me right, >>> MSECURE signal from SoC is triggered in secure mode (trustzone) - the >>> requirement was that certain PMIC modifications should only be done in >>> secure mode for certain product applications. What this means is that >>> certain functions of the PMIC will be unavailable when the SoC is >>> running in "untrusted" mode. >>> >>> Instead, the usual mode of operation is to set it up as GPIO (as Nikolas >>> pointed below) and either use GPIO HOG or default weak pull to keep it >>> in the required state. >>> >>> I think it is better to set it as GPIO than as DRM_MSECURE. > > Well we do have the data manual saying it's the msecure pin, and > we are muxing it to msecure for omap4 in twl6030_omap4.dtsi. And a > TI commit has used msecure mode for GP omap5 evm at least here: > > https://gitlab.com/ubuntu-omap/u-boot-omap5/commit/dcc5279ffe880e874abb4d7f95302a34ab4968ca We used to have High security devices previously (before those got scrapped). > > I've added Keerthy to Cc, maybe he knows how this should be handled > in the long run? > > So if we start changing things to GPIO mode, we really need some > further explanations and neeed to handle the GPIO pin properly in > the TWL driver. And it should be done in a separate patch for all > of the TWL SoCs. That does not make sense to me. The original intent of MSECURE is to use PMIC control (in specific certain usecases - which are no longer relevant) in trustzone or equivalent secure processor modes. when such a mode is not planned on being used, you just tell PMIC that it is always in secure mode. In fact, there was discussion internally that MSECURE should never even have been connected to SoC if the SoC was GP SoC - but ofcourse, the want to have a consistent reference schematics for evms (since EVMs have HS/Non-HS parts) trumped such talk. trying to split this up into further steps adds 0 additional functionality - what is the pmic driver supposed to do with the GPIO even? in *real* HS product devices, in fact, the register space is really firewalled out > >>> This is probably also the reason why this mode is NOT in public TRM - >>> all security related topics are probably in the NDA only secure TRM >>> addendum. > > Right, probably the msecure pin has been set reserved in the public TRM > because of whatever NDA reasons there might be to not allow writes to RTC. > Unfortunately, the norm inside TI, anything that remotely sounds "secure" gets wrapped up in NDA and triple signed blah blah.. I cant explain the rationale for why such a definition came on RTC. >>> I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we >>> are not doing any HS OMAP5 at least in public domain :) ). >> >> Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi) >> and, again if i remember correctly, someone reported that sys_drm_msecure might have different values >> on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality >> was always modeled using GPIO. > > Care to dig up some more information on that? The last TI product kernel tree that seriously focussed on OMAP5/OMAP4 was http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 things changed definitions (in terms of descope) since then.. but anyways.. thought I'd just pitch it out here. sevm: - this board got scrapped http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097 omap5-panda is the omap5uevm/evm now: http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816 > > I don't have anything against adding GPIO handling to the TWL driver > so it can be optionally specified. But that's clearly a separate patch TWL/TPS driver will need no change in the proposal I made with "gpio hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt - gpio-hog property) - just a dt change for the right configuration. > and should be done by somebody who knows more about the issue and has > a test case needing the GPIO logic for this pin. > Since my explanation does not seem to suffice, alright - we can wait for the right person, then.
On 01/13/2016 11:12 AM, Grygorii Strashko wrote: > On 01/13/2016 06:48 PM, Tony Lindgren wrote: [...] >> Care to dig up some more information on that? > > i can't find this report, sry - as i remember there was difference > between some OMAP4 HS and GP SoCs. > > But links on commits for old 3.4 kernel below: > http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208 > http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a > >> >> I don't have anything against adding GPIO handling to the TWL driver >> so it can be optionally specified. But that's clearly a separate patch >> and should be done by somebody who knows more about the issue and has >> a test case needing the GPIO logic for this pin. >> > > if it helps in anyways http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170707.html
* Nishanth Menon <nm@ti.com> [160113 09:30]: > On 01/13/2016 10:48 AM, Tony Lindgren wrote: > > > > So if we start changing things to GPIO mode, we really need some > > further explanations and neeed to handle the GPIO pin properly in > > the TWL driver. And it should be done in a separate patch for all > > of the TWL SoCs. > > That does not make sense to me. The original intent of MSECURE is to use > PMIC control (in specific certain usecases - which are no longer > relevant) in trustzone or equivalent secure processor modes. when such a > mode is not planned on being used, you just tell PMIC that it is always > in secure mode. In fact, there was discussion internally that MSECURE > should never even have been connected to SoC if the SoC was GP SoC - but > ofcourse, the want to have a consistent reference schematics for evms > (since EVMs have HS/Non-HS parts) trumped such talk. > > trying to split this up into further steps adds 0 additional > functionality - what is the pmic driver supposed to do with the GPIO even? > > in *real* HS product devices, in fact, the register space is really > firewalled out Right, OK here we are finally getting some answers to the "why" part :) And I also have few more "why" question in mind. If this change from msecure to GPIO muxing is so important. Why it was never fixed in the mainline kernel for omap4 and omap5 and it was just sitting in various TI trees? And it sounds like any kind of muxing on HS devices here for this pin will oops the device? > The last TI product kernel tree that seriously focussed on OMAP5/OMAP4 > was > http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 > things changed definitions (in terms of descope) since then.. but > anyways.. thought I'd just pitch it out here. > > sevm: - this board got scrapped > http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097 > > omap5-panda is the omap5uevm/evm now: > http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816 OK > > I don't have anything against adding GPIO handling to the TWL driver > > so it can be optionally specified. But that's clearly a separate patch > > TWL/TPS driver will need no change in the proposal I made with "gpio > hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt - > gpio-hog property) - just a dt change for the right configuration. OK. So are we sure the TWL driver will never have to toggle this pin? Again, that's another "why" that I have no clue about and that is not documented anywhere. > > and should be done by somebody who knows more about the issue and has > > a test case needing the GPIO logic for this pin. > > Since my explanation does not seem to suffice, alright - we can wait for > the right person, then. Sorry don't take it personally. I'm just trying to make sense of the "why do we need to do this change?" part. Especially if I need to make the change and write the commit log. 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
Am 13.01.2016 um 18:38 schrieb Nishanth Menon <nm@ti.com>: > On 01/13/2016 11:12 AM, Grygorii Strashko wrote: >> On 01/13/2016 06:48 PM, Tony Lindgren wrote: > > [...] > >>> Care to dig up some more information on that? >> >> i can't find this report, sry - as i remember there was difference >> between some OMAP4 HS and GP SoCs. >> >> But links on commits for old 3.4 kernel below: >> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208 >> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a >> >>> >>> I don't have anything against adding GPIO handling to the TWL driver >>> so it can be optionally specified. But that's clearly a separate patch >>> and should be done by somebody who knows more about the issue and has >>> a test case needing the GPIO logic for this pin. >>> >> >> > if it helps in anyways > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170707.html >> Yes, the TRM has some mode bits marked as reserved, but that doesn't >> mean they don't work. It just means the documentation is squirreled >> away in the secure TRM addendum. Ok, now I understand why the "reserved" MUX_MODE1 could still be correct for OMAP5. And that I just have a "squirreled away" version of the TRM which made me wonder what is going on. From this discussion I read that for X15 there is a different PMIC (Palmas derived, but not a twl6037) so that it needs something different. So my proposal would be to keep the MUX_MODE1 (because it works on OMAP5+TWL6037) as proposed by Tony. Maybe after adding a comment that MUX_MODE1 is a weakly documented feature. And the X15 board can "patch" it after using the omap5-board-common.dtsi to whatever it needs to fix it. BR, Nikolaus -- 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
Am 13.01.2016 um 19:00 schrieb Tony Lindgren <tony@atomide.com>: > * Nishanth Menon <nm@ti.com> [160113 09:30]: >> On 01/13/2016 10:48 AM, Tony Lindgren wrote: >>> >>> So if we start changing things to GPIO mode, we really need some >>> further explanations and neeed to handle the GPIO pin properly in >>> the TWL driver. And it should be done in a separate patch for all >>> of the TWL SoCs. >> >> That does not make sense to me. The original intent of MSECURE is to use >> PMIC control (in specific certain usecases - which are no longer >> relevant) in trustzone or equivalent secure processor modes. when such a >> mode is not planned on being used, you just tell PMIC that it is always >> in secure mode. In fact, there was discussion internally that MSECURE >> should never even have been connected to SoC if the SoC was GP SoC - but >> ofcourse, the want to have a consistent reference schematics for evms >> (since EVMs have HS/Non-HS parts) trumped such talk. >> >> trying to split this up into further steps adds 0 additional >> functionality - what is the pmic driver supposed to do with the GPIO even? >> >> in *real* HS product devices, in fact, the register space is really >> firewalled out > > Right, OK here we are finally getting some answers to the "why" part :) > > And I also have few more "why" question in mind. If this change from > msecure to GPIO muxing is so important. > > Why it was never fixed in the mainline kernel for omap4 and omap5 and > it was just sitting in various TI trees? > > And it sounds like any kind of muxing on HS devices here for this > pin will oops the device? > >> The last TI product kernel tree that seriously focussed on OMAP5/OMAP4 >> was >> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 >> things changed definitions (in terms of descope) since then.. but >> anyways.. thought I'd just pitch it out here. >> >> sevm: - this board got scrapped >> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097 >> >> omap5-panda is the omap5uevm/evm now: >> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816 > > OK > >>> I don't have anything against adding GPIO handling to the TWL driver >>> so it can be optionally specified. But that's clearly a separate patch >> >> TWL/TPS driver will need no change in the proposal I made with "gpio >> hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt - >> gpio-hog property) - just a dt change for the right configuration. > > OK. So are we sure the TWL driver will never have to toggle this pin? After studying the Palmas TRM it appears that this pin just should be "high" to be able to write to RTC and some scratchpad register. If the Palmas OTP is programmed to use gpio7 as msecure input. Since the scratchpad is not used we can permanently enable msecure. Which means that we must somehow get the driving output to be "1". This can be either done by * a gpio with pull-up - switched to input mode as I proposed, or * a real gpio output which is actively set to value 1 in u-boot or kernel driver, or * the not well documented feature of MUX_MODE1 (OMAP5), other MUX_MODEs for OMAP3/4. For my application we do not need to change the msecure state. We just need to be able to write the rtc. And since the gpio7 of the Palmas is connected to gpio8_234 of the OMAP5 we just have to initialize it properly once. BR, Nikolaus -- 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 01/13/2016 12:00 PM, Tony Lindgren wrote: > * Nishanth Menon <nm@ti.com> [160113 09:30]: >> On 01/13/2016 10:48 AM, Tony Lindgren wrote: >>> >>> So if we start changing things to GPIO mode, we really need some >>> further explanations and neeed to handle the GPIO pin properly in >>> the TWL driver. And it should be done in a separate patch for all >>> of the TWL SoCs. >> >> That does not make sense to me. The original intent of MSECURE is to use >> PMIC control (in specific certain usecases - which are no longer >> relevant) in trustzone or equivalent secure processor modes. when such a >> mode is not planned on being used, you just tell PMIC that it is always >> in secure mode. In fact, there was discussion internally that MSECURE >> should never even have been connected to SoC if the SoC was GP SoC - but >> ofcourse, the want to have a consistent reference schematics for evms >> (since EVMs have HS/Non-HS parts) trumped such talk. >> >> trying to split this up into further steps adds 0 additional >> functionality - what is the pmic driver supposed to do with the GPIO even? >> >> in *real* HS product devices, in fact, the register space is really >> firewalled out > > Right, OK here we are finally getting some answers to the "why" part :) > > And I also have few more "why" question in mind. If this change from > msecure to GPIO muxing is so important. > > Why it was never fixed in the mainline kernel for omap4 and omap5 and > it was just sitting in various TI trees? > > And it sounds like any kind of muxing on HS devices here for this > pin will oops the device? > It depends on what the secure firewall does - unfortunately HS devices are basically lego blocks that way. In the original usecase where specific function like MSECURE was desired, the 4k chunk for padconf registers would be firewalled away and only setup for access from trustzone or a specific "trusted" processor like IPU M3/DSP. >> The last TI product kernel tree that seriously focussed on OMAP5/OMAP4 >> was >> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 >> things changed definitions (in terms of descope) since then.. but >> anyways.. thought I'd just pitch it out here. >> >> sevm: - this board got scrapped >> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097 >> >> omap5-panda is the omap5uevm/evm now: >> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816 > > OK > >>> I don't have anything against adding GPIO handling to the TWL driver >>> so it can be optionally specified. But that's clearly a separate patch >> >> TWL/TPS driver will need no change in the proposal I made with "gpio >> hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt - >> gpio-hog property) - just a dt change for the right configuration. > > OK. So are we sure the TWL driver will never have to toggle this pin? > > Again, that's another "why" that I have no clue about and that is not > documented anywhere. > It is not necessary for the functions we just described -MSECURE function by itself is not something to be controlled by "non secure" software (which is probably weird to us, but that is what security team folks call HLOS like Linux). I dont recollect any recent product that actually uses MSECURE the way we originally defined it. For the sake of debate, Lets take a theoretical case where such a function might be desired: in such a case, "non-secure" software should generate an SMC service call into secure world for "setting RTC time"; When ARM enters trustzone mode, MSECURE will be auto asserted by SoC. the secure firmware will then have an I2C driver that will send a RTC set time register access for the RTC time to be set. In the above definition, we should not even have an TWL RTC driver, instead a custom TWL-SMC-RTC driver will need to be written that will access RTC on TWL/TPS over SMC calls to secure service. infact, if DSP was desired for the "secure access", then a DSP-RPROC-RTC driver will have to be written. The "generic definition" then became "MSECURE" and was envisaged to protect further stuff eventually beyond RTC(I dont recollect more than RTC unfortunately). In all such cases, you'd not use MSECURE in GPIO mode - that will just defeat it's original purpose. Instead you'd set it up as MSECURE in secure boot software(even before HLOS starts), then firewall the region off from access by non-secure software, finally write a shim driver to send non-secure requests to the secure world - which will determine who of the actors can actually do which actions.. As you already see it is ridiculously round about way of protecting RTC time.. but anyways, for what ever reason, that was mandatory function to support on certain product lines. I hope this helps. >>> and should be done by somebody who knows more about the issue and has >>> a test case needing the GPIO logic for this pin. >> >> Since my explanation does not seem to suffice, alright - we can wait for >> the right person, then. > > Sorry don't take it personally. I'm just trying to make sense of the > "why do we need to do this change?" part. Especially if I need to make > the change and write the commit log. Not a problem, just trying to share what I can given that not all thought process and background work that takes place inside TI is either "logical" or in many cases fails to reach public documentation :( .
On 01/13/2016 12:00 PM, H. Nikolaus Schaller wrote: [...] > And the X15 board can "patch" it after using the omap5-board-common.dtsi > to whatever it needs to fix it. > There is nothing to patch on X15[1]. there is no MSECURE pin on X15. there are three RTCs on X15: MCP, TPS and DRA7-RTC. TPS has no use for RTC, in fact has no capability of having a backup battery - which pretty much (at least IMHO) removes real world use of TPS as a RTC in a non-networked world.. but anyways, lets keep X15 and uevm seperate - they dont share much in this context. [1] https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf
On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: [...] >> OK. So are we sure the TWL driver will never have to toggle this pin? > > After studying the Palmas TRM it appears that this pin just should be "high" > to be able to write to RTC and some scratchpad register. If the Palmas OTP > is programmed to use gpio7 as msecure input. Thanks for digging it up. we dont use the scratchpad, but in some cases where SoC cold reset is involved, those registers may store additional information. > > Since the scratchpad is not used we can permanently enable msecure. Which > means that we must somehow get the driving output to be "1". > > This can be either done by > * a gpio with pull-up - switched to input mode as I proposed, or I think you intended to suggest to do a mux to gpio with just pinmux pull? The internal pull on padconf is very weak - for typical needs like these, it is rather suggested to stick with real GPIO drive to prevent conditions like noise interference(for example).
Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>: > On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: > [...] > >>> OK. So are we sure the TWL driver will never have to toggle this pin? >> >> After studying the Palmas TRM it appears that this pin just should be "high" >> to be able to write to RTC and some scratchpad register. If the Palmas OTP >> is programmed to use gpio7 as msecure input. > > Thanks for digging it up. we dont use the scratchpad, but in some cases > where SoC cold reset is involved, those registers may store additional > information. I remember a similar thing from omap3-twl4030 where the boot source is stored so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM is using that. > >> >> Since the scratchpad is not used we can permanently enable msecure. Which >> means that we must somehow get the driving output to be "1". >> >> This can be either done by >> * a gpio with pull-up - switched to input mode as I proposed, or > > I think you intended to suggest to do a mux to gpio with just pinmux > pull? Yes. > The internal pull on padconf is very weak > - for typical needs like > these, it is rather suggested to stick with real GPIO drive to prevent > conditions like noise interference(for example). well, on OMAP5 pull up/down are astonishingly strong :) 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic. So a noise source must be coupled by an impedance in the 1 kOhm range. This is quite rare. So I would not worry about that. But if there is MUX_MODE1 for this purpose that works equally well, we should use it instead of a gpin+pullup. BR, Nikolaus-- 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 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote: > > Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>: > >> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: >> [...] >> >>>> OK. So are we sure the TWL driver will never have to toggle this pin? >>> >>> After studying the Palmas TRM it appears that this pin just should be "high" >>> to be able to write to RTC and some scratchpad register. If the Palmas OTP >>> is programmed to use gpio7 as msecure input. >> >> Thanks for digging it up. we dont use the scratchpad, but in some cases >> where SoC cold reset is involved, those registers may store additional >> information. > > I remember a similar thing from omap3-twl4030 where the boot source is stored > so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM > is using that. > I believe that nonsense of OMAP ROM accessing PMIC stopped with OMAP3. I dont believe OMAP4 or any later generation processors does any PMIC access anymore - they instead make assumptions about specific voltage levels they will work on (So called OPP_BOOT) instead of assuming specific PMIC they will work with.. >>> Since the scratchpad is not used we can permanently enable msecure. Which >>> means that we must somehow get the driving output to be "1". >>> >>> This can be either done by >>> * a gpio with pull-up - switched to input mode as I proposed, or >> >> I think you intended to suggest to do a mux to gpio with just pinmux >> pull? > > Yes. > >> The internal pull on padconf is very weak >> - for typical needs like >> these, it is rather suggested to stick with real GPIO drive to prevent >> conditions like noise interference(for example). > > > well, on OMAP5 pull up/down are astonishingly strong :) > 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic. > So a noise source must be coupled by an impedance in the 1 kOhm range. > This is quite rare. So I would not worry about that. > Interesting. I did not know that, and have'nt dug at people to confirm that either :). An internal feedback I got some time back on AM57 (not OMAP5) - context was that we were discussing if an external pull up resistor was needed for a GPIO button: "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) and are good for avoiding higher leakage due to floating input level, and may not be sufficient for valid logic 1/0 depending on what else is connected on the board. If a signal must absolutely be pulled to a valid logic 1 or 0 for system functionality, then an external pull should be used." Anyways... will let Tony decide where he wants to go on this..
On 01/13/2016 09:05 PM, Nishanth Menon wrote: > On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote: >> >> Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>: >> >>> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: >>> [...] >>> >>>>> OK. So are we sure the TWL driver will never have to toggle this pin? >>>> >>>> After studying the Palmas TRM it appears that this pin just should be "high" >>>> to be able to write to RTC and some scratchpad register. If the Palmas OTP >>>> is programmed to use gpio7 as msecure input. >>> >>> Thanks for digging it up. we dont use the scratchpad, but in some cases >>> where SoC cold reset is involved, those registers may store additional >>> information. >> >> I remember a similar thing from omap3-twl4030 where the boot source is stored >> so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM >> is using that. >> > > I believe that nonsense of OMAP ROM accessing PMIC stopped with OMAP3. I > dont believe OMAP4 or any later generation processors does any PMIC > access anymore - they instead make assumptions about specific voltage > levels they will work on (So called OPP_BOOT) instead of assuming > specific PMIC they will work with.. > >>>> Since the scratchpad is not used we can permanently enable msecure. Which >>>> means that we must somehow get the driving output to be "1". >>>> >>>> This can be either done by >>>> * a gpio with pull-up - switched to input mode as I proposed, or >>> >>> I think you intended to suggest to do a mux to gpio with just pinmux >>> pull? >> >> Yes. >> >>> The internal pull on padconf is very weak >>> - for typical needs like >>> these, it is rather suggested to stick with real GPIO drive to prevent >>> conditions like noise interference(for example). >> >> >> well, on OMAP5 pull up/down are astonishingly strong :) >> 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic. >> So a noise source must be coupled by an impedance in the 1 kOhm range. >> This is quite rare. So I would not worry about that. >> > > Interesting. I did not know that, and have'nt dug at people to confirm > that either :). > > An internal feedback I got some time back on AM57 (not OMAP5) - context > was that we were discussing if an external pull up resistor was needed > for a GPIO button: > "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) > and are good for avoiding higher leakage due to floating input level, > and may not be sufficient for valid logic 1/0 depending on what else is > connected on the board. If a signal must absolutely be pulled to a > valid logic 1 or 0 for system functionality, then an external pull > should be used." MUX_MODE1(secure modes) is not working well as i mentioned. Here I agree with Nishanth - "gpio hog" mechanism looks like the best solution now, because of: - it exist now :P. At the moment when omap4/5 were fixed the pinmux solution was the simplest and fastest one, with not too many alternatives. - explicit gpio hog definition in DT will help other developer (and what is more important HW designers) to better understand that this gpio can be used as generic GPIO (at minimum without HW modification).
* Nishanth Menon <nm@ti.com> [160113 11:06]: > On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote: > > > > Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>: > > > >> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: > >>> Since the scratchpad is not used we can permanently enable msecure. Which > >>> means that we must somehow get the driving output to be "1". > >>> > >>> This can be either done by > >>> * a gpio with pull-up - switched to input mode as I proposed, or > >> > >> I think you intended to suggest to do a mux to gpio with just pinmux > >> pull? > > > > Yes. > > > >> The internal pull on padconf is very weak > >> - for typical needs like > >> these, it is rather suggested to stick with real GPIO drive to prevent > >> conditions like noise interference(for example). > > > > > > well, on OMAP5 pull up/down are astonishingly strong :) > > 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic. > > So a noise source must be coupled by an impedance in the 1 kOhm range. > > This is quite rare. So I would not worry about that. > > > > Interesting. I did not know that, and have'nt dug at people to confirm > that either :). > > An internal feedback I got some time back on AM57 (not OMAP5) - context > was that we were discussing if an external pull up resistor was needed > for a GPIO button: > "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) > and are good for avoiding higher leakage due to floating input level, > and may not be sufficient for valid logic 1/0 depending on what else is > connected on the board. If a signal must absolutely be pulled to a > valid logic 1 or 0 for system functionality, then an external pull > should be used." > > Anyways... will let Tony decide where he wants to go on this.. Eek now we have at least three options! Time for online vote: 1. Use msecure pinmux and let whatever mystery software control the pin completely out of our control like we've been doing with the mainline kernel for years. 2. Set up the msecure pin as GPIO output high unconditionally. This is what the TI android kernel tree seems to be doing. 3. New suggestion to use the SoC internal pull to keep the msecure pin high. This might be a little bit more power friendly than option #2 or #3. Maybe option #3 would save a little bit more power compared to options 1 and 2? Anyways, considering what's been discussed, after the minimal RTC fix we could also add code to allow the TWL driver optionally configure the GPIO. This way the TWL driver could also check the GPIO state in case some out-of-our-control mystery software goes tweak the msecure pin state. Or the RTC driver could just check that the bits really change after= writing them. Then we would at least know things are not working right for the TWL related RTC drivers. 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 01/13/2016 01:40 PM, Tony Lindgren wrote: > Anyways, considering what's been discussed, after the minimal RTC fix > we could also add code to allow the TWL driver optionally configure the > GPIO. This way the TWL driver could also check the GPIO state in case > some out-of-our-control mystery software goes tweak the msecure pin > state. I dont even know how that will work: If you are using MSECURE as it is intended to be, then you'd mux it to msecure, which means that GPIO read is just a waste of time - you dont even mux it to external world. Now, some SoCs like DRA7 has input lines always connected. even assuming this is for such a case: a) when you are running linux, you are already in nonsecure - it needs no read of MSECURE GPIO to figure that out. b) when you are in secure world, Linux wont be running either. Reading from GPIO is just misguided in my opinion. firewalls are not reconfigured, and muxes are usually done a single time. Or the RTC driver could just check that the bits really change > after= writing them. Then we would at least know things are not working > right for the TWL related RTC drivers. that is reasonable to check, but just a overhead - anyways, just isolated to palmas-rtc.. fail reason maynot always be issues with MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah - that might give a hint that there is an issue..
On Thursday 14 January 2016 04:02 AM, Nishanth Menon wrote: > On 01/13/2016 01:40 PM, Tony Lindgren wrote: > >> Anyways, considering what's been discussed, after the minimal RTC fix >> we could also add code to allow the TWL driver optionally configure the >> GPIO. This way the TWL driver could also check the GPIO state in case >> some out-of-our-control mystery software goes tweak the msecure pin >> state. > > I dont even know how that will work: > If you are using MSECURE as it is intended to be, then you'd mux it to > msecure, which means that GPIO read is just a waste of time - you dont > even mux it to external world. Now, some SoCs like DRA7 has input lines > always connected. even assuming this is for such a case: > a) when you are running linux, you are already in nonsecure - it needs > no read of MSECURE GPIO to figure that out. > b) when you are in secure world, Linux wont be running either. > > Reading from GPIO is just misguided in my opinion. firewalls are not > reconfigured, and muxes are usually done a single time. > > Or the RTC driver could just check that the bits really change >> after= writing them. Then we would at least know things are not working >> right for the TWL related RTC drivers. > > that is reasonable to check, but just a overhead - anyways, just > isolated to palmas-rtc.. fail reason maynot always be issues with > MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah - > that might give a hint that there is an issue.. > IIRC without configuring the mux mode of gpio234 to msecure mode we were unable to write to the rtc registers. Hence configured it one time at boot. -- 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 01/14/2016 04:01 AM, Keerthy wrote: > > > On Thursday 14 January 2016 04:02 AM, Nishanth Menon wrote: >> On 01/13/2016 01:40 PM, Tony Lindgren wrote: >> >>> Anyways, considering what's been discussed, after the minimal RTC fix >>> we could also add code to allow the TWL driver optionally configure the >>> GPIO. This way the TWL driver could also check the GPIO state in case >>> some out-of-our-control mystery software goes tweak the msecure pin >>> state. >> >> I dont even know how that will work: >> If you are using MSECURE as it is intended to be, then you'd mux it to >> msecure, which means that GPIO read is just a waste of time - you dont >> even mux it to external world. Now, some SoCs like DRA7 has input lines >> always connected. even assuming this is for such a case: >> a) when you are running linux, you are already in nonsecure - it needs >> no read of MSECURE GPIO to figure that out. >> b) when you are in secure world, Linux wont be running either. >> >> Reading from GPIO is just misguided in my opinion. firewalls are not >> reconfigured, and muxes are usually done a single time. >> >> Or the RTC driver could just check that the bits really change >>> after= writing them. Then we would at least know things are not working >>> right for the TWL related RTC drivers. >> >> that is reasonable to check, but just a overhead - anyways, just >> isolated to palmas-rtc.. fail reason maynot always be issues with >> MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah - >> that might give a hint that there is an issue.. >> > > IIRC without configuring the mux mode of gpio234 to msecure mode we were > unable to write to the rtc registers. Hence configured it one time at boot. > Looks like you missed the code section that shows that the u-boot configuration was overridden by kernel as GPIO for the very same reason.! http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816
On 13 January 2016 at 19:18, Nishanth Menon <nm@ti.com> wrote: > As you already see it is ridiculously round about way of protecting RTC > time.. but anyways, for what ever reason, that was mandatory function to > support on certain product lines. Having secure date/time is probably necessary for some digital rights management schemes; e.g. you rent a movie for limited time, but it may not always be acceptable to require working internet connectivity to be able to hit the play button hence the need to rely on a secure RTC. There wouldn't even be an SMC for setting the RTC, probably it would synchronize when the secure-world shizzle contacts the Big Server O'Secrety Bits. :P Protecting pinmux through the L4 firewall sounds hilarious: the whole ctrl_core module (0x4a002000 - 0x4a002fff) is a single firewall region. All permitted access to it by linux would have to be redirected to an SMC or similar. On 13 January 2016 at 20:05, Nishanth Menon <nm@ti.com> wrote: > An internal feedback I got some time back on AM57 (not OMAP5) - context > was that we were discussing if an external pull up resistor was needed > for a GPIO button: > "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) Unlike the OMAP5, AM57xx uses 1.8V/3.3V drivers for its generic IOs, which have to do magic to not get fried by such high voltages. Crappier specs result, especially for pulling up to 3.3V: 1.8V mode, pull-down current while pin is held high: 50-210 uA 3.3V mode, pull-down current while pin is held high: 40-200 uA 1.8V mode, pull-up current while pin is held low: 60-200 uA 3.3V mode, pull-up current while pin is held low: 10-290 uA Note the worst-case equivalent pull-up resistance in 3.3V mode is 330 kOhm, eleven times higher than in 1.8V mode. Matthijs -- 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/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -213,6 +213,12 @@ >; }; + palmas_msecure_pins: palmas_msecure_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */ + >; + }; + usbhost_pins: pinmux_usbhost_pins { pinctrl-single,pins = < 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */ @@ -278,6 +284,12 @@ &usbhost_wkup_pins >; + palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */ + >; + }; + usbhost_wkup_pins: pinmux_usbhost_wkup_pins { pinctrl-single,pins = < 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */ @@ -345,6 +357,8 @@ interrupt-controller; #interrupt-cells = <2>; ti,system-power-controller; + pinctrl-names = "default"; + pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>; extcon_usb3: palmas_usb { compatible = "ti,palmas-usb-vid";