Are you sure, that the old interrupt controller can be used on the RPi 4? How did you enable this?
You don't follow because you did not read the first paragraph of the opening posters question. Where MikeDB says:Not following that heater.. what does any of that have to do with a Pi4 under baremetal (aka there is no liunx)?
Doesn't it measure the temperature of the SDRAM and adjust its settings accordingly?Heater wrote: ↑Sat Jul 13, 2019 7:02 pm"However some posts seem to indicate the cores running bare-metal will still get interrupted on a regular basis and so I can't rely on the audio being output on a regular 10uS basis."
I have also read about that. I have also seen it, in the example I linked to. So far I have yet to find out what that interrupt is and/or how to get rid of it.
I agree.Yes I do want to run Linux on one or even two cores, but bare metal on the other 2 (or 3). This seems to be far more sensible than reinventing the wheel writing Ethernet, Video and USB drivers to run on bare metal.
In your baremetal core situation, linux can not reach across and interrupt your core because you control the interrupt table and EL levels for the core. The only thing you need to agree on with linux is the shared memory and peripheral access.MikeDB wrote: ↑Sat Jul 13, 2019 11:59 pmBut I suppose the main thing is not that so much removing any delays due to Linux but ensuring they don't affect the audio. So a reliable DMA with say 10 samples in the queue would only be 100uS and probably fine. But since nobody seems able to say what the interupts even are due to, only that they can be demonstrated to exist, it is a little worrying.
Yes I've done that with STM32MP1 systems and assumed the Pi would be similar. Nothing is shared apart from a small section of inter-communication memory. Linux would do display and all ports, baremetal the GPIO.There are systems out there that already do linux and baremetal on multicore as reference
There is a listing of a bug with it in the Pi distro when maxcpus = 1'nosmp' and 'maxcpus=N'
(Only when __SMP__ is defined.) A command-line option of
'nosmp' or 'maxcpus=0' will disable SMP activation entirely;
an option 'maxcpus=N' limits the maximum number of CPUs acti‐
vated in SMP mode to N.
I am somewhat familiar with Greg K.H's book. It was a great help when I made some simple kernel modules some years ago.1.) You need to understand how Interrupts work on linux can I recommend
https://www.oreilly.com/library/view/li ... /ch10.html
Yes indeed. More on that later.2.) Regardless of everything even if linux was routing interrupts to the baremetal core (which I still say is unlikely) the baremetal
core can simply ignore them it can either mask them off or take the irq look at it and ignore it.
Seems very likely to me. When I toggle an output pin in a tight C loop on one of those cores and look at the pin with a scope I can see it toggling at 50MHz. But with those occasional 5us pauses. If that is not an interrupt then I don't see what else it could be?2.) Regardless of everything even if linux was routing interrupts to the baremetal core (which I still say is unlikely)...
That is not true in the case of booting Linux with "isolcpus" on it's command line.Linux can't force the core to do anything because it has no code running on the core and in fact the only way it can even talk to the baremetal core is via some agreed mechanism. You are worrying about a none issue to the baremetal code.
Code: Select all
PID PSR COMMAND ... 19 2 cpuhp/2 20 2 migration/2 21 2 ksoftirqd/2 22 2 kworker/2:0 23 2 kworker/2:0H-events_highpri 24 3 cpuhp/3 25 3 migration/3 26 3 ksoftirqd/3 27 3 kworker/3:0 28 3 kworker/3:0H-events_highpri ... 577 2 kworker/2:1H 578 3 kworker/3:1H
Code: Select all
$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 17: 69294 0 0 0 ARMCTRL-level 1 Edge 3f00b880.mailbox 18: 36 0 0 0 ARMCTRL-level 2 Edge VCHIQ doorbell 40: 0 0 0 0 ARMCTRL-level 48 Edge bcm2708_fb DMA 42: 353 0 0 0 ARMCTRL-level 50 Edge DMA IRQ 44: 3298 0 0 0 ARMCTRL-level 52 Edge DMA IRQ 56: 13603322 0 0 0 ARMCTRL-level 64 Edge dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1 80: 692 0 0 0 ARMCTRL-level 88 Edge mmc0 81: 4819 0 0 0 ARMCTRL-level 89 Edge uart-pl011 86: 581601 0 0 0 ARMCTRL-level 94 Edge mmc1 161: 0 0 0 0 bcm2836-timer 0 Edge arch_timer 162: 1356702 1105247 12 12 bcm2836-timer 1 Edge arch_timer 165: 0 0 0 0 bcm2836-pmu 9 Edge arm-pmu FIQ: usb_fiq IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 155660 568248 446 444 Rescheduling interrupts IPI3: 146 1811 4 4 Function call interrupts IPI4: 0 0 0 0 CPU stop interrupts IPI5: 212033 157693 0 0 IRQ work interrupts IPI6: 0 0 0 0 completion interrupts
I have cores 2 and 3 isolated with "isolcpus". I really don't want to start poking around at random registers. If you can point me to some documentation I might have a go at it.If you want my guess, I assume you have core 3 free, so write zero to address 0x4000004C and see if your mysterious irq goes away.
I haven't done anything with any registers yet, except the GPIO.The question beyond that is what have you done with the VBAR register or is it still pointing at the linux interrupt handler?
Now there is the thing...Can't help you with the linux side but isolating the core completely in baremetal we can do and there is a pile of registers we need to check and set and none of which you have told us about.
"isolates" CPU is via the CPU affinity syscalls.
I agree.You don't have the core in baremetal at all, you need to stop referring to it as such. It's idling in linux with no tasks being scheduled to the core via affinity is all that is happening. The task switcher is clearly still active and the 1ms interrrupt is the reschedule tick.
Certainly any executable run on such a "bare-metal core" would be a Linux executable and make use of Linux to load and run it. I see nothing wrong with that. Being able to make use of Linux facilities is the whole point of this, rather than starting from nothing.Realistically you might as well write whatever you are trying to do as a linux executable and use linux core and I am guessing that is the intention of the command.