Running Pure Debian on the Raspberry Pi 3B+?

[Rogério Brito]

Hi, people.

I tried to send the message below more than 12h ago, but it seems to
have been lost, so I am resending it via another relay.

Thanks in advance for any help,

Rogério.

---------- Forwarded message ----------
From: Rogério Brito <***@ime.usp.br>
Date: Tue, Aug 14, 2018 at 6:59 AM
Subject: Running Pure Debian on the Raspberry Pi 3B+?
To: debian-***@lists.debian.org


Dear people,

I am thinking of getting a Raspberry Pi 3B+ and, from what I read, it is
mostly supported by the upstream Linux kernel, but I still have doubts about
what I may be losing or not, compared to Raspbian.

From what I read, there are some binary blobs needed for the video to work

(and I would like to use it with Kodi, to play some videos and to, perhaps,
act as a NAS or a place where I can use to save some files via NFS when a
USB HD is attached to it).

Regarding hardware support, are there many customizations in Raspbian that
are not in Debian?

Regarding video, are the players available in Debian (mpv, vlc, ffplay etc.)
able to take advantage of the hardware acceleration, if all the needed blobs
are in place? I would be tracking the testing distribution (as I do with
all my other computers).

Also, when people talk about the performance of the raspberry pi and videos,
they always talk about the hardware decoding being used (which, I suppose,
is about H.264 video) and that gives no idea of how powerful the hardware is
(or is not).

To get an idea, what about the software encoding with NEON or whatever SIMD
that the is used with arm64? How are the numbers that one can get with, say,
the following command (with or without raspbian)?

mplayer -nosound -vo null -benchmark -endpos 200
big_buck_bunny_480p_stereo.ogg

(The video available from:
http://download.blender.org/peach/bigbuckbunny_movies/)

Thanks in advance for any help with understanding both running a pure Debian
distribution on the Raspberry Pi and understanding its performance (so that
I can compare with other hardware before I go on and buy one of these small
board computers).


Thanks once again,

--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[Alan Corey]

Raspbian's pretty close to pure Debian I think, and has more hardware
drivers for the VC4, GPIO, Bluetooth. They made millions of them, the
software's pretty good. Try omxplayer and notice how busy the CPU
isn't. That's because it's utilizing the GPU in about the optimum
way. I have a Rock64 and smplayer on that uses the hardware
acceleration too. No, the Raspbian smplayer (16.11.0 (revision 8242))
isn't doing the acceleration right yet, it'll probably catch up.
Actually on the Rock it's the same version smplayer but it's arm64
Debian. Only omxplayer is fast I think. And if you read the man page
you can write little scripts like

#!/bin/bash
omxplayer -o local --win 448,272,1472,1040 $1

To use it with your choice of window size and audio output. No
screenshots though.

I have 2 Pis running Raspbian, and one running arm64 Debian using
https://people.debian.org/~stapelberg/raspberrypi3/ with updates and
upgrades. I think I prefer the Raspbian. I had to try 64 bit, but,
nah, it's not a significant improvement in this case. For one thing
64 bit is bigger and the Pi can only use 1 GB of RAM.

I'd maybe consider the Rockpro64 https://www.pine64.org/?page_id=61454
if I didn't already have a full house. But the software is in its
infancy, a lot doesn't work right yet and the documentation's in
Chinese. My Rock64's still experimental, not something I use everyday
like the Pis. I don't use a big computer at all, just Pis.

Post by Rogério Brito
Hi, people.
I tried to send the message below more than 12h ago, but it seems to
have been lost, so I am resending it via another relay.
Thanks in advance for any help,
Rogério.
---------- Forwarded message ----------
Date: Tue, Aug 14, 2018 at 6:59 AM
Subject: Running Pure Debian on the Raspberry Pi 3B+?
Dear people,
I am thinking of getting a Raspberry Pi 3B+ and, from what I read, it is
mostly supported by the upstream Linux kernel, but I still have doubts about
what I may be losing or not, compared to Raspbian.

From what I read, there are some binary blobs needed for the video to work

(and I would like to use it with Kodi, to play some videos and to, perhaps,
act as a NAS or a place where I can use to save some files via NFS when a
USB HD is attached to it).
Regarding hardware support, are there many customizations in Raspbian that
are not in Debian?
Regarding video, are the players available in Debian (mpv, vlc, ffplay etc.)
able to take advantage of the hardware acceleration, if all the needed blobs
are in place? I would be tracking the testing distribution (as I do with
all my other computers).
Also, when people talk about the performance of the raspberry pi and videos,
they always talk about the hardware decoding being used (which, I suppose,
is about H.264 video) and that gives no idea of how powerful the hardware is
(or is not).
To get an idea, what about the software encoding with NEON or whatever SIMD
that the is used with arm64? How are the numbers that one can get with, say,
the following command (with or without raspbian)?
mplayer -nosound -vo null -benchmark -endpos 200
big_buck_bunny_480p_stereo.ogg
http://download.blender.org/peach/bigbuckbunny_movies/)
Thanks in advance for any help with understanding both running a pure Debian
distribution on the Raspberry Pi and understanding its performance (so that
I can compare with other hardware before I go on and buy one of these small
board computers).
Thanks once again,
--
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[Gene Heskett]

Post by Rogério Brito
I am thinking of getting a Raspberry Pi 3B+ and, from what I read,
it is mostly supported by the upstream Linux kernel, but I still
have doubts about
what I may be losing or not, compared to Raspbian.

From what I read, there are some binary blobs needed for the video to work

(and I would like to use it with Kodi, to play some videos and to,
perhaps, act as a NAS or a place where I can use to save some files
via NFS when a USB HD is attached to it).

Apologies for missing the original message which for some reason got
marked as spam/malware.
We're running a number of RPi3s here with the "Jessie" build done by
Collabora, which relies on the Raspbian kernel and loader (hence also
any proprietary binaries), originally because KDE didn't play nicely
with Raspbian. I've also looked briefly at somebody's 64-bit port.
My suggestion would be to stick with Raspbian unless you have a very
good reason to explore alternatives.

I've gone back to armbian stretch on the rock64. Its networking init will
at least accept a gateway argument in /etc.network/interfaces.
debian-arm stretch will not, so you can get all over ones local network,
but cannot use the gateway to install any updates that might fix that.

Questions asked here re the lack of a gateway when it IS assigned haven't
been answered with a solution that worked with the exception that
someone did give me the correct syntax to make it work with "route"
after the boot and login, something the man page for route doesn't make
clear. And I am not convinced it even executes /etc/rc.local as I tried
to put that command in as a shell util, and it was ignored on reboot.

Armbian Just Works with the exception that its sd /boot partition is too
small to allow a full completion of a kernel update, but on reboot, it
has worked. When we use a 32GB (or even larger) sd card, we gain years
before the card fails, and there is no valid excuse for a /boot
partition so small its unable to hold 2 or even 3, bootable kernel
versions.

I have yet to make the rock64's do what I bought them for, but hold out
hope that they may someday, when the coder folks userstand some of us
did NOT buy them to make a media server. We want to run potentially
dangerous machinery, which requires a realtime kernel, and in the case
of the rock64, access to the spi (gpio pins) interface(s) at 50 megabaud
speeds. The pi CAN do it at 42 megabaud w/o breaking a sweat.

Thats a roadblock I expect will eventually be fixed with a new spi
driver. But I'm not reading any rumors yet. :)

[Alan Corey]

Debian on a Pi means you don't/cant' have the whole /opt/vc userland
stuff, some of which came from Broadcom. Without that the Pi is just
a slow computer. The magic is probably Pi-specific but
/opt/vc/src/hello_pi has working examples of things like OpenGL ES and
the assembly code to do an FFT on the GPU. I tried straight Debian,
on 2 of 3 machines I'm sticking with Raspbian. The folks at
https://www.raspberrypi.org/forums/ are pretty good too, some of the
original Pi engineers are in there.

Post by Gene Heskett

Post by Rogério Brito
I am thinking of getting a Raspberry Pi 3B+ and, from what I read,
it is mostly supported by the upstream Linux kernel, but I still
have doubts about
what I may be losing or not, compared to Raspbian.

From what I read, there are some binary blobs needed for the video to work

(and I would like to use it with Kodi, to play some videos and to,
perhaps, act as a NAS or a place where I can use to save some files
via NFS when a USB HD is attached to it).

Apologies for missing the original message which for some reason got
marked as spam/malware.
We're running a number of RPi3s here with the "Jessie" build done by
Collabora, which relies on the Raspbian kernel and loader (hence also
any proprietary binaries), originally because KDE didn't play nicely
with Raspbian. I've also looked briefly at somebody's 64-bit port.
My suggestion would be to stick with Raspbian unless you have a very
good reason to explore alternatives.

I've gone back to armbian stretch on the rock64. Its networking init will
at least accept a gateway argument in /etc.network/interfaces.
debian-arm stretch will not, so you can get all over ones local network,
but cannot use the gateway to install any updates that might fix that.
Questions asked here re the lack of a gateway when it IS assigned haven't
been answered with a solution that worked with the exception that
someone did give me the correct syntax to make it work with "route"
after the boot and login, something the man page for route doesn't make
clear. And I am not convinced it even executes /etc/rc.local as I tried
to put that command in as a shell util, and it was ignored on reboot.
Armbian Just Works with the exception that its sd /boot partition is too
small to allow a full completion of a kernel update, but on reboot, it
has worked. When we use a 32GB (or even larger) sd card, we gain years
before the card fails, and there is no valid excuse for a /boot
partition so small its unable to hold 2 or even 3, bootable kernel
versions.
I have yet to make the rock64's do what I bought them for, but hold out
hope that they may someday, when the coder folks userstand some of us
did NOT buy them to make a media server. We want to run potentially
dangerous machinery, which requires a realtime kernel, and in the case
of the rock64, access to the spi (gpio pins) interface(s) at 50 megabaud
speeds. The pi CAN do it at 42 megabaud w/o breaking a sweat.
Thats a roadblock I expect will eventually be fixed with a new spi
driver. But I'm not reading any rumors yet. :)
--
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Gene Heskett]

Post by Alan Corey
Debian on a Pi means you don't/cant' have the whole /opt/vc userland
stuff, some of which came from Broadcom. Without that the Pi is just
a slow computer.

And its slow because with the exception of spi and wifi, everything has
to fight for a time slot in the internal usb-2 hub it uses as a gateway
to talk to the rest of its i/o. But its a very small pinhole.

Post by Alan Corey
The magic is probably Pi-specific

The rpspi.ko spi driver included now with LinuxCNC, is 100% gplv2, and
extremely specific to the gpio in the pi-3b.

And it would make one hell of an spi driver for anything else with gpio,
but would need to be stripped of its pi-3b detectors and ported to the
newer gpio's shipping today. My thinker is 83 yo, and after a pulmonary
embolism 3 years back is no longer capable of that.

Post by Alan Corey
but
/opt/vc/src/hello_pi has working examples of things like OpenGL ES and
the assembly code to do an FFT on the GPU. I tried straight Debian,
on 2 of 3 machines I'm sticking with Raspbian.

So am I. My one working pi-3b install is raspian jessie, solid as a
block of granite unless a disk has been added or subtracted since the
last session of nano/geany adding them to /etc/fstab, otherwise it runs
an 11x36 Sheldon lathe for me from power outage to power outage. I need
to label the partitions, and edit fstab accordingly. For some reason,
blkid's do not seem to be the answer, I think because they change
according to which usb socket they are plugged into.

Sadly I cannot make a similar claim about stability for stretch.

Post by Alan Corey
The folks at
https://www.raspberrypi.org/forums/ are pretty good too, some of the
original Pi engineers are in there.

And sadly, deaf to any requests involving LinuxCNC, which needs at least
a fully preemptable kernel to run. RTAI or *enomai might work, but
hasn't been tried.

Post by Alan Corey

Post by Gene Heskett

Post by Rogério Brito
I am thinking of getting a Raspberry Pi 3B+ and, from what I
read, it is mostly supported by the upstream Linux kernel, but I
still have doubts about
what I may be losing or not, compared to Raspbian.

From what I read, there are some binary blobs needed for the video to work

(and I would like to use it with Kodi, to play some videos and
to, perhaps, act as a NAS or a place where I can use to save
some files via NFS when a USB HD is attached to it).

Apologies for missing the original message which for some reason
got marked as spam/malware.
We're running a number of RPi3s here with the "Jessie" build done
by Collabora, which relies on the Raspbian kernel and loader (hence
also any proprietary binaries), originally because KDE didn't play
nicely with Raspbian. I've also looked briefly at somebody's 64-bit
port.
My suggestion would be to stick with Raspbian unless you have a
very good reason to explore alternatives.

I've gone back to armbian stretch on the rock64. Its networking init
will at least accept a gateway argument in /etc.network/interfaces.
debian-arm stretch will not, so you can get all over ones local
network, but cannot use the gateway to install any updates that
might fix that.
Questions asked here re the lack of a gateway when it IS assigned
haven't been answered with a solution that worked with the exception
that someone did give me the correct syntax to make it work with
"route" after the boot and login, something the man page for route
doesn't make clear. And I am not convinced it even executes
/etc/rc.local as I tried to put that command in as a shell util, and
it was ignored on reboot.
Armbian Just Works with the exception that its sd /boot partition is
too small to allow a full completion of a kernel update, but on
reboot, it has worked. When we use a 32GB (or even larger) sd card,
we gain years before the card fails, and there is no valid excuse
for a /boot partition so small its unable to hold 2 or even 3,
bootable kernel versions.
I have yet to make the rock64's do what I bought them for, but hold
out hope that they may someday, when the coder folks userstand some
of us did NOT buy them to make a media server. We want to run
potentially dangerous machinery, which requires a realtime kernel,
and in the case of the rock64, access to the spi (gpio pins)
interface(s) at 50 megabaud speeds. The pi CAN do it at 42 megabaud
w/o breaking a sweat.
Thats a roadblock I expect will eventually be fixed with a new spi
driver. But I'm not reading any rumors yet. :)

See above, the src code for rpspi.ko is available and gplv2.