rk3399 boards broken, only partially converted to standard boot? (was Re: [PATCH 71/71] rockchip: Convert rockpro64-rk3399 to use standard boot)

[Vagrant Cascadian]

On 2023-02-20, Simon Glass wrote:
> On Sat, 18 Feb 2023 at 19:19, Vagrant Cascadian <vagrant at debian.org> wrote:
>> On 2022-12-07, Simon Glass wrote:
>> > Drop the use of scripts and rely on standard boot for all operation.
>>
>> This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke
>> booting on pinebook-pro-rk3399, which still tries to "run
>> distro_bootcmd" but distro_bootcmd is no longer defined... probably
>> several other rk3399 systems are similarly affected? Maybe other
>> rockchip systems as well? Reverting the patch fixes booting on the
>> pinebook-pro-rk3399, at least.
>>
>> It seems that rockpro64-rk3399 was used as an example, so that
>> presumably works, but in actuality, this commit only modifies common
>> files for many rockchip and rk3399 boards and nothing rockpro64-rk3399
>> specific, so the commit message is a bit misleading.
>>
>> I am not sure what the best way forward is; to quickly convert all the
>> other boards in a new patch series, or incrementally shift one system at
>> a time over (and somehow restore previous behavior in the
>> meantime?)... as it stands it appears we are left with rk3399 boards
>> partially converted but broken...
>>
>> FWIW, I have not confirmed for sure that other boards are broken, so it
>> might just be pinebook-pro-rk3399 for some reason. I have a few rk3399
>> based boards I can test to confirm...
>
> I suspect it needs BOOTSTD_DEFAULTS enabled. Could you try that? I can
> send a patch if you like?

I added CONFIG_BOOTSTD_DEFAULTS=y to
configs/pinebook-pro-rk3399_defconfig but it still had the same issue...

bootcmd does not get updated to use bootstd instead of distro_bootcmd
... and distro_bootcmd is not defined, so it fails to boot! At least it
gets as far as a u-boot prompt!


As mentioned on irc, I wasn't able to get rockpro64-rk3399 to boot at
all (hanging at SPL), so cannot test if it also needs further changes
for BOOTSTD to work... and for good measure, rock64-rk3328 also fails in
the same way.

I also have puma-rk3399, firefly-rk3399 and firefly-rk3288 to
test... though might wait on some of those till the dust settles a
bit...


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230221/d065b1e4/attachment.sig>