ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Off-Topic: #armbian-offtopic | Logs: -> irc.armbian.com
califax has quit [Remote host closed the connection]
califax has joined #armbian
<DC-IRC> <Tonymac32> Me: I'll stick mainline on My FrienlyElec R5S
<DC-IRC> <Tonymac32> also me:
<DC-IRC> <Tonymac32> fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
<DC-IRC> <Tonymac32> it's no wonder no one mainlines these things, I have to print out 5 device trees and consult some runes to make one that works
<DC-IRC> <Tonymac32> this is a terrible way to name stuff
<DC-IRC> <Tenkawa> @MacKahan I know you aren't using them yet/ever but... this is fun....
<DC-IRC> <Tenkawa> Linux vf2 6.3.2-vf2+ #3 SMP Mon May 15 19:33:55 EDT 2023 riscv64 GNU/Linux.. mainline slowly getting there
<DC-IRC> <RichN> trying to sell off a t4 now and wait for my t6 to get dispatched
<DC-IRC> <Tenkawa> this is what's being prepared to merge
<DC-IRC> <Tonymac32> haha sell off the T4? did it hurt you?
<DC-IRC> <Tonymac32> it's be one of the only RK3399's I would keep 😄
<DC-IRC> <Tonymac32> so rev 4 includes rev 2 includes common
<DC-IRC> <Tonymac32> sweeeet
<DC-IRC> <RichN> no its not being used ... I spend most my time working on the uefi imgs in utm on mac
<DC-IRC> <RichN> so I can test build imgs and add options to make them perform better
<DC-IRC> <Tonymac32> I spend most of my time in WSL2 on Windows 😄
<DC-IRC> <RichN> but I agree on the naming issue
<DC-IRC> <RichN> and there has to be a way for it to be cleaned up
<DC-IRC> <Tonymac32> thankfully the one I want isn't tangled too badly
<DC-IRC> <Tonymac32> so RK3568-nanopi-r5s.dts or whatever
<DC-IRC> <RichN> well we need to get one started for the 3588
<DC-IRC> <RichN> but all is good
<DC-IRC> <Tonymac32> I'm not worried about the rk3588 just yet, the 68 actually works with mainline, it's just sloppy ass device trees holding these boards back in the craptastrophy that is the rockchip garbage pile kernel
<DC-IRC> <Tonymac32> I'm guessing if an rk3588 device tree is ready by the next LTS it should be something worth looking at
<DC-IRC> <RichN> ok
<DC-IRC> <Tonymac32> so there's time, I just need beer and an evening
<DC-IRC> <RichN> I will get you a 12 pack
<DC-IRC> <Tonymac32> haha
<DC-IRC> <RichN> and lock you in the basement
<DC-IRC> <RichN> lol
<DC-IRC> <Tonymac32> lol
<DC-IRC> <Tonymac32> tell FE we need 16 MB spi flashes on all boards, I saw those unpopulated pads on my R5S
<DC-IRC> <RichN> well I am working to figure out all the desktop issus on debian for bookworm and for sid
<DC-IRC> <Tonymac32> 😄
<DC-IRC> <RichN> yeah I need to talk to bing about it
<DC-IRC> <Tonymac32> and don't you dare put some bullshit Rockchip u-boot on there, Rockchip's dev team got lost somewhere in 2017 and never escaped
<DC-IRC> <Tonymac32> 😄 😄
<DC-IRC> <c0rnelius> there s already a functional dts/dtsi for the NanoPi R5S/C
lemonzest has quit [Quit: WeeChat 3.6]
<DC-IRC> <Tonymac32> oooo, it's a dtsi, where is the dts
<DC-IRC> <Tonymac32> and 2 months old
<DC-IRC> <Tonymac32> there it is
<DC-IRC> <Tonymac32> I had my search pinned to 6.1
<DC-IRC> <Tonymac32> gracias
<DC-IRC> <c0rnelius> yeap
<DC-IRC> <c0rnelius> you just need to backport it to 6.1
<DC-IRC> <Tonymac32> now the trick is, did they make a mess like they did the nanopi4 lineup
<DC-IRC> <Tonymac32> even the mainline tree is gross
<DC-IRC> <c0rnelius> not sure. my t4 is ok.
<DC-IRC> <Tonymac32> it works, I'm not saying there's a functional issue
<DC-IRC> <Tonymac32> I'm saying the logical organization is... insane
lemonzest has joined #armbian
<DC-IRC> <jkent> @MacKahan oh yeah that naming of the DTS just irks me
<DC-IRC> <jkent> I couldn't get 6.1 doing PCIe on the T4 myself
<DC-IRC> <Tonymac32> hmmmm
<DC-IRC> <Tonymac32> ever since Oleg put it in the media kernel I haven't updated anything
<DC-IRC> <jkent> It's a serious regression
<DC-IRC> <jkent> Maybe I'll find some time to look at it
<DC-IRC> <jkent> Yeah I think I'll just drop one of my projects for a little while
<DC-IRC> <RichN> 1 big issue that still needs fixing in armbian is the extfs as the armbian install breaks
<DC-IRC> <RichN> so it has to be plain uboot or uefi
<DC-IRC> <RichN> and no one has fixed it in years or looked at it
<DC-IRC> <RichN> so I do think we will have to move alot of boards to uefi
<DC-IRC> <RichN> and grub
val has quit [Ping timeout: 256 seconds]
val has joined #armbian
jclsn has quit [Ping timeout: 265 seconds]
jclsn has joined #armbian
tachi_ has joined #armbian
jantones has quit [Ping timeout: 240 seconds]
tachi_ has quit [Quit: Leaving]
mlu has left #armbian [#armbian]
loki_val has joined #armbian
crabbedhaloablut has quit [Read error: Connection reset by peer]
zeemate has joined #armbian
ikmaak has quit [Ping timeout: 240 seconds]
ikmaak has joined #armbian
Schrostfutz has joined #armbian
<Schrostfutz> Hi, I'm trying to use stateless v4l2 decoders on a rock pi 4. The API is fairly recent so I am checking the kernel version. The image I have is running a 5.15 kernel, so I was assuming e.g. this commit (https://github.com/torvalds/linux/commit/95e95ebe9119dcdf04e8aa9e1d9e8de4f1150c67) would be present, since it was added in 5.11. However, the constant seems to be missing in the image. This is just an example, there is a number of mismatches and
<Schrostfutz> I'm wondering whether I am misunderstanding something with how kernel versions work, is this to be expected?
<DC-IRC> <IgorPec> without diffing in ... code is often moved around, so perhaps its not at this location anymore.
<Schrostfutz> That's what I thought, but it is not present at all. The constant I mention (V4L2_PIX_FMT_H264_SLICE) was moved to its current (6.4) location in that commit from its previous one, but it isn't present in either, even though the commit in question is introduced in 5.11 which precedes what I'm running (5.15).
<Schrostfutz> Or I am just looking in the wrong place... It seems the headers I am looking for are in /usr/src/linux-headers-5.15.80-rockchip64/... Then again, why are there two versions of kernel headers present, and which one should I consider?
<DC-IRC> <IgorPec> headers are those linux-headers-current-rockchip64
<DC-IRC> <IgorPec> so if you install linux-image-current-rockchip64 je have a match
<DC-IRC> <IgorPec> sadly for this video i'am not an expert to understand details
danilogondolfo has joined #armbian
Suspect has joined #armbian
Suspect has quit [Quit: Leaving]
zeemate has quit [Ping timeout: 240 seconds]
Schrostfutz has quit [Ping timeout: 240 seconds]
<DC-IRC> <Dal> is there a reason a ko module is inside an xz file?
<DC-IRC> <Dal> does it still recognise modules inside xz's?
archetech has joined #armbian
archetech has quit [Client Quit]
archetech has joined #armbian
ccatss08 has quit [Quit: The Lounge - https://thelounge.chat]
ccatss08 has joined #armbian
ccatss08 has quit [Client Quit]
ccatss08 has joined #armbian
ccatss08 has quit [Quit: The Lounge - https://thelounge.chat]
ccatss08 has joined #armbian
ccatss08 has quit [Client Quit]
ccatss08 has joined #armbian
<DC-IRC> <Tenkawa> @Dal the more recent kernels support module ie compression if configured ie:
<DC-IRC> <Tenkawa> CONFIG_MODULE_COMPRESS_NONE=y
<DC-IRC> <Tenkawa> # CONFIG_MODULE_COMPRESS_GZIP is not set
<DC-IRC> <Tenkawa> # CONFIG_MODULE_COMPRESS_XZ is not set
<DC-IRC> <Tenkawa> # CONFIG_MODULE_COMPRESS_ZSTD is not set
<DC-IRC> <Tenkawa> like XZ for example:
<DC-IRC> <Tenkawa> found in Linux kernels: 6.0–6.3, 6.4-rc+HEAD
<DC-IRC> <Dal> @Tenkawa ah that makes sense, sorry it's my first time finding a module inside an xz
<DC-IRC> <Tenkawa> Yeah I think it would have been nicer about 10-15 years ago when lower space requirements were a bigger offset than the overhead of cpu/io to uncompress the module now personally
<DC-IRC> <Tenkawa> There are still very small built systems (or ones they want to build extremely small though) so I can see where it is very useful
LanDi has joined #armbian
alekksander has joined #armbian
LanDi has quit [Read error: Connection reset by peer]
lyri has joined #armbian
lyri has quit [Ping timeout: 240 seconds]
lyri has joined #armbian
lyri has quit [Remote host closed the connection]
lyri has joined #armbian
danilogondolfo has quit [Ping timeout: 256 seconds]
alekksander has quit [Quit: Konversation terminated!]
<DC-IRC> <rpardini> `armbian/build` is for a few (6?) months now forcing `CONFIG_MODULE_COMPRESS_NONE=y`.
<DC-IRC> <rpardini> So if users are finding `.ko.xz` or such, they're handling really old builds.
<DC-IRC> <Tenkawa> @rpardini I was showing him "generic" explanations...
<DC-IRC> <rpardini> Sure, thanks, I was just wondering where he found `.ko.xz`'s...
<DC-IRC> <rpardini> Before the force of that config, roughly 50% of Armbian's 60-ish kernels had XZ compression. The rest, none.
lyri has quit [Ping timeout: 268 seconds]
lyri has joined #armbian
jantones has joined #armbian
archetech has quit [Quit: Konversation terminated!]
hook has quit [Ping timeout: 256 seconds]
hook has joined #armbian
smcavoy16 has quit [Quit: Ping timeout (120 seconds)]
smcavoy16 has joined #armbian
alekksander has joined #armbian
junaid_ has joined #armbian
lyri has quit [Ping timeout: 268 seconds]
lyri has joined #armbian
archetech has joined #armbian
junaid_ has quit [Remote host closed the connection]
<DC-IRC> <Dal> most of the boards I use have builds that have come from the archives
<DC-IRC> <Dal> generally buster releases
zeemate has joined #armbian
<DC-IRC> <RichN> wow you still use buster
<DC-IRC> <RichN> I figure most had updated to bullseye by now
alekksander has quit [Quit: Konversation terminated!]
<DC-IRC> <c0rnelius> and bookworm will be out shortly
lyri has quit [Ping timeout: 240 seconds]
lyri has joined #armbian
<DC-IRC> <Dal> it was just the path of least resistance, as we have been using a very old application that uses python3.7, gcc9, tensorflow1.15 etc etc etc
jantones has quit [Quit: Leaving]
<DC-IRC> <Dal> whilst we can install and compile it all on later releases, on the smaller sbc's it takes an age to compile
<DC-IRC> <Dal> the smaller, pocket sized sbc's are what we build on
<DC-IRC> <Dal> it was also why I enquired about a fast native armv7l board 😛
s1b1 has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<DC-IRC> <Tenkawa> @Dal you could setup a cross environment to build the software... that's quite easy
<DC-IRC> <Tenkawa> This way you can build it on faster hardware and then transfer it over to needed destinations
<DC-IRC> <Dal> I've had so many issues cross compiling that I just gave up
<DC-IRC> <Tenkawa> bummer
lyri has quit [Ping timeout: 240 seconds]
lyri has joined #armbian
s1b1 has joined #armbian
<DC-IRC> <patrickdk> I do not like cross compiling much, unless it's go
<DC-IRC> <patrickdk> I mostly just do it inside a docker container using the other enviroment using qemu to emulate it
<DC-IRC> <patrickdk> slow, but works well, and it's complex as it sounds
<archetech> I just use native
rockworld has quit [Quit: it was nice to meet you peace]
lyri has quit [Remote host closed the connection]
crabbedhaloablut has joined #armbian
loki_val has quit [Read error: Connection reset by peer]
jantones has joined #armbian
jantones has quit [Remote host closed the connection]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #armbian
zeemate has quit [Ping timeout: 248 seconds]