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

[Simon Glass]

Hi Vagrant,

On Tue, 21 Feb 2023 at 13:32, Vagrant Cascadian <vagrant at debian.org> wrote:
>
> 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...

Yes, see my note about this a few minutes back. I sent 3 patches at
lunchtime too:

https://patchwork.ozlabs.org/project/uboot/list/?series=343056

Regards,
Simon