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)
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61523): https://lists.yoctoproject.org/g/yocto/message/61523 Mute This Topic: https://lists.yoctoproject.org/mt/101691822/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
