U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: Kever Yang <kever.yang@rock-chips.com>,
	Quentin Schulz <foss+uboot@0leil.net>,
	Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Klaus Goger <klaus.goger@cherry.de>
Cc: u-boot@lists.denx.de, Paul Kocialkowski <paulk@sys-base.io>,
	Paul Kocialkowski <contact@paulk.fr>
Subject: Re: [PATCH next v2 4/4] rockchip: rk3399: move sysreset-gpio logic to TPL
Date: Thu, 7 Nov 2024 12:04:46 +0100	[thread overview]
Message-ID: <5cfa0fbe-5003-4da1-9933-7664da07cd4d@cherry.de> (raw)
In-Reply-To: <149361d4-4cbb-4007-b00f-6b4efbd7978f@rock-chips.com>

Hi Kever,

On 11/7/24 8:14 AM, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/11/6 19:29, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is
>> provided in the TPL Device Tree, this will trigger a system reset
>> similar to what's currently been done in SPL whenever the RK3399 "warm"
>> boots. Because there's currently only one user of sysreset-gpio logic,
>> and TPL is enabled on that board, so let's migrate the logic and that
>> board to do it in TPL.
>>
>> There are three reasons for moving this earlier:
> 
> Yes, this movement is reasonable and needed for this workaround, 
> although still not
> 
> understand why puma board need this.
> 

Me neither, this predates me joining the company, c.f.:
https://source.denx.de/u-boot/u-boot/-/commit/ae0d33a7291a164a11ae034bcf4f71226b2bef48
https://source.denx.de/u-boot/u-boot/-/commit/5f104178bf713615dc404fdfcf0fb53d89c66a07
https://source.denx.de/u-boot/u-boot/-/commit/07586ee4322abca01db52624b925e5218538f259

What I can tell you is that it seems this is required as Paul (in Cc) is 
trying to add support for it for the Firefly ROC-RK3399-PC[1] and the 
ROCKPro64[2], so it seems it's useful for **some** purpose.

[1] 
https://lore.kernel.org/u-boot/20240926183111.1324284-1-paulk@sys-base.io/
[2] 
https://lore.kernel.org/u-boot/20240926183111.1324284-2-paulk@sys-base.io/

>> - faster boot time as we don't need to reach SPL to be able to reset the
>>    system on a condition we know is already met in TPL,
>> - have less code to be impacted by the issue this system reset works
>>    around (that is, "unclean" SoC registers after a reboot),
>> - less confusion around the reason for restarting. Indeed when done from
>>    SPL, the following log can be observed:
>>
>> """
>> U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
>> Channel 0: DDR3, 666MHz
>> BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
>> Channel 1: DDR3, 666MHz
>> BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
>> 256B stride
>> Trying to boot from BOOTROM
>> Returning to boot ROM...
>>
>> U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 
>> 15:31:45 +0100)
>> Trying to boot from MMC2
>>
>> U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
>> """
> So with this patch set, we can see the TPL banner twice ?
> 
> 
> PS: We are able to merge to master instead of next before next branch is 
> open, because we still have
> 
> enough time to debug before next release.
> 

My understanding is that once -rc1 is out, we should only do bug fixing 
in master. BUT at the same time, next branch isn't actually open until -rc2.

Up to you! It's not really urgent, Puma was migrated to TPL only in 
v2023.01 and we've lived without sysreset-gpio in TPL since then :)

Cheers,
Quentin

  reply	other threads:[~2024-11-07 11:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 11:29 [PATCH next v2 0/4] rockchip: rk3399: trigger sysreset in TPL Quentin Schulz
2024-11-06 11:29 ` [PATCH next v2 1/4] pinctrl: rockchip: allow to build for TPL Quentin Schulz
2024-11-08  3:28   ` Kever Yang
2024-11-06 11:29 ` [PATCH next v2 2/4] rockchip: rk3399: merge CRU check within rk3399_force_power_on_reset Quentin Schulz
2024-11-08  3:28   ` Kever Yang
2024-11-06 11:29 ` [PATCH next v2 3/4] rockchip: tpl: allow to call board/SoC-specific code before DRAM init Quentin Schulz
2024-11-08  3:29   ` Kever Yang
2024-11-06 11:29 ` [PATCH next v2 4/4] rockchip: rk3399: move sysreset-gpio logic to TPL Quentin Schulz
2024-11-07  7:14   ` Kever Yang
2024-11-07 11:04     ` Quentin Schulz [this message]
2024-11-07 12:27       ` Paul Kocialkowski
2024-11-08  0:50         ` Kever Yang
2024-11-12 11:18           ` Dragan Simic
2024-11-07 12:30   ` Paul Kocialkowski
2024-11-08  3:29   ` Kever Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5cfa0fbe-5003-4da1-9933-7664da07cd4d@cherry.de \
    --to=quentin.schulz@cherry.de \
    --cc=contact@paulk.fr \
    --cc=foss+uboot@0leil.net \
    --cc=kever.yang@rock-chips.com \
    --cc=klaus.goger@cherry.de \
    --cc=paulk@sys-base.io \
    --cc=philipp.tomsich@vrull.eu \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox