01:39 <broonie> mvaittin: FWIW BBB is covered in KernelCI so you can look there for boot/runtime tests from the trees that are covered (it's used a lot for runtime tests because I've got loads of them in my lab).

05:52 <mvaittin> broonie: Thanks for the tip. It seems to me your BBBs are booting up just successfully using for example a v6.2-rc7-* with both the omap2plus_defconfig and the multi_v7_defconfig.

08:57 <arnd> mvaittin: is the machine broken for you with omap2plus_defconfig or with multi_v7_defconfig? If it's the former, maybe the bug has returned that we couldn't figure out last spring, where a CPU_V6+SMP kernel ran into issues running on single-core v7 machines

09:05 <mvaittin> arnd: Origins of the config I have used on these boards may be in a downstream bbb config (could be the Robert C Nelson bbb-tree)? I don't even remember any more as I have used these bones mostly for I2C / SPI device driver development - and they have mostly "just worked" with the olddefconfig. Hence I haven't changed config except when adding support for my new drivers or when enabling debug features / NFS rootfs. I guess I can try out the

09:05 <mvaittin> omap2plus_defconfig later today though :)

09:05 <mvaittin> I'll let you know how it works with that

09:07 <arnd> mvaittin: ok, got it. See if your config enables CPU_V6 then, and if it does, maybe try runing without it as the first step

09:15 <mvaittin> arnd: Thanks. The config seems to say:

09:15 <mvaittin> CONFIG_ARCH_MULTI_V7=y

09:15 <mvaittin> # CONFIG_ARCH_MULTI_V6 is not set

09:15 <mvaittin> CONFIG_ARCH_MULTI_V6_V7=y

09:16 <arnd> ok, then it's not that old but but something else

09:16 <arnd> s/but/bug/

09:39 <linusw_> maz_: I lost patience in GPIO irq chips not getting converted to immutable so I made some 17 patches.

10:00 <tmlind> linusw_: nice, this will reduce some boot time warnings :) will test

10:01 <linusw_> tmlind: thanks, I am a bit unsure about the OMAP patch because it's a bit intrusive.

10:02 <tmlind> linusw_: ok

10:55 <maz_> linusw_: thanks for that, much appreciated.

10:56 <maz_> you probably only have another 200 to go... ;-)

12:21 <mvaittin> For the record - multi_v7_defconfig boots as expected on my BBB. I guess this is a good thing as most upstream users do hopefully use either derivative of that or derivative of omap2plus_defconfig

12:50 <broonie> linusw_: I need to finish off some conversions for atmel.

12:51 <linusw_> maz_: it was sufficiently painless, so I will take another sweep or two in the next merge cycle

12:52 <linusw_> broonie: at91 pinctrl?

12:53 <broonie> Yeah, IIRC. Whichever driver prints immutability warnings at boot anyway.

12:54 <broonie> Boot log says gpio-at91.

13:06 <milkylainen> hi. what are the current status around v4 and v5 in the kernel? some of it has been deprecated already right?

13:08 <arnd> milkylainen: ARMv4, ARMv4T and ARMv5 CPU support is still fully supported by the kernel, at least for DT-enabled platforms. Individual SoC platforms are getting removed as they fall out of use, and in 6.3 we will remove 80% of the boards that are not converted to DT

13:09 <arnd> gcc-9 dropped support for ARMv3, so mach-rpc will eventually get removed as the minimum compiler version gets raised, but at the moment gcc-5 is still supported with CONFIG_WERROR=n

13:10 <milkylainen> arnd: thanks for the summary. So no plan for complete arch obsolecense yet?

13:10 <arnd> no

13:11 <milkylainen> Ok. I'm finding it difficult to recommend new v5 designs though.

13:13 <Xogium> I gotta admit, I've no idea why picking armv5 over armv7 would be a good idea these days

13:13 <Xogium> so I'm not sure why they still produce armv5 chips ^^

13:13 <Xogium> I'm sure people know better than me over here though :D

13:14 <arnd> ARCH_WPCM450, SOC_SAM9X60 and MACH_SUNIV are probably the only ones that anyone is using in new products, but of course they are all on the very low end

13:14 <milkylainen> Xogium: probably some existing products and existing production lines churning out stuff. Buyers exist and are buying still.

13:15 <milkylainen> Yeah. It was a SAM9X60.

13:15 <Xogium> yeah, sure. But I'm baffled why chinese think it's a good idea to make an armv5 board like the mangopi for example

13:15 <milkylainen> Warehouse leftovers? $0? :)

13:16 <arnd> SAM9X60 is a perfect upgrade for anyone that wants to replace an existing AT91 based design with cheaper and more readily available components but minimal software changes

13:16 <milkylainen> arnd: nah. This is a new design for network related equipment.

13:17 <milkylainen> I'd choose something beefier.

13:18 <arnd> also, I can understand users really liking microchip/atmel products in general. If you don't need more performance but like them as a supplier, it probably saves a little money for each one compared to a SAMA5

13:19 <broonie> There aren't that many vendors serving the catalog market.

13:19 <Xogium> oh yeah I wasn't thinking they were dumb for picking out armv5, merely wondered why that would be in 2023

13:20 <broonie> Also you'll often find that fancier SoCs have more dense pinouts and so on that require fancier assembly technologies, older and simpler silicon is often packaged in a form factor that lets you use cheaper assembly technologies.

13:20 <Xogium> that makes sense

13:20 <broonie> Especially with parts that have been around for a while, you'll often see some successful devices at a given assembly complexity stick around for a very long time since all the R&D is going into harder to assemble stuff.

13:21 <arnd> also power consumption, it's hard to compete with a 40nm ARM926

13:21 <milkylainen> Absolutely. But that isn't an issue here. Probably cost. But their products have a _very_ long life. Maintained life.

13:21 <Xogium> fair point about power draw

13:55 <geertu> arnd: But e.g. an 28nm ARM926 would consume less power? Or would it leak more?

14:20 <arnd> geertu: I don't think anyone has ever created one, and I'm not sure it would make sense as the core design makes tradeoffs that are intended for a given process. I think ARM9 started out at 0.35µm (350nm), and at its height it was integrated into 65nm processors like the first Cortex-A8 or A9 cores.

14:20 <arnd> SAM9X60 is the only one I know below that

14:22 <milkylainen> geertu: leakage goes up, static current leakage goes up, process voltage goes down, total dynamic power for a similar design usually goes down.

14:22 <milkylainen> less efficient, but still using less power. :)

14:25 <geertu> arnd: I guess it's also time to ditch the Ingenient dm644x board I have lying around? While it boots some version of Linux, I never managed to find a tree with support for it.

14:26 <arnd> Cortex-A5 on 22nm FD-SOI might be the lowest power ARMv7-A if anyone builds that. Anything below 22nm likely uses FinFET

14:27 <arnd> geertu: dm64xx was removed last summer in 7dd33764486d ("ARM: davinci: Delete DM644x board files")

14:28 <milkylainen> Or variants of GAA-FET if you get bleeding edge. :)

14:28 <geertu> arnd: I know ;-)

14:29 <milkylainen> I don't think a v7a design will ever see a GAA-FET process though.

14:29 <milkylainen> Maybe a built in coprocessor of some kind.

14:35 <arnd> milkylainen: Qualcomm X65 is a 4nm Cortex-A7. It's still FinFET but it's almost the same generation as Samsung's GAA

14:37 <milkylainen> I don't know who qualcomm uses as a foundry? I know Samsung are targeting GAA soon. Intel too? No clue about TSMC and others.

14:39 <milkylainen> hmm googling yields TSMC(?) and they're targeting GAA for 2nm?

14:45 <milkylainen> arnd: x65 btw. like a modem? so some sort of coprocessor to the modem?

14:46 <milkylainen> Or a standalone SoC with a7 access available to the world?

14:47 <arnd> milkylainen: it's both, depending on what you run on it. See arch/arm/boot/dts/qcom-sdx65.dtsi for what it looks like when you run Linux on the chip itself. Most users would have a high-performance SoC and communicate over PCIe with some firmware stack running on the X65 chip

14:59 <milkylainen> arnd: interesting. tnx.

20:49 <linusw_> milkylainen: SoCs produced in a lower technology node has more longevity. Intel IXP4xx has a MTBF (Mean Time Before Failure) of 60 years.

20:51 <linusw_> milkylainen: another factor can be if certain archs contains technology engineered in certain countries, which are in trade war with certain other countries and cannot be exported, which lead to technology choices that appear not logical

20:53 <linusw_> mean time before failure matters a lot where it is easy to upgrade software but hard to replace hardware, such as in space.

22:36 <marex> dtor: hey, was this one https://patchwork.kernel.org/project/linux-input/patch/20220715155905.219391-1-marex@denx.de/ missed or something ?

22:36 <marex> I just found it rotting in my upstream queue

22:43 <dtor> I guess I simply missed it, sorry. Let me respond on email.

22:43 <marex> dtor: no worries, there's no rush

22:43 <marex> dtor: I also totally forgot about it ; thanks !