[PATCH v3 19/31] rockchip: Provide a VPL phase on rk3399

[Jonas Karlman]

Hi Simon,

On 2025-03-29 00:40, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 28 Mar 2025 at 10:16, Jonas Karlman <jonas at kwiboo.se> wrote:
>>
>> Hi Simon,
>>
>> On 2025-03-28 16:34, Simon Glass wrote:
>>> Add support for this new phase, which runs after TPL. It determines the
>>> state of the machine, then selects which SPL image to use. SDRAM init is
>>> then done in SPL, so that it is updatable.
>>>
>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>> ---
>>>
>>> (no changes since v2)
>>>
>>> Changes in v2:
>>> - Rewrite help for VPL_ROCKCHIP_COMMON_BOARD
>>> - Skip spl-boot-order.c for VPL (rather than modifying it)
>>>
>>>  arch/arm/include/asm/spl.h               |   1 +
>>>  arch/arm/mach-rockchip/Kconfig           |  25 +++++-
>>>  arch/arm/mach-rockchip/Makefile          |  11 ++-
>>>  arch/arm/mach-rockchip/rk3399/Kconfig    |   9 ++
>>>  arch/arm/mach-rockchip/spl.c             |   3 +
>>>  arch/arm/mach-rockchip/tpl.c             |   2 +-
>>>  arch/arm/mach-rockchip/u-boot-vpl-v8.lds | 107 +++++++++++++++++++++++
>>>  arch/arm/mach-rockchip/vpl.c             |  53 +++++++++++
>>>  common/spl/Kconfig                       |   1 +
>>>  9 files changed, 205 insertions(+), 7 deletions(-)
>>>  create mode 100644 arch/arm/mach-rockchip/u-boot-vpl-v8.lds
>>>  create mode 100644 arch/arm/mach-rockchip/vpl.c
>>>
>>
>> This patch and therefore this series does not apply to the next branch.
>>
>> Are there any depends that are missing or are you only testing based on
>> your own fork?
> 
> Until we are ready to apply things, yes I am using the sjg tree. See
> the tags in the cover letters of patches I send. For this one it is:
> 
> base-commit: 3f76d803db9b500f43bc534465945a8d2836bb3e
> branch: vbi3

This base-commit does not even exist in your vbi3 branch :-/

> 
> So no, there is nothing else that this series depends on and if you
> can review it I can send a PR for Tom for -next one all necessary
> changes are made.

Sorry, this does not help, my main concern is testing that this does not
break or affect anything for the remaining Rockchip boards. Something
that is hard to test and validate when patches do not even apply to any
of the mainline master or next branches.

Sending patches based on a tree that has diverged with around 677 files
changed, 20072 insertions(+), 17023 deletions(-), if my git fu is
correct, and then expect us to test based on this diverged tree does not
help with gaining confidence in this series.

I can understand keeping a personal tree that will diverge at times,
i.e. my personal tree has ~120-150 patches on top of mainline master.
However, I always try to keep my work-in-progress branches rebased on
top of master or next.

For v4, please send a series based on mainline master or next branch,
as stated in "General Patch Submission Rules" [1] in the U-Boot docs.

If the series has some depends, I suggest you also publish a branch
to a public repo with any limited depends applied on top of master or
next along with the patches in your series.

[1] https://docs.u-boot.org/en/latest/develop/sending_patches.html

Regards,
Jonas

> 
> Regards,
> Simon