[PATCH] ARM: stm32: Power cycle Buck3 in reset on DHSOM

[Marek Vasut]

On 8/16/23 15:22, Patrice CHOTARD wrote:
> 
> 
> On 7/10/23 23:43, Marek Vasut wrote:
>> On 6/17/23 02:36, Marek Vasut wrote:
>>> On 6/16/23 15:04, Patrick DELAUNAY wrote:
>>>> Hi,
>>>
>>> Hi,
>>>
>>>>> [   39.426015] Disabling non-boot CPUs ...
>>>>> [   39.448635] Retrying again to check for CPU kill
>>>>> [   39.451909] CPU1 killed.
>>>>> U-Boot SPL 2023.07-rc4-00008-g2f4664f5c3e (Jun 15 2023 - 08:36:52 +0200)
>>>>> RAM: DDR3-DDR3L 32bits 533000kHz
>>>>> DDR invalid size : 0x4, expected 0x40000000
>>>>> DRAM init failed: -22
>>>>> ### ERROR ### Please RESET the board ###
>>>>>
>>>>> Press RESET button
>>>>>
>>>>> U-Boot SPL 2023.07-rc4-00008-g2f4664f5c3e (Jun 15 2023 - 08:36:52 +0200)
>>>>> RAM: DDR3-DDR3L 32bits 533000kHz
>>>>> DDR invalid size : 0x4, expected 0x40000000
>>>>> DRAM init failed: -22
>>>>> ### ERROR ### Please RESET the board ###
>>>>>
>>>>>
>>>> I try it with the latest STMicroelectronics OSS image.
>>>>
>>>> I just change in U-Boot config to be aligned the expected SD-Card partionning
>>>>
>>>> configs/stm32mp15_basic_defconfig:
>>>>
>>>> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
>>>> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=5
>>>>
>>>> But low power is not supported in this downstream config :-<
>>>
>>> Use multi_v7_defconfig or some such ?
>>>
>>>> I got the error:
>>>>
>>>>
>>>> .......
>>>> U-Boot SPL 2023.07-rc4-00008-g2f4664f5c3ed-dirty (Jun 16 2023 - 11:37:52 +0200)
>>>> RAM: DDR3-DDR3L 32bits 533000kHz
>>>> WDT:   Started watchdog at 5a002000 with servicing every 1000ms (32s timeout)
>>>> image entry point: 0xc0100000
>>>>
>>>>
>>>> U-Boot 2023.07-rc4-00008-g2f4664f5c3ed-dirty (Jun 16 2023 - 11:37:52 +0200)
>>>>
>>>> CPU: STM32MP157FAA Rev.Z
>>>> Model: STMicroelectronics STM32MP157C eval daughter on eval mother
>>>> Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
>>>> Board: MB1263 Var4.0 Rev.C-03
>>>> DRAM:  1 GiB
>>>> Clocks:
>>>> - MPU : 800 MHz
>>>> - MCU : 208.878 MHz
>>>> - AXI : 266.500 MHz
>>>> - PER : 24 MHz
>>>> - DDR : 533 MHz
>>>> Core:  288 devices, 42 uclasses, devicetree: separate
>>>> WDT:   Started watchdog at 5a002000 with servicing every 1000ms (32s timeout)
>>>> NAND:  1024 MiB
>>>> MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
>>>> Loading Environment from MMC... Invalid ENV offset in MMC, copy=0
>>>> In:    serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Net:   eth0: ethernet at 5800a000
>>>> Hit any key to stop autoboot:  0
>>>>
>>>> ....
>>>> [    0.000000] Booting Linux on physical CPU 0x0
>>>> [    0.000000] Linux version 6.4.0-rc6 (oe-user at oe-host) (arm-ostl-linux-gnueabi-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.40.20230119) #1 SMP PREEMPT Sun Jun 11 21:35:30 UTC 2023
>>>> ....
>>>> root at stm32mp1-disco-oss:~# while true ; do rtcwake -s 100 -m mem ; done
>>>> rtcwake: unrecognized suspend state 'mem'
>>>
>>> Please fix your kernel config and enable suspend to mem, I am sure that is not difficult.
>>>
>>>> I check also with downstream (OpenSTLinux V4.0),
>>>
>>> This is not relevant to this discussion.
>>>
>>>> and I can't reproduced the issue but we are using TF-A  / OP-TEE / SCMI to support all the low power modes.
>>>>
>>>>
>>>> And this low power support (in TF-A/ OP-TEE / Linux with SCMI) is not yet up streamed.
>>>>
>>>>
>>>> PS: if you are not able to restart even after a RESET,
>>>>         I assume something is wrong in the PMIC configuration
>>>>
>>>>         (for example in NVM or in initial regulator configuration)
>>>>
>>>>         so you have no power cycle on DDR during reset...
>>>>
>>>>          => something is wrong in PMIC configuration in linux ?
>>>
>>> Possibly, but then it is also something wrong on STM32MP157C EV1, because I can reproduce the failure on EV1 too. I specifically did check this on the EV1. Please fix your kernel config and try again, then you should be able to see it yourself.
>>
>> Has there been any news on this defect of EV1 or has this been ignored by ST ?
> 
> Hi Marek

Hi,

> Sorry for the delay,

No worries.

What I am more concerned about is -- why is this problem present on EV1 
too and how to solve it there ? (and no, "add more unnecessary software 
to the stack to cover this up" is not the answer)

> Patch applied on stm32-master

Thank you