Hi Andre and Yixun Lan,
On 4/21/25 11:29 PM, Andre Przywara wrote:
On Fri, 18 Apr 2025 13:28:23 +0200
Quentin Schulz <quentin.sch...@cherry.de> wrote:
Hi Quentin,
thanks for having a look!
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.przyw...@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.
As Yixun Lan already pointed out, the DT is not available at this
point, and doing several pull-ups to get this information from the DT
into the SPL image are really over the top for this purpose.
OK, we do have something "similar" for Rockchip boards, via the
sysreset-gpio DT property in /config, see
arch/arm/mach-rockchip/rk3399/rk3399.c and
arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi.
I guess something similar could be implemented IFF there's an actual DT
in SPL (or even TPL). We for sure have DT in SPL for most if not all
Rockchip devices, and probably in TPL as well. Hence why I sometimes
forget other Arm boards may not have DT in those stages :)
This is more a sweet hacker device: I often have devices with eMMC and
SPI flash, but without a FEL button. So the idea was to just pick a
GPIO and use menuconfig to set it. Then I could just connect this pin
to GND during boot, to get into FEL and test-boot firmware. "Connect to
GND" could really be a jumper or even the tip of a screwdriver ;-)
So I don't think this qualifies to being defined in the DT, really.
If I understood correctly, this GPIO is essentially not fixed, you just
pick a random one that you like and have access to and it may differ
depending on the user I guess?
Then yeah, I understand.
Can you please specify this in the commit log and also why we are not
going the DT route (if I read correctly, in addition to it not being
suitable for DT due to the ability to the function being available on
any unused GPIO, there's also no DT available in the stage when this
needs to be done?).
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
Yes, I have a patch to add this particular button as a GPIO button into
the DT, so people can use it for whatever they want in Linux (trigger
reboot, update, you name it). But this is rather orthogonal to this
problem, as mentioned above.
Mmmmm but this will be in the Linux kernel DT and I assume you want the
same GPIO to be used in U-Boot and in Linux, so it would probably be
best to make sure they stay in sync? How are you planning to do that?
Cheers,
Quentin
