ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
sakman has quit [Quit: sakman]
heat has quit [Ping timeout: 260 seconds]
iivanov_ has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
ajb-linaro has joined #armlinux
jwerner_ has joined #armlinux
hanetzer1 has joined #armlinux
vup2 has joined #armlinux
punit` has joined #armlinux
iivanov has quit [Ping timeout: 264 seconds]
punit has quit [Ping timeout: 264 seconds]
hanetzer has quit [Ping timeout: 264 seconds]
jwerner has quit [Ping timeout: 264 seconds]
ajb-lina- has quit [Ping timeout: 264 seconds]
vup has quit [Ping timeout: 264 seconds]
shailangsa has joined #armlinux
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 255 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #armlinux
tambarus has quit [Ping timeout: 256 seconds]
tambarus_ has quit [Ping timeout: 256 seconds]
iivanov has joined #armlinux
iivanov_ has quit [Ping timeout: 255 seconds]
vup2 has quit [Ping timeout: 255 seconds]
vup has joined #armlinux
matthias_bgg has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #armlinux
ezulian has joined #armlinux
milkylainen has quit [Ping timeout: 260 seconds]
milkylainen has joined #armlinux
milkylainen has quit [Ping timeout: 264 seconds]
milkylainen has joined #armlinux
milkylainen has quit [Ping timeout: 255 seconds]
milkylainen has joined #armlinux
mvaittin has joined #armlinux
amitk_ has joined #armlinux
ezulian has quit [Quit: ezulian]
amitk has quit [Ping timeout: 272 seconds]
milkylainen has quit [Ping timeout: 246 seconds]
cbeznea_ has joined #armlinux
milkylainen has joined #armlinux
milkylainen has quit [Ping timeout: 255 seconds]
monstr has joined #armlinux
gclement has joined #armlinux
milkylainen has joined #armlinux
rgallaispou has joined #armlinux
frieder has joined #armlinux
ezulian has joined #armlinux
pivi has quit [Ping timeout: 260 seconds]
vingu has quit [Quit: Leaving.]
vingu has joined #armlinux
headless has joined #armlinux
qpla has joined #armlinux
nsaenz has joined #armlinux
sszy has joined #armlinux
hanetzer1 is now known as hanetzer
luispm has quit [Quit: Leaving]
tambarus has joined #armlinux
tambarus_ has joined #armlinux
matthias_bgg has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #armlinux
proton has joined #armlinux
headless has quit [Quit: Konversation terminated!]
qpla has quit [Remote host closed the connection]
heat has joined #armlinux
proton has quit [Ping timeout: 268 seconds]
qpla has joined #armlinux
qpla has quit [Quit: Leaving]
apritzel_ has joined #armlinux
luispm has joined #armlinux
heat has quit [Remote host closed the connection]
heat has joined #armlinux
prabhakar has quit [Quit: Connection closed]
prabhakar has joined #armlinux
prabhakarlad has joined #armlinux
heat has quit [Remote host closed the connection]
heat has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
psydroid has joined #armlinux
prabhakar has joined #armlinux
prabhakarlad has joined #armlinux
headless has joined #armlinux
iivanov has quit []
pivi has joined #armlinux
ungeskriptet has quit [Ping timeout: 252 seconds]
ungeskriptet has joined #armlinux
Amit_T has joined #armlinux
<milkylainen>
freebsd deprecating support for 32-bit platforms in 15.0, including armv7 in 16.0? A bit sooner than I expected, but then again, not a lot of people use freebsd on such hardware I guess?
<milkylainen>
Just trying to get a reaö
<milkylainen>
realitycheck for 32-bit hw in general.
<maz>
I like the stance they made on RISC-V 32bit ("let's not bother").
<javierm>
milkylainen: Fedora retired armv7 support almost 2 years ago. As a Fedora user I was a little bit sad, but can understand the reasons
<milkylainen>
javierm: mm. Sometimes I wonder how to best dissuade companies from using very old designs as new implementations. I have a very recent case which I think is just utterly stupid. But the comment is always "is cheaper". Maybe it needs axing so we can easier move into a more sane world.
<milkylainen>
Like taking removing fire from the hands of kids, because you know they'll get burned. :)
<milkylainen>
taking/removing.
<milkylainen>
Very controversial opinion I guess.
mvaittin has quit [Ping timeout: 246 seconds]
headless has quit [Quit: Konversation terminated!]
<geertu>
milkylainen: It will just become more expensive when Y2038 arrives on their short-distance radar, eventually...
<milkylainen>
geertu: There is cost involved in less and less mass using a platform. Now v7a still has a large userbase. But thinks like 32-bit ppc aren't that many around anymore. Atleast not ones wanting the latest kernel on it.
<milkylainen>
s/thinks/things
<geertu>
milkylainen: Someone in the AU Navy once told me: Given how long we've been using the m68k MVME boards, I'm quite sure we will be using 32-bit PPC MVME boards in 2038...
<milkylainen>
geertu: Absolutely. But they'd be runnin 2.6.x something and never change. :)
<geertu>
milkylainen: Except that external time advances, and time_t will wrap...
<milkylainen>
geertu: "fix time, but don't change anything else. It's a certified software stack".
<milkylainen>
:)
<robmur01>
v7 will live on forever in embedded, but in general embedded doesn't care about distros :/
<arnd>
milkylainen, geertu: I think what changed over the past few years is that almost nobody is using 32-bit hardware for new projects any more the way they used to not that long ago
<robmur01>
true EOL is when the likes of Yocto drop 32-bit support ;)
<arnd>
in 2023 we had one new armv5 soc and three armv7 socs, compared to 20+ new arm64 socs, and the ratios for boards were similar. I expect to see even fewer in 2024
<milkylainen>
robmur01: Does a sane build env care much about build bitness? I mean, you have a cross compiler. Things are pretty high level with the tools. Yocto shouldn't care much?
<arnd>
of course, some of these are incredibly long-lived and people will use e.g. stm32mp1 forever, as well as run 32-bit userland on cortex-a35s
<milkylainen>
feels like a forever poison pill. people will use it for as long as it is provided.
<milkylainen>
arnd: but a 32-bit userland should be fine? I'm mostly talking about how long the kernel should care about 32-bit machines that almost never sees new projects. 32-bit ppc?
<geertu>
milkylainen: The issues will start when package maintainers start dropping support for anything not 64-bit little endian
<robmur01>
milkylainen: Arm is "special" in that it's not a bitness concern, it's a whole-other-entirely-independent-target concern
<arnd>
milkylainen: so far it's fine, I agree with geertu that upstream packages will get worse over time, I have definitely come across packages that explicitly require 64-bit mode, and complex stuff (web browsers, libreoffice, machine learning stuff, ...) eventually all grows beyond what you can fit into a 32-bit virtual address sapce
<robmur01>
so the lifecycle is however long people remain motivated to maintain the "old" target
<robmur01>
(which, as mentioned, I would expect in practice is likely to be quite long)
<milkylainen>
v7a is probably going to live for a very long time indeed.
<arnd>
sam9x7 certainly shows how long the long tail can be for maintenance, I think the AT91RM9200 out in 2002 and remains in production, while sam9x7 is the latest in that family and came out in 2023 as a drop-in replacement for everything inbetween
<arnd>
the last cortex-a7 will likely be similarly long after its original release
<milkylainen>
arnd: yes. It's also a sam9x60 they have choosen to pester my ideas about a long lived arch with. ;)
marc|gonzalez has joined #armlinux
<marc|gonzalez>
robher: hi! about DT overlays, are you saying we cannot use the -@ flag?
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar85 has joined #armlinux
prabhakarlad has joined #armlinux
prabhakar has quit [Ping timeout: 268 seconds]
<robher>
marc|gonzalez: Not at all. I'm saying upstream overlays must apply to an upstream base DT and you must prove that at build time.
tambarus has quit [Ping timeout: 264 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
tambarus_ has quit [Ping timeout: 272 seconds]
prabhakar85 has quit [Ping timeout: 264 seconds]
<milkylainen>
I won't be recommending any 32-bit hw designs though.
<marc|gonzalez>
robher: so that means the build will create the base DTB + 2 overlays + 2 full DTBs?
<marc|gonzalez>
My understanding was that overlays were useful also to save space for distros? (May have misunderstood)
<geertu>
marc|gonzalez: Yes they are. But they cannot be validated properly without applying them to a base DTB first.
<geertu>
It does become complicated when you have N dtsos that can be used with M dtbs. Do you provide rules to apply each dtbo to a sample dtb, or rules to handle all possible combos?
<marc|gonzalez>
If I have 3 variants on feature A (A1, A2, A3) and 4 variants on feature B (B1, B2, B3, B4) it means I have 12 possible boards, but only need to merge the 7, so I "save" 5 DTBs?
<marc|gonzalez>
Add 2 variants on feature C (C1, C2) => 24 boards vs 9 overlays to test?
tambarus has joined #armlinux
tambarus_ has joined #armlinux
<marc|gonzalez>
geertu: dunno if I made sense?
<geertu>
marc|gonzalez: What is a feature? An overlay for an expansion board?
tambarus_ has quit [Read error: Connection reset by peer]
tambarus has quit [Read error: Connection reset by peer]
<marc|gonzalez>
Right, feature X = overlay for a specific node, so X1/X2/X3 are 3 mutually exclusive overlays
<marc|gonzalez>
And different features are orthogonal
<marc|gonzalez>
So we can compose A1 + B3 + C2 for example
<geertu>
marc|gonzalez: Yeah, that quickly explodes, if you want to have all combos in the Makefile
<geertu>
I think one of each is good enough for validation.
<geertu>
Your users may complain why the build does not produce "full DTBs
<geertu>
" for all combos
prabhakarlad has joined #armlinux
<robher>
marc|gonzalez: Add the combination to 'dtb-' rather than 'dtb-y' if you don't want the applied overlay installed. If you had a full dtb upstream and then split it to a base+overlay, then the full dtb should also be installed.
<marc|gonzalez>
My initial understanding was that we should mainline the base DTS + the overlay fragments, build the base DTB with -@ and merge the various appropriate DTBOs at run-time BUT 1) user-space support does not seem to be ready YET and 2) robher stated that the fragments should be tested
<marc|gonzalez>
robher: with dtb-$(CONFIG_ARCH_MESON) for example?
<robher>
marc|gonzalez: Your understanding is correct. There are little plans for "userspace" support, runtime applying is mainly done by bootloaders.
gclement has quit [Quit: Leaving.]
<robher>
marc|gonzalez: dtb-$(CONFIG_ARCH_MESON) is dtb-y. 'dtb-' is "no" by default, but there is a kconfig option to build all dtbs which adds $(dtb-) to ${dtb-y). The result is an allyesconfig build builds all dtbs.
headless has joined #armlinux
prabhakar has joined #armlinux
<marc|gonzalez>
robher: could I just not mention the base DTB *at all* as a target? (It gets built only as a requirement)
gclement has joined #armlinux
gclement has quit [Quit: Leaving.]
<robher>
marc|gonzalez: Yes, but then the base DTB will not be installed by dtbs_install
<marc|gonzalez>
robher: I think that's the desired behavior, there is no actual board with the base DTB. It was originally a DTSI, but narmstrong suggested using DT overlays
<robher>
marc|gonzalez: No point in overlays if there is no one applying them at runtime.
<marc|gonzalez>
robher: runtime, in the boot loader?
<marc|gonzalez>
(because Linux does not support dynamically tweaking the DTB from user-space, right)
<robher>
marc|gonzalez: yes
<narmstrong>
ok so the initial proposition is right ?
<marc|gonzalez>
Thanks, things are much clearer (starting from "not much")
<marc|gonzalez>
narmstrong: I think phh wants to use overlays because he wants to load the right fragment in the boot loader
<marc|gonzalez>
right now, he reboots the system based on some input
<narmstrong>
marc|gonzalez: yes this is what I understood
<marc|gonzalez>
OK so v3 incoming then
<phh>
marc|gonzalez: it's also because of possibly incoming dvb, which will add another dimension, but technically only 3 variants exist in the field.
<phh>
though if we wanted to also add DDR, it'll also increase number of variants (but we probably won't do that)
<narmstrong>
phh: usually memory size is added by the bootloader in the DT, we usually don't use variants for that
<phh>
narmstrong: not size, but timings
<phh>
like we at least have ddr3 and ddr4
<phh>
and uh maybe other variants intra-ddr3/intra-ddr3 that i don't remember
<narmstrong>
if linux is concerned yeah indeed
<phh>
narmstrong: ddr timings are exclusively in uboot not linux? I thought they shared dtb 1:1
<narmstrong>
phh: mainline uboot doesn't care about ddr timings (yet ?), it's a downstream thing
rgallaispou has quit [Quit: Leaving.]
snalty has quit [Ping timeout: 240 seconds]
proton has joined #armlinux
gclement has joined #armlinux
marc|gonzalez has quit [Quit: Leaving.]
gclement has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
vingu has quit [Quit: Leaving.]
vingu has joined #armlinux
apritzel_ has quit [Ping timeout: 268 seconds]
luispm has quit [Quit: Leaving]
monstr has quit [Remote host closed the connection]
heat has quit [Read error: Connection reset by peer]