03:08 <hanetzer> anyone know if peter griffin of linaro is on irc somewhere?

07:20 <milkylainen> Can I run a modern linux on a sam9x60d6k? I saw something about the 60 eval kit but unsure if that applies to other processors in the sam9x60 range?

07:26 <arnd> milkylainen: it's the most modern arm9 SoC, and definitely runs a modern kernel well. It's still ARMv5 without an FPU though, so the user space side will have limitations. Most prebuilt distros are ARMv7 and won't work, and anything that uses floating point math with be slow

07:28 <milkylainen> arnd: That's fine. Target is custom latest stable vanilla. Probably rather trivial userspace.

07:33 <milkylainen> Out of curiosity, is armv5/v5te at risk for becoming dropped in linux anytime soon?

07:37 <arnd> milkylainen: no, not at all

07:38 <arnd> my guess would be that it will be dropped eventually of course, along with most other 32-bit targets, but probably not before 2030

07:39 <Xogium> I certainly hope not ! I mean... What would be the point on working on the year 2038 issue if not to support them a bit longer despite that ?

07:40 <milkylainen> :)

07:40 <milkylainen> arnd: appreciate the insight.

07:41 <Xogium> I'm of the opinion that a lot of arm64 SoC are just too bloody power hungry

07:42 <arnd> Xogium: there are a number of different angles to this: ARMv7 support will probably outlive most other 32-bit targets (x86-32, ppc32, mips32, armv5, ...) by 10 years, just because of the relative size of the developer community and the release dates of the most recent chips

07:42 <Xogium> and far as I'm aware there is not a single vendor of arm64 SoC that really bothers actually mainlining properly a la st for example

07:42 <Xogium> I heard nxp is making an effort but its not quite that

07:42 <arnd> and 32-bit user space will outlive 32-bit hardware by quite a while as well, as that is often used on memory constrained systems

07:45 <milkylainen> Xogium: my .c signer for stm32mp1 works as intended. Now I can ignore cubeprogrammer and the pesky signer tools there. :)

07:45 <Xogium> I don't know maybe arm64 is a viable with low power and I just haven't found something able to do it. Then again, my experience with arm64 is limited to odroid c2 aka amlogic s905 which was a lie for quite a while, and the rpi 4... Which doesn't even have any form of low power modes

07:45 <arnd> Xogium: I agree that arm64 has not made it into the low-power / low-performance designs yet, but I think that is a matter of time. There are already some low-end riscv64 designs, and they clearly want to skip 32-bit kernels but still run 32-bti user space on those

07:46 <Xogium> milkylainen: awesome ! Will you provide a buildroot package ?

07:47 <Xogium> riscv64 sounds like a good alternative, especially for folks like me who generally stay at a high level

07:48 <arnd> Xogium: a single-core Cortex-A35 on 12nm FD-SOI should be rather competitive with existing 32-bit chips, that would be my guess where the absolute low end arm hardware is headed.

07:48 <milkylainen> Xogium: It's a rather trivial c file. So I'll post it and let people decide how they want to use the code. Maybe integrate it into stm32image.c. Unfortunately that one has diverged a bit between tf-a, u-boot, barebox. Maybe someone will convert it to shell/python etc now that the method is clearly visible.

07:49 <Xogium> hmm a35, gotta refresh my ram.. Err, memory, I mean

07:50 <Xogium> ah righto big brother to a32

07:50 <arnd> I don't think anyone ever made a Cortex-A32 based chip (rightfully so)

07:50 <Xogium> milkylainen: ah, intersting. So it isn't really a command line program, and is meant more like a lib you integrate into other projects ?

07:51 <arnd> A32 is just the A35 with the 64-bit parts removed

07:51 <Xogium> arnd: lol probably not, they would have gone like, what is the point

07:52 <milkylainen> Xogium: It's a regular command. --image xyz --pkey priv.pem --password qwerty

07:53 <Xogium> oh

07:53 <Xogium> that is very interesting

07:54 <Xogium> so you skip only the signing part, or you also plan to integrate key generation and such ?

07:54 <milkylainen> skip signing part? This signs the binary. Keys are generated elsewere.

07:54 <milkylainen> Normal eckeys.

07:55 <Xogium> skip the signing part from the cube programmer I meant, sorry

07:55 <Xogium> ah... Because st talks about their keygen tool so I figured it was a specific tool you need to use

07:56 <milkylainen> yes. there are two tools. But keygen is trivial with a openssl cmd.

07:57 <Xogium> oh it is just openssl, got it

07:57 <milkylainen> Maybe I'll write something in the head of the c-file.

07:57 <milkylainen> Ot's a p-256 nist curve. prime256v1. There is an option for a brainpool curve too. But I haven't checked that yet.

07:58 <milkylainen> s/Ot/It

07:59 <Xogium> ah, very nice

07:59 <Xogium> I don't know a whole lot about crypto so I don't know which key type would be better, actually

08:02 <milkylainen> Most people know. It's usually "I don't trust NIST".

08:02 <milkylainen> Sorry. Most people don't know.

08:03 <milkylainen> Religion. :)

08:05 <Xogium> hehehe

08:17 <milkylainen> arnd: atsama5dx? v7a, right? Same outlook as sam9x60?

08:18 <arnd> milkylainen: equally well supported, but obviously a more modern CPU core, with all the advantages that brings

08:19 <arnd> there is also a sama7 now, which would be the next step up from that, using Cortex-A7

08:21 <arnd> milkylainen: I tihnk the sam9x60 was intended mostly as a drop-in replacement for the older sam9 chips to upgrade existing designs with minimal changes. if you can get the sama5 at a similar price, that would be a better choice for a new project

08:22 <arnd> check the power usage maybe, I don't know how they compare

08:25 <milkylainen> ok.

12:38 <mvaittin> broonie: I was going through couple of more drivers that match git grep -n -A10 -B5 devm_regulator_get |grep -A10 -B10 devm_add_action. Many of the IIO/ADC drivers do that and store ptr to the regulator because they need to read Vref. I wonder would it work if we provided an devm_get_enable which did allow part of the regulator API to be used? Perhaps by adding a flag in regulator struct indicating that only part of the API can be used (The

12:38 <mvaittin> enable/disable would be forbidden). Just an initial idea - not at all sure if it would be worth the hassle though.

12:39 <broonie> I think it's probably more trouble than it's worth TBH.

12:41 <mvaittin> broonie: could be. I just had some extra time to think while waiting for the answers from ROHM HW colleagues :) Well, time's probably up anyways as I should get some answers Tomorrow... I'll stick with the original proposal then

20:25 <hanetzer> question; would hyp vs svc vs whateverelse arm32 has mode hypothetically have a big impact in how openocd works with a board? I've got what looks to be a mostly working config for my target but reset [init|run|halt] refuse to work. I only have a trst pin, srst is unavailble