Looking at my 'I only do one thing' Pi running 94 different processes, >realistically how many of them do I need? And how could I get rid of them?
I want to examine the pi as a reasonably real-time signal processing unit.
I don't need disk access except to load the code. I may not need network >access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than >Linux? More like e.g. DOS?
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
On Thu, 10 Sep 2020 12:47:40 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than >Linux? More like e.g. DOS?
I get pretty good results with the latest version of devuan for the Pi.
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than Linux? More like e.g. DOS?
Looking at my 'I only do one thing' Pi running 94 different processes, realistically how many of them do I need? And how could I get rid of them?
I want to examine the pi as a reasonably real-time signal processing unit.
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than Linux? More like e.g. DOS?
On 10/09/2020 12:47, The Natural Philosopher wrote:
Looking at my 'I only do one thing' Pi running 94 different processes,
realistically how many of them do I need? And how could I get rid of
them?
I want to examine the pi as a reasonably real-time signal processing
unit.
I don't need disk access except to load the code. I may not need
network access. I don't need logging. I sure don't need systemd. I
don't need a gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler
than Linux? More like e.g. DOS?
If you want to cut out all of that, then you probably don't need the Pi
at all. Have a look at an Arduino, you can either program bare metal, or
if you don't want to do your own scheduling run under FreeRTOS.
---druck
Folderol <general@musically.me.uk> wrote:
On Thu, 10 Sep 2020 12:47:40 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than >>> Linux? More like e.g. DOS?
I get pretty good results with the latest version of devuan for the Pi.
Alpine Linux is popular with containers, because it's extremely stripped down:
https://wiki.alpinelinux.org/wiki/Raspberry_Pi
For non-Linux, you could try an alternative OS like RISC OS or FreeRTOS.
You would need to port your apps to those OSes though - it wouldn't be a simple recompile.
Theo
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than >Linux? More like e.g. DOS?
Looking at my 'I only do one thing' Pi running 94 different processes, realistically how many of them do I need? And how could I get rid of
them?
I want to examine the pi as a reasonably real-time signal processing
unit.
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than Linux? More like e.g. DOS?
I need a fair bit of RAM and a pretty fast floating point processor. But >Arduino has some definite pluses.
I need a fair bit of RAM and a pretty fast floating point processor. But Arduino has some definite pluses.
On Thu, 10 Sep 2020 12:47:40 +0100, The Natural Philosopher wrote:
Looking at my 'I only do one thing' Pi running 94 different processes,
realistically how many of them do I need? And how could I get rid of
them?
I want to examine the pi as a reasonably real-time signal processing
unit.
I don't need disk access except to load the code. I may not need
network access. I don't need logging. I sure don't need systemd. I
don't need a gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler
than Linux? More like e.g. DOS?
I believe there is a real time os in development somewhere - have you
looked for it? You might also check out arch and gentoo,or maybe risc
os.
The Natural Philosopher <tnp@invalid.invalid> wrote:
I need a fair bit of RAM and a pretty fast floating point processor. But
Arduino has some definite pluses.
Have a look at the Teensy 4.1 with 600 MHz cortex-m7 and room for extra memory: https://www.pjrc.com/store/teensy41.html
Or perhaps the cheaper 4.0, if the 4.1 is still unavailable.
Looking at my 'I only do one thing' Pi running 94 different processes, realistically how many of them do I need? And how could I get rid of them?
I want to examine the pi as a reasonably real-time signal processing unit.
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than Linux? More like e.g. DOS?
The Natural Philosopher <tnp@invalid.invalid> wrote:
I need a fair bit of RAM and a pretty fast floating point processor. But
Arduino has some definite pluses.
Have a look at the Teensy 4.1 with 600 MHz cortex-m7 and room for extra memory: https://www.pjrc.com/store/teensy41.html
Or perhaps the cheaper 4.0, if the 4.1 is still unavailable.
The Natural Philosopher <tnp@invalid.invalid> wrote:
Looking at my 'I only do one thing' Pi running 94 different processes,
realistically how many of them do I need? And how could I get rid of them? >>
I want to examine the pi as a reasonably real-time signal processing unit. >>
I don't need disk access except to load the code. I may not need network
access. I don't need logging. I sure don't need systemd. I don't need a
gui.
Try PiCore, it's as stripped-down as Linux gets for the Pi. Boots
_way_ quicker than RPi OS on my Pi Zeros. No GUI, or systemd, no
disk access (runs in RAM). if you want to disable hardware
drivers, you can do that in config.txt (as you can in Raspberry Pi
OS).
http://www.tinycorelinux.net/ports.html
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than
Linux? More like e.g. DOS?
There are various Bare-Metal environments, such as: https://github.com/rsta2/circle http://www.stevebate.net/chibios-rpi/GettingStarted.html
On Thu, 10 Sep 2020 17:39:48 +0000, ray carter wrote:
On Thu, 10 Sep 2020 12:47:40 +0100, The Natural Philosopher wrote:
Looking at my 'I only do one thing' Pi running 94 different processes,
realistically how many of them do I need? And how could I get rid of
them?
I want to examine the pi as a reasonably real-time signal processing
unit.
I don't need disk access except to load the code. I may not need
network access. I don't need logging. I sure don't need systemd. I
don't need a gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler
than Linux? More like e.g. DOS?
I believe there is a real time os in development somewhere - have you
looked for it? You might also check out arch and gentoo,or maybe risc
os.
Microware OS-9 could be a starter, since it was designed from the ground
up as an RTOS.
It was originally released for the 6809 and quickly ported to the 680x0
where v2.4 was super-stable. Since then seems to have been ported to ARM
and picked up TCP/IP support, but I can't determine which ARM
architectures it has been ported to. Its website doesn't mention
RaspberryPis either. Pity: I used it for years on a 68020 and liked it a
lot.
Looking at my 'I only do one thing' Pi running 94 different processes, realistically how many of them do I need? And how could I get rid of them?
I want to examine the pi as a reasonably real-time signal processing unit.
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than Linux? More like e.g. DOS?
On 2020-09-10, The Natural Philosopher <tnp@invalid.invalid> wrote:https://unix.stackexchange.com/questions/428347/how-to-pass-arguments-to-a-linu x-kernel-init-bootparam
Looking at my 'I only do one thing' Pi running 94 different processes,
realistically how many of them do I need? And how could I get rid of them? >>
I want to examine the pi as a reasonably real-time signal processing unit. >>
I don't need disk access except to load the code. I may not need network
access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than
Linux? More like e.g. DOS?
You can start what you want. Linux is just the kernel. Alter the
cmdline.txt to tell the kernel what program to start (init=...), instead
of systemd or another init process.
see
Ok, your code that acts as init would have to start anything else you
wanted, or set up networking etc. but it can be done. I'm pretty sure
you could use busybox to form a minimal but adaptable boot environment.
This maybe of use...
All the parts are available from the standard Raspbian OS
Looking at my 'I only do one thing' Pi running 94 different processes, realistically how many of them do I need? And how could I get rid of
them?
I want to examine the pi as a reasonably real-time signal processing
unit.
I don't need disk access except to load the code. I may not need network access. I don't need logging. I sure don't need systemd. I don't need a
gui.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than Linux? More like e.g. DOS?
On Thu, 10 Sep 2020 12:47:40 +0100, The Natural Philosopher wrote:
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than
Linux? More like e.g. DOS?
You could also do LFS (Linux From Scratch) - you'd build up from nothing >instead of try to remove. Absolutely nothing in there that you don't want.
In article <hs44k1FomrmU2@mid.individual.net>,
ray carter <ray@zianet.com> wrote:
On Thu, 10 Sep 2020 12:47:40 +0100, The Natural Philosopher wrote:
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than >>> Linux? More like e.g. DOS?
You could also do LFS (Linux From Scratch) - you'd build up from nothing
instead of try to remove. Absolutely nothing in there that you don't want.
There's also Gentoo Linux, which you could think of as a more automated LFS. You can even get a proper 64-bit userland under Gentoo on the RPi 3 & 4;
it's been around for probably at least a year now while Raspbian is just now getting around to a 64-bit beta.
It's also systemd-free, unless you select otherwise.
On 14/09/2020 18:49, Scott Alfter wrote:
In article <hs44k1FomrmU2@mid.individual.net>,
ray carter <ray@zianet.com> wrote:
On Thu, 10 Sep 2020 12:47:40 +0100, The Natural Philosopher wrote:There's also Gentoo Linux, which you could think of as a more automated LFS.
I just want to run one high priority daemon and one lower priority
demon, with shared memory between them...is there something simpler than >>>> Linux? More like e.g. DOS?
You could also do LFS (Linux From Scratch) - you'd build up from nothing >>> instead of try to remove. Absolutely nothing in there that you don't want. >>
You can even get a proper 64-bit userland under Gentoo on the RPi 3 & 4;
it's been around for probably at least a year now while Raspbian is just now
getting around to a 64-bit beta.
It's also systemd-free, unless you select otherwise.
I've been looking at all the options and trying to understand the boot >process and the kernel threads.
First of all thank you everyone, because ist been an interesting
extensions of the knowledge base.
It seems that the pi boots (via the GPU) some stock boot loader that
tarts around with the hardware using instructions found in config.txt
and then boots a default kernel (on my Pi zero its simply kernel.img) -
or one specified in config.txt in the FAT formatted boot partition. A
few parameters may be passed to that: device drivers are specified in >config.txt and cmdline.txt has a few more boot options like where to
find the root filesystem.
Now this is the bit that I am not sure about - the kernel having booted
from the FAT partition then invokes - I assume - /sbin/init, which in my
case is linked to systemd.
I understand that in some sort of way it needn't be, or it could be
specified to NOT be /sbin/init....(where?)
So effectively one can intercept the boot process before systemd gets is
ugly evil claws into the nice shiny Linux, and run something else -
busybox?
So in principle one would lose all the daemons spun up by systemd as
default - logging, hotplugging and so on would all simply never get
started ... and start only those required - network layer perhaps.
I wonder what apache needs to start it? Never mind. Don't need it, just
need a very simple web server for control purposes, could even write one
that lived in user space so didn't pre-empt valuable real time
background task cycles.
And that brings me to the next question.
Assuming I am just running a kernel, plus networking of some sort, I
still have all the kernel threads which don't seem to take up CPU time,
or do they?
Under systemd on my system (it uses NFS, hence the related daemons,
these would not be needed in the system I want to build) I have..
ps -eadf | grep "1 0" | awk '{print $8}'
/lib/systemd/systemd-journald
/usr/sbin/blkmapd
/lib/systemd/systemd-udevd
/lib/systemd/systemd-timesyncd
/usr/sbin/rpc.idmapd
/usr/bin/dbus-daemon
/usr/sbin/cron
/usr/sbin/rsyslogd
/lib/systemd/systemd-logind
/usr/lib/rtkit/rtkit-daemon
avahi-daemon:
/sbin/wpa_supplicant
/usr/sbin/thd
wpa_supplicant
/sbin/dhcpcd
/sbin/rpcbind
/usr/sbin/sshd
/usr/sbin/rpc.mountd
/sbin/agetty
/sbin/agetty
/usr/sbin/apache2
/usr/sbin/exim4
/usr/lib/policykit-1/polkitd
/lib/systemd/systemd
grep
The ONLY one of those I might need (this is a pi zero W) is
wpa-supplicant and children. Or the equivalent on an ethernet equipped Pi...
So my next questions are:
1/. How much latency do the kernel thread processes conceivably
introduce? There are an awful lot of them. If these are insurmountable
that really rules out Linux altogether.
2/. How interruptible are they by interrupts coming from the Pi's GPIO
pins? I want my handler to have top priority for its run - whose length
is a bit indeterminate till I know how fast the pi executes floating point.
3/. What have I forgotten that systemD does that I might actually need?
For the purposes of setting the context for the last question, the Pi
would be sitting there waiting for a low priority webserver request, >executing low priority foreground code in an interruptible loop, and >responding to time critical interrupts on a GPIO pin.
Disk access would not be involved in the initial prototype.
By using suitable buffering I might be able to cope with 50ms max time
spent by the pi doing housekeeping.
The Natural Philosopher wrote:
I understand that in some sort of way it needn't be, or it could be
specified to NOT be /sbin/init....(where?)
Normal way on grub based machines is to override init=/bin/bash in the grub.cfg
Presume cmdline.txt is the equivalent on a pi, can you append init=/bin/bash there?
On 15/09/2020 11:07, Andy Burns wrote:
The Natural Philosopher wrote:
I understand that in some sort of way it needn't be, or it could be
specified to NOT be /sbin/init....(where?)
Normal way on grub based machines is to override init=/bin/bash in the
grub.cfg
Presume cmdline.txt is the equivalent on a pi, can you append
init=/bin/bash there?
Well that is precisely what I am trying to find out!
Busybox installs must do something like that
I understand that in some sort of way it needn't be, or it could be
specified to NOT be /sbin/init....(where?)
On 15/09/2020 11:11, The Natural Philosopher wrote:Actually doesn't answer the question. It seems to assume the kernel will
On 15/09/2020 11:07, Andy Burns wrote:
The Natural Philosopher wrote:
I understand that in some sort of way it needn't be, or it could be
specified to NOT be /sbin/init....(where?)
Normal way on grub based machines is to override init=/bin/bash in
the grub.cfg
Presume cmdline.txt is the equivalent on a pi, can you append
init=/bin/bash there?
Well that is precisely what I am trying to find out!
Busybox installs must do something like that
<https://pi3g.com/2019/01/10/alpine-boot-process-on-the-raspberry-pi/>
So my next questions are:
1/. How much latency do the kernel thread processes conceivably
introduce? There are an awful lot of them. If these are insurmountable
that really rules out Linux altogether.
2/. How interruptible are they by interrupts coming from the Pi's GPIO
pins? I want my handler to have top priority for its run - whose length
is a bit indeterminate till I know how fast the pi executes floating point.
On 15/09/2020 11:17, Pancho wrote:
On 15/09/2020 11:11, The Natural Philosopher wrote:Actually doesn't answer the question. It seems to assume the kernel will always execute /sbin/init
On 15/09/2020 11:07, Andy Burns wrote:
The Natural Philosopher wrote:
I understand that in some sort of way it needn't be, or it could be
specified to NOT be /sbin/init....(where?)
Normal way on grub based machines is to override init=/bin/bash in
the grub.cfg
Presume cmdline.txt is the equivalent on a pi, can you append
init=/bin/bash?? there?
Well that is precisely what I am trying to find out!
Busybox installs must do something like that
<https://pi3g.com/2019/01/10/alpine-boot-process-on-the-raspberry-pi/>
I've been dealing a lot with Pi interrupts in Linux lately, but with
a somewhat different application to yours. In my case I've ended up
cheating my way out of setting up an interrupt-driven system in Linux
(for now) by avoiding/disabling the system interrupts and polling an
input.
These are my links for when I go back and try to implement things
"properly" so that I'm not wasting so many cycles polling (I believe
I'll have to write a Linux kernel driver, but my timing requirements
are much tighter than 50ms):
*Interrupts can be used to avoid polling the edge detection register.https://stackoverflow.com/questions/34808276/poll-on-raspberry-gpio-sysfs-raspb erry
Need to use the Linux GPIO subsystem and poll() in C.
-A sort-of example:
-Best (fastest) interrupt handling would require a proper Linux
device driver. Or running bare-metal.
-Example of the latter:https://github.com/enricorov/Pinterrupt
-See:https://www.raspberrypi.org/forums/viewtopic.php?p=1149836
-- Notes some measured interrupt response times
-Some valuable low-level info:
http://xinu.mscs.mu.edu/Interrupt_handling_(Raspberry_Pi)
-Hints at usage with Linux:https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c /chapters-raspberry-pi-and-the-iot-in-c/55-raspberry-pi-and-the-iot-in-c-input- and-interrupts?start=1
-Getting into it properly here:https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c /chapters-raspberry-pi-and-the-iot-in-c/55-raspberry-pi-and-the-iot-in-c-input- and-interrupts?start=2
Bugger. I really wanted to be in and around 25uS total time to service
the interrupt.
On 15/09/2020 11:07, Andy Burns wrote:
Presume cmdline.txt is the equivalent on a pi, can you append
init=/bin/bash there?
Well that is precisely what I am trying to find out!
Busybox installs must do something like that
Yes. I had more or less got there. As said three options now present themselves- a device driver under stripped down linux, a bare metal
approach and 'byte' the networking bullet, or use something other than a
Pi. Maybe an X86 would have better floating point...
Maybe an almost bare metal PC chassis is the way to go...
On Tue, 15 Sep 2020 11:11:19 +0100, The Natural Philosopher <tnp@invalid.invalid> declaimed the following:
On 15/09/2020 11:07, Andy Burns wrote:
Presume cmdline.txt is the equivalent on a pi, can you append
init=/bin/bash there?
Well that is precisely what I am trying to find out!
Busybox installs must do something like that
Based on https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md cmdline.txt is not the file to be modified for this purpose. Nor does config.txt seem to cover it. OTOH:
pi@rpi3bplus-1:~$ cat /boot/cmdline.txt
console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
pi@rpi3bplus-1:~$ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1280 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
pi@rpi3bplus-1:~$
shows the contents of cmdline.txt concatenated to the rest of the actual
boot parameters used, so it may work by just adding init=...
https://www.debian.org/doc/manuals/debian-reference/ch03.en.html
"""
The init program is executed as the first program with PID=1 to perform the main boot process of starting many programs. The default file path for the init program is "/sbin/init" but it can be changed by the kernel boot parameter as "init=/path/to/init_program".
"""
pi@rpi3bplus-1:~$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 May 11 03:06 /sbin/init -> /lib/systemd/systemd pi@rpi3bplus-1:~$
So... creating a file system where /sbin/init is a link to your desired init process might also be sufficient.
Bugger. I really wanted to be in and around 25uS total time to service
the interrupt.
Kernel driver at least on i/o to achieve buffering to carry past that
delay looks needful..
Hmm. So its either code device drivers to get speed, or code your own
network drivers and write a minimal real time kernel.
Many thanks for all that. It narrows the options down enough to be of
use in deciding whether to use a pi at all.
The Natural Philosopher <tnp@invalid.invalid> wrote:
Yes. I had more or less got there. As said three options now present
themselves- a device driver under stripped down linux, a bare metal
approach and 'byte' the networking bullet, or use something other than a
Pi. Maybe an X86 would have better floating point...
Maybe an almost bare metal PC chassis is the way to go...
Teensy has 64-bit hardware fp. Of course something like this is on a completely different level https://www.seeedstudio.com/ODYSSEY-X86J4105800-p-4445.html
On 15/09/2020 12:12, Computer Nerd Kev wrote:
-Some valuable low-level info:
http://xinu.mscs.mu.edu/Interrupt_handling_(Raspberry_Pi)
No link found
-Hints at usage with Linux:
https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c /chapters-raspberry-pi-and-the-iot-in-c/55-raspberry-pi-and-the-iot-in-c-input- and-interrupts?start=1
-Getting into it properly here:
https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c /chapters-raspberry-pi-and-the-iot-in-c/55-raspberry-pi-and-the-iot-in-c-input- and-interrupts?start=2
Hmm. So its either code device drivers to get speed, or code your own
network drivers and write a minimal real time kernel.
On 15/09/2020 17:10, A. Dumas wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
Yes. I had more or less got there. As said three options now present
themselves- a device driver under stripped down linux, a bare metal
approach and 'byte' the networking bullet, or use something other than a >> Pi. Maybe an X86 would have better floating point...
Maybe an almost bare metal PC chassis is the way to go...
Teensy has 64-bit hardware fp. Of course something like this is on a completely different level https://www.seeedstudio.com/ODYSSEY-X86J4105800-p-4445.html
Ive got access to plenty of 10 year old PCs for next to no money
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 82:12:29 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,096 |
Messages: | 5,276,772 |