Hi Trevor,
On 10/30/23 18:26, Trevor Woerner wrote:
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?
So, the TPL (ddr.bin) we get from rockchip-rkbin isn't configurable and
it outputs something on some UART controller for the user to be able to
debug stuff.
Then, if U-Boot isn't properly supported (which is sadly often the case
in the beginning or, for poorly supported SoCs... forever), it just
simply does nothing for configuring the debug serial (or initializes the
"wrong" one). I don't remember exactly if U-Boot does something with the
serial device defined as main output in the DTB used by U-Boot or if it
just expects the SPL to properly set up everything.
I think this should be fixed in U-Boot itself in any case. See what I
had to do for PX30 a year ago for example:
https://source.denx.de/u-boot/u-boot/-/commit/d0af506625ff909b123a298e435a95ae1b8ee3e7
I haven't looked into it in depth, but it seems only UART2 is supported
currently on RK3308, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-rockchip/rk3308/rk3308.c?ref_type=heads#L178
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)
This would be a blocker to me if I were to use this board, so I second
your decision of going for older rkbin for now.
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61575): https://lists.yoctoproject.org/g/yocto/message/61575
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]
-=-=-=-=-=-=-=-=-=-=-=-
