Re: [yocto] [meta-rockchip][PATCH 3/3] rock-pi-s: add

[Trevor Woerner <twoerner@gmail.com>]

On Wed 2023-10-04 @ 04:23:31 PM, Quentin Schulz wrote:
> On 10/3/23 15:56, Trevor Woerner wrote:
> > On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote:
> > > > diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
> > > > index 7fefb017053b..49e1e682eb7d 100644
> > > > --- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
> > > > +++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
> > > > @@ -1,9 +1,12 @@
> > > >    DESCRIPTION = "Rockchip Firmware and Tool Binaries"
> > > >    LICENSE = "Proprietary"
> > > > +LICENSE:rk3308 = "CLOSED"
> > > >    LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
> > > > +LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95"
> > > >    SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
> > > >    SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
> > > > +SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2"
> > > 
> > > Could you please say a few words about this change? It seems that there are
> > > still binaries for it in the SRCREV we already point to. I assume newer
> > > should be better (though it's not always the case), so wondering what's
> > > prompted this change?
> > > 
> > > 
> > > Oooooooh, there is no TPL with uart0m0 support anymore... honestly not sure
> > > it's a good idea to stay on a old blob version just for that? I assume you
> > > should only be missing the uart in TPL but the moment you reach the SPL the
> > > console should appear, doesn't it?
> > 
> > Exactly, I would prefer to be able to capture all of the console output all in
> > one place. It's annoying they randomly decided to change uarts for every other
> > update. As far as I'm concerned one binary blob is a good (or bad) as the
> > next, and if this one gives me diagnostic info in the console, then it wins
> > :-)
> > 
> 
> I think this is a bit too much to hope for :) In the commit logs for ddr-bin
> updates in rkbin, I've seen a few mentions to DDR init stability/reliability
> for example. So saying it's all the same is probably incorrect.

I did a test with the rk3308 binaries from the latest commit of rkbin that
don't support uart0. Specifically I tested with rk3308_ddr_589MHz_uart4_m0_v2.07.bin:
this also works.

Also, it's a lot less hassle to build (rather than rolling back to a release
that has a uart0 console for the rk3308). However, even though the console is
set to uart4, this binary also outputs a lot of data to uart0. I've tried both
1,500,000 baud (the standard rockchip baud) and 115,200 baud: neither are able
to interpret the data. U-Boot, apparently, doesn't try to reset the serial
port either, because the garbage output continues until the Linux kernel
finally takes over. Or perhaps maybe the gibberish that I'm seeing is from
U-Boot outputting to an uninitialized serial port?

Roll back to older rkbin checkout:
PRO:
- supports console on uart0 (same as linux kernel) and all messages from
  rkbin, u-boot, linux kernel, and console appear legibly on the terminal
CON:
- more cumbersome to build (recipe requires a bunch of rk3308-based
  overrides), perhaps a separate rkbin recipe would be better?
- uses older ddr initialization code

Use latest rkbin:
PRO:
- simpler recipe, no overrides necessary, simpler build
- uses the latest code (might include bug fixes or other improvements?)
CON:
- spews a bunch of gibberish to the serial console (from rkbin? from u-boot?
  from both?)
- the first legible messages only start once the linux kernel takes over,
  therefore the user can't interact with U-Boot (should they so wish)