<uis>
apritzel: why they don't publish dram init code?
<apritzel>
uis: because it's rocket science, apparently ;-)
<uis>
Why not to publish any code? Why they don't publish other parts of TRM?
<apritzel>
uis: I don't understand either, I guess it's a mixture of third party code, embarrassing hacks and ignorance
<uis>
TRMs
<uis>
rk3328
<uis>
RK3399TRMs AFAIK doesn't contain third party code
<n0mis>
Does anybody have an idea what might be wrong if a 5.10.16 kernel for the rk3328 does not reliably want to start init? It sometimes starts, sometimes not. It feels somewhat related to USB ports, but plug/unplug-Events still get shown.
<ukleinek>
n0mis: did you compare the boot log between work and works not?
<n0mis>
hm, I should probably check the complete log. For now I just compared the last lines which were somewhat related to filesystems, but not really consistent.
<ukleinek>
n0mis: Yesterday I experienced a few times "[ 1.357218] Initramfs unpacking failed: junk within compressed archive" which happens quite early before failing
<n0mis>
Hm. I have the impression that somehow mmc0 mmc1 and mmc2 are switching names.
<n0mis>
it detects the partitions of the emmc in one case on mmcblk1 and in the other case on mmcblk2
<n0mis>
I certainly specify it on mmcblk1.
<n0mis>
wtf.
<apritzel>
n0mis: yeah, that's a new "feature" in recent Linux kernels, much to some people's annoyance
<apritzel>
n0mis: you can use UUIDs or labels to work around this, or try mmc<x> aliases in the DT
<mps>
n0mis: this is quite iritating, rk3399 fixed this
<mps>
and I fixed it for mediatek elm chromebooks for alpine kernels
<n0mis>
apritzel: how would I specify these aliases in a DT?
<mps>
but didn't posted patch to mainline (lazy to go over kernel mainline barriers)
<mps>
similar is in rk3399.dtsi in mainline kernel, iirc
<mps>
ahm, apritzel already answered
<ukleinek>
n0mis: but using UUID is the future proof thing to use
<n0mis>
oh, so really in the aliases-section of the DTB. I was under the assumption that this is a "made-for-humans" thing.
<n0mis>
ukleinek: hrm, then I would have to fight a yocto/rauc/mess again...
<ukleinek>
n0mis: rauc can handle UUIDs just fine
<apritzel>
n0mis: yeah, there was some discussion around whether it's the right solution and place, but eventually the MMC framework in the kernel now supports it
<apritzel>
but yeah, UUIDs are the proper answer, most of the time
<n0mis>
ukleinek: aren't the UUIDs contained in the rauc bundles? Since I don't really have a control over which image gets written to what slot (they are alternating and if a user skips an update we'd be out of sync?) I fear that I lose the fallback boot.
<n0mis>
or are the UUIDs in the GPT table?
<ukleinek>
n0mis: I (luckily) don't know the details for U-Boot but barebox handles UUIDs just fine.
<apritzel>
n0mis: there are two kind of UUIDs, the normal ones are part of the filesystem, so are partition table ignorant, and survive a "dd" copy
<ukleinek>
n0mis: You just say: boot /dev/mmc0.2 and it adds the right root=UUID=... to the cmdline
<n0mis>
ukleinek: uh, that would need some fiddeling in uboot I think. Have not looked at that kind of stuff now.
<n0mis>
+mmc0 = &mmc0;
<n0mis>
+mmc1 = &mmc1;
<n0mis>
oops. sorry.
<n0mis>
/dev/disk/by-partlabel might be a solution for me.
<apritzel>
the other UUIDs are some kind of GPT labels, so are part of the partition table (entry)
<ukleinek>
n0mis: maybe you need initramfs support for that one.
<ukleinek>
using barebox on rockchip needs some fiddeling, too :-\
<apritzel>
yes, UUIDs typically require an initrd to resolve them, that's the downside
<apritzel>
most real distros use initrds anyway, so it's not a problem for those
<n0mis>
yeah, no. I can't rework the boot process drastically in this stage of the project.
<n0mis>
I'll try the alias route and try switching to /dev/disk/by-partlabel...
<ukleinek>
the kernel can do PARTUUID=.., but UUID needs initrd
kaspter has joined #linux-rockchip
<mps>
kernel can also use PARTNROFF, relative partition from one where kernel is booted
<mps>
I have these for gru and elm chromebooks, 'root=PARTUUID=%U/PARTNROFF=1'
<mps>
never had problem booting from internal emmc, external mmc or ssd over usb
Putti has quit [Quit: Leaving]
field^Mop has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
<uis>
How make rk3328 to run dram on 933 mhz?
<apritzel>
uis: by understanding ALOT about DRAM operations and timings, having done elaborate tests to confirm it's stable, then entering the right timing parameters into arch/arm/dts/rk3328-sdram-xxx.dtsi
macromorgan has quit [Read error: Connection reset by peer]
<ukleinek>
uis: maybe you just need the right include in the u-boot.dtsi
macromorgan has joined #linux-rockchip
<macromorgan>
sorry, internet crapped out on me. I got that SFC patch working (had to modify a few things since the spi-nor structs changed since that patch was written), but the weird part is it seems to be reading the jedec ID twice of my flash chip