[linux-sunxi] Re: [PATCH v2 16/21] sunxi: Add H616 FEL support
On 1/11/21 2:11 PM, Jernej Skrabec wrote: > H616 uses different address for reset. Add it. > > Signed-off-by: Jernej Skrabec > --- > arch/arm/cpu/armv8/fel_utils.S | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S > index 9510dcd9e4c1..2dbd4b365221 100644 > --- a/arch/arm/cpu/armv8/fel_utils.S > +++ b/arch/arm/cpu/armv8/fel_utils.S > @@ -40,7 +40,10 @@ ENTRY(return_to_fel) > str w2, [x1] > > ldr x0, =0xfa50392f // CPU hotplug magic > -#ifdef CONFIG_MACH_SUN50I_H6 > +#ifdef CONFIG_MACH_SUN50I_H616 > + ldr x2, =(SUNXI_RTC_BASE + 0x5c0) This is more accurately (SUNXI_R_CPUCFG_BASE + 0x1c0). This is noticeable in secure mode, where the RTC is accessible but R_CPUCFG is not. Cheers, Samuel > + str w0, [x2], #0x4 > +#elif CONFIG_MACH_SUN50I_H6 > ldr x2, =(SUNXI_RTC_BASE + 0x1b8) // BOOT_CPU_HP_FLAG_REG > str w0, [x2], #0x4 > #else > -- 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/e6e66ec1-888d-6089-2b76-1b68d0374bf3%40sholland.org.
Re: [linux-sunxi] [RFC PATCH 0/2] sunxi: Pass a reboot mode to the bootloader via the RTC
On Wed, Jan 20, 2021 at 12:41 PM Chen-Yu Tsai wrote: > > Hi, > > On Tue, Jan 19, 2021 at 1:52 PM Samuel Holland 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.
Re: [linux-sunxi] [RFC PATCH 0/2] sunxi: Pass a reboot mode to the bootloader via the RTC
Hi, On Tue, Jan 19, 2021 at 1:52 PM Samuel Holland 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. 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/CAGb2v67Hsks3L-5nSpXFXZps%3D7_kY02stzsUmz3zvxFLcjbm_Q%40mail.gmail.com.
Re: [linux-sunxi] [PATCH] sunxi: Properly check for SATAPWR and MACPWR
Dne torek, 19. januar 2021 ob 02:05:20 CET je Andre Przywara napisal(a): > The #ifdef CONFIG_xxxPWR conditionals were not working as expected, as > string Kconfig symbols are always "defined" from the preprocessor's > perspective. This lead to unnecessary calls to the GPIO routines, but > also always added a half a second delay to wait for a SATA disk to power > up. Many thanks to Peter for pointing this out! > > Fix this by properly comparing the Kconfig symbols against the empty > string. strcmp() would be nicer for this, but GCC does not optimise this > away, probably due to our standalone compiler switches. > > Reported-by: Peter Robinson > Signed-off-by: Andre Przywara Nice find! Reviewed-by: Jernej Skrabec Best regards, Jernej -- 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/2273364.cmf3nSqCEo%40kista.
[linux-sunxi] Re: [PATCH] sunxi: Properly check for SATAPWR and MACPWR
On Tue, Jan 19, 2021 at 1:06 AM Andre Przywara wrote:
>
> The #ifdef CONFIG_xxxPWR conditionals were not working as expected, as
> string Kconfig symbols are always "defined" from the preprocessor's
> perspective. This lead to unnecessary calls to the GPIO routines, but
> also always added a half a second delay to wait for a SATA disk to power
> up. Many thanks to Peter for pointing this out!
>
> Fix this by properly comparing the Kconfig symbols against the empty
> string. strcmp() would be nicer for this, but GCC does not optimise this
> away, probably due to our standalone compiler switches.
>
> Reported-by: Peter Robinson
> Signed-off-by: Andre Przywara
Tested-by: Peter Robinson
Tested on Pine64, Cubietruck with root fs on SATA SSD, and an orangepi_pc
> ---
> board/sunxi/board.c | 34 ++
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 4f058952b5b..a0b5778b3bc 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -265,18 +265,28 @@ int board_init(void)
> if (ret)
> return ret;
>
> -#ifdef CONFIG_SATAPWR
> - satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> - gpio_request(satapwr_pin, "satapwr");
> - gpio_direction_output(satapwr_pin, 1);
> - /* Give attached sata device time to power-up to avoid link timeouts
> */
> - mdelay(500);
> -#endif
> -#ifdef CONFIG_MACPWR
> - macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> - gpio_request(macpwr_pin, "macpwr");
> - gpio_direction_output(macpwr_pin, 1);
> -#endif
> + /* strcmp() would look better, but doesn't get optimised away. */
> + if (CONFIG_SATAPWR[0]) {
> + satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> + if (satapwr_pin >= 0) {
> + gpio_request(satapwr_pin, "satapwr");
> + gpio_direction_output(satapwr_pin, 1);
> +
> + /*
> +* Give the attached SATA device time to power-up
> +* to avoid link timeouts
> +*/
> + mdelay(500);
> + }
> + }
> +
> + if (CONFIG_MACPWR[0]) {
> + macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> + if (macpwr_pin >= 0) {
> + gpio_request(macpwr_pin, "macpwr");
> + gpio_direction_output(macpwr_pin, 1);
> + }
> + }
>
> #ifdef CONFIG_DM_I2C
> /*
> --
> 2.17.5
>
--
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/CALeDE9O%2BBgOrU%3DAcCGqhggH4zTaYX4SwadvGBHOcL3qJOca5JA%40mail.gmail.com.
