lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC> [Discord] <c133> well, this doesn't seem like a _great_ start. used `dd` to write out Armbian_24.8.0-trunk.224_Rock-5b_trixie_edge_6.10.0-rc5_minimal.img to a SanDisk microSD card that has been working fine in another SBC, plugged it into the Rock 5B and tried to boot it and it doesn't seem to load after this: <https://gist.githubusercontent.com/clee/65ed36628afb4e109b4a55eed637b53c/raw/d945a0ea1 <clipped message>
<DC-IRC> [Discord] <c133> 846a2e473bc9c03807207a87ee42073/rock5b-uboot.log>
<DC-IRC> [Discord] <Werner> Is spi clear?
<DC-IRC> [Discord] <Werner> If unsure wipes beforehand
<DC-IRC> [Discord] <Werner> If unsure wipe beforehand
<DC-IRC> [Discord] <Werner> Well to cut a long story short each electrical device that gets warm when running and isn't meant to get warm when doing so (space heater for example) means energy is wasted as heat. The less heat it generates the more efficient it is.
<DC-IRC> [Discord] <rpardini> Yeah you're mixing blobs there. Notice how SPL is `2017.09`, while a recently-built edge image should be using 24.04 or such.
<DC-IRC> [Discord] <rpardini> So yeah clean off SPI / eMMC, or, make sure those match.
<DC-IRC> [Discord] <c133> is there any way to temporarily ignore SPI on Rock5B, like shorting those two pins on the 40-pin GPIO for Rock4[ABC]?
<DC-IRC> [Discord] <c133> is there any way to temporarily ignore SPI on Rock5B, like shorting pins 23+25 on the 40-pin GPIO for Rock4[ABC]?
<DC-IRC> [Discord] <rpardini> Errr, good question. Maybe that Maskrom button there does it?
<DC-IRC> [Discord] <rpardini> I don't have a rock-5b so dunno...
<DC-IRC> [Discord] <rpardini> I know the NanoPCT6's Maskrom button masks both eMMC & SPI -- unsure about the rock-5b.
<DC-IRC> [Discord] <c133> well, maskrom mode let me erase the flash and now Armbian is booting from SD
<DC-IRC> [Discord] <c133> so, victory!
<DC-IRC> [Discord] <rpardini> bootlog or didn't happen 😛
<DC-IRC> [Discord] <rpardini> cool. I just realized we're carrying old blobs for the rock-5b. It's high time we bumped the defaults
<DC-IRC> [Discord] <c133> `Error: The repository 'http://beta.armbian.com trixie Release' no longer has a Release file.`
<DC-IRC> [Discord] <c133> O_o
<DC-IRC> [Discord] <rpardini> ooooh that's.... not on me 😉
<DC-IRC> [Discord] <c133> ahhhh, and we've got a kernel panic here too
<DC-IRC> [Discord] <c133> on `6.10.0-rc5-edge-rockchip-rk3588`
<DC-IRC> [Discord] <Werner> Whole beta repo is 404 again. There is some issue in the repo management. Could not figure the cause yet
<DC-IRC> [Discord] <rpardini> Yeah let's bump blobs?
<DC-IRC> [Discord] <rpardini> rock-5b is using defaults which are `rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin` and `rk35/rk3588_bl31_v1.28.elf` which are pretty ancient by now
<DC-IRC> [Discord] <Werner> I'd suggest to ask @spooky8086 if he's aware of regressions of newer blobs beforehand
<DC-IRC> [Discord] <rpardini> I was gonna check what blobs he is using and ~~steal~~ copy his ideas
<DC-IRC> [Discord] <rpardini> Also @mariob has bumped up a bit then downgraded https://github.com/edk2-porting/edk2-rk3588/commits/master/
<DC-IRC> [Discord] <Werner> 👍
<DC-IRC> [Discord] <c133> yeah, I was running edk2-rk3588 before
<DC-IRC> [Discord] <c133> FreeBSD doesn't seem to have the ability to control frequencies or voltages for RK3588 yet, but I haven't managed to get their kernel to panic yet
<DC-IRC> [Discord] <rpardini> Hmm edk2 is using SPL blob (and that's what was downgraded) -- Armbian only uses DDR and BL31 blobs, as u-boot produces its own SPL.
<DC-IRC> [Discord] <mecoblock> I’ve used the newer blobs through his ubuntu, did not notice any regression. Heard people even say it helps with random reboots ? Never experienced those
<DC-IRC> [Discord] <rpardini> Yeah we had _one_ instance of trouble updating blobs, years ago -- that's when this board-specific-blobs thing started. I'll send a PR trying to restore commonality
<DC-IRC> [Discord] <rpardini> and yeah 1.16/1.45 seem to be safe by looking at Joshua and Mario
<DC-IRC> [Discord] <narga_64> Usually the CPU cores should switch to lower power states in idle. For rk3588 this isn't fully implemented yet unfortunately. There was some kernel talk last year I think which explained this issue.
<DC-IRC> [Discord] <narga_64> This is the cause that we're seeing very high idle temps. And as @werner explained, the high temps also means wasted energy. You can see this if you compare idle power with a power meter for vendor vs edge kernel.
<DC-IRC> [Discord] <rpardini> https://github.com/armbian/build/pull/6810
<DC-IRC> [Discord] <rpardini> seems like `v1.45` BL31 supports wake-from-UART ♥️
<DC-IRC> [Discord] <Werner> Never heard of that before. Interesting though
<DC-IRC> [Discord] <rpardini> LC had that in for some meson boards and I was envious
<DC-IRC> [Discord] <rpardini> now I was testing updated 3588 blobs, deployed a desktop image to one, left it sitting on login for a while, it slept. When I touched the serial console, _it woke_
<DC-IRC> [Discord] <rpardini> reproduced by running `systemctl suspend` and it _worked again_
<DC-IRC> [Discord] <narga_64> Awesome! We should always use the latest blobs 😄
<DC-IRC> [Discord] <rpardini> I'm still trying to find wth is `rk35/rk3588_spl_loader_v1.08.111.bin` -- used for Maskrom in `rkdevflash` extension. Where did it come from....
<DC-IRC> [Discord] <narga_64> Ah yes I have asked myself this as well in the past 😂 I think it's just miniloader.bin
<DC-IRC> [Discord] <narga_64> I use version 1.11 when flashing for rk3588
<DC-IRC> [Discord] <narga_64> Like, the loader that enables the flashing in the first place.
<DC-IRC> [Discord] <rpardini> it _should_ be just the DDR blob plus some SPL that only runs rockusb stuff
<DC-IRC> [Discord] <rpardini> but I can't find it at rkbin repo (or miniloader.bin for that matter)
<DC-IRC> [Discord] <rpardini> seems it's cobbled together from the other blobs with `boot_merger`
<DC-IRC> [Discord] <rpardini> also, radxa/collabora has a DFU-enabled variant
<DC-IRC> [Discord] <narga_64> Good find 👍
<DC-IRC> [Discord] <narga_64> I saw in the past that the miniloader can be compiled somehow but didn't bother since the loader v1.11 worked just fine.
<DC-IRC> [Discord] <narga_64> We can update it to the latest version though.
<DC-IRC> [Discord] <narga_64> I don't know how to use DFU
<DC-IRC> [Discord] <rpardini> should be pretty handy for developing u-boot
<DC-IRC> [Discord] <narga_64> You can update u-boot from within u-boot?
<DC-IRC> [Discord] <rpardini> you can boot the board without any media
<DC-IRC> [Discord] <rpardini> maskrom-boot it, load the DFU-enabled SPL, then use DFU to load u-boot proper
<DC-IRC> [Discord] <rpardini> with mainline uboot proper you can then use wget/NFS/TFTP or whatever to get a kernel & initrd
<DC-IRC> [Discord] <rpardini> with mainline uboot proper you can then use wget/NFS/TFTP or whatever to get a kernel & initrd & dtb
<DC-IRC> [Discord] <mecoblock> you can use NFS to get a kernel?? I knew collabora did some development dynamically loading in their stuff over the network but always thought that’s limited to TFTP
<DC-IRC> [Discord] <rpardini> that's just upstream u-boot, no collabora involved AFAIK. they added TCP support and thus HTTP (wget) support
<DC-IRC> [Discord] <rpardini> NFS is UDP so has been working for a while now
<DC-IRC> [Discord] <rpardini> you do need `CONFIG_CMD_NFS=y` and dependencies
<DC-IRC> [Discord] <mecoblock> cpufreq is merged for 6.11rc1
<DC-IRC> [Discord] <rpardini> "cool". heh. tkaiser is gonna have a(nother) fit.
<DC-IRC> [Discord] <efectn> wondering when hdmi bridge will get upstreamed
<DC-IRC> [Discord] <efectn> it looks like there are still a lot to do
<DC-IRC> [Discord] <mecoblock> I think by the end of the year we’re gonna have HDMI, Vulkan, Most of the decoders maybe H264 encoding.
<DC-IRC> [Discord] <efectn> it'd be great. rkvdec2 and panvk are promising
<DC-IRC> [Discord] <mecoblock> Can someone running a panthor image try running rusticl? Can be done in docker with three steps: http://paste.armbian.com/ujahosuzeb.yaml
<DC-IRC> [Discord] <spooky8086> I would note - if blob versions do not match the DMC will be disabled leading to a large preformance impact on memory.
<DC-IRC> [Discord] <rpardini> Interesting. Most mismatches I've found are eMMC vs SD, but some have had SPI vs eMMC and so on.
<DC-IRC> [Discord] <rpardini> I suppose we can detect the DMC being disabled (in userspace) and warn the user...?
<DC-IRC> [Discord] <mecoblock> btw I got it "running" on RK3568 (since I was running mainline on that system). Spit out more errors than I could count trying to run geekbench6‘s gpu test.
<DC-IRC> [Discord] <spooky8086> There is a message in u-boot that gives a warning, though I did not check in userspace to see if DMC was disabled, but I'm sure we should be able to see it's disabled.
<DC-IRC> [Discord] <c133> so I soldered a GD25Q64B SPI flash chip to a Rock64. and it seems like I didn't mess it up too badly, because:
<DC-IRC> [Discord] <c133> SF: Detected gd25q64b with page size 256 Bytes, erase size 4 KiB, total 8 MiB
<DC-IRC> [Discord] <c133> SF: 1073096 bytes @ 0x8000 Written: OK
<DC-IRC> [Discord] <c133> but it doesn't seem like the Rock64 is actually using it to boot for some reason. I get no serial output when I boot unless I have a microSD card inserted, and then it just seems to load whatever u-boot is on the SD card.
<DC-IRC> [Discord] <c133> so I soldered a GD25Q64B SPI flash chip to a Rock64. and it seems like I didn't mess it up too badly, because I was able to flash it:
<DC-IRC> [Discord] <c133> SF: Detected gd25q64b with page size 256 Bytes, erase size 4 KiB, total 8 MiB
<DC-IRC> [Discord] <c133> SF: 1073096 bytes @ 0x8000 Written: OK