On Wed, Jan 20, 2021 at 12:41 PM Chen-Yu Tsai <w...@csie.org> wrote: > > Hi, > > On Tue, Jan 19, 2021 at 1:52 PM Samuel Holland <sam...@sholland.org> wrote: > > > > As the A64 is designed for use in mobile devices without easy access to > > a UART, MMC0, or a FEL button, it would be useful to be able to reboot > > to FEL mode, fastboot, etc. via a command from Linux. As reboot(2) > > supports passing a command with LINUX_REBOOT_CMD_RESTART2, and we have > > battery-backed RAM provided by the RTC (and also the PMIC), we can hook > > the Linux side up with just a little bit of glue. > > > > For examples of the bootloader side, see Rockchip boards in U-Boot[1] > > (an implementation of this for a similar platform) and p-boot[2] (an > > implementation of a similar idea for the A64). An interesting feature of > > the p-boot implementation is the ability to choose and chainload the > > bootloader from a different storage medium. This allows modifying the > > boot order without needing to burn eFuses. > > > > I'm sending this as an RFC to start discussion about allocating these > > RTC registers, for this and other purposes. p-boot uses a second > > register to store a boot order and some flags[3]. There has also been > > discussion of using the registers to store key material and a > > tamper-evident boot shim, to make up for deficiencies in the SoC's > > secure boot ROM. > > > > I suggest putting the reboot mode at the beginning of the region (to > > preserve the most consecutive registers for other uses), or copying > > p-boot's layout and using the second register (to respect prior art). > > > > Consecutive values (like the Allwinner[4] and Rockchip implementations) > > or arbitrary values (like in patch 2) would work for the reboot mode. > > I would suggest magic numbers with higher entropy than those in p-boot. > > Back when I worked on the A23, the BSP used a magic value to force the > BROM to drop directly into FEL mode. However I've lost any notes about > what the value was or which register it was stored in.
So it was actually boot0 that was checking for the flag, and jumping to FEL mode [1]. The flag, the magic value 0x5aa5a55a [2], is stored in 0x01f00108 [3]. Not sure if we care since this is Allwinner vendor bootloader specific. ChenYu [1] https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/boot0/Boot0_C_part.c#L82 [2] https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/boot0/Boot0_C_part.c#L29 [3] https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/bsp/bsp_for_a23/common/common.c#L319 > ChenYu > > > Any ideas/comments are welcome. > > > > Cheers, > > Samuel > > > > [1]: https://lists.denx.de/pipermail/u-boot/2016-September/267128.html > > [2]: > > https://megous.com/git/p-boot/commit/?id=5ebcf9d7f611d87eac16e06ab7f77f679c593d07 > > [3]: https://megous.com/git/p-boot/tree/src/main.c#n144 > > [4]: > > https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/rtc/rtc-sunxi.h#L113 > > > > Samuel Holland (2): > > rtc: sun6i: Add NVMEM provider > > arm64: dts: allwinner: a64: Add reboot mode > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 ++++++++ > > drivers/rtc/rtc-sun6i.c | 42 +++++++++++++++++++ > > 2 files changed, 59 insertions(+) > > > > -- > > 2.26.2 > > > > -- > > You received this message because you are subscribed to the Google Groups > > "linux-sunxi" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to linux-sunxi+unsubscr...@googlegroups.com. > > To view this discussion on the web, visit > > https://groups.google.com/d/msgid/linux-sunxi/20210119055204.55070-1-samuel%40sholland.org. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAGb2v64SitFoHtwmB1wQd3f3derz5KUobYaHqMbL1rFqCG35rw%40mail.gmail.com.
