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] <narga_64> Wow, I didn't even know uboot had a menu where you can choose what to boot! I need to look into `extlinux.conf` π€
<DC-IRC>
[Discord] <narga_64> I assume uboot has to work with HDMI for this?
<DC-IRC>
[Discord] <rpardini> This is over serial console / UART.
<DC-IRC>
[Discord] <amazingfate> For HDMI you can use edk2+grub
<DC-IRC>
[Discord] <rpardini> Yep, that also works.
<DC-IRC>
[Discord] <rpardini> - For the u-boot menu build with `EXT=u-boot-menu` and just install multiple linux-image + linux-dtb pairs. edge might have different DTB name though and that's not accounted for by default
<DC-IRC>
[Discord] <rpardini> - From edk2+grub build with `EXT=uefi-edk2-rk3588` and you'll get menu with option for "UMS mode" out of box
<DC-IRC>
[Discord] <rpardini> Yep, that also works.
<DC-IRC>
[Discord] <rpardini> - For the u-boot menu build with `EXT=u-boot-menu` and just install multiple linux-image + linux-dtb pairs. edge might have different DTB name though and that's not accounted for by default
<DC-IRC>
[Discord] <rpardini> - For edk2+grub build with `EXT=uefi-edk2-rk3588` and you'll get menu with option for "UMS mode" out of box
<DC-IRC>
[Discord] <rpardini> both those have received very little testing so far but might work
<DC-IRC>
[Discord] <narga_64> Makes sense. I've only used UART for debugging so far. Often the output is a bit borked though (using `minicom`). Like for example `nano` is unusable over serial. But I guess that's a limitation about how UART works
<DC-IRC>
[Discord] <narga_64> Thanks, I'll give it a try π
<DC-IRC>
[Discord] <lanefu> Try `picocom` rpardini successfully converted me
<DC-IRC>
[Discord] <rpardini> Yes. The serial must guess what's the size of the terminal and it's capabilities. You can configure the systemd unit to force a specific TERM and size etc if you know them in advance.
<DC-IRC>
[Discord] <rpardini> But yeah usually I just use it for bootlogs and establishing network, then I move over to SSH.
<DC-IRC>
[Discord] <narga_64> Whaaaat, just tried it and `nano` works more or less like normal. Even `armbian-config` works. So far it seems better than `minicom`.
<DC-IRC>
[Discord] <narga_64> Is there a way to prevent `picocom` deleting lines or clearing the screen?
<DC-IRC>
[Discord] <narga_64> When u-boot does its thing, at some point it clears like the last 30 lines or so and I can't get them by scrolling up.
<DC-IRC>
[Discord] <narga_64> Interesting! I guess I'll just make my terminal small to fit the size I see when I open nano. Maybe this was the issue with `minicom` as well, my terminal was the wrong size. Will try that out tomorrow.
<DC-IRC>
[Discord] <rpardini> Well it's not u-boot, usually, it's either the initrd or some systemd unit
<DC-IRC>
[Discord] <rpardini> it varies by distro too - some Debian releases do different than Ubuntu releases. I never tracked it down though
<DC-IRC>
[Discord] <narga_64> Ah yes, you're right. it's closer to the end of the boot process.
<DC-IRC>
[Discord] <narga_64> Oh I thought it was a `minicom/picocom` thing.
<DC-IRC>
[Discord] <narga_64> As a workaround I save the output to a file. `minicom` can not remove lines from my file π
<DC-IRC>
[Discord] <rpardini> Nah. You can tinker with `/etc/systemd/system/serial-getty@.service.d/override.conf`
<DC-IRC>
[Discord] <rpardini> `man agetty` reveals things
<DC-IRC>
[Discord] <narga_64> This config has `INSTALL_HEADERS="yes"` hardcoded and I wanted to find out why someone put this line there. So I looked at the commit history of the file.
<DC-IRC>
[Discord] <narga_64> At commit "Update report" the `INSTALL_HEADERS` line is missing. After that, only 2 commits are shown which only renamed the file. In the current file, the line is there though.
<DC-IRC>
[Discord] <narga_64> Where did it come from? π€ It's a mystery to me...
<DC-IRC>
[Discord] <narga_64> Thanks, I'll have a look!
<DC-IRC>
[Discord] <narga_64> Just realized even more things changed between those commits. "File renamed without changes." is somehow not true. I think either Git or GitHub is hiding something π€
<DC-IRC>
[Discord] <narga_64> Ahhh I solved the mystery! π‘
<DC-IRC>
[Discord] <narga_64> File got renamed from `.csc` to `.wip` and then back to `.csc`. Changes were made to the `wip` file, but these are not shown when looking at the commit history of the `csc` file.
<DC-IRC>
[Discord] <narga_64> (Sorry for the spam π)
<DC-IRC>
[Discord] <narga_64> I still don't understand why `INSTALL_HEADERS="yes"` is hardcoded in the board config though π
<DC-IRC>
[Discord] <amazingfate> Use git blame to find who own this change.
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC>
[Discord] <rpardini> My guess? This came from `nanopi-r5c.csc`
<DC-IRC>
[Discord] <rpardini> Or not... maybe it's the other way around.
<DC-IRC>
[Discord] <rpardini> Let us know, @lanefu
<DC-IRC>
[Discord] <lanefu> R5c came from r5s
<DC-IRC>
[Discord] <rpardini> I bet you had some dkms or such in there at some point during development
<DC-IRC>
[Discord] <lanefu> Install headers was likely already there when I took on the board. Or cuz I copied from something else, but I also subscribe to the philosophy of shipping headers on a board like that so people don't bitch about it later when they try to install a stupid USB wifi or whatever
<DC-IRC>
[Discord] <rpardini> Yeah. I'm partial to shipping headers as a (compressed) linux-headers .deb in `/usr/src` -- jsut because installing it during image build takes a lot of time and is large-ish
<DC-IRC>
[Discord] <narga_64> Ahhh I never really used `git blame`. I'll have to learn it, sounds useful!
<DC-IRC>
[Discord] <rpardini> user offline, needs a wifi driver, has source on pendrive, but no headers, he can always install/build headers on the spot and costs few mb.
<DC-IRC>
[Discord] <rpardini> @Narga you can send a PR removing those INSTALL_HEADERS from those 2 boards
<DC-IRC>
[Discord] <rpardini> it's literally the only 2 boards that have it
<DC-IRC>
[Discord] <narga_64> Alright will do tomorrow π
<DC-IRC>
[Discord] <rpardini> ofc Lane will have to approve it
<DC-IRC>
[Discord] <rpardini> I'll accept bribes in his name too
<DC-IRC>
[Discord] <lanefu> I left r5s as .CSC to keep my accountability low
<DC-IRC>
[Discord] <narga_64> Yeah that's why I tried to figure out why it's there. Maybe there was some reason I don't understand yet or something else why it's needed π
<DC-IRC>
[Discord] <narga_64> I'm running the R5C with updated uboot for a while now, can PR that update too (should work for R5S too)
<DC-IRC>
[Discord] <rpardini> Oh that's bad. It's a very old linked-against-god-knows-who binary to make a spinner logo we don't use
<DC-IRC>
[Discord] <c0rnelius77> Indeed. If I delete it the run the builds fin fine. I just thought I would let you know.
<DC-IRC>
[Discord] <rpardini> I hoped that would have rotten away and died long ago
<DC-IRC>
[Discord] <narga_64> Oh I'm still using kwiboo's uboot repo. Just using his 2024.1 branch. Was also using 2024.4 for a while without problems.
<DC-IRC>
[Discord] <narga_64> But I don't know enough to judge if mainline uboot would be the better pick. I could try out mainline though
<DC-IRC>
[Discord] <c0rnelius77> also not sure if matters but in this use case I'm on Jammy. Don't recall having the issue on Bookworm.
<DC-IRC>
[Discord] <rpardini> I suppose the plymouth stuff completely replaced that old throbber animation, that even required kernel patches to show etc if I'm not mistaken?
<DC-IRC>
[Discord] <narga_64> I don't think I have ever seen this loading icon π
<DC-IRC>
[Discord] <rpardini> This is from 10+ years ago
<DC-IRC>
[Discord] <narga_64> Have you been with Armbian for this long? Damn, respects ππ
<DC-IRC>
[Discord] <rpardini> Nah just a couple years for me, but I ran git blame before _clearly_ hiding the crap under the carpet
<DC-IRC>
[Discord] <narga_64> A couple of years is still quite respectable
<DC-IRC>
[Discord] <amazingfate> At GitHub code page, click `blame`
<DC-IRC>
[Discord] <narga_64> Oh I feel so dumb now... It's so easy... This button has always been there and I have never even once used it. Seems like I successfully ignored it π
<DC-IRC>
[Discord] <rpardini> Binary is ancient, but boot_logo stuff is from 2020: https://github.com/armbian/build/pull/2065 - Igor will later let us know if still used, I don't think so
<DC-IRC>
[Discord] <rpardini> off to bed, although insommia. π«‘
<DC-IRC>
[Discord] <narga_64> Oh I feel you π
<DC-IRC>
[Discord] <narga_64> Thanks everyone for the discussions, I learned some new things again π
<DC-IRC>
[Discord] <nottoosmart> is there still no working bookworm version of armbian for the orangepi 5+
<DC-IRC>
[Discord] <Werner> DIY?
<DC-IRC>
[Discord] <kwiboo> @lanefu @narga_64 mainline u-boot 2024.01 should have sufficient rk356x support merged, there are some improvements merged in latest 2024.04 rc
<DC-IRC>
[Discord] <kwiboo> my branches contain patches that hopefully will be merged for 2024.07, and a few work-in-progress not yet on mailing list
<DC-IRC>
[Discord] <kwiboo> current focus have been to improve support on rk3308, rk3328 and rk3399 family of devices
<DC-IRC>
[Discord] <lanefu> Awesome. Thank you for confirming.
<DC-IRC>
[Discord] <lanefu> Awesome. Thank you for confirming..... And doing all the hard work
<DC-IRC>
[Discord] <narga_64> Awesome, thanks a lot! I'll try my R5C with mainline 2024.4 then.
<DC-IRC>
[Discord] <narga_64> When testing new uboot versions, am I correct on the assumption that testing is only needed for the boot process itself? Like, there is no need to do any tests on the live system once it has booted?
<DC-IRC>
[Discord] <narga_64> (with testing I don't mean in-depth tests of every uboot function, I just mean "has this update introduced any catastrophic failures on this specific device or does it still work and boot without issues")
<DC-IRC>
[Discord] <kwiboo> I would think so, if OS boots there is not more to test unless you depend on specific uboot functionality
<DC-IRC>
[Discord] <kwiboo> I have seen report of possible ethernet issues in linux on e.g. quartz64-b, after ethernet support was enabled in u-boot, so might be good to confirm if you see any changes in lost packets after updating u-boot on rk356x
<DC-IRC>
[Discord] <lanefu> Reminds me I need to setup my 2nd r5s to test regressions easily. (My first r5s is my router). Funny how these things cascade into more work lol
<DC-IRC>
[Discord] <narga_64> Yeah I purchased my R5C to use as a router with OpenWRT as well. But for now it's running Armbian π
<DC-IRC>
[Discord] <lanefu> Make Armbian a router π€
<DC-IRC>
[Discord] <liwei19920307> I tried the above two Bluetooth writing methods in dts, wifi is normal, but Bluetooth can't get the mac address, and /dev can't find ttyS1
<DC-IRC>
[Discord] <liwei19920307> Thank you all, you are all great. I still have a lot to learnπ€£π«‘
<DC-IRC>
[Discord] <narga_64> Me too π
<DC-IRC>
[Discord] <shivansps> panfork? or it is panthor somehow?
<DC-IRC>
[Discord] <monkablyat> Yeah good question
<DC-IRC>
[Discord] <monkablyat> I hope this new vendor kernel works with panthor
<DC-IRC>
[Discord] <amazingfate> not now
<DC-IRC>
[Discord] <amazingfate> Panfrost for rk3568 works fine.
javabean_ has joined #armbian-rockchip
javabean has quit [Ping timeout: 240 seconds]
javabean_ is now known as JavaBean
<DC-IRC>
[Discord] <rpardini> The Khadas Edge2 stuff was mostly rotting there since that very first version kernel we did, was it rkr3? Something like that. I never followed up since I only had the board for a few days
<DC-IRC>
[Discord] <rpardini> I dunno even if Khadas themselves ever updated from that very first .66 kernel
<DC-IRC>
[Discord] <rpardini> also: I was hasty in enabling `vendor` branch for kedge2 and cm3588, apparently.
<DC-IRC>
[Discord] <rpardini> I was hasty in general, but specially for those two heh
<DC-IRC>
[Discord] <rpardini> guess we should push to armbian/linux-rockchip and let the PRs talk? or ya'll still rebasing constantly?
<DC-IRC>
[Discord] <efectn> Yeah i also tested it with legacy before. It wasn't at good condition