Re: [PATCH v4 3/3] reboot-mode: read the boot mode from RTC memory

On 7/5/21 6:29 PM, Simon Glass wrote: Hi Nandor, On Mon, 28 Jun 2021 at 03:44, Nandor Han wrote: On 6/26/21 9:30 PM, Simon Glass wrote: Hi Nandor, On Thu, 10 Jun 2021 at 07:57, Nandor Han wrote: RTC devices could provide battery-backed memory that can be used for storing the reboot mode

Re: [PATCH v4 3/3] reboot-mode: read the boot mode from RTC memory

On 6/26/21 9:30 PM, Simon Glass wrote: Hi Nandor, On Thu, 10 Jun 2021 at 07:57, Nandor Han wrote: RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The

[PATCH v4 3/3] reboot-mode: read the boot mode from RTC memory

RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The driver also supports both endianness modes. Signed-off-by: Nandor Han --- arch/sandbox/dts/test.dts

[PATCH v4 2/3] reboot-mode: read the boot mode from GPIOs status

the magic value. Having the modes associated with the magic value generated based on the GPIO values, allows the reboot mode uclass to select the proper mode. Signed-off-by: Nandor Han --- arch/sandbox/dts/test.dts | 8 ++ configs/sandbox_defconfig | 2

[PATCH v4 1/3] reboot-mode: add support for reboot mode control

: Nandor Han --- drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/reboot-mode/Kconfig | 18 +++ drivers/reboot-mode/Makefile | 7 ++ drivers/reboot-mode/reboot-mode-uclass.c | 134 +++ include/dm

[PATCH v4 0/3] Add reboot mode support

lected in 0.40 seconds == ``` Changes since v1: - rebased Changes since v2: - unit-tests added Changes since v3: - rebased - fix the struct udevice and struct driver incompatibilities Nandor Han (3): reboo

[PATCH v2 1/1] bootcount: add a new driver with syscon as backend

The driver will use a syscon regmap as backend and supports both 16 and 32 size value. The value will be stored in the CPU's endianness. Signed-off-by: Nandor Han --- Notes: Description --- Add a new driver for bootcount feature that supports `syscon` device as ba

[PATCH v3 3/3] reboot-mode: read the boot mode from RTC memory

RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The driver also supports both endianness modes. Signed-off-by: Nandor Han --- arch/sandbox/dts/test.dts

[PATCH v3 2/3] reboot-mode: read the boot mode from GPIOs status

the magic value. Having the modes associated with the magic value generated based on the GPIO values, allows the reboot mode uclass to select the proper mode. Signed-off-by: Nandor Han --- arch/sandbox/dts/test.dts | 8 ++ configs/sandbox_defconfig | 2

[PATCH v3 1/3] reboot-mode: add support for reboot mode control

: Nandor Han --- drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/reboot-mode/Kconfig | 18 +++ drivers/reboot-mode/Makefile | 7 ++ drivers/reboot-mode/reboot-mode-uclass.c | 134 +++ include/dm

[PATCH v3 0/3] Add reboot mode support

lected in 0.40 seconds == ``` Changes since v1: - rebased Changes since v2: - unit-tests added Nandor Han (3): reboot-mode: add support for reboot mode control reboot-mode: read the boot mode from GPIOs status reboot-mod

[PATCH 1/1] bootcount: add a new driver with syscon as backend

The driver will use a syscon regmap as backend and supports both 16 and 32 size value. The value will be stored in the CPU's endianness. Signed-off-by: Nandor Han --- Notes: Description --- Add a new driver for bootcount feature that supports `syscon` device as ba

Re: [PATCH v2 0/3] Add reboot mode support

On 2020-05-04 12:18, Nandor Han wrote: Description --- Add support for reboot-mode configuration using GPIOs and RTC SRAM as back-end. Ping. Any comments about this? Can this be applied? Regards, Nandor

[PATCH v2 2/3] reboot-mode: read the boot mode from GPIOs status

the magic value. Having the modes associated with the magic value generated based on the GPIO values, allows the reboot mode uclass to select the proper mode. Signed-off-by: Nandor Han --- .../reboot-mode/reboot-mode-gpio.txt | 20 +++ drivers/reboot-mode/Kconfig | 9

[PATCH v2 1/3] reboot-mode: add support for reboot mode control

: Nandor Han --- drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/reboot-mode/Kconfig | 18 drivers/reboot-mode/Makefile | 7 ++ drivers/reboot-mode/reboot-mode-uclass.c | 132 +++ include/dm

[PATCH v2 3/3] reboot-mode: read the boot mode from RTC memory

RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The driver also supports both endianness modes. Signed-off-by: Nandor Han --- .../reboot-mode/reboot-mode

[PATCH v2 0/3] Add reboot mode support

gured anymore: PASS U-Boot> print reboot-mode ## Error: "reboot-mode" not defined 4. Toggle the GPIO configured for test mode to active and reset the system with command reset. 5. Stop in U-Boot and check that reboot-mode env variable is configured:PASS U-Boot> print reboot-mode reboo

Re: [PATCH 1/3] reboot-mode: add support for reboot mode control

initialization time. The map contains a list of modes and associated ids. Signed-off-by: Nandor Han --- drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/reboot-mode/Kconfig | 18 drivers/reboot-mode/Makefile

Re: `uclass_find_device_by_name` fails to find the device

Hi Simon and thanks, On 2019-12-24 17:58, Simon Glass wrote: Can you use a phandle to refer to the device from another node, perhaps a UCLASS_BOARD node if needed? It is not a good idea to use this function. I'm not sure, I'll have to check that. Anyway `uclass_find_device_by_name` is u

[U-Boot] `uclass_find_device_by_name` fails to find the device

Hi everybody, I've noticed that commit 4213609cc7fb78f84b2ea63f4a5691b60d01c248 changes how `uclass.c:uclass_find_device_by_name` function compares the names for finding devices. Because of this I have an issue when having a DTS and trying to find a device by name. The `lists.c:lists_bind