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> [Discord] <alexl83> here's the ouput from debug uart - it finds my nvme drive but doesn't boot
<DC-IRC> [Discord] <alexl83> my nvme boot partition ended up corrupted, rebuilt and now it boots
Javabean has joined #armbian-rockchip
<DC-IRC> [Discord] <alexl83> everytime I update u-boot from armbian-config my nvme boot partition gets unreadable
sfo has quit [Read error: Connection reset by peer]
sfo has joined #armbian-rockchip
<DC-IRC> [Discord] <igorpec> huh, that is weird
Javabean has quit [Remote host closed the connection]
Javabean has joined #armbian-rockchip
<DC-IRC> [Discord] <rpardini> Hey folks, "today" is v2024.10-rc3 -- is patching `include/configs/rockchip-common.h` to change `BOOT_TARGETS` order still the (only?) way to influence the default boot order on u-boot? 😄
<DC-IRC> [Discord] <rpardini> I really wish we could change default boot_targets ordering without patching or preboot tricks -- any ideas?
<DC-IRC> [Discord] <rpardini> (I feel like I'm missing something really simple like being able to set CONFIG_BOOT_TARGETS in .config)
<DC-IRC> [Discord] <c0rnelius77> I've only tried this on the BPI-F3; https://paste.armbian.com/elibeduhaj.bash
<DC-IRC> [Discord] <c0rnelius77> As I have it currently scripted it needs to be set to true, but its better than needing to patch it.
<DC-IRC> [Discord] <rpardini> Hmm, but that's a boot script fragment -- thus I think "too late" to change your mind. I was thinking how to influence bootstd ordering (pre-bootscript AFAIK)
<DC-IRC> [Discord] <kwiboo> What is the reason you think you need to change the default boot_targets and probably because of that also slow down boot?
<DC-IRC> [Discord] <rpardini> Well 90% of cases it's about "booting NVMe first"
<DC-IRC> [Discord] <rpardini> I understand scanning pcie slows things down for people on mmc
<DC-IRC> [Discord] <kwiboo> if you move nvme first then recovery boot or booting live images from e.g. sd-card will become harder for users?
<DC-IRC> [Discord] <rpardini> I usually go further, and do `usb / sdcard / nvme / mmc / others `
<DC-IRC> [Discord] <rpardini> usb _really_ slows down things, but makes sense for boards with spi -- its convenient for users to just flash Armbian-built uboot to SPI and then be able to boot pendrives
<DC-IRC> [Discord] <rpardini> but I agree it's not for _everybody_
<DC-IRC> [Discord] <rpardini> thus the reason why I ask how to let ppl easily customize boot order
<DC-IRC> [Discord] <kwiboo> if no bootflow is found on the faster medium it will try it on slower media, you can always change and save a custom boot_targets to u-boot env
<DC-IRC> [Discord] <rpardini> wait. tell me more about "faster medium first" -- what I'm looking at is simply https://github.com/u-boot/u-boot/blob/master/include/configs/rockchip-common.h#L16
<DC-IRC> [Discord] <kwiboo> yes, checking if there is something at mmc is faster then init nvme, sata or usb
<DC-IRC> [Discord] <rpardini> that ultimately ends up in `boot_targets` in env -- and, I agree, for boards with SPI I usually enable env-in-spi and be done with it
<DC-IRC> [Discord] <rpardini> (also like to enable easy userspace access eg fw_printenv to the in-spi-env for easy multiboot etc)
<DC-IRC> [Discord] <kwiboo> with u-boot 2024.07 and newer mmc env on rk will also follow the mmc device where u-boot proper was loaded, so should be safer to enable env in mmc now
<DC-IRC> [Discord] <rpardini> oh now that's very interesting.
<DC-IRC> [Discord] <kwiboo> https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-rockchip/board.c#L508-L536 here is the logic used to locate mmc dev to read env from
<DC-IRC> [Discord] <rpardini> thanks!
<DC-IRC> [Discord] <rpardini> still... I feel like there's a much easier way to change that BOOT_TARGETS #define sans-patching that I am missing?
<DC-IRC> [Discord] <rpardini> eg, with `scripts/config` we can let boards set menuconfig-equivalent config options, and avoid having maintainers "patch" the mainline defconfig
<DC-IRC> [Discord] <kwiboo> basically if you use SPL from u-boot 2024.07 (possible 2024.04), the boot device is added to FDT and u-boot proper will load env from the mmc dev where u-boot FIT was loaded from, or fall back on config dev num
<DC-IRC> [Discord] <rpardini> I wish I could offer a 1-liner for Armbian board maintainers allowing them to change boot order.
<DC-IRC> [Discord] <rpardini> I _could_ write a patch generator.... 🧻
<DC-IRC> [Discord] <kwiboo> I do not think you can change it too easy and may have to patch it in, it could possible be easier if u-boot env for rk moved to use text based .env files in u-boot instead of defines, but that is a much bigger task
<DC-IRC> [Discord] <rpardini> Yeah, it's no biggie -- literally one `sed` call really.
<DC-IRC> [Discord] <rpardini> Super thanks for the pointers on env-in-mmc-device-that-booted
<DC-IRC> [Discord] <kwiboo> still I do not really understand the need to change the default `boot_targets`, it is still possible to boot from nvme using the default `boot_targets` or is there some other issue preventing that?
<DC-IRC> [Discord] <rpardini> no, except user has to clear the emmc to boot from nvme
<DC-IRC> [Discord] <rpardini> user story is like this
<DC-IRC> [Discord] <rpardini> - user buys board; comes with vendor stuff on-emmc
<DC-IRC> [Discord] <rpardini> - boots it, tries vendor stuff, downloads & burns Armbian to SD card
<DC-IRC> [Discord] <rpardini> - somehow makes SD boot -- possibly mixing blobs in the process
<DC-IRC> [Discord] <rpardini> - armbian-installs to NVMe (NOT to eMMC)
<DC-IRC> [Discord] <rpardini> - expects to reboot into NVMe, but instead gets vendor eMMC again
<DC-IRC> [Discord] <kwiboo> they probably just have to remove the boot.scr, extlinux.conf or boot.efi from the emmc drive to skip u-boot from finding an OS to boot from emmc
<DC-IRC> [Discord] <kwiboo> can understand that user-flow better, thanks
<DC-IRC> [Discord] <rpardini> user generally ends up using armbian-install to flash Armbian-built u-boot to eMMC
<DC-IRC> [Discord] <rpardini> that's when Armbian's default bootorder comes into play
<DC-IRC> [Discord] <rpardini> if we don't change the bootorder, Armbian-uboot-in-eMMC will boot... _again_ the vendor stuff
<DC-IRC> [Discord] <kwiboo> yep, understand that flow better, even if the first thing I do on my devices is to wipe everything from any onboard emmc 😄
<DC-IRC> [Discord] <rpardini> I definitely agree it's a distro-only concern... u-boot's faster-to-scan-first default is defintely a good one
<DC-IRC> [Discord] <kwiboo> ideally you could possible have a default env bundled in the u-boot that is written onto the mmc device during install, not sure how to best do that
<DC-IRC> [Discord] <rpardini> Yeah preboot tricks also work there for env-is-nowhere scenarios
<DC-IRC> [Discord] <rpardini> and preboot, ugly as it is, can be set in .config.
<DC-IRC> [Discord] <rpardini> maybe all I need is to send a patch to rockchip-common.h that #ifdef CONFIG_ROCKCHIP_BOOT_TARGETS and uses it instead of default.
<DC-IRC> [Discord] <rpardini> and preboot, ugly as it is, can be set in .config.
<DC-IRC> [Discord] <rpardini> maybe all I need is to patch rockchip-common.h that #ifdef CONFIG_ROCKCHIP_BOOT_TARGETS and uses it instead of default.
<DC-IRC> [Discord] <kwiboo> that should probably work if you want to make it configurable instead of board specific patches
<DC-IRC> [Discord] <rpardini> Armbian's carrying at least 6 rockchip patches for boot-order change (and another dozen+ for configs/meson64.h which is(/was?) slightly different)
<DC-IRC> [Discord] <rpardini> either way, super thanks. For now I'll patch cm3588 to match our previous vendor-uboot setup & make .config fancy.
<DC-IRC> [Discord] <rpardini> btw love it you included CONFIG_LED_GPIO and GADGET stuff already 👍
<DC-IRC> [Discord] <kwiboo> hehe, yeah, I updated my local config test script (https://gist.github.com/Kwiboo/34c099fb42eb6ae5ed515a04275a7ed7) that looks for compatibles <-> config options to also include BUTTON, LED and GADGET options 🙂
<DC-IRC> [Discord] <rpardini> 💗 _compatibles <-> config options_
<DC-IRC> [Discord] <rpardini> hmm. wouldn't "recommended CONFIG_s" fit in somewhere in dtschema / yamls?
<DC-IRC> [Discord] <rpardini> although those'd be _kernel_ stuff
<DC-IRC> [Discord] <rpardini> but yeah I rely heavily on `/sys/kernel/debug/devices_deferred` to try and find missing kernel configs
* DC-IRC [Discord] <rpardini> goes run checkdtb.py on all the stuff
<DC-IRC> [Discord] <kwiboo> Hehe, mostly created it to assist when re-working/unifying rk3399 boards configs in u-boot, still run it at end of all my local test builds to see if there could be some option missing or something that can be removed
<DC-IRC> [Discord] <kwiboo> Ideally some/most of the options could/should be implied by platform and/or soc, something for another day
<DC-IRC> [Discord] <alexl83> HI guys! Just to let you know, especially @kwiboo - I tested 2024.10-rc3 mainline on rockchip-rk3588 (rock-5b) and it works, ARMV8_CRYPTO is still broken by the way
<DC-IRC> [Discord] <alexl83> I was about to send a PR to move rk3588 to mainline for current and edge, but if you're importing and patching with your secret sauce, I'll use your branch!
<DC-IRC> [Discord] <alexl83> HI guys! Just to let you know, especially @kwiboo - I tested 2024.10-rc3 mainline on rockchip-rk3588 (rock-5b) and it works, ARMV8_CRYPTO is still broken by the way
<DC-IRC> [Discord] <alexl83> I was about to send a PR to move rk3588 to mainline for current and edge (board rock-5b, thinking about orangepi5-plus too), but if you're importing and patching with your secret sauce, I'll use your branch!
<DC-IRC> [Discord] <igorpec> on which boards would this also have effect on? bpi m7 k-edge2?
<DC-IRC> [Discord] <ozus82> I got a rockpi e, with armbian 24.8.1 (bookworm) , after boot I cannot access the serial console anymore (ttyS2). During boot process boot messages is outputted to the console.
<DC-IRC> [Discord] <ozus82> I have added 1500000 baudrate in the /lib/systemd/system/serial-getty@.service but still no console access after boot.
<DC-IRC> [Discord] <ozus82> Any ideas why ?
<DC-IRC> [Discord] <kwiboo> mainline u-boot since 2024.04/07 should be very stable for rockchip aarch64 rk3xxx targets, my repo now mainly contains work in progress patches for e.g. small boot speed optimization and other unimportant features, my suggestion is to try and use upstream
<DC-IRC> [Discord] <alexl83> Ok @kwiboo - thanks for your suggestion, will follow it! 😉
<DC-IRC> [Discord] <superkali> @kwiboo Can i ask you some thing on DM?
<DC-IRC> [Discord] <superkali> @kwiboo Can i ask you some thingS on DM?
<DC-IRC> [Discord] <superkali> @kwiboo Can i ask you some things on DM?
<DC-IRC> [Discord] <kwiboo> My U-Boot work will probably slow down now that rk356x/rk3588 is in an okay state, may look at rk3576 and rk3528 in future, but my main focus now is on linux and ffmpeg completing old v4l2-request, rkvdec and hdmi work
<DC-IRC> [Discord] <kwiboo> Sure
<DC-IRC> [Discord] <superkali> thank you
<DC-IRC> [Discord] <superkali> i've sent you a friend request
<DC-IRC> [Discord] <lanefu> thanks so much for all the RK356x/rk3588 uboot work you've done the past year!
<DC-IRC> [Discord] <kwiboo> Thanks, it has been fun, I spent way to much time focused on U-Boot than originally planned, at least now I can start running linux on my boards ;D
<DC-IRC> [Discord] <lanefu> it's always funny what rabbit holes these things take you down.... for an extended period of time
<DC-IRC> [Discord] <ozus82> echoing to ttyS2 show output on the console so the console is 'still working' after boot, but it seems that I cant send anything to it. Anyone got any ideas why ?
<DC-IRC> [Discord] <kwiboo> so true, initial plan was to just try and get my new rk356x board booting and upstream some old rk33xx patch from libreelec, but down the rabbit hole I fell, finnaly back at surface level again, I think 😄
<DC-IRC> [Discord] <alexl83> next rabbit hole around the corner 😄
<DC-IRC> [Discord] <kwiboo> very likely, but have some old work/sins I really should try to finish up next, like ffmpeg v4l2-request https://ffmpeg.org/pipermail/ffmpeg-devel/2024-August/332034.html, rkvdec h264 hi10 https://lore.kernel.org/linux-media/20240618194647.742037-1-jonas@kwiboo.se/, rkvdec hevc https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.se/ before I start on something new
<DC-IRC> [Discord] <alexl83> go for it, it'll be great!
<DC-IRC> [Discord] <ioncube7221> can I do something same for board configuration file? I mean how can I overwrite existing?