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

[Marek Vasut]

On 8/16/23 15:28, Marek Vasut wrote:
> 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)

I ran into this defect again, it seems the EV1 problem is ignored by ST, 
or are there any news ?