07:28 <linusw__> ukleinek: BTW I was very impressed with the recent waveform rework of PWM, good job!

10:23 <ukleinek> linusw__: do you have a use case for it? I would be interested to hear about it.

15:21 <rfs613> hmm, i am re-running the same test multiple times, looking at kernel printk output.

15:21 <rfs613> in some runs, it shows ___ptrval___ and in others the hex value.

15:22 <rfs613> it's the same printk, and the kernel/commandline are exactly the same.

15:23 <rfs613> is it being initialized by random value perhaps? seems so odd...

15:28 <geertu> rfs613: Anyone playing with no_hash_pointers

15:28 <geertu> ?

15:29 <rfs613> not that I know of ;-)

15:29 <rfs613> i mean, I am booting the same kernel binary, in exactly the same way...

15:29 <ardb> mrutland: i'm trying to make sense of the alternatives changes to the VDSO

15:30 <rfs613> geertu: and I have scripted the 5 lines I need to start my test, so those are the same too.

15:30 <ardb> given that vdso.so is an opaque blob as far as the vmlinux link is concerned, these are never applied right?

15:31 <rfs613> geertu: anyhoo it's just weird... though it is not really what I am trying to debug, just another mystery I can't explain right now

15:31 <mrutland> ardb: they're applied specially, separately from the main kernel alternatives

15:31 <geertu> rfs613: Just use %px instead of %p

15:31 <mrutland> ardb: see apply_alternatives_vdso()

15:32 <rfs613> geertu: sure, but this is an existing printk (which of course I could modify), i just don't understand why it is toggling

15:32 <mrutland> ... unless I'm misunderstanding and you're saying that shouldn't work?

15:33 <ardb> mrutland: no that seems to be the puzzle piece i was missing thanks

15:34 <mrutland> ardb: enjoy!

15:48 <geertu> rfs613: During early boot it uses a weaker hash

15:49 <rfs613> geertu: i'm look at output after userspace starts, so by then it shouldn't be changing, right?

15:50 <rfs613> (in any case i've take the suggestion and changed %p to %px, so I can put this oddity aside, and focus on the real issue...)

16:10 <geertu> rfs613: correct

19:02 <Juliaaa> you would recommend arm-v6 or v7 for the microcontrollers ?

19:21 <Xogium> Juliaaa: microcontroller ? :O

19:21 <Juliaaa> yes

19:22 <Xogium> you want to run linux on a mcu, or you want to have a realtime OS on a mcu / coprocessor kind of thing ?

19:22 <Juliaaa> asm

19:25 <Xogium> Juliaaa: asm... That doesn't answer my question ?

19:25 <Juliaaa> i wanna use asm code on it i mean

19:25 <Xogium> sure but

19:25 <Juliaaa> realtime os

19:25 <Juliaaa> or linux

19:25 <Juliaaa> both are ok

19:25 <Juliaaa> yes sir

19:26 <Xogium> do you want a coprocessor, with a rtos running alongside linux and interacting with the remoteproc subsystem, or just a mcu ?

19:26 <Juliaaa> just mcu

19:26 <Xogium> you are aware that a mcu has no MMU, correct ?

19:26 <Juliaaa> no sir

19:26 <Juliaaa> lemme check

19:26 <Juliaaa> now

19:27 <Xogium> some have a basic mpu (memory protection unit), but none at least to my knowledge have a full MMU (memory management unit)

19:29 <Xogium> running linux on these is possible... Now, will it be useful ? Doubful. Something like the stm32f769 dev kit from st for example is supported. It has 16 MB of external ddram, and 512 KiB of sysram on the SoC itself. Unless you want to havily work on XIP (execute in place), that is barely enough to run the stm32_defconfig unmodified and already tinyi-ish kernel plus a *minimal* busybox. You can't even run

19:30 <Xogium> the normal sized busybox

19:32 <Xogium> if someone here ever saw an actual project or even a simple mcu running linux and being actually useful in what it does, I'd be very interested in knowing about it

19:32 <Xogium> very curious

19:36 <headless> Xogium: arch/arm/ does support MMUless CPUs

19:36 <headless> IIUC

19:49 <cambrian_invader> I have gotten an mcu running linux working before

19:49 <cambrian_invader> but it wasn't useful :)

19:49 <cambrian_invader> you could boot it up and run perhaps 10 or 20 programs before memory got too fragmented

19:50 <cambrian_invader> so you basically can't call fork() after startup

19:50 <cambrian_invader> I think it would only be useful if you e.g. wanted to use the Linux networking/filesystem/usb stack or something

19:51 <cambrian_invader> but you didn't have $5 for a Real Computer

20:11 <linusw__> ukleinek: nothing serious really, I just happened to look at the code :)

20:12 <Xogium> yes it's *supported* as I said, but is it really that useful ? I fail to see how one could even seriously consider using linux there

20:12 <Xogium> no MMU will hurt, even if you have a MMU-less kernel

20:13 <Xogium> I toyed a bit with stm32f7 dev kit myself... It lacks so much it isn't even of real use imho. No access to the onboard microphones, no to the lineout and RCA plugs neither, not even the qspi flash of 64 MB

20:16 <Xogium> I am not criticizing the fact this was added in the kernel at all. I'm just... Not quite sure I get the idea behind it. Maybe it was an experiment at first, see if I can do that, kind of thing ? I don't know