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.sch...@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-a0e5559f8...@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.y...@rock-chips.com>
Thanks,
- Kever
Cheers,
Quentin
