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

[Quentin Schulz]

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.



> 
>>
>> There's an external hardware pull-up strong enough to keep the STM32_RST
>> state high on ATtiny side but weak enough it can be overridden by
>> external UPDI. This also means it is safe to use for the STM32 variant,
>> where STM32_RST line will be in the same state as if output high was
>> used.
>>
>> The Q7 standard specifies that MFG_NC1 and MFG_NC2 (used for UPDI for
>> Ringneck) pins should neither be driven by the carrierboard, nor have
>> pull-up or pull-down resistors.
> 
> This sounds like it should use output and pull-none for these GPIOs?
> 

This would be a configuration for the Linux kernel DT, but we would 
still need some custom handling in U-Boot. What are you suggesting 
exactly with this?

Cheers,
Quentin