Just how much bloat can you strip out of a Pi?

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.

_/_ / v \ Scott Alfter (remove the obvious to send mail) (IIGS(

Top-posting! \_^_/ >What's the most annoying thing on Usenet?

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.

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
someone else's pocket.

You might like to think about devuan as a base rather than raspbian. It uses SysV for init, so is far more accessible. I use this for a standalone soft-synth. It is dramatically quicker to start and I can run at lower latency. The current release is beowulf and runs on the Pi4, as well as the earlier ones.

--
W J G

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

--
Climate Change: Socialism wearing a lab coat.

Actually doesn't answer the question. It seems to assume the kernel will always execute /sbin/init

--
Outside of a dog, a book is a man's best friend. Inside of a dog it's  
too dark to read. 

Groucho Marx

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. 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: -See: -- Notes some measured interrupt response times -Some valuable low-level info: -Hints at usage with Linux: -Getting into it properly here:

--
__          __ 
#_ < |\| |< _#

kernel command line parameter init=/bin/sh or similar. Just specify what the kernel will execute as the first userland program. This is generic linux.

yuk. No way!

I don't think you should have to do that. I believe I saw that the gpio interrupts can be handled by a your own routine

A kernel driver is not the hardest thing to write, anyway.

The advantage of bare metal is that you control the environment totally, the disadvantage is you have to write your own networking drivers to use networkimg and usb drivers top use that.

"For the record the normal driver response is about ten to twenty times faster than user space .. usual quoted numbers Jessie user space: tmin =179 us tave = 280us tmax = 511us Jessie driver space: tmin = 6us tave = 12us tmax = 43us"

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..

No link found

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 urge to save humanity is almost always only a false face for the  
urge to rule it.? 
? H. L. Mencken

Microcontroller with networking, like esp32 with wifi, or teensy4 with ethernet adapter.

On Tue, 15 Sep 2020 11:11:19 +0100, The Natural Philosopher declaimed the following:

Based on

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=...

""" 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.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

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...

--
"The most difficult subjects can be explained to the most slow witted  
man if he has not formed any idea of them already; but the simplest  
thing cannot be made clear to the most intelligent man if he is firmly  
persuaded that he knows already, without a shadow of doubt, what is laid  
before him." 

    - Leo Tolstoy

Teensy has 64-bit hardware fp. Of course something like this is on a completely different level

Ive got access to plenty of 10 year old PCs for next to no money

--
?Puritanism: The haunting fear that someone, somewhere, may be happy.? 

H.L. Mencken, A Mencken Chrestomathy

Circle claims to support networking. I haven't looked into the practicalities of using it too deeply (obviously you'd have to look into how it uses interrupts itself).

Note that the Pi also has a "Fast Interrupt" (FIQ), which might be useful for minimising lattency. In Linux, FIQ is used by the Pi Foundation's dwc-otg USB driver (and any settings to tell it not to use FIQ don't seem to work anymore - I tried hard), but not by the standard dwc2 USB driver which can be used instead.

In my case the Kernel high resolution timer system is also something to look into because my requirement is to write to the GPIO at a certain time after a previous write. If, like me, you can calculate in advance when the external interrupt signal is going to come, then that might be something you want to look at too.

--
__          __ 
#_ < |\| |< _#

Yes, but more expensive to run if they're on continuously.

I have an old PC running as a NAS in the garage, it's not *that* old so consumes about 40w when idle. I'm about to replace it with a Pi 4 which is probably nearer 10w or even a bit less when idle. The saving

more expensive of course) so maybe I'll save the cost of the Pi 4 in around a year or a bit more. The old PC was getting a bit creaky too, it's not just a power saving exercise.

--
Chris Green