[PATCH] rockchip: ringneck-px30: put STM32_RST line in input mode instead of output

[Kever Yang]

Hi Quentin,

On 2024/3/22 17:38, Quentin Schulz wrote:
> Hi Kever,
>
> On 2/19/24 10:50, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 2/18/24 02:14, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/2/9 21:18, Quentin Schulz wrote:
>>>> From: Quentin Schulz<quentin.schulz at theobroma-systems.com>
>>>>
>>>> The STM32_RST line is routed to the ATtiny microcontroller
>>>> PA0/RESET/UPDI pin. By driving the PX30 SoC pin as GPIO output 
>>>> high, we
>>>> prevent external UPDI to be used for flashing without first putting 
>>>> this
>>>> pin as GPIO input, an extra step we could avoid in userspace.
>>>
>>> A little confuse here, this GPIO is an output for PX30, right?So the 
>>> config is:
>>>
>>> 1. the PX30 SPL init STM32_RST as input, with hardware pull-up the 
>>> keep STM32 work;
>>>
>>
>> The pin needs to be high for STM32, and high **but not driven** for 
>> ATtiny in order to allow flashing scripts to work.
>>
>>> 2. when need UPDI for flashing, need to set STM32_RST to output and 
>>> trigger the reset in userspace?
>>>
>>
>> For STM32, STM32_RST needs to be driven low, then STM32_BOOT needs to 
>> be driven high, then STM32_RST needs to be high to deassert reset.
>>
>> For ATtiny, STM32_RST needs to be NOT driven so that UPDI lines can 
>> be used to interact with the MCU. Note that we also have the ability 
>> to do bitbang UPDI on that STM32_RST pin but that's another topic 
>> (just explaining why it is routed while seemingly useless for ATtiny).
>>
>> All the above is for entering the flashing mode.
>>
>> However, in U-Boot we do NOT want to enter flashing mode, we want to 
>> exit it, c.f. 
>> https://lore.kernel.org/u-boot/20231103-ringneck-stm32-reset-v2-1-a0e5559f89bf@theobroma-systems.com/
>>
>> An external HW pull-up is required because of glitches on the line 
>> when powering up/down. However, this is only done on newer versions 
>> of the PCB, so we need to tackle old versions.
>>
>> The old versions do not have this external HW pull-up and the glitch 
>> may cause the MCU to enter its flashing mode. Therefore, we force it 
>> to exit the flashing mode by always hard resetting it into the normal 
>> runtime mode. This is what spl_board_init() does. STM32_RST and 
>> STM32_BOOT are controlled by our flashing script for the STM32 
>> variant for the MCU, so the default state when entering the Linux 
>> kernel doesn't matter. For the ATtiny MCU variant, we do not handle 
>> those GPIOs as part of the flashing script, therefore the default 
>> state when entering the Linux kernel should be the expected value for 
>> which we can use UPDI to flash the ATtiny. For ATtiny, the reset line 
>> is shared between STM32_RST that goes to the SoC and the UPDI lines 
>> exposed over the Q7 header. If STM32_RST is driven by the SoC, the 
>> UPDI lines won't be able to interact with the MCU. Therefore it needs 
>> to be put into input mode, whether in U-Boot or in Linux userspace.
>>
>
> Can we have this in the next merge request for next please? Or maybe 
> there's something I need to change here?

I will merge this patch next time when I send the PR.


Reviewed-by: Kever Yang <kever.yang at rock-chips.com>

Thanks,
- Kever


>
> Cheers,
> Quentin