linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: "Michal Simek" <michal.simek@xilinx.com>,
	"Vesa Jääskeläinen" <dachaac@gmail.com>,
	robh+dt@kernel.org, mark.rutland@arm.com,
	devicetree@vger.kernel.org
Cc: m.tretter@pengutronix.de, nava.manne@xilinx.com,
	rajan.vaja@xilinx.com, manish.narani@xilinx.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] devicetree: zynqmp.dtsi: Add bootmode selection support
Date: Thu, 20 Feb 2020 09:01:02 +0100	[thread overview]
Message-ID: <a4fa4009-8d1e-1e5c-2b5c-0f9f1209e78d@topic.nl> (raw)
In-Reply-To: <f2592ed7-9f1b-9a23-a6bd-ed8773a7873e@xilinx.com>

On 20-02-2020 08:01, Michal Simek wrote:
> On 20. 02. 20 7:56, Mike Looijmans wrote:
>> On 19-02-2020 19:23, Vesa Jääskeläinen wrote:
>>> Hi Mike,
>>>
>>> On 19.2.2020 14.20, Mike Looijmans wrote:
>>>> Add bootmode override support for ZynqMP devices. Allows one to select
>>>> a boot device by running "reboot qspi32" for example. Activate config
>>>> item CONFIG_SYSCON_REBOOT_MODE to make this work.
>>>>
>>>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>>>> ---
>>>>    arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++++++++++++++++++++++++
>>>>    1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> index 26d926eb1431..4c38d77ecbba 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> @@ -246,6 +246,30 @@
>>>>                };
>>>>            };
>>>> +        /* Clock and Reset control registers for LPD */
>>>> +        lpd_apb: apb@ff5e0000 {
>>>> +            compatible = "syscon", "simple-mfd";
>>>> +            reg = <0x0 0xff5e0000 0x0 0x400>;
>>>> +            reboot-mode {
>>>> +                compatible = "syscon-reboot-mode";
>>>> +                offset = <0x200>;
>>>> +                mask = <0xf100>;
>>>> +                /* Bit(8) is the "force user" bit */
>>>> +                mode-normal = <0x0000>;
>>>> +                mode-psjtag = <0x0100>;
>>>> +                mode-qspi24 = <0x1100>;
>>>> +                mode-qspi32 = <0x2100>;
>>>> +                mode-sd0    = <0x3100>;
>>>> +                mode-nand   = <0x4100>;
>>>> +                mode-sd1    = <0x6100>;
>>>> +                mode-emmc   = <0x6100>;
>>>> +                mode-usb0   = <0x7100>;
>>>> +                mode-pjtag0 = <0x8100>;
>>>> +                mode-pjtag1 = <0x9100>;
>>>> +                mode-sd1ls  = <0xe100>;
>>>
>>> This kinda looks a bit misuse of reboot mode support.
>>>
>>> Usually you are signal with reboot-mode that you want to do factory
>>> reset, enter recovery mode or such things.
>>>
>>> Now this signaling here is telling that this is used for selecting
>>> from what device to boot from.
>>
>> On the ZynqMP this is the only way to communicate with the ROM.
>>
>>> Another problem is that this now modifies all Xilinx Zynq MPSoCs which
>>> is kinda wrong. This behavior should really be product/board specific
>>> and not common for all boards -- undoing this in product/board is
>>> somewhat cumbersome.
>>
>> The boot mode setting is in the SOC, and is not board specific. The ROM
>> interprets this field. The only board specific thing is that you may not
>> actually have a NAND chip attached to it.
>>
>> My idea was that a board could easily add say 'mode-recovery=<0x2100>;'
>> to make the QPSI boot the method of recovery. The bootloader also has
>> access to this register, so it can see that there was a boot mode
>> override in effect.
>>
>>> Now this change hijacks the "reboot <arg>" with this behavior which is
>>> not so nice.
>>
>> If anyone has a better suggestion as to where this should go, I'd be
>> more than happy to hear about it. It's the only interface that I could
>> find in the kernel to attach a bootmode override to.
> 
> IIRC as the part of PSCI 1.1 spec is SYSTEM_RESET2 where you can device
> reset_type. IIRC that 0 as warm reset was coming based on discussion
> with Xilinx (and maybe others) and I think this is what Xilinx is still
> using. But didn't track it if that was really implemented or not.

I checked the arm-trusted-firmware code, there's no Xilinx vendor specific 
implementation of SYSTEM_RESET2 today, so it will only do a generic warm 
reboot and nothing else.

I'll move the patch to our BSP, we need the functionality for software 
update/recovery mechanisms.



      reply	other threads:[~2020-02-20  8:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 12:20 [PATCH] devicetree: zynqmp.dtsi: Add bootmode selection support Mike Looijmans
2020-02-19 18:23 ` Vesa Jääskeläinen
2020-02-20  6:49   ` Michal Simek
2020-02-20  6:56   ` Mike Looijmans
2020-02-20  7:01     ` Michal Simek
2020-02-20  8:01       ` Mike Looijmans [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4fa4009-8d1e-1e5c-2b5c-0f9f1209e78d@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=dachaac@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=manish.narani@xilinx.com \
    --cc=mark.rutland@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=nava.manne@xilinx.com \
    --cc=rajan.vaja@xilinx.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).