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
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
nsaenz has joined #armlinux
xvmt has quit [Ping timeout: 252 seconds]
nsaenz has quit [Ping timeout: 265 seconds]
xvmt has joined #armlinux
iivanov has joined #armlinux
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #armlinux
iivanov has quit [Ping timeout: 258 seconds]
Saalim has quit [Ping timeout: 248 seconds]
Saalim has joined #armlinux
qpla has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 248 seconds]
heat has joined #armlinux
heat has quit [Ping timeout: 252 seconds]
cbeznea_ has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 276 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
sukrutb has quit [Remote host closed the connection]
iivanov has joined #armlinux
mvaittin has joined #armlinux
frieder has joined #armlinux
gclement has joined #armlinux
gclement has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
manchaw has quit [Quit: Connection closed for inactivity]
gclement has joined #armlinux
nsaenz has joined #armlinux
monstr has joined #armlinux
HerbY_NL has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
monstr has quit [Remote host closed the connection]
vingu has quit [Ping timeout: 244 seconds]
headless has joined #armlinux
mal`` has quit [Quit: Leaving]
vingu has joined #armlinux
mal`` has joined #armlinux
frieder has quit [Remote host closed the connection]
apritzel has joined #armlinux
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bencoh has quit [Remote host closed the connection]
bencoh has joined #armlinux
LeSpocky has quit [Ping timeout: 260 seconds]
HerbY_NL has joined #armlinux
LeSpocky has joined #armlinux
HerbY_NL has quit [Ping timeout: 260 seconds]
frieder has joined #armlinux
bjoto has quit [Ping timeout: 260 seconds]
bjoto has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
headless has quit [Quit: Konversation terminated!]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
prabhakalad has quit [Ping timeout: 272 seconds]
prabhakalad has joined #armlinux
HerbY_NL has joined #armlinux
cambrian_invader has quit [Server closed connection]
cambrian_invader has joined #armlinux
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iivanov_ has joined #armlinux
iivanov_ has quit [Client Quit]
iivanov_ has joined #armlinux
iivanov_ has quit [Remote host closed the connection]
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
Lucanis has quit [Ping timeout: 252 seconds]
Lucanis has joined #armlinux
HerbY_NL has joined #armlinux
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #armlinux
<NishanthMenon>
arnd: krzk what do you think of a formal doc in Documentation/arch/arm64 highlighting what can go into defconfig ? ref: https://lore.kernel.org/all/20240819204352.1423727-1-jm@ti.com/ - in principle, I like the idea of standardizing on just initramfs + with just the drivers necessary for console operation..
iivanov has quit [Ping timeout: 260 seconds]
<arnd>
yes, documenting it (possibly with a wider discussion on this) sounds like a good idea
iivanov has joined #armlinux
<arnd>
I don't think we have ever made it a formal rule that you need to use an initramfs as krzk suggests in his reply, the way I normally handle it is to assume that anything you need to get you to mount a rootfs is ok to have built-in, and anything that can be loaded from disk should be a loadable module
<arnd>
I do agree with krzk about defconfig not being for products, and that things like boot time are not a critical limitation here
<arnd>
also, if your platform normally uses an initramfs, having all drivers as loadable modules is a good idea
<NishanthMenon>
Agree and yup - same rule we have insisted on as well for k3 platforms, but I do recognize the space pressures that it puts on the Image size with armv9 platforms getting added etc. the boot time argument from the context of developers is probably a mistaken argument from my side. some of the platforms do have 256MB. so a large initramfs gets in their way of development, just need to put in some guidelines to deal with it.
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<krzk>
NishanthMenon: arnd: the benefit of modules and initramfs is that you could decide what goes to initramfs, leaving all modules on the rootfs. If this is built-in, then you you cannot (assuming we do not modify here build process, so defconfig).
<krzk>
That's why module-choice is better not only for bigger boards but also tiny ones. Or even over nfs/tfpt over uboot,which can be slow (my very old boards download at 700 kB/s, so small kernel and small initramfs are important for me)
<NishanthMenon>
krzk: agreed - we just need to put the mechanisms in place to ensure people know what to add in initramfs so as to not hand hold folks. that said, if you can post an initial documentation, i'd be more than happy to support the direction.
<arnd>
right, using initramfs for this has a lot of advantages, and that is clearly why all distros (including android) do it that way. I just don't want to force all developers to do it like that because it does add a few extra steps to the workflow. One of the things I do a lot is to boot a rootfs in qemu with a custom kernel (usually defconfig+kvm_guest.config). Since qemu -M virt only use a handful of drivers, having those built-in
<arnd>
gives a much faster round-trip time for repeated kernel boots.
siak has joined #armlinux
<arnd>
I assume there are many developers that use something similar for real hardware
lain6141 has quit [Read error: Connection reset by peer]
<NishanthMenon>
The thing i am struggling a bit with: how do i inform people what modules will be needed for a particular platform boot - without having to write documentation in ti.com since there are non TI generated boards as well in the ecosystem. debating if adding rst documentation will help OR if a machine readable format is necessary (e.g. for automatic consumption for say buildroot)..
<robmur01>
also who actually uses defconfig for development? You really want to waste minutes rebuilding nouveau, amdgpu, mlx5 and piles of platform drivers for other SoCs you don't care about every time you touch a common header?
lain6141 has joined #armlinux
<NishanthMenon>
robmur01: development: maybe.. as such, i do build regularly for testing when i pull things in, kernelci.org does for testing.. etc.. again, mileage might vary depending on what you are goals of development is ;)
<robmur01>
sure, it has its place for final build-testing, CI, etc., but in the context of developers iterating and flashing stuff to boot a board to test it, anyone not using a custom config to turn off all the irrelevant crap is already making pain for themselves...
<NishanthMenon>
yup. we used to have this https://git.ti.com/cgit/ti-linux-kernel/ti-upstream-tools/tree/ to help streamline the process for developers. it used config fragments quite a bit.. but then.. ended up with challenges around it as well.. might be good to discuss a better balance.
<arnd>
robmur01: amdgpu is thankfully not included in defconfig, and not everyone touches common headers during their development. Depending on what I work on, I often just rebuild vmlinux, so things like nouveau, mlx5 don't get rebuilt iteratively. Changing a single source file in defconfig isn't much worse than in many other configs, and it's something that already boots on most platforms
<robmur01>
yeah, I guess I do touch device.h and dma-mapping.h more than most :)
System_Error has joined #armlinux
ex--parrot has quit [Server closed connection]
ex-parrot has joined #armlinux
<broonie>
If you're testing over multiple boards you can rapidly end up needing a good portion of defconfig unfortunately, and the fact that we don't have per platform defconfigs means if you've got a bunch of boards you'd need to maintain a pile of cut down defconfigs.
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #armlinux
siak has joined #armlinux
<Forty-Bot>
I think arm got it right tbh; having a bunch of defconfigs specialized for individual platforms is much better than one defconfig which isn't good for any platform
<broonie>
It's good for distros and for CI farms.
<Forty-Bot>
well, I'm not that so...
<Forty-Bot>
and while having an arch-allmodconfig may be nice for those sorts of things, its existance has been used to block platform configs which are actually useful for specific platforms
<broonie>
No, the per platform configs are blocked separately (we have the multi_vX_defconfigs on 32 bit for example).
<Forty-Bot>
that's what I mean
<Forty-Bot>
arm6 should do what arm does
<maz>
no matter how many defconfigs, you provide, this is never going to work for everyone.
<Forty-Bot>
yes, this is fine
<Forty-Bot>
just let the major vendors sign up to support their own defconfigs
<maz>
they can have their own defconfig outside of the tree if they want.
<Forty-Bot>
nicer to have it in-tree
<broonie>
maz: We are in general trying to convince people not to carry things out of tree!
<maz>
no, it's just leadds to a stupid mess.
<maz>
broonie: I don't think random combinations of config options qualify as useful things in tree.
<maz>
otherwise, I want my own defconfig merged yesterday.
<maz>
4 of them, actually.
<broonie>
I mean there's an extreme, but given the amount of time I see people passing around defconfigs and config fragments I suspect there might be a better balance.
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
iivanov_ has joined #armlinux
vup has quit [Server closed connection]
vup has joined #armlinux
iivanov has quit [Ping timeout: 255 seconds]
headless has quit [Quit: Konversation terminated!]
vingu has quit [Quit: Leaving.]
vingu has joined #armlinux
iivanov has joined #armlinux
iivanov_ has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #armlinux
System_Error has joined #armlinux
<javierm>
broonie: agree. Every developer having their own set of cut down defconfigs for their platforms/boards isn't the best approach either
<javierm>
and the distros defconfigs are really not suitable for developement either, since they enable every driver and their dog as modules to support as much platforms as possible
<javierm>
I don't know what's the solution though...
HerbY_NL has joined #armlinux
<maz>
I have the exact opposite approach. I have one defconfig for over 40 machines. the only difference between my various configs is the page size and the level of debug.
<maz>
but hey, I'm not a developer.
<javierm>
maz: yeah, that's another approach indeed but then as arnd said the disadvantage is longer build times to build all the drivers needed for the different machines you want to support
<maz>
7 minutes for a set of debian packages, including all the debug info. for me, this is a price worth paying.
<javierm>
maz: yup, I guess not everyone has the same compute to build their kernels
<javierm>
*compute power
<javierm>
anyway, I think that NishanthMenon is correct that a clear guideline of what's acceptable and what's not for arm64 defconfig would be useful
<javierm>
for example, I tried to enable xfs as a module and that was nacked
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mvaittin has quit [Remote host closed the connection]
<Xogium>
fwiw I'm the sort of person who doesn't use fragments, primarily because the way buildroot handles them is not suitable for me. I want to be able to pick my options in menuconfig, enable/disable whatever, save that and fragments in the context of buildroot make this impossible since if you use them you cannot save your kernel config anymore
mvaittin has joined #armlinux
<Xogium>
so what I used to do was to grab multi v7 defconfig and trim it down to whatever I needed. Every, single time. And that's gotten very exhausting over time. I don't want or need a huge kernel containing 40 tons of drivers I don't ever need on each board, personally
<Xogium>
I get it, for developers, having one single defconfig to maintain is probably easier... But for me personally it's just made things more annoying
<Xogium>
so impopular opinion probably here ;) but I actually prefer having defconfig for each hardware (maybe not each board, lets not go that far), but something like stm32_defconfig, with multiple family of SoCs supported from stm32 made sense to me
<jn>
Xogium: i agree
<Xogium>
cause like I know what my hardware is, and I don't like having to spend like 2 or 3 hours chasing around kernel options that I need to turn off because they serve no purpose. I know my hardware doesn't have a sata port, and it definitely doesn't need to have *all* of the ethernet and wireless drivers enabled
sudeepholla_ has joined #armlinux
<Xogium>
but as I said I understand why the single defconfig was made, too. It's basically being stuck between two hard places
HerbY_NL has joined #armlinux
HerbY_NL has quit [Client Quit]
<ziy>
is there a mechanism to trim down defconfig? something like make localmodconfig? I run it, it detects my platform and disable other unrelated platforms.
<Xogium>
ziy: sure, there is. But to do that you need to run it on the target in the first place
<Xogium>
often embedded systems are built and entirely crosscompiled
<Xogium>
I sure as hell wouldn't want to even try building a kernel on this tiny single core machine ;)
<ziy>
actually, I am too lazy to crosscompile, so last time I tried to compile kernel on my pi 4. that was terrible. :(
<Xogium>
hehe yes
<Xogium>
so imagine trying it on a single coretex a7 core running at 650 mhz :D
<ziy>
a VM on Mac mini M1 is much better. :)
<Xogium>
*cortex a7 even
<javierm>
ziy: there's also ./scripts/dtc/dt_to_config arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
<ziy>
javierm: thanks.
<Xogium>
hmm, I tried that once, and somehow it didn't quite do what I expected it would. I can't recall what happened atm
<Xogium>
{2023.tar.zst:2023/10/libera/#armlinux.05.log}-17:31 < geertu> These scripts are meant to add hardware support, starting from a pure software policy config.
<Xogium>
ah, so that is why
<Xogium>
so in order for that script to work you need to have only software stuff enabled, like filesystem drivers, that sort of thing. It then adds the hardware drivers you need
frieder has quit [Remote host closed the connection]
<Xogium>
good luck making a pure software defconfig
mvaittin has quit [Ping timeout: 244 seconds]
sudeepholla_ has quit [Quit: Ex-Chat]
cbeznea_ has quit [*.net *.split]
TheCoffeMaker has quit [*.net *.split]
sudeepholla has quit [*.net *.split]
Perflosopher has quit [*.net *.split]
Stary has quit [*.net *.split]
militantorc has quit [*.net *.split]
russ has quit [*.net *.split]
ukleinek has quit [*.net *.split]
qyousef_ has quit [*.net *.split]
qyousef_ has joined #armlinux
ukleinek has joined #armlinux
pikapika_lunar has joined #armlinux
russ has joined #armlinux
sudeepholla has joined #armlinux
cbeznea_ has joined #armlinux
TheCoffeMaker has joined #armlinux
Perflosopher has joined #armlinux
Stary has joined #armlinux
iivanov has quit [Remote host closed the connection]
psydroid has quit [Ping timeout: 272 seconds]
psydroid has joined #armlinux
gclement has quit [Ping timeout: 244 seconds]
iivanov has joined #armlinux
headless has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
frieder has joined #armlinux
nsaenz has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
psydroid2 has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
apritzel has joined #armlinux
heat has quit [Read error: Connection reset by peer]
heat has joined #armlinux
cbeznea_ has quit [Ping timeout: 264 seconds]
lain6141 has quit [Read error: Connection reset by peer]
nact has quit [Ping timeout: 248 seconds]
lain6141 has joined #armlinux
nact has joined #armlinux
iivanov has quit [Remote host closed the connection]