From: Quentin Schulz <quentin.schulz@cherry.de>
To: Andre Przywara <andre.przywara@arm.com>,
Jagan Teki <jagan@amarulasolutions.com>,
u-boot@lists.denx.de
Cc: Yixun Lan <dlan@gentoo.org>, Tom Rini <trini@konsulko.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v2 2/3] sunxi: add "fake" FEL pin support
Date: Fri, 18 Apr 2025 13:28:23 +0200 [thread overview]
Message-ID: <b7ffc468-1970-4eba-85e1-47aaced0161a@cherry.de> (raw)
In-Reply-To: <20250417000539.3709-3-andre.przywara@arm.com>
Hi Andre,
On 4/17/25 2:05 AM, Andre Przywara wrote:
> Some boards with Allwinner SoCs feature a "FEL" key, sometimes also
> labelled "uboot", which triggers the BootROM FEL mode, when pressed upon
> power-on or reset. This allows to access the SoC's memory via USB OTG,
> and to upload and execute code. There is a tool to upload our U-Boot image
> and immediately boot it, when the SoC is in FEL mode.
>
> To mimic this convenient behaviour on boards without such a dedicated key,
> we can query a GPIO pin very early in the SPL boot, then trigger the
> BootROM FEL routine. There has not been much of a SoC or board setup at
> this point, so we enter the BROM in a rather pristine state still. On
> 64-bit SoCs the required AArch32 reset guarantees a clean CPU state anyway.
>
> Any GPIO can be used for that, the signal is expected to be active low,
> consequently we enable the pull-up resistors for that pin. A board (or a
> user) is expected to specify the GPIO name using the
> CONFIG_SUNXI_FAKE_FEL_PIN Kconfig variable. When this variable is not set,
> the compiler will optimise away the call.
>
> Call the code first thing in board_init_f(), which is the first sunxi
> specific C routine.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm/mach-sunxi/Kconfig | 10 ++++++++++
> arch/arm/mach-sunxi/board.c | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index ab432390d3c..f1cfdb548bc 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -825,6 +825,16 @@ config USB3_VBUS_PIN
> ---help---
> See USB1_VBUS_PIN help text.
>
> +config SUNXI_FAKE_FEL_PIN
> + string "fake FEL GPIO pin"
> + default ""
> + ---help---
> + Define a GPIO that shall force entering FEL mode when a button
> + connected to this pin is pressed at boot time. This must be an
> + active low signal, the internal pull-up resistors are activated.
> + This takes a string in the format understood by sunxi_name_to_gpio,
> + e.g. PH1 for pin 1 of port H.
> +
Why not use the DT for that? Then you wouldn't even need to assume the
polarity of the signal or whether pull-up/downs need to be activated, etc.
You can have the property in the -u-boot.dtsi then if you want?
While the FEL button on the X96 is "fake", it does what it says, just in
software, maybe that is close enough to "hardware definition" which
would make it suitable for the DT (well, we also store binman nodes in
the DT, which aren't strictly speaking hardware definition either :) ).
Cheers,
Quentin
next prev parent reply other threads:[~2025-04-18 11:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 0:05 [PATCH v2 0/3] sunxi: add "fake" FEL button feature Andre Przywara
2025-04-17 0:05 ` [PATCH v2 1/3] sunxi: fix return_to_fel() prototype Andre Przywara
2025-04-17 0:05 ` [PATCH v2 2/3] sunxi: add "fake" FEL pin support Andre Przywara
2025-04-17 3:39 ` Yixun Lan
2025-04-17 4:08 ` Yixun Lan
2025-04-21 21:42 ` Andre Przywara
2025-04-18 11:28 ` Quentin Schulz [this message]
2025-04-18 22:51 ` Yixun Lan
2025-04-21 21:29 ` Andre Przywara
2025-04-22 10:49 ` Quentin Schulz
2025-04-22 12:11 ` Andre Przywara
2025-04-22 14:30 ` Quentin Schulz
2025-05-12 12:39 ` Andre Przywara
2025-05-15 15:13 ` Quentin Schulz
2025-04-17 0:05 ` [PATCH v2 3/3] sunxi: x96_mate: Add "fake" FEL key definition Andre Przywara
2025-04-17 4:10 ` [PATCH v2 0/3] sunxi: add "fake" FEL button feature Yixun Lan
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=b7ffc468-1970-4eba-85e1-47aaced0161a@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=andre.przywara@arm.com \
--cc=dlan@gentoo.org \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=samuel@sholland.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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