Re: Debian on ARM64

[Alan Corey]

Old-fashioned maybe but maybe I was expecting an ftp//. URL, or I did a web
search.  That was a few months ago.

On Thu, Aug 8, 2024, 7:30 PM Wookey  wrote:

> On 2024-08-08 17:34 -0400, Alan Corey wrote:
> > Thank you, it's not easy to find.
>
> Type 'debian' into a search engine. Top hit is: https://www.debian.org/
>
> Big 'download' icon on top right. It's true that the big 'Download' button
> get you an x86_64 image. But clicking on
> 'other downloads' immediately below, gets you to:
> https://www.debian.org/distrib/
>
> Most of the images there are x86 too, except for the cloud ones. (We
> should fix that for the next release) But if you click on 'small
> installation image' or 'complete installation image' you get pages
> with images for all the arches on, including arm64.
>
> e.g. 'small installation image' gets you to
> https://www.debian.org/distrib/netinst with links for "Small CDs or
> USB sticks"
>
> https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.6.0-arm64-netinst.iso
>
> I'm not convinced that that is really 'not easy to find', but I agree
> it could be fewer clicks, and we have too heavy an emphasis on x86_64
> for the modern age, and arm64 images should be on the 'other
> downloads' page, so thanks for bringing that to our attention. With a
> bit of luck someone will change it soon.
>
> Wookey
> --
> Principal hats:  Debian, Wookware, ARM
> http://wookware.org/
>

Re: Debian on ARM64

[Alan Corey]

Thank you, it's not easy to find.

On Thu, Aug 8, 2024, 5:11 PM Luna Jernberg  wrote:

> https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/
> (if you have network and can burn a CD and use netboot)
>
> https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/
> (if you need an offline install DVD)
>
> Den tors 8 aug. 2024 kl 22:09 skrev :
> >
> > Hiya,
> >
> > How do I get access to Debian 12 on ARM64?
> >
>
>

Re: Ability to further support 32bit architectures

[Alan Corey]

So, can you set an RPI4 to 32 bit for even more speed?
My Pi4 config.txt (Debian Bookworm) says

# Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
arm_64bit=1

I haven't tried it because I don't know how the software will handle the
timing.

On Fri, Jan 12, 2024 at 1:37 PM gene heskett  wrote:

> On 1/12/24 13:07, Alan Corey wrote:
> > Are you forgetting that 64 bit is slower?  In the arm world where it's
> > easily switchable 64 bit is pokey when you don't need it.
> >
> Thank Alan, to put numbers behind that, linuxcnc has a thing called
> latency-test on an rpi4b the armhf kernel I built from 4.19 srcs, can
> respond to an irq in 12 microseconds, this in 2018. in 2023, an arm64
> rt-preempt kernel can only do that in around 50 microseconds. The huge
> majority of that time is a increased size of the stack frame it has to
> put away and then reload the environment to handle the interrupt.
>
> > On Fri, Jan 12, 2024, 12:54 PM  > <mailto:r...@neoquasar.org>> wrote:
> >
> >
> >
> > Sent from my mobile device.
> >
> >
>  
> > *From:* YunQiang Su mailto:wzss...@gmail.com>>
> > *Sent:* Friday, January 12, 2024 10:11
> > *To:* r...@neoquasar.org <mailto:r...@neoquasar.org>
> > *Cc:* noloa...@gmail.com <mailto:noloa...@gmail.com>;
> > debian-ker...@lists.debian.org
> > <mailto:debian-ker...@lists.debian.org>; debian-arm@lists.debian.org
> > <mailto:debian-arm@lists.debian.org>; debian-de...@lists.debian.org
> > <mailto:debian-de...@lists.debian.org>;
> > debian-rele...@lists.debian.org  debian-rele...@lists.debian.org>
> > *Subject:* Re: Ability to further support 32bit architectures
> >
> > mailto:r...@neoquasar.org>> 于2024年1月12日周五
> > 23:59写道：
> >  >
> >  > Keeping in mind that I am new to this arena...
> >  >
> >  > I have some Intel systems - both 64-bit and 32-bit - that I might
> > be able to use as build platforms.
> >  >
> >
> > I guess all of your hardwares are 64bit. You setup different OS on
> them.
> >
> > No. I have multiple 32-bit systems, one of which is Intel.
> >
> >  > What does the Debian team need from me to be able to use these
> > systems?
> >  >
> >
> > It's not about performance of hardware. It is about some limitation
> > of 32bit.
> > 2 examples for it:
> > 1. if we use 32bit value for time, it will overflow in 2038, then
> > your time will be shown as 1900.
> > https://en.wikipedia.org/wiki/Year_2038_problem
> > <https://en.wikipedia.org/wiki/Year_2038_problem>
> > 2. A single process (or maybe APP, not precisely), can only use
> UP
> > to 4GiB RAM.
> > In fact on most system the value is less than 4GiB:
> >on intel32, it is 3GiB
> >on mips32, it is 2GiB
> > But currently, it is not enough, for example, when we build a
> > big APP, it will need much more RAM.
> > The RAM does install in your Rack, but you can NOT use it.
> > https://en.wikipedia.org/wiki/3_GB_barrier
> > <https://en.wikipedia.org/wiki/3_GB_barrier>
> >
> >  > I can't guarantee they'll be FAST, but I'll do what I can to make
> > them EFFECTIVE.
> >  >
> >
> > If you are really need 32bit system. Maybe you can say out why you
> > *REALLY* need it.
> > For most users, the suggestion is: upgrade to 64bit.
> >
> >
> > That's not at all what I was asking or talking about.
> >
> > --J
> >
>
> Cheers, Gene Heskett.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
>
>

-- 
-
Education is contagious.

Re: Ability to further support 32bit architectures

[Alan Corey]

Are you forgetting that 64 bit is slower?  In the arm world where it's
easily switchable 64 bit is pokey when you don't need it.

On Fri, Jan 12, 2024, 12:54 PM  wrote:

>
>
> Sent from my mobile device.
>
> --
> *From:* YunQiang Su 
> *Sent:* Friday, January 12, 2024 10:11
> *To:* r...@neoquasar.org
> *Cc:* noloa...@gmail.com; debian-ker...@lists.debian.org;
> debian-arm@lists.debian.org; debian-de...@lists.debian.org;
> debian-rele...@lists.debian.org
> *Subject:* Re: Ability to further support 32bit architectures
>
>  于2024年1月12日周五 23:59写道：
> >
> > Keeping in mind that I am new to this arena...
> >
> > I have some Intel systems - both 64-bit and 32-bit - that I might be
> able to use as build platforms.
> >
>
> I guess all of your hardwares are 64bit. You setup different OS on them.
>
> No. I have multiple 32-bit systems, one of which is Intel.
>
> > What does the Debian team need from me to be able to use these systems?
> >
>
> It's not about performance of hardware. It is about some limitation of
> 32bit.
> 2 examples for it:
>1. if we use 32bit value for time, it will overflow in 2038, then
> your time will be shown as 1900.
>https://en.wikipedia.org/wiki/Year_2038_problem
>2. A single process (or maybe APP, not precisely), can only use UP
> to 4GiB RAM.
>In fact on most system the value is less than 4GiB:
>   on intel32, it is 3GiB
>   on mips32, it is 2GiB
>But currently, it is not enough, for example, when we build a
> big APP, it will need much more RAM.
>The RAM does install in your Rack, but you can NOT use it.
>   https://en.wikipedia.org/wiki/3_GB_barrier
>
> > I can't guarantee they'll be FAST, but I'll do what I can to make them
> EFFECTIVE.
> >
>
> If you are really need 32bit system. Maybe you can say out why you
> *REALLY* need it.
> For most users, the suggestion is: upgrade to 64bit.
>
>
> That's not at all what I was asking or talking about.
>
> --J
>

Re: Just tried arm64 netinstall on a bananai-m5

[Alan Corey]

Seems to me it would be a good target to shoot for having "make
menuconfig" encompass hardware choices as well as others, so the
hardware is just another choice in the menu.

On 8/15/23, peter green  wrote:
> On 15/08/2023 17:44, gene heskett wrote:
>> used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
>> ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
>> bring card back to reader, can't mount it, wrong filesystem for both
>> partitions. Give up, write Armbian-jammie-full-desktop iso to card, mounts
>> ok, boots bananapi-m5 normally.
>>
>> What did I do wrong?
>
> The unfortunate reality is that boot on arm is *still* a mess. The server
> guys and the windows laptop guys
> have settled on uefi (though the implementations are often far from
> perfect), but the hobbyist board segment
> is still all over the place, with each board (or family of closely related
> boards) still needing it's own build
> of u-boot that knows how to initialise the board, load a kernel and initrd
> and pass them the relavent device
> tree.
>
> For some boards, Debian offers "concatenatable images", where a
> board-specific boot section can be concatenated
> with a board-independent d-i section to produce a boot image suitable for a
> specific board, yours doesn't seem
> to be one of them though.
>
> .
>
>


-- 
-
Education is contagious.

Re: Looking for an armhf install image

[Alan Corey]

I'm not sure exactly how debootstrap works but it seems to let me set
up an armhf install, and running file on the resulting /bin/bash shows
it's 32-bit.  I get a good chroot simulating a drive but it doesn't
boot yet.  It's 263 MB and I copied it with cp -ar to a blank SD card.

For whatever reason I'm talking about the same issue in the thread at
https://forums.debian.net/viewtopic.php?p=770867#p770867

On 4/4/23, Tim Small  wrote:
> I could be wrong, but I also thought that processor errata
> fixes/workarounds for 64 bit capable ARM processors are only
> (consistently) applied to the 64 bit kernel.
>
> i.e. if you run a 64-bit-capable ARM processor such as the A53 with a
> 32-bit Linux kernel, then you might hit unpatched processor errata,
> whereas wouldn't be vulnerable to those when running a 64-bit Linux kernel.
>
> Now it may well be that for a widely used machine like the Pi 3, that
> the errata fixes for the A53 core have made it into the 32 bit kernel
> anyway.
>
> In the more general case, running a 32 bit user space with a 64 bit
> kernel might be an option?
>
> Tim.
>
>
>
> On 03/04/2023 12:56, Lennart Sorensen wrote:
>> On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote:
>>> I know I can but it will be twice as slow, which is why I want armhf.
>>> Under 64 bit both the data and pointers will be twice as big.  With
>>> unlimited memory that would be OK but a Pi CPU can only access 1 GB.
>>> I've tried 64 bit.
>>
>> It's certainly a balance trade off.  The pointers will be twice as large.
>> The data will be whatever size the code asked for.  Only in the case that
>> the code asked to use a long will be be 32 bit in one case and 64 bit
>> in the other case.  Most code isn't that sloppy about their data types.
>>
>> In terms of actual code, apparently the A53 core runs 64 bit code about
>> 20% faster than 32 bit code, so it comes down to whether you are doing
>> execution heavy or data heavy work.
>>
>


-- 
-
Education is contagious.

Re: Looking for an armhf install image

[Alan Corey]

Well, somewhere I got this and I like it, I'd like to have more.  On a Pi 3b:

Architecture:armv7l
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Vendor ID:   ARM
Model:   4
Model name:  Cortex-A53
Stepping:r0p4
CPU max MHz: 1200.
CPU min MHz: 600.
BogoMIPS:51.20
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Not affected
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:Mitigation; __user pointer sanitization
Vulnerability Spectre v2:Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected
Flags:   half thumb fastmult vfp edsp neon
vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32



On 4/3/23, Lennart Sorensen  wrote:
> On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote:
>> I know I can but it will be twice as slow, which is why I want armhf.
>> Under 64 bit both the data and pointers will be twice as big.  With
>> unlimited memory that would be OK but a Pi CPU can only access 1 GB.
>> I've tried 64 bit.
>
> It's certainly a balance trade off.  The pointers will be twice as large.
> The data will be whatever size the code asked for.  Only in the case that
> the code asked to use a long will be be 32 bit in one case and 64 bit
> in the other case.  Most code isn't that sloppy about their data types.
>
> In terms of actual code, apparently the A53 core runs 64 bit code about
> 20% faster than 32 bit code, so it comes down to whether you are doing
> execution heavy or data heavy work.
>
> --
> Len Sorensen
>


-- 
-
Education is contagious.

Re: Looking for an armhf install image

[Alan Corey]

I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big.  With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

On 4/2/23, Emanuele Rocca  wrote:
> Hi Alan,
>
> On Sat, Apr 01, 2023 at 09:01:42PM -0400, Alan Corey wrote:
>> I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
>> with Debian armhf
>
> The Raspberry Pi 3 has a 64-bit CPU, you can install Debian arm64 instead
> of
> armhf on it.
>
> ema@raspi:~
> $ sudo dmesg | grep 'Machine model'
> [0.00] Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
> ema@raspi:~
> $ lscpu | head
> Architecture:aarch64
> CPU op-mode(s):  32-bit, 64-bit
> Byte Order:  Little Endian
> CPU(s):  4
> On-line CPU(s) list: 0-3
> Vendor ID:   ARM
> Model name:  Cortex-A53
> Model:   4
> Thread(s) per core:  1
>
>


-- 
-
Education is contagious.

Re: Looking for an armhf install image

[Alan Corey]

Never mind, I'm just looking at
https://raspi.debian.net/tested-images/ which is about what I'm
looking for.  I also found a complete(?) set of raspbian archives back
to 2012 at http://downloads.raspberrypi.org/raspbian/images/

On 4/1/23, Alan Corey  wrote:
> I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
> with Debian armhf about a year ago and forgot how I did it.  A couple
> evenings spent searching and downloading got me nowhere so I thought
> I'd ask here since it's Debian arm.  At one point there were images
> requiring you to concatenate 2 parts to create the image then boot
> from that, that may be what I'm running.  I just want to make more of
> these.  The uname I get here is Linux upstairs 5.10.0-15-armmp #1 SMP
> Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux
>
> armmp?  I thought it was just armhf  Bullseye is fine, I want something
> stable.
>
>   Alan Corey
>
> --
> -
> Education is contagious.
>


-- 
-
Education is contagious.

Looking for an armhf install image

[Alan Corey]

I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
with Debian armhf about a year ago and forgot how I did it.  A couple
evenings spent searching and downloading got me nowhere so I thought
I'd ask here since it's Debian arm.  At one point there were images
requiring you to concatenate 2 parts to create the image then boot
from that, that may be what I'm running.  I just want to make more of
these.  The uname I get here is Linux upstairs 5.10.0-15-armmp #1 SMP
Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux

armmp?  I thought it was just armhf  Bullseye is fine, I want something stable.

  Alan Corey

-- 
-
Education is contagious.

Re: Is an ARM computer a good choice? Which one?

[Alan Corey]

I also have an Acer Chromebook that's aarch64, bought because it was Arm to
replace the Pinebook.  Chromebooks are weird but it does a little Debian
Bullseye running under Chrome OS.  It runs for days on a battery charge,
quite fun compared to the usual Intel/AMD power hungry  beasts.

On Mon, Mar 20, 2023 at 11:21 PM Paul Wise  wrote:

> On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:
>
> > Would an ARM-based machine be a good freedom-respecting computer to
> > run Debian on? I read the Raptor/Power guys saying modern ARM has
> > freedom problems in a, but I haven't seen them go into specifics.
>
> It depends on what you mean by freedom-respecting. All of the major
> ARM SoC vendors now have libre GPU drivers (inc IMGTEC). There may be
> various minor drivers that aren't free though depending on devices.
> For example sometimes GPS on smartphones uses a proprietary daemon.
>
> Firmware on the other hand is a different matter and quite varied.
>
> For example, the RPi devices start the VideoCore GPU first, proprietary
> firmware then starts the ARM cores, then starts the ARM boot process.
> The LibreRPi folks are reverse engineering this firmware and maybe also
> the other cores on the SoC, which are all different ISAs. In addition
> there is some DRM but that turns out to be easily bypassed.
>
> https://github.com/librerpi/lk-overlay/
>
> https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt
>
> On lots of other devices (esp SBCs), the ARM core starts first and its
> bootrom loads libre bootloaders like u-boot, which load Linux.
>
> On other devices, especially laptops, use UEFI, which is usually a
> vendor fork of TianoCore EDK2, possibly not published. There are some
> devices that can run mainline libre edk2+edk2-platforms, but the latter
> is not available in Debian yet so you would need to package it.
>
> https://github.com/tianocore/edk2-platforms/
>
> Outside boot firmware, most firmware will be proprietary on ARM, just
> as it is on x86 or any other platform except the ones where there have
> been intensive reverse engineering efforts like RaptorCS POWER devices.
>
> On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform,
> other devices have less mainline Linux support or worse freedom issues.
>
> https://wiki.debian.org/Mobile
>
> On laptops, probably the Apple ARM devices are the fastest, but
> mainline Linux isn't yet suitable but is gaining ground quickly.
> I think there might be some blobs during the boot or something and
> the different page size for Apple ARM devices might be a challenge.
> Otherwise Lenovo and other vendors have some ARM laptops. Or
> there is the PineBook or MNT Reform for more esoteric devices.
>
> https://asahilinux.org/
>
> Not sure about ARM desktops. ARM servers seem problematic, IIRC the
> arm64 ones Debian uses for buildds are unstable and the potential
> replacements are way too expensive. Not sure of the status here.
>
> > Will popular Debian software "generally work"
>
> There aren't many open bugs tagged as affecting ARM ports and most of
> them look like build related failures rather than not working. Probably
> folks don't bother to usertag their ARM-only bug reports though.
>
>
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-arm%40lists.debian.org
> https://wiki.debian.org/Teams/Debbugs/ArchitectureTags
>
> There are of course various build/test issues on ARM ports too.
>
> https://buildd.debian.org/status/architecture.php?a=arm64
> https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=arm64
> https://ci.debian.net/status/failing/?arch[]=arm64
>
> > I don't particularly want to get deep into being a porter
>
> Personally I think users of every non-amd64 port should consider doing
> porting work to keep their ports viable, since your personal package
> set might not be on the radar of vendors like ARM or other users.
>
> In case you do, we now have a document about the different ways to
> contribute to creating new ports (it applies to existing ports too).
> Some of the steps may be missing for existing ports, for example all
> of the ARM ports are missing a page based on the status template.
>
> https://wiki.debian.org/PortsDocs/New
> https://wiki.debian.org/PortTemplate
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>


-- 
-
Education is contagious.

Re: Is an ARM computer a good choice? Which one?

[Alan Corey]

Well, I said barely qualified.  I retired in 2009 from an IT job
(using and installing Windows) at a local college.  With very few
exceptions I've run only Linux on my Pi 3bs since.  When I can get a
Pi4 I'll be glad of the extra RAM and buy a few but I do everything on
these Pis.  They won't compile something like Firefox, even with much
fiddling with swap.

I had a Pinebook Pro https://www.pine64.org/pinebook-pro/ until it had
a hinge failure and the spare parts situation is dubious but mine is
apart in a box.  It would compile Firefox (rock64 also), a couple
other machines would too.  I have a rock64
https://www.pine64.org/devices/single-board-computers/rock64/  These
are both Chinese, no Ampere Computing involved.  But the RAM size on
every ARM machine I've had is limited to what's built into the SOC,
maybe some use an SODIMM or something now.

None of my computers have a fan, the Pis  (and Zeros) will run on a
single 186500 lithium cell.  Learning to program the GPU was goal of
mine but that's not portable.  I don't have a 400 watt computer
anymore, my latest project is streaming MLB baseball games (on a Pi
3B).

On 3/20/23, Lionel Élie Mamane  wrote:
> The Raspberrys have to me a reputation of being small cheap "slower"
> hackable mini-computers, not "workhorses". Have they scaled up that
> much since they were introduced?
>
> Is even the Raspberry Pi 4 even close to 'a beefy but quiet desktop
> that won't shy away from compiling e.g. LibreOffice'? I don't know
> what hardware it runs, but the buildd for arm64 took 17 hours to build
> LibreOffice
> https://buildd.debian.org/status/logs.php?pkg=libreoffice&ver=4%3A7.4.5-2&arch=arm64
> and from https://db.debian.org/machines.cgi
> the hardware seems to be sponsored by Ampere Computing, so maybe it
> uses one of their CPUs?
>
>
> Also, I'm worried about the memory. My current desktop has as 8.7GB to
> 10GB memory used when running "nothing in particular", no compilation,
> just Exim4 (+ bayesian spam filtering software when an email comes
> in), XFCE, Firefox, Emacs, terminal emulator / shell windows, mutt and
> a few instant messaging clients. And a Raspberry Pi 4 tops at 8GB?
>
>
> Or are you saying I should run that as a silent "terminal" to SSH into
> my real work machine? Which begs the question of what the work machine
> would be :)
>
>
> And any idea for a laptop?
>
> On Mon, Mar 20, 2023 at 08:16:26PM -0400, Alan Corey wrote:
>> This is a non-technical barely qualified opinion but yes.  An easy
>> start is a Raspberry Pi, about a 3B ($35), it's what I'm typing on.
>> I've got 4 of them.  And this one is running Debian, not Raspbian AKA
>> Raspberry Pi OS.  The differences are tiny.  Just get a monitor and
>> keyboard, a couple of SD cards about 32 GB or larger and a Pi.  It's
>> easy to download your first image and get it booted, from there you
>> can experiment.  Install Synaptic the package manager, after that you
>> search for applications and click on them to install.
>>
>> There is a Raspberry Pi 4 which is considerably better but relatively
>> rare due to the infamous chip shortage.  I have other ARM machines too
>> but the Pi 3B is super reliable and straight forward.  Try a $10 Zero
>> for a single core version, but have fun.
>>
>> On 3/20/23, Lionel Élie Mamane  wrote:
>> > Would an ARM-based machine be a good freedom-respecting computer to
>> > run Debian on? I read the Raptor/Power guys saying modern ARM has
>> > freedom problems in a, but I haven't seen them go into specifics. Is
>> > it at least "not as bad" as amd64, with Intel's Management Engine and
>> > AMD's equivalent? Or is something like a System76 or Puri.sm
>> > amd64-based machine better / just as good?
>> >
>> > Do you have specific "ready to buy" (even if lead times are months,
>> > not year+) computers to recommend for that? For a laptop? For a
>> > "beefy" but quiet desktop that won't shy away from compiling
>> > e.g. LibreOffice?
>> >
>> > Will popular Debian software "generally work" or will I run into
>> > "many" situations like e.g. Firefox WebRTC doesn't work on Power and
>> > QT 5 doesn't work on Sparc64 (!!!)?
>> >
>> > I don't particularly want to get deep into being a porter, but I want
>> > a good desktop to run XFCE, emacs, mutt, gdal, Firefox ESR, etc,
>> > developing my pet software, maybe get back into LibreOffice (a beast
>> > to compile...)  development and/or become active as Debian package
>> > maintainer again, flashing LineageOS to my Android pocket computers
>> > (smartphones) until a better alternative becomes usable, ...
>> >
>> > Thanks in advance for your advice,
>> >
>> >
>> >
>>
>>
>
>


-- 
-
Education is contagious.

Re: Is an ARM computer a good choice? Which one?

[Alan Corey]

This is a non-technical barely qualified opinion but yes.  An easy
start is a Raspberry Pi, about a 3B ($35), it's what I'm typing on.
I've got 4 of them.  And this one is running Debian, not Raspbian AKA
Raspberry Pi OS.  The differences are tiny.  Just get a monitor and
keyboard, a couple of SD cards about 32 GB or larger and a Pi.  It's
easy to download your first image and get it booted, from there you
can experiment.  Install Synaptic the package manager, after that you
search for applications and click on them to install.

There is a Raspberry Pi 4 which is considerably better but relatively
rare due to the infamous chip shortage.  I have other ARM machines too
but the Pi 3B is super reliable and straight forward.  Try a $10 Zero
for a single core version, but have fun.

On 3/20/23, Lionel Élie Mamane  wrote:
> Would an ARM-based machine be a good freedom-respecting computer to
> run Debian on? I read the Raptor/Power guys saying modern ARM has
> freedom problems in a, but I haven't seen them go into specifics. Is
> it at least "not as bad" as amd64, with Intel's Management Engine and
> AMD's equivalent? Or is something like a System76 or Puri.sm
> amd64-based machine better / just as good?
>
> Do you have specific "ready to buy" (even if lead times are months,
> not year+) computers to recommend for that? For a laptop? For a
> "beefy" but quiet desktop that won't shy away from compiling
> e.g. LibreOffice?
>
> Will popular Debian software "generally work" or will I run into
> "many" situations like e.g. Firefox WebRTC doesn't work on Power and
> QT 5 doesn't work on Sparc64 (!!!)?
>
> I don't particularly want to get deep into being a porter, but I want
> a good desktop to run XFCE, emacs, mutt, gdal, Firefox ESR, etc,
> developing my pet software, maybe get back into LibreOffice (a beast
> to compile...)  development and/or become active as Debian package
> maintainer again, flashing LineageOS to my Android pocket computers
> (smartphones) until a better alternative becomes usable, ...
>
> Thanks in advance for your advice,
>
> --
> Lionel
>
>


-- 
-
Education is contagious.

Re: About ARM

[Alan Corey]

Sounds a little like a Pinebook Pro
https://www.pine64.org/pinebook-pro/ I wish mine hadn't died (hinge
crapout).  As far as I know they aren't available right now doe to the
chip shortage but that's getting to be an old story, there might be
some around somewhere.

I bought a mid-price Chromebook (Acer CP-513) as a replacement but I'm
not real happy with it.  It is a 64 bit ARM machine with a couple days
battery life but it mostly runs Google Chrome OS.  It can run Debian
part time as a secondary OS, it can't run a server because Debian only
runs part time.  Mostly doesn't do xfree-86.  Debian is a task running
under Chrome I think.  Mostly Android compatible, big touch screen.

On 2/8/23, p db  wrote:
> Good Evening,
>
> Thank you very much for your replies, finally i found an arm laptop with
> these specs:
>
> CPU: 64-Bit Dual-Core ARM 1.8GHz Cortex A72 and Quad-Core ARM 1.4GHz Cortex
> A53
> GPU: Quad-Core MALI T-860
> RAM: 4 GB LPDDR4 Dual Channel System DRAM Memory
> Flash: 64 GB eMMC 5.0
> Wireless: WiFi 802.11AC + Bluetooth 5.0
> One USB 3.0 and one USB 2.0 Type-A Host Ports
> USB 3.0 Type-C ports with alt-mode display out (DP 1.2) and 15W 5V 3A
> charge.
> MicroSD Card Slot: 1
> Headphone Jack: 1
> Microphone: Built-in
> Keyboard: Full Size ANSI(US) type Keyboard
> Touch-pad: Large Multi-Touch Touchpad
> Power: Input: 100~240V, Output: 5V3A
> Battery: Lithium Polymer Battery (9600mAH)
> Display: 14.1″ IPS LCD (1920 x 1080)
> Front Camera: 2.0 Megapixels
> Power Supply included, comes with both US and EU plugs
> Dimension: 329mm x 220mm x 12mm (WxDxH)
> Weight: 1.26 kg (2.78 lbs)
> Warranty: 30 days
>
> On which is possibile to install Debian, for the moment i haven't found an
> ARM computer to put on my office desk.
>
> Best Regards to all the members of Debian,
>
> Paolo Del Bene ☮️
>
>>
>


-- 
-
Education is contagious.

Re: Debian abandoning armhf, Raspberry Pi OS - was Re: [PATCH v2] arm64: compat: Implement misalignment fixups formultiword loads

[Alan Corey]

Debian ARM actually splits 3 ways: https://www.debian.org/ports/arm/
for armel, armhf, arm64.  Raspbian still uses one version I think.

I had been using Raspbian for years until somebody there decided to
drop the LXDE/Openbox desktops with Bullseye.  And they seem to be
using Debian now(?).  I actually use a RPI ZeroW for doing audio
recording powered by a 18650 cell, but at the other end I have a few
RPI 3Bs, no need for arm64.  So I took the path less trodden.  Mostly
not bad (Debian armhf) but a few oddities like menu colors in Gimp are
mostly unreadable with the default theme.

On 7/15/22, Andrew M.A. Cater  wrote:
> On Fri, Jul 15, 2022 at 05:39:34AM -0400, gene heskett wrote:
>> On 7/15/22 04:04, LinAdmin wrote:
>> > Pi 4 has much more throughput in 32-bit modes but the so
>> > called experts of Debian decided to abandon it :-(
>> >
>> >
>> > On 14.07.22 03:52, Wookey wrote:
>> > > On 2022-07-01 15:53 +0200, Ard Biesheuvel wrote:
>> > > > The 32-bit ARM kernel implements fixups on behalf of user space
>> > > > when
>> > > > using LDM/STM or LDRD/STRD instructions on addresses that are not
>> > > > 32-bit
>> > > > aligned.
>> > > > This feature is one of the remaining impediments to being able to
>> > > > switch
>> > > > to 64-bit kernels on 64-bit capable hardware running 32-bit user
>> > > > space,
>> > > > so let's implement it for the arm64 compat layer as well.
>> I agree.  So far, raspios is still available in armhf flavor, and for
>> running
>> heavy machinery with just a few microseconds to respond to an IRQ,
>> armhf builds are a given. LinuxCNC is such an application.
>>
>
> LinAdmin,
>
> Just a thought: you might want to check which "so called experts" you are
> calling out here. Wookey has been an expert at ARM for the last 15 years or
>
> more - he knows what he's talking about.
>
> Debian has *not* abandoned armhf - Debian is one of the last Linux
> distributions actively supporting 32 bit for ARM or Intel architectures.
>
> Gene,
>
> Raspberry Pi OS is **not** Debian. Strictly, it's very much on its own as a
> forkof Raspbian from Peter Green.
> For historical reasons, Raspbian and Raspberry Pi OS are the odd ones out
> with
> their version of armhf - arm v6 plus hardware floating point originally,
> where everyone else had settled on arm v7 plus hardware floating point.
>
> LinuxCNC is probably supported by neither Debian nor Raspberry Pi OS.
>
> Finally, of course, it's useful for everyone to remember to be polite
> and considerate - Code of Conduct applies here as everywhere else on
> Debian's mailing lists.
>
> With every good wish, as ever,
>
> Andy Cater
>
>>
>
>


-- 
-
Education is contagious.

Re: Debian Pinebook Pro

[Alan Corey]

See 
https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-post-install/blob/master/asound.state
for a sound fix, it's just an asound.state file, delete it if it
doesn't work.  There are other weirdnesses, like speaker/headphone
sound is 2 cascaded devices, and the speaker may not turn off when you
plug in headphones.  I have a workaround using amixer.

#!/bin/bash
# Turn laptop speakers (always card 0) off
amixer -q -c0 cset numid=28 0 &> /dev/null

and

#!/bin/bash
# Turn laptop speakers (always card 0) on
amixer -q -c0 cset numid=28 on &> /dev/null

AFAIK nobody has suspend working.

On 9/12/21, Oregano  wrote:
> September 11, 2021 9:19 PM, "Vagrant Cascadian"  wrote:
>
>> On 2021-09-11, Peter Ehlert wrote:
>>
>>> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
 On Tue, 7 Sep 2021 10:01:49 +0300
 Andrei POPESCU  wrote:
>>>
>>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>> the Pinebook Pro for my next laptop
>>
>> ...
>>> superior build quality, I really like it, but it is not my daily driver
>>>
>>> lurking here for tips on how to get Debian running on it.
>>
>> I gave a talk (that had some glitches...) at DebConf21 which has bits
>> and pieces of what I did to make a live image that boots on both the
>> pinebook and pinebook-pro:
>>
>> https://debconf21.debconf.org/talks/88-two-pinebooks-walk-into-a-bar
>>
>> with video available at:
>>
>> https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21
>>
>> And slides:
>>
>> https://salsa.debian.org/vagrant/two-pinebooks-walk-into-a-bar
>>
>> At some point I'd like to firm up the process for making live images for
>> arm64... but at the moment it's still a bit ad-hoc, though I've managed
>> a proof of concept! :)
>>
>> The next feature I need to work into it would be to add UEFI support,
>> then it could boot any system with UEFI as well as 1-3 systems with
>> compatible u-boot offsets...
>>
>> live well,
>> vagrant
>
>
> Awesome! Very much enjoyed seeing, and hearing, the talk, on and about my
> Pinebook Pro! With Kali/debian on PineBook Pro: Wifi works; sound works, not
> very loud, but loud enough to hear the talk; also has difficulty with
> suspend/hybernate and low battery.
>
> What was the purpose of providing a makefile instead of just a PDF of
> slides? I already had graphviz, but all the rest took "185 MB of archives"
> download, and used "605 MB of additional disk space," for 1.2 MB of PDF
> file? Now I is a developer/builder?!
>
>


-- 
-
Education is contagious.

Re: kernel configs in Debian

[Alan Corey]

The headers wouldn't be unnecessary if you want to build modules for
it I think.  The linux-config may do the same thing as a config.gz.

On 4/27/21, Ryutaroh Matsumoto  wrote:
> Hi Alan,
>
>> I think you can probably enable CONFIG_IKCONFIG, I'm running a
>
> I am pretty sure I can,
> as I am using my rebuilt Debian RT kernel with CONFIG_IKCONFIG=m.
> I guess that Arnd wants comparison between the original Debian kernel
> and a minimally changed kernel (I am not completely sure, of course).
>
> I wonder why the Debian kernel team keeps CONFIG_IKCONFIG
> and CONFIG_IKHEADERS disabled...
> which probably makes linux-headers-* and linux-config-* packages
> unnecessary.
>
> Best regards, Ryutaroh
>


-- 
-
Education is contagious.

Re: kernel configs in Debian

[Alan Corey]

I think you can probably enable CONFIG_IKCONFIG, I'm running a
Bullseye kernel that has a /proc/config.gz.  But the kernel did come
from Manjaro I think, it's a little strange.  It's on a Pinebook Pro
and there's no official Debian release for it yet, this came from
debootstrap.  Getting the drivers and device tree right are a
challenge, a few of the drivers are blobs.  Made in China, engineered
in Hong Kong.

On 4/27/21, Ryutaroh Matsumoto  wrote:
> Hi Alan, thank you for your interest.
>
>> Also look lor /proc/config.gz.  If you have it it's a dump of the
>> config options of the running kernel. Whether it gets generated or not
>> is itself a config option.
>
> I plan to make the minimal chanages to the config as rebuilding it by
>
> apt-get source linux/sid
> cd linux-5.10.28
> fakeroot make -f debian/rules.gen setup_arm64_none_arm64
> cat >>debian/build/build_arm64_none_arm64/.config <<'EOF'
> CONFIG_XEN=n
> CONFIG_PARAVIRT=n
> EOF
> fakeroot debian/rules source
> fakeroot make -j 3 -f debian/rules.gen binary-arch_arm64_none_arm64
>
> I expect not having /proc/config.gz as the CONFIG_IKCONFIG is disabled
> in the Debian kernel.
> I will include diff -u of .config in debian/build/build_arm64_none_arm64
> and /usr/src/linux-config-5.10/config.arm64_rt_arm64
>
> As CONFIG_XEN selects CONFIG_PARAVIRT, CONFIG_XEN=n is required
> to build a kernel with CONFIG_PARAVIRT=n.
>
> The last build of the above steps failed as ".btf.vmlinux.bin.o: file not
> recognized: file format not recognized". I am re-trying the build with
> adding
> CONFIG_DEBUG_INFO_BTF=n
>
> As single build takes 6 hours on RPi4B, it can take several days to find
> correct
> steps to build. The above steps seems completely obeying the instructions
> at
>
> https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html#s4.2.3
> and
> https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html#s4.2.5
>
> Best regards, Ryutaroh
>


-- 
-
Education is contagious.

Re: kernel configs in Debian

[Alan Corey]

Also look lor /proc/config.gz.  If you have it it's a dump of the
config options of the running kernel. Whether it gets generated or not
is itself a config option.

On 4/26/21, Ryutaroh Matsumoto  wrote:
> Hi Arnd,
>
>> Also, do you see the same performance difference with the non-rt kernel?
>> Most people would not run the -rt kernel because of the inherent
>> performance overhead, and it's not clear whether the slowdown you
>> see is the result of a combination of CONFIG_PREEMPT_RT with some
>> other option, or if this is something that hurts normal users as well.
>
> Thank you for your interest.
> I will check the differences of kernel compilation options for
> non-rt kernel (linux-image-arm64).
> Hopefully, I can return additional info. within one week.
>
> Best regards, Ryutaroh
>
>


-- 
-
Education is contagious.

Re: Unclean (USB) filesystem on reboot of arm64 8GB RPi4 UEFI

[Alan Corey]

I always use halt -p (or reboot) and I have USB drives on just about
everything.  I don't have a Pi 4 though.  Probably no UEFI.  I use hard
drives or SSDs in USB adapters.  Arm64, got 3 of them.  How about SDs in
USB readers?  I usually use msdos partitiion type.

On Thu, Apr 1, 2021, 10:43 PM Ryutaroh Matsumoto <
ryuta...@ict.e.titech.ac.jp> wrote:

> > My problem is that each time I reboot (using shutdown -r now)
> > my system boots into an initrd shell asking me to fsck /dev/sda3
> > Possibly related log entry:
>
> To access USB devices on RPi4B, initramfs must load reset_raspberrypi.ko,
> as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694
>
> I hope it fixes your problem.
> Best regards, Ryutaroh Matsumoto
>
>

Re: WiFi on RPi

[Alan Corey]

Interference from bluetooth?

On 3/3/21, Ryutaroh Matsumoto  wrote:
>> | 3: wlan0:  mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>> | link/ether dc:a6:32:ae:8d:59 brd ff:ff:ff:ff:ff:ff
>>
>> \--
>
> Just FYI, with kernel version 5.9 and 5.10, I have been unable to
> get WiFi on RPi4B 8GB working with 2.4GHz.
> 5GHz works fine without vc4.ko and fails with vc4.ko.
> 2.4GHz WiFi is usable with Raspbian kernel 64-bit 5.10,
> so I am assuming my hardware is OK.
> Since I do not use 2.4GHz WiFi because it gets interfered by my
> microwave oven, I have not spent much time on investigating the cause...
>
> Best regards, Ryutaroh
>
>


-- 
-
Education is contagious.

Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

I remember when 16 bit computers ran faster than 32.  The data is half
the size.  But eventually the advantages of the wider bus win out.
Like memory was measured in K, some chips wouldn't handle more than
640k of RAM without weird schemes.  My first computer had 64k.

On 3/3/21, Gene Heskett  wrote:
> On Wednesday 03 March 2021 03:44:13 LinAdmin wrote:
>
>> The common believe that on the same hardware 64-bit must be
>> better or equal to 32-bit is clearly wrong for the "crazy"
>> BCM2711 chip used in Pi4.
>> The detailed benchmarks for Raspian Buster are at 32 Bit
>> Kernel 4.19  and 64 Bit Kernel 5.4.
>>  showing for calculation AES 16KB  50%
>> less throughput for 64-bit.
>>
>> On my system I get similar results e.g. for AES-128 (16KB):
>>     Salsa Buster arm64     5.9.0   42'000
>>     Ubuntu LTS armv7l  5.4      92'000
>> When playing a FullHD video coded H265, the average CPU load
>> is 80% on 64-bit and less than 30% on 32-bit!
>> Similar situations when encoding to H265 using ffmpeg .
>>
>> LinAdmin
>>
>> On 02.03.21 21:30, Arnd Bergmann wrote:
>> > On Tue, Mar 2, 2021 at 7:51 PM LinAdmin 
> wrote:
>> >>> There is really no good reason to run a 32-bit /kernel/ on the Pi
>> >>> 4, especially the version
>> >>> with 8GB RAM. While the bug should get fixed in principle to make
>> >>> the default kernel
>> >>> work and allow installing a 32-bit distro, the best setup for this
>> >>> machine (especially
>> >>> the versions with less than 4GB) is to use an armhf user space
>> >>> with a 64-bit kernel.
>> >>
>> >> Benchmarking shows that the Pi4 with 32 bit kernel has about
>> >> double performance compared to 64 bit kernel!!!
>> >
>> > Can be more specific about what benchmarks and who ran them?
>> > This seems highly unlikely.
>> >
>> >Arnd
>
> To add further fuel to this fire, this is precisely why, when running cnc
> machinery with a pi3 or pi4, an armhf kernel is the only one that comes
> anywhere near meeting the performance it takes to do a decent job of
> running dangerous machinery.  The irq response time of the 64 bit
> kernels has been found to be seriously lacking. I built a
> 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
> kernel last on an rpi4 over a year ago, which can respond to a fault
> interrupt in as little as 12 microseconds.  Several have now tried the
> arm64 version and all got far worse latency results. As bad as 200
> microseconds. You simply cannot run a stepper motor, using software step
> generators at even 10% of that motors speed potential with that kind of
> timing wibbles in the steps sent. They will stall, stop, losing step
> counts. Even if the code stops and the motor then restarts, you've lost
> the home reference and wrecked the part being made. That kernel was also
> built for a pi3b and worked well for around 2 years, but the pi3b was
> about to its limits.
>
> The other limit to using it, is the odd layout of the /boot directory
> enforced by the firmware that boots it, not well documented, so I had to
> invent my own way to install that kernel. But suffice to say, its dead
> stable. I even put a small ups on it, runs for months. So stable that I
> am also running an armhf version of a buildbot for linuxcnc on it.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>


-- 
-
Education is contagious.

Re: How to push back against repeated login attempts?

[Alan Corey]

Of course, dictionary or random attacks will be drastically hampered
if you limit how often they can fail.  3 failures or so causes a
lockout for some hours is the usual.  Failed attempts can constitute a
denial of service attack under some circumstances though due to
network chatter.

On 3/2/21, Luke Kenneth Casson Leighton  wrote:
> On Tue, Mar 2, 2021 at 9:51 AM  wrote:
>
>> Considering running a freedom box or similar, I have a RPi running Buster
>> outside my home router's DMZ. It was discovered within a short time
>> (minutes or hours) of first being setup.
>
> ahh yes.  welcome to the discovery that there are people running
> extremely sophisticated long-running break-in attempts, world-wide.
>
>> It now has fail2ban running with defaults. Over about the last month,
>> fail2ban logs show about 35,000 "unbans" from about 3700 unique IPs.
>
> if you want to do something "gradual", use fail2ban recidive.
>
> i decided 3 years ago that enough was enough, and simply set all and
> any failed password attempts at an instant 2 week ban.  by running
> OpenVPN i can at least get in if i happen to make a mistake.
>
> l.
>
>


-- 
-
Education is contagious.

Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

Or just run raspbian on a Pi 3B, I've got 4 of them.  omxplayer and
other things that utilize the GPU make it quite livable.

On 3/1/21, Arnd Bergmann  wrote:
> On Mon, Mar 1, 2021 at 9:40 AM LinAdmin  wrote:
>>
>> Bullseye 64 Bit does more or less work. There arise problems when you
>> install a desktop with media players which deliver audio and should give
>> output to the headphone plug and HDMI.
>>
>> I also had to find out that all 64 Bit versions of all distributions are
>> much less powerful than the 32 Bit solution of the same software. The
>> benchmark by T. Kaiser shows that some performances of 64 Bit are only
>> about half of the values compared to the 32 Bit installation :-(
>>
>> Unfortunately the Bullseye 32 Bit kernel seems not to boot, because the
>> support of USB looks broken:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
>> I just wonder why this bug has not got any answers?
>
> Presumably nobody has tried debugging it ;-)
>
> There is really no good reason to run a 32-bit /kernel/ on the Pi 4,
> especially the version
> with 8GB RAM. While the bug should get fixed in principle to make the
> default kernel
> work and allow installing a 32-bit distro, the best setup for this
> machine (especially
> the versions with less than 4GB) is to use an armhf user space with a
> 64-bit kernel.
>
> You can get that today by installing a multiarch system starting with
> an armhf install
> (if you get its kernel to boot) and then running 'dpkg
> --add-architecture arm64' to
> allow installing the arm64 version of the kernel image. It would be
> nice to actually
> package the arm64 kernel image for armhf to make it easier to run this
> way without
> having to set up a multiarch system. This is how mipsel kernels work as
> well, so
> there is definitely precedence.
>
>Arnd
>
>


-- 
-
Education is contagious.

Re: RPi customization utility [Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]]

[Alan Corey]

What's interesting about raspi-config is that it works to some degree
on all the little ARM machines.  If it can't find what it's trying to
change it aborts.  No guarantees but I've never seen it break
anything.  I never overclock anything.

On 2/28/21, Rick Thomas  wrote:
> Thanks Andy and Alan, for the clarification.
>
> This is an experimental system, so I felt there was no long-term harm (it
> being a short-term installation, anyway) in installing rapsi-config from the
> raspian archives just to see what it looked like and explore what it could
> do.  Having verified that it really doesn't do anything I can't do just as
> easily manually (all the things Andy listed and a few more) I will probably
> take the manual approach in the future.
>
> Enjoy!
> Rick
>
> On Sun, Feb 28, 2021, at 3:49 AM, Alan Corey wrote:
>> Right, I wasn't exactly recommending running raspi-config on a non-raspian
>> system but looking at how it does things and doing them manually.  One of
>> the things I dislike about Debian (I haven't looked at others) is that
>> there's an ever-increasing hodgepodge of specialized little scripts.  If
>> you've been using it awhile you're probably not in the habit of re-reading
>> documentation to see if somebody changed how you're officially supposed to
>> do something.
>>
>> But raspi-config is a place to look up things like how to boot to a
>> command line, or how to configure locales or change your keyboard layout.
>> And it's maintained, unlike some ancient documentation that should be
>> banished but is still out there.
>>
>>
>> On Sun, Feb 28, 2021, 6:17 AM Andrew M.A. Cater 
>> wrote:
>>> On Sun, Feb 28, 2021 at 02:16:29AM -0800, Rick Thomas wrote:
>>> >
>>> > On Thu, Feb 25, 2021, at 10:10 PM, Alan Corey wrote:
>>> > > There are scripts for those, keyboard and language too.  Also WiFi
>>> > > country, I forget what else.  Locales is in there.
>>> > >
>>> > > Take a look at a recent raspi-config.  I think Odroid, maybe the
>>> > > Pine64 bunch has a generic-ized version of that.  Armbian probably
>>> > > does too.  Raspi-config is just a Bash script that uses Whiptail for
>>> > > its menus.  Parts of it are useful on other things.  It's on Github
>>> > > somewhere.
>>> > >
>>> > >
>>> > > On Thu, Feb 25, 2021, 11:09 PM Rick Thomas 
>>> > > wrote:
>>> > >>
>>> >
>>> > Thanks! Alan...
>>> >
>>> > So, here's what I found...
>>> >
>>> > Immediately after the first boot of the SD card, as root, do the
>>> > following:
>>> >
>>> > #Get the raspi-config utility:
>>> > wget
>>> > https://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20200601_all.deb
>>> > -P /tmp
>>> > #Install packages it needs:
>>> > apt-get install libnewt0.52 whiptail parted triggerhappy lua5.1
>>> > alsa-utils -y
>>> > sudo apt-get install -fy
>>> > #Install the utility itself:
>>> > dpkg -i /tmp/raspi-config_20200601_all.deb
>>> > #And run it
>>> > raspi-config
>>> >
>>> > It will give you a bunch of customizations you might want to do.  I can
>>> > personally vouch that you'll need to at least do options (1) change the
>>> > root password and set up a non-root user,  (2) Configure the network,
>>> > and (4) set localizations (timezone, keyboard, locale, and a few
>>> > others).
>>> >
>>> > The 20200601 version happens to be the latest as of this writing.  But
>>> > just to be sure, you can use the tool itself (option 8) to check for
>>> > and install any updated version.
>>> > Easy!
>>> >
>>> > Rick
>>>
>>> And whoosh - you've created a FrankenDebian and dependencies on a
>>> Raspberry
>>> Pi OS that you don't run.. Raspi-config is a collection of
>>> shell scripts. Gunnar's Raspberry Pi images are deliberately small.
>>>
>>> If you want to reconfigure locale -
>>>
>>> apt-get install locales ; dpkg-reconfigure locales
>>>
>>> (this last as root / root equivalent using sudo)
>>>
>>> Timezone: dpkg-reconfigure tzdata
>>>
>>> There are good Debian commands that will work on every Debian system you
>>> come across :-)
>>>
>>> All the very best, as ever,
>>>
>>> Andy C.
>>>
>


-- 
-
Education is contagious.

Re: RPi customization utility [Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]]

[Alan Corey]

Right, I wasn't exactly recommending running raspi-config on a non-raspian
system but looking at how it does things and doing them manually.  One of
the things I dislike about Debian (I haven't looked at others) is that
there's an ever-increasing hodgepodge of specialized little scripts.  If
you've been using it awhile you're probably not in the habit of re-reading
documentation to see if somebody changed how you're officially supposed to
do something.

But raspi-config is a place to look up things like how to boot to a command
line, or how to configure locales or change your keyboard layout.  And it's
maintained, unlike some ancient documentation that should be banished but
is still out there.


On Sun, Feb 28, 2021, 6:17 AM Andrew M.A. Cater  wrote:

> On Sun, Feb 28, 2021 at 02:16:29AM -0800, Rick Thomas wrote:
> >
> > On Thu, Feb 25, 2021, at 10:10 PM, Alan Corey wrote:
> > > There are scripts for those, keyboard and language too.  Also WiFi
> country, I forget what else.  Locales is in there.
> > >
> > > Take a look at a recent raspi-config.  I think Odroid, maybe the
> Pine64 bunch has a generic-ized version of that.  Armbian probably does
> too.  Raspi-config is just a Bash script that uses Whiptail for its menus.
> Parts of it are useful on other things.  It's on Github somewhere.
> > >
> > >
> > > On Thu, Feb 25, 2021, 11:09 PM Rick Thomas 
> wrote:
> > >>
> >
> > Thanks! Alan...
> >
> > So, here's what I found...
> >
> > Immediately after the first boot of the SD card, as root, do the
> following:
> >
> > #Get the raspi-config utility:
> > wget
> https://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20200601_all.deb
> -P /tmp
> > #Install packages it needs:
> > apt-get install libnewt0.52 whiptail parted triggerhappy lua5.1
> alsa-utils -y
> > sudo apt-get install -fy
> > #Install the utility itself:
> > dpkg -i /tmp/raspi-config_20200601_all.deb
> > #And run it
> > raspi-config
> >
> > It will give you a bunch of customizations you might want to do.  I can
> personally vouch that you'll need to at least do options (1) change the
> root password and set up a non-root user,  (2) Configure the network, and
> (4) set localizations (timezone, keyboard, locale, and a few others).
> >
> > The 20200601 version happens to be the latest as of this writing.  But
> just to be sure, you can use the tool itself (option 8) to check for and
> install any updated version.
> > Easy!
> >
> > Rick
>
> And whoosh - you've created a FrankenDebian and dependencies on a
> Raspberry
> Pi OS that you don't run.. Raspi-config is a collection of
> shell scripts. Gunnar's Raspberry Pi images are deliberately small.
>
> If you want to reconfigure locale -
>
> apt-get install locales ; dpkg-reconfigure locales
>
> (this last as root / root equivalent using sudo)
>
> Timezone: dpkg-reconfigure tzdata
>
> There are good Debian commands that will work on every Debian system you
> come across :-)
>
> All the very best, as ever,
>
> Andy C.
>
>

Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

There are scripts for those, keyboard and language too.  Also WiFi country,
I forget what else.  Locales is in there.

Take a look at a recent raspi-config.  I think Odroid, maybe the Pine64
bunch has a generic-ized version of that.  Armbian probably does too.
Raspi-config is just a Bash script that uses Whiptail for its menus.  Parts
of it are useful on other things.  It's on Github somewhere.


On Thu, Feb 25, 2021, 11:09 PM Rick Thomas  wrote:

> I installed the most recent Bullseye image [1] on my Pi4B (4GB) a few days
> ago.  It's happily running on the table next to me right now.
>
> Here's what I found:
>
> It loads and boots just as expected.  Apt and tasksel work and I was able
> to install all the utilities I need to make it useful on my network.
>
> However, I noticed a couple of things that I should have expected, but
> nevertheless caused me some confusion at first:
> 1) The default timezone is set to UTC.  I had to manually set it to
> account for the fact that I live on the US West Coast.
> 2) When I tried to use aptitude, it complained about not having "locale"
> info.  I would have expected default locale to be set to something like "C"
> that would avoid the error messages, even if some/most users would want to
> re-set it to their own preferences, later on.
>
> It would be nice if there was a README describing these quirks (and any
> others I've missed), and how to deal with them after the first boot.  Even
> better would be if there was a script that automatically ran on the first
> boot that asked a bunch of questions and made the appropriate
> customizations automatically.  I'd be willing to write such a script if
> someone else would first write the README so I knew exactly what the script
> needed to do.
>
> Great work!  Looking forward to the next iteration.
>
> Enjoy!
> Rick
>
>
> [1]  "2021.02.1011 (Bullseye)4"
> https://raspi.debian.net/tested-images/
>
>

Re: 20210210_raspi_4_buster.img - howto boot in graphics mode

[Alan Corey]

As an aside, I found it interesting that you can run xorg and wayland
at the same time in different virtual terminals (ctrl-alt-Fn).  But
I've yet to find a use for wayland.

On 2/23/21, Lennart Sorensen  wrote:
> On Tue, Feb 23, 2021 at 06:00:03PM +0100, martin wrote:
>> This morning I downloaded this image 20210210_raspi_4_buster.img from
>> https://raspi.debian.net/verified/ and installed it on a sdcard. All
>> looks
>> well in console mode, so I installed KDE and did run adduser to create a
>> normal user. But now I cannot find out how to boot into graphics mode.
>> There
>> is no good old startx but the sddm login is in /etc/init.d. I tried to
>> start
>> it but I don't get any reaction. So my question is:
>>
>> How do I boot into graphics mode?
>
> You probably didn't install it.  The image is probably kept as minimal as
> possible by default.
>
> running 'tasksel' should let you add the graphical desktop and such.
>
> --
> Len Sorensen
>
>


-- 
-
Education is contagious.

Re: 20210210_raspi_4_buster.img - howto boot in graphics mode

[Alan Corey]

try sudo apt-get install xinit
but it may be a non-graphics (minimal) version meant for headless use.
I've converted them before, start installing some big GUI stuff like
Firefox or Gimp, eventually you'll get it.

Or maybe it's set up for wayland.

On 2/23/21, martin  wrote:
> This morning I downloaded this image 20210210_raspi_4_buster.img from
> https://raspi.debian.net/verified/ and installed it on a sdcard. All
> looks well in console mode, so I installed KDE and did run adduser to
> create a normal user. But now I cannot find out how to boot into
> graphics mode. There is no good old startx but the sddm login is in
> /etc/init.d. I tried to start it but I don't get any reaction. So my
> question is:
>
> How do I boot into graphics mode?
>
> Thanks in advance,
> Martin.
>
>


-- 
-
Education is contagious.

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

That's why when you get a real time you adjust the times on your logged
events.  There's the time you got the time fix, everything else is N
microseconds before that back to when you started recording. So you record
back to  minus .

On Sun, Feb 21, 2021, 12:47 PM Reco  wrote:

> On Sun, Feb 21, 2021 at 12:19:31PM -0500, Alan Corey wrote:
> > I think it's unreasonable to expect that kind of time accuracy from the
> > first microsecond of bootup.  Relative accuracy maybe, by counting cycles
> > of a crystal oscillator and storing events in some buffer.  Then once you
> > have a good time reference write them all out to permanent storage by
> doing
> > the arithmetic to assign real times to those events.
>
> The kernel itself does exactly this.
> But what does it tell the kernel about the "right" time in the rest of
> the world (i.e. - any other host)? Exactly nothing.
>
> End result - you can measure whatever happens during the boot just fine,
> but you start 1st Jan 1970 0:00 each boot.
>
> You see, the problem is not the timekeeping, it's the setting
> more-or-less the same time on different systems.
>
> Reco
>
>

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

I think it's unreasonable to expect that kind of time accuracy from the
first microsecond of bootup.  Relative accuracy maybe, by counting cycles
of a crystal oscillator and storing events in some buffer.  Then once you
have a good time reference write them all out to permanent storage by doing
the arithmetic to assign real times to those events.

On Sun, Feb 21, 2021, 11:24 AM Reco  wrote:

> Hi.
>
> On Sun, Feb 21, 2021 at 06:10:08PM +0200, Andrei POPESCU wrote:
> > On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> > > On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
> > > > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > > > I guess a question is why you want an RTC. If you have a decent
> > > > > internet connection just run NTP on something and it will set the
> > > > > computer's clock.
> > > >
> > > > IPSec, Tor, sec=krb5* NFS mounts.
> > >
> > > And anything related to X.509.
> > >
> > > In the old days of cell phones, back when you needed a SIM card to get
> > > time from the network, you had to jump through hoops to use a
> > > non-provisioned device for development.
> > >
> > > I think things have gotten better since then. I don't recall seeing
> > > clock problems on unprovisioned devices in a while.
> > >
> > > > At least these four things are badly screwed if Debian OS lacks
> access
> > > > to RTC. Systemd manages to launch those before NTP-based time
> > > > synchronization kicks in, which leads to funny things to say the
> least.
> > >
> > > This may be a Systemd bug.
> >
> > I'd say it's up to each daemon to declare its dependencies in the
> > service file.
>
> The problem here is "started NTPd != time sync". Lack of internet
> connectivity, slow to start 1st stratum time source (GNSS cold start can
> take several minutes), misconfiugured resolver - it all will lead to the
> problem described above.
>
> And it's perfectly understandable why systemd does not have
> "time-synced.target" state. To have it it needs to magically deduce
> correct time somehow :)
>
> So no, it's not a bug per se, but an unimplementable restriction, and it
> cannot be solved by introducing everyone's dependency on ntpd. Besides,
> if your platform provides RTC (and most do) - it's a problem that should
> not arise at the first place.
>
>
> > The problems are likely also much less visible for systems that are
> > always on as systemd-timesyncd will quite quickly advance the clock on
> > reboots based on a time stamp saved during shutdown.
>
> And again - started systemd-timesyncd != synced time. The only
> difference with proper ntpd is that systemd-timestynced uses only one
> source of correct time - another NTP server.
>
> Reco
>
>

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

I guess a question is why you want an RTC.  If you have a decent
internet connection just run NTP on something and it will set the
computer's clock.  If you have a cell phone install the Termux app and
then NTP under that, that can be your local NTP clock.

I looked into it a little years ago when I had only a part time dial
up connection.  There is a time signal on GPS satellites with about 1
microsecond accuracy, it's how a GPS works, by triangulation.  But
then I got my first cell phone which got me both internet and an
accurate time.  And now I tether one to a Pi with a USB cable and it's
a wifi AP for the whole house.


On 2/21/21, Reco  wrote:
>   Hi.
>
> On Sun, Feb 21, 2021 at 02:26:26AM -0800, Rick Thomas wrote:
>> On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
>> >Hi.
>> >
>> > On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
>> > > root@pi:~# ls -l /dev/rtc*
>> > > ls: cannot access '/dev/rtc*': No such file or directory
>> > >
>> > > What package should I file a bug report against for this problem?
>> >
>> > There's nothing to report. No model of Raspberry PI has RTC, so this is
>> > expected.
>>
>> Hmmm... A little googling turns up a GPS hat from Adafruit which fits
>> the Pi4B.  It can double as both a battery backed hardware clock and
>> an NMEA-PPS source for ntp, which would be very cool.  Cost is about
>> $40 which is well within the budget for this project.
>
> Way too expensive. A battery-backed DS1307 chip will cost you $4-5 on
> Amazon *and* will do the same as far as RTC is concerned.
>
> Of course, if you absolutely need GNSS that's different. Separate GNSS
> UART connected chip cost me $20 - a certain Neoway G7.
>
> And yes, you can attach both to your RPi.
>
> Reco
>
>


-- 
-
Education is contagious.

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

Price sounds high, look around a little.  This is a GPS clock module?  The
bare module is in the $5 range I think, I have a few.  Mine came from dx.com

On Sun, Feb 21, 2021, 5:42 AM Rick Thomas  wrote:

> On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
> >   Hi.
> >
> > On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> > > root@pi:~# ls -l /dev/rtc*
> > > ls: cannot access '/dev/rtc*': No such file or directory
> > >
> > > What package should I file a bug report against for this problem?
> >
> > There's nothing to report. No model of Raspberry PI has RTC, so this is
> > expected.
>
> Hmmm... A little googling turns up a GPS hat from Adafruit which fits the
> Pi4B.  It can double as both a battery backed hardware clock and an
> NMEA-PPS source for ntp, which would be very cool.  Cost is about $40 which
> is well within the budget for this project.
>
> Thanks for the encouragement!
> Rick
>
>

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Alan Corey]

Yet if you stick with Raspbian everything "just works".  There is only one
distribution that works on everything they sold.  If you look at the source
of raspi-config you can see how the software identifies the hardware
versions

And ARMv7 becomes ARMv8 under the right conditons and can run 64 bit Debian
(not on the Zero).  There was a Manjaro I think 64 bit that I was running
on a Pi 3b a couple years ago.


On Sat, Feb 20, 2021, 6:27 AM Matthias Klein  wrote:

>
>
> Am 20. Februar 2021 11:49:27 schrieb Ian Campbell :
>
> >
> > I'm sure someone who follows rpi closer than I will correct if not, but
> > isn't the whole Pi Zero range based the older ARMv6 (i.e. not armhf)
> > processor which requires the Raspbian rebuild because it is not
> > compatible with the armhf baseline used by Debian (and most other
> > distros I think)?
>
> Yes, the Pi Zero does not support armhf.
>
> The prebuild images use the armel baseline:
> https://salsa.debian.org/raspi-team/image-specs/-/blob/master/Makefile#L70
>
> Best regards,
> Matthias
>
>
>
>

Re: Reducing apt's memory footprint (on small boxes)

[Alan Corey]

Linux From Scratch is interesting because it has no package system at
all.  But it's mostly i386 with Raspberry Pi added by a contributor.
Once it's bootstrapped everything is built from sources.

You don't actually need most upgrades, I have a Jessie machine
running, haven't updated it in a couple years.

On 2/14/21, Christoph Biedl  wrote:
> Hello,
>
> this story isn't new: Older boxes with rather small memory. In my case,
> DockStar with 128 Mbyte RAM. They still serve a job as e.g. a router,
> but that limitation becomes more and more a problem. The biggest issue,
> at least for me, is apt although it's just the bringer of the bad news:
> The packages indexes became that big they no longer fit into memory. In
> September 2015, there was a suggestion to create subsets of a release,
> but I objected it will be more or less impossible to create them without
> breaking some builds or installations for unresolved dependencies.
>
> Time has passed, the problem became worse, and my dockstars are still on
> stretch for that very problem - after a buster upgrade, they would
> often crash during an automated "apt update".
>
> However, I figured the above dependency problem isn't one I really have
> to care about. If there is an unresolvable dependency, I still could
> switch to the full packages indexes if I really have to. Also, it's only
> about installing packages, building happens on machines with sufficient
> ressources.
>
> And so I started a small project:
>
> * Take the list of binary packages that are actually installed, less
>   than 500 in my case.
> * Have copies of `dists/stretch/main/binary-{all,armel}/Packages`.
> * Drop all stanzas that are *not* in the above list.
> * gzip, xz. Create a Release file and sign it.
> * Place the file structure in an appropriate webroot.
> * Have a rewrite rule, so /pool/(.*) is redirected to the next Debian
>   mirror.
>
> As a result: Execution time of "apt update" dropped from 52 seconds to
> some 12, and the memory pressure is gone.
>
> Next steps were to repeat that for buster, do a dist-upgrade, and
> observe how the box makes it through the next hours. Looking good so
> far, therefore I'll keep maintaining this, at least for myself.
>
> Now, from my experience: Every good idea that I believe to have found
> turned out had been prosoped earlier by somebody else and/or was not as
> good as it initially seemed. So, where's the actual catch in that setup?
> Or is that something that might be of broader interest and possibly even
> become part of a Debian release?
>
> Of course there is the problem of defining which packages should be
> included in such a "debian-narrowed"¹. I have some ideas about this but
> it's a bit too early to share them. Still, even if the list contains
> 2000 binary packages, it should have everything for the tasks such a box
> would do while still being *way* smaller than the ~75k that I see in
> stretch currently,
>
> Christoph
>
> ¹ Initially, I was thinking of "narrow-gauge" but dropped that because
>   it abbreviates to "ng" ...
>
>


-- 
-
Education is contagious.

Re: No /dev/video0 on Pi 4 with CSI camera

[Alan Corey]

You could write your own script that calls fswebcam feeding it all the
options you want, chmod it executable, and put a copy in your path
somewhere.  That won't be touched by upgrades.  Not sure about the
user, if you can call sudo or su from a script or not.  I don't think
I've ever used fswebcam.  Can you add yourself to a camera group?

I wrote this and use it on my Pinebook Pro laptop which as a USB
camera as builtin.  Output filenames are date and time .jpg.

#!/bin/bash
adate=`date +"%Y-%m-%d_%H-%M"`
uvccapture -d/dev/video2 -v -x1600 -y1200 -m -o$adate.jpg



On 2/10/21, oreg...@disroot.org  wrote:
> Thanks for the forum link! As mentioned there, fswebcam can capture images
> after config.txt is setup (again and again).
>
> # fswebcam -F 5 --png --save fsw2.png
>
> gave a 384x288 png image from the camera, with a date-time tag along the
> bottom! It's not the highest quality by today's phone standards, but it's
> OK.
>
> A tip on making config.txt changes persistent after upgrades, or getting it
> to work as non-root user, would be appreciated.
>
> # fswebcam -F 5 --png --save fsw2.png
> --- Opening /dev/video0...
> Trying source module v4l2...
> /dev/video0 opened.
> No input was specified, using the first.
> --- Capturing 5 frames...
> Captured 5 frames in 0.71 seconds. (7 fps)
> --- Processing captured image...
> Setting output format to PNG, quality 0
> Writing PNG image to 'fsw2.png'.
>
> # file fsw2.png
> fsw2.png: PNG image data, 384 x 288, 8-bit/color RGB, non-interlaced
>
>
>
> January 29, 2021 6:53 PM, "Alan Corey"  wrote:
>
>> The CSI cameras are not natively anything like v4l, maybe you can run
>> something now to make them compliant. The Pi should work with a USB
>> camera and give v4l.
>>
>> See the RPI forums at
>> https://www.raspberrypi.org/forums/viewforum.php?f=43&sid=a62693ef63165f18071bd85d069e6e90
>> Or in Raspbian look at the raspistill and raspicam programs. They're
>> more like surplus cell phone cameras than anything with a standard
>> interface.
>>
>> On 1/29/21, Gunnar Wolf  wrote:
>>
>>> Hi!
>>>
>>> oreg...@disroot.org dijo [Wed, Jan 06, 2021 at 09:09:09AM +]:
>>>>> I'm experimenting with a Raspberry Pi 4 Model B and can't seem to get
>>>>> V4L to expose a /dev/video0 device when using the standard CSI camera
>>>>> module. Raspbian on the same device seems to expose one correctly. I'm
>>>>> using the 20200707_raspi_4 image.
>>>> I was having similar problems with an early Pi 1, Model B+. The
>>>> following
>>>> exposed a /dev/video0 device for me. Maybe it works for a Pi4 too.
>>>
>>> I was very happy to see this message! Still...
>>>
>>>> Installed raspi_0w image.
>>>> Added start_x=1 in /boot/firmware/config.txt
>>>> Installed v4l-utils, v4l2ucp, v4l-conf.
>>>> Installed a bunch of python stuff...
>>>> No joy.
>>>> Upgraded system to debian testing (to get the bcm2835_v4l2 module, from
>>>> the staging directory).
>>>> Reboot.
>>>> Changed /boot/firmware/config.txt again, because it was overwritten
>>>> during
>>>> upgrade to testing: start_x=1 ; Also added gpu_mem=128 but not sure if
>>>> this is needed.
>>>> Reboot
>>>> Magic! /dev/video0 now exists.
>>>> Haven't captured a picture yet, but this looks promising:
>>>> # v4l2-ctl --info
>>>
>>> No luck yet :-( I tried this on a RPi4, and while /dev/vide0 exists,
>>> any attempts to use it ends up with a dead camera grabbing program :-(
>>
>> --
>> -
>> Education is contagious.
>


-- 
-
Education is contagious.

Re: Debian on a Iomega StorCenter ix4-200d...

[Alan Corey]

Try ctrl-alt-F(1-4 or so) for virtual terminals.

On booting, you'll probably need some uboot.  Which looks quite
complicated, see https://gitlab.denx.de/u-boot/u-boot

On 2/3/21, Marco Gaiarin  wrote:
>
> Someone gift me a NAS as subject, some year ago, and i was curious about
> installing debian in...
>
> I've just installed debian on m68k, ppc, sparc, spar64, alpha and now...
> Arm.
>
>
> I've done some search and speaked with some friends here in local linux
> user
> group, leading to some info about u-boot and arm architecture.
> I've:
>
> a) found the serial pin and connected a serial cable/adapter
>
> b) understood that in ARM there's no 'automatic hardware inventory', and
> the
>  exact hardware inventory have to be provided via a DTB file.
>
> c) found the DTB of this box here:
>   https://forum.doozan.com/read.php?2,12096
>
>
> so, i've downloaded the 'raw' linux kernel and built a uImage from here:
>
>   
> http://ftp.it.debian.org/debian/dists/buster/main/installer-armel/current/images/kirkwood/netboot/
> with:
>   cat vmlinuz-4.19.0-13-marvell kirkwood-iomega_ix4_200d.dtb > uKernel
>   mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n
> "Debian kernel" -d uKernel uImage
>
> and downloaded the initrd from here:
>
>   
> http://ftp.it.debian.org/debian/dists/buster/main/installer-armel/current/images/kirkwood/netboot/marvell/guruplug/
>
> then i've setup a tftp server and booted from tftp.
>
>
> system booted correctly, and i was able to install debian. Cool!
>
>
> Some question:
>
> a) (not specific ARM, indeed, but...) in installation, done clearly via
>  serial terminal, on the top there's some 'window' coices, eg:
>
>   1: installer 2: terminal 3: log 4: ...
>
>  how can i access other term? I've looked in installation manual, but i was
>  not able to found the key combination to switch 'window'/VT
>
> b) at the end of the installation, the system warn me that there's no 'boot
>  loader support' (or something like that), and the resulting system was not
> bootable. This was expected, but i hoped that the installer have the option
> to chroot on the new installed system to be able to to some manual
> bootloader setup, or at least to scp out the initrd.
>
> I've missed something?
>
>
> Anyway, thanks!
>
> --
>   La condivisione è il segreto di tutto...(Roberto Colonello)
>
>
>


-- 
-
Education is contagious.

Re: No /dev/video0 on Pi 4 with CSI camera

[Alan Corey]

The CSI cameras are not natively anything like v4l, maybe you can run
something now to make them compliant.  The Pi should work with a USB
camera and give v4l.

See the RPI forums at
https://www.raspberrypi.org/forums/viewforum.php?f=43&sid=a62693ef63165f18071bd85d069e6e90
Or in Raspbian look at the raspistill and raspicam programs.  They're
more like surplus cell phone cameras than anything with a standard
interface.

On 1/29/21, Gunnar Wolf  wrote:
> Hi!
>
> oreg...@disroot.org dijo [Wed, Jan 06, 2021 at 09:09:09AM +]:
>> > I'm experimenting with a Raspberry Pi 4 Model B and can't seem to get
>> > V4L to expose a /dev/video0 device when using the standard CSI camera
>> > module. Raspbian on the same device seems to expose one correctly. I'm
>> > using the 20200707_raspi_4 image.
>> I was having similar problems with an early Pi 1, Model B+. The following
>> exposed a /dev/video0 device for me. Maybe it works for a Pi4 too.
>
> I was very happy to see this message! Still...
>
>> Installed raspi_0w image.
>> Added start_x=1 in /boot/firmware/config.txt
>> Installed v4l-utils, v4l2ucp, v4l-conf.
>> Installed a bunch of python stuff...
>> No joy.
>> Upgraded system to debian testing (to get the bcm2835_v4l2 module, from
>> the staging directory).
>> Reboot.
>> Changed /boot/firmware/config.txt again, because it was overwritten during
>> upgrade to testing: start_x=1 ; Also added gpu_mem=128 but not sure if
>> this is needed.
>> Reboot
>> Magic! /dev/video0 now exists.
>> Haven't captured a picture yet, but this looks promising:
>> # v4l2-ctl --info
>
> No luck yet :-( I tried this on a RPi4, and while /dev/vide0 exists,
> any attempts to use it ends up with a dead camera grabbing program :-(
>
>


-- 
-
Education is contagious.

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Alan Corey]

I'm wondering when it will be available.  Is this in the daily builds?

On Sun, Nov 1, 2020, 2:27 PM Christian Kastner  wrote:

> On 10/31/20 11:52 PM, Vagrant Cascadian wrote:
> > Well, lima wasn't actually necessary.
> >
> > Turned out to need i2c_mv64xx for the console video on the LCD.
> >
> > Also needed to add pinctrl_axp209 to get the usb keyboard to work.
> >
> > Should be in the next kernel upload:
> >
> >
> https://salsa.debian.org/kernel-team/linux/-/commit/6b3763e98d3d5d6856d131d6a1ad246b57981fd8
> >
> https://salsa.debian.org/kernel-team/linux/-/commit/9c5c235ae023ff521bcbad740f8ba1efb9d0b9cc
>
> Thank you *very* much for looking into this! I'll give it a try as soon
> as the kernel is available, and will report back then.
>
>

Re: pinebook wifi (rtl8273cs) (Was: Debian installer auf Pinebook)

[Alan Corey]

It's in Daniel Thompson's Bulleye package for the Pinebook Pro.  I see
a few variants like 8723ae,be,com

https://github.com/daniel-thompson/pinebook-pro-debian-installer

I'm not using it right now, it has Manjaro stuff in it that I don't like.

On 11/1/20, Vagrant Cascadian  wrote:
> On 2020-11-01, Vagrant Cascadian wrote:
>> On 2020-10-31, Christian Kastner wrote:
>>> Apparently the WIFI is a RTL8723cs device and support landed in 5.9,
>>> coincidentally the kernel in bullseye
> ...
>> I don't see anything regarding RTL8723cs support specifically in 5.9
> ...
>> Maybe there's a proposed patchset somewhere or an out-of-tree driver?
>
> Nothing was ever proposed:
>
>
> https://patchwork.kernel.org/project/linux-wireless/list/?state=*&q=rtl8723cs
>
> This looks promising, though:
>
>   https://github.com/Icenowy/rtl8723cs
>
>
> live well,
>   vagrant
>


-- 
-
I already voted, leave me alone.

Re: Debian installer auf Pinebook (Was: X11 modul for pinebook?)

[Alan Corey]

Serial is through the headphone jack but there's a switch inside to change
it from headphone to  serial.  So 10 screws or so.

On Sat, Oct 31, 2020, 1:21 PM Christian Kastner  wrote:

> On 4/22/20 7:15 PM, Vagrant Cascadian wrote:
> > The debian-installer concatenateable images from buster *should* work
> > with *serial console*:
> >
> >
> https://deb.debian.org/debian/dists/buster/main/installer-arm64/current/images/netboot/SD-card-images/README.concatenateable_images
> >
> > Getting the installer running on LCD is still a work-in-progress, but
> > you *might* be able to get the text console running by editing the boot
> > arguments on the boot media and passing console=tty0 and adding the
> > appropriate modules to the initrd by appending an additional cpio
> > archive to it... finding out exactly which modules... is a
> > project. Though you could append all of the modules for the matching
> > kernel version.
> >
> > But no, there's no image that will "just work" without some fiddling.
>
> I found this older thread and wanted to check if there have been any
> updates on this that I might have missed?
>
> I gave the images from buster a try and the installation process ran
> fine on LCD until the network interface wasn't found.
>
> Apparently the WIFI is a RTL8723cs device and support landed in 5.9,
> coincidentally the kernel in bullseye, so I gave its SD card images a
> try. However, they launch to a black screen, so I assume that this still
> goes out to serial?
>
> Assuming that I figure out how to connect the serial (apparently through
> the headphone jack), should installation over serial be routine, or are
> there also still gotchas?
>
> Thanks,
> Christian
>
>

Re: Installation images for arm64

[Alan Corey]

This is more readable

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x

Device Boot  StartEnd Sectors  Size Id Type
/dev/mmcblk0p1   0 536575  536576  262M 83 Linux
/dev/mmcblk0p2  536576 54271961443M ef EFI (FAT-12/16/32)


Disk /dev/mmcblk1: 58.2 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb317b23b

Device Boot  Start   End   Sectors  Size Id Type
/dev/mmcblk1p1 * 32768163839131072   64M  c W95 FAT32 (LBA)
/dev/mmcblk1p2 *262144 122142719 121880576 58.1G 83 Linux




Disk /dev/mmcblk1boot1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk1boot0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme0n1: 953.9 GiB, 1024209543168 bytes, 2000409264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xeefe8c83

Device Boot StartEndSectors   Size Id Type
/dev/nvme0n1p1   204820991992097152 1G  c W95 FAT32 (LBA)
/dev/nvme0n1p2   22099200 2000409263 1978310064 943.3G  5 Extended
/dev/nvme0n1p5   22102016  441532415  419430400   200G 83 Linux
/dev/nvme0n1p6  441534464  462505983   2097152010G 82 Linux
swap / Solaris
/dev/nvme0n1p7  462508032 2000409263 1537901232 733.3G 83 Linux


On 10/28/20, Alan Corey  wrote:
> OK, I downloaded the netboot stuff first, there's nothing bootable on
> the sd image it made, mostly a bunch of dbs.  So I tried the netinst.
> On my Pinebook Pro, booted from a mrfixit Stretch on emmc I see:
>
> NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> mmcblk0  179:00  59.5G  0 disk
> ├─mmcblk0p1  179:10   262M  0 part /sd
> └─mmcblk0p2  179:20 3M  0 part
> mmcblk1  179:32   0  58.2G  0 disk
> ├─mmcblk1p1  179:33   064M  0 part /boot
> └─mmcblk1p2  179:34   0  58.1G  0 part /
> mmcblk1boot0 179:64   0 4M  1 disk
> mmcblk1boot1 179:96   0 4M  1 disk
> mmcblk1rpmb  179:128  016M  0 disk
> nvme0n1  259:00 953.9G  0 disk
> ├─nvme0n1p1  259:10 1G  0 part
> ├─nvme0n1p2  259:20 1K  0 part
> ├─nvme0n1p5  259:30   200G  0 part
> ├─nvme0n1p6  259:4010G  0 part [SWAP]
> └─nvme0n1p7  259:50 733.3G  0 part /data
>
> I think I should follow
> https://www.debian.org/releases/buster/arm64/ch05s01.en.html#arm64-console-setup
>
> And it looks like I need to find my serial console cable and enable it
> with the switch inside the PBP.  This has no text mode like an i386,
> video seems to be one of the last things loaded. I'm not familiar with
> UEFI so I'd rather not use it.  I have a 1 TB nvme SSD, I'd like to
> install into partitions 1 and 5 with swap on 6.  My intention is to
> leave partition 7 for my stuff and have the OS replaceable.
>
> I installed an iso file by dding it to an sd, but it doesn't boot so
> I'm in Stretch on the emmc.  I can look inside the install disk.
>
>
> On 10/27/20, Reco  wrote:
>> On Tue, Oct 27, 2020 at 10:21:01AM -0700, Vagrant Cascadian wrote:
>>> Please file bugs and/or merge requests on u-boot and
>>> arm-trusted-firmware if you want to get those parts enabled for Odroid
>>> N2 and g12a.
>>
>> Did that, thank you.
>> Currently bug reports are greylisted by buxtehude.debian.org, so it
>> could take some time to reach bugs.d.o.
>>
>> Reco
>>
>>
>
>
> --
> -
> I already voted, leave me alone.
>


-- 
-
I already voted, leave me alone.

Re: Installation images for arm64

[Alan Corey]

OK, I downloaded the netboot stuff first, there's nothing bootable on
the sd image it made, mostly a bunch of dbs.  So I tried the netinst.
On my Pinebook Pro, booted from a mrfixit Stretch on emmc I see:

NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0  179:00  59.5G  0 disk
├─mmcblk0p1  179:10   262M  0 part /sd
└─mmcblk0p2  179:20 3M  0 part
mmcblk1  179:32   0  58.2G  0 disk
├─mmcblk1p1  179:33   064M  0 part /boot
└─mmcblk1p2  179:34   0  58.1G  0 part /
mmcblk1boot0 179:64   0 4M  1 disk
mmcblk1boot1 179:96   0 4M  1 disk
mmcblk1rpmb  179:128  016M  0 disk
nvme0n1  259:00 953.9G  0 disk
├─nvme0n1p1  259:10 1G  0 part
├─nvme0n1p2  259:20 1K  0 part
├─nvme0n1p5  259:30   200G  0 part
├─nvme0n1p6  259:4010G  0 part [SWAP]
└─nvme0n1p7  259:50 733.3G  0 part /data

I think I should follow
https://www.debian.org/releases/buster/arm64/ch05s01.en.html#arm64-console-setup

And it looks like I need to find my serial console cable and enable it
with the switch inside the PBP.  This has no text mode like an i386,
video seems to be one of the last things loaded. I'm not familiar with
UEFI so I'd rather not use it.  I have a 1 TB nvme SSD, I'd like to
install into partitions 1 and 5 with swap on 6.  My intention is to
leave partition 7 for my stuff and have the OS replaceable.

I installed an iso file by dding it to an sd, but it doesn't boot so
I'm in Stretch on the emmc.  I can look inside the install disk.


On 10/27/20, Reco  wrote:
> On Tue, Oct 27, 2020 at 10:21:01AM -0700, Vagrant Cascadian wrote:
>> Please file bugs and/or merge requests on u-boot and
>> arm-trusted-firmware if you want to get those parts enabled for Odroid
>> N2 and g12a.
>
> Did that, thank you.
> Currently bug reports are greylisted by buxtehude.debian.org, so it
> could take some time to reach bugs.d.o.
>
> Reco
>
>


-- 
-
I already voted, leave me alone.

Re: Bullseye installer, daily image broken for cubox-i

[Alan Corey]

Concatenateable images seem like a good idea but it looks like there
are none for any hardware I have (Pinebook Pro, Odroid N2, Rock64,
Raspberry Pi 3B).

Having a serial console might let you see more of what's going on.
How to do that varies with the machine.

On 10/26/20, Vagrant Cascadian  wrote:
> On 2020-10-26, Rainer Dorsch wrote:
>> I wanted to do a test on the mainline support of bullseye for the
>> Cubox-i.
>>
>> I downloaded the bullseye installer from
>>
>> https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/
>>
>> put it on an SD card
> ...
>> But all I saw was a quick u-boot message then the screen stayed dark
>> (screen
>> reported "no HDMI signal").
>>
>> Strange is that I see the same issue with the lastest install images of
>> buster
>> :-/
>>
>> The Fedora32 installer boots and the installer comes up.
>>
>> Any ideas what is going wrong? Hmm.just wondering now, is it required
>> to
>> install Debian via ttyUSBx or should the text based installer work on
>> HDMI?
>
> It may need new modules added for the framebuffer video output; at one
> point many years ago I had gotten a wandboard quad (also imx6, like the
> cubox-i) to boot debian-installer on the video console, but then support
> was enabled for video acceleration in the kernel and I never tracked
> down which kernel modules were needed to enable in the installer to get
> the framebuffer video back again...
>
> It's no fun playing kernel module .udeb whack-a-mole :/
>
>
> live well,
>   vagrant
>


-- 
-
I already voted, leave me alone.

Debian support for SPI/MTD on ARM?

[Alan Corey]

Since some of  the original eMMCs are starting to fail I decided to
give a more serious try to getting the nvme ssd in my Pinebook Pro
working.  It's one of the Intel 1 TB ones.  The first hurdle is
dealing with uboot but the more serious one is that the PBP relies on
putting something in SPI that hooks the nvme to boot.  That doesn't
seem to be in Debian, maybe it just needs a custom kernel, but there
should be a /dev/mtd which gets created on boot when the driver finds
the SPI.  I see none.  The nvme works, but carefully copying an image
(2 tries) ends up with something that doesn't boot (from the nvme).

The PBP now ships with Manjaro partly as a workaround, or it can run
Android or Ubuntu or whatever but they've given up on Debian.  I found
this Debian page https://wiki.debian.org/DebianInstaller/MTD but it
seems not ready for prime time "WARNING! DO NOT DO THIS ON REAL FLASH,
IT WRITES TO THE MEMORY WHICH IS PROBABLY REALLY DANGEROUS!!!" so I
didn't try it.

I'm still running the original mrfixit Debian Stretch eMMC, which I at
least backed up.  I wonder if this could be done as a kernel module
for now.  I'm not sure missing this bit of kernel is the only problem.
The nvme doesn't come standard in a PBP, you have add one, so not
everybody uses one.

-- 
-
I already voted, leave me alone.

Re: Is there any "easy to use" arm64 laptop

[Alan Corey]

I have a PBP and mostly like it except:

1. The small physical size and 1920x1080 resolution make old-school non-GUI
stuff almost impossible.

2. The touch pad has the usual buttons but they're unmarked.  And it's a
black touchpad in a black case so in low lighting it takes experimenting to
find the buttons.

But I did buy one and then invested in a 1 TB SSD which fits inside.

On Tue, Oct 13, 2020, 7:03 AM Marcin Juszkiewicz 
wrote:

> W dniu 13.10.2020 o 12:47, Andrei POPESCU pisze:
> > On Ma, 13 oct 20, 09:28:15, Andreas Tille wrote:
> >>
> >> Since I have not given up the plan to have a "small laptop replacement"
> >> for my amd64 workhorse, I wonder whether you might be able to recommend
> >> some hardware with the following features:
> >
> > The PineBookPro comes pretty close to your requirements, provided you
> > are willing to run bullseye on it.
> >
> >> 1. Easy installation from Debian installer USB medium (just if
> >>I would install some Intel machine but with an arm64 image)
> >
> > SD card images only[1].
>
> If you spend an hour on building U-Boot for on-board SPI flash then you
> can use normal AArch64 ISO.
>
> I went that way on RockPro64 (RK3399 like Pinebook Pro).
>
>

Re: bt question

[Alan Corey]

I don't think they go to sleep that fast, they just stop being
discoverable.  The 30 year old engineer that designed them thought that
would be plenty of time.  My pi kept going non-discoverable about 4 times
as I was sitting in front of it.  This phone stays discoverable as long as
the Bluetooth settings screen is up, it says.

I've gotten nowhere in getting any HID device working with Linux so far.  I
have a little cheapie USB microphone ($1.50) that's also an hid, it doesn't
work either.  No Bluetooth involved, it just plugs into a USB jack.  HID is
another layer.  But people do it, the visors that people into wearable
computers use are hid I think.  The device name becomes longer because it's
device.subdevice.  Except not with a period.

On Sat, Sep 26, 2020, 1:14 PM Gene Heskett  wrote:

> On Saturday 26 September 2020 08:23:14 Alan Corey wrote:
>
> > bluetoothctl's info feature can be useful to see what states devices
> > are in even if you're not pairing with them.  Especially devices with
> > few buttons.
> >
> > Yes there's a time limit because being discoverable is considered
> > vulnerable.
>
> I wonder if this keyboard is timeing out while I am walking the 50 feet
> from turning it on, back to this ssh console to type show. Would it be
> that fast? Or do these cellphone apps I have no way to run, have a
> wakeup call they send? In which case, can bluetoothctl trigger that
> wakeup?
>
> > On 9/26/20, Gene Heskett  wrote:
> > > On Saturday 26 September 2020 06:48:11 Alan Corey wrote:
> > >> Bring your devices closer together at least until you get them
> > >> paired. BT doesn't have great range.  There are covid tracing
> > >> schemes which figure if you got within BT range you're in danger.
> > >> 20 feet or so should be OK.  Also heavy WiFi use disrupts it since
> > >> they're both in the same frequency band.
> > >>
> > >> A device may be discoverable only when it's first turned on but
> > >> there has to be a way.  My ear buds have one button each and the
> > >> LEDs flash differently: red and blue instead of just red.  It's
> > >> easiest to start with them all within reach until they're set up.
> > >> Playing sound my ear buds aren't 100% reliable 20 feet away.  At
> > >> one job a receptionist had a BT headset, they worked within that
> > >> room, not beyond.  A niece had a BT headset for hands-free driving
> > >> on her cell phone, mostly didn't work outside her car.
> > >>
> > >> With my ear buds a long press on the one button powers them on and
> > >> makes them discoverable for about 1 minute.
> > >
> > > I wasn't aware there was a time limit. Anyway, the transmitter the
> > > phone will need to pair with is about 3 weeks away, so I'll suggest
> > > we shelve this until that kit arrives.
> > >
> > >> On Sat, Sep 26, 2020, 4:22 AM deloptes  wrote:
> > >> > Gene Heskett wrote:
> > >> > > Can anyone else contribute here?
> > >> >
> > >> > for the audio you may need the pulse bluetooth module package.
> > >> > pulseaudio-module-bluetooth
> > >
> > > Cheers, Gene Heskett
> > > --
> > > "There are four boxes to be used in defense of liberty:
> > >  soap, ballot, jury, and ammo. Please use in that order."
> > > -Ed Howdershelt (Author)
> > > If we desire respect for the law, we must first make the law
> > > respectable. - Louis D. Brandeis
> > > Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>

Re: bt question

[Alan Corey]

My phone has lots of subdevices, I don't know how to connect to any of
them yet either

info F8:CF:C5:00:F0:E2
Device F8:CF:C5:00:F0:E2 (public)
Name: MotoE2(4G-LTE)
Alias: MotoE2(4G-LTE)
Class: 0x005a020c
Icon: phone
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: OBEX Object Push  (1105--1000-8000-00805f9b34fb)
UUID: OBEX File Transfer(1106--1000-8000-00805f9b34fb)
UUID: Audio Source  (110a--1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
UUID: Headset AG(1112--1000-8000-00805f9b34fb)
UUID: NAP   (1116--1000-8000-00805f9b34fb)
UUID: Handsfree Audio Gateway   (111f--1000-8000-00805f9b34fb)
UUID: Phonebook Access Server   (112f--1000-8000-00805f9b34fb)
UUID: Message Access Server (1132--1000-8000-00805f9b34fb)
UUID: PnP Information   (1200--1000-8000-00805f9b34fb)
UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb)
Modalias: bluetooth:v001Dp1200d1436
RSSI: -68

I now have installed
dpkg-query -l | grep blue
ii  bluealsa  0.13
  armhfBluetooth ALSA Audio backend
ii  bluez 5.50-1.2~deb10u1+rpt2
  armhfBluetooth tools and daemons
ii  bluez-firmware1.2-4+rpt4
  all  Firmware for Bluetooth devices
ii  bluez-obexd   5.50-1.2~deb10u1+rpt2
  armhfbluez obex daemon
ii  bluez-tools   2.0~20170911.0.7cb788c-2
  armhfSet of tools to manage Bluetooth devices for
linux
ii  libbluetooth3:armhf   5.50-1.2~deb10u1+rpt2
  armhfLibrary to use the BlueZ Linux Bluetooth stack
ii  lxplug-bluetooth  0.14
  armhfBluetooth plugin for lxpanel
ii  pi-bluetooth  0.1.15
  all  Raspberry Pi 3 bluetooth

There's more about bluez at https://github.com/Arkq/bluez-alsa

Just occurred to me that with a musical keyboard you may run into
stuff for doing midi (music synthesizer, think moog) over bluetooth.
You probably don't want that although it could be fun, she'd just need
a laptop with software.


On 9/26/20, Alan Corey  wrote:
> I moved the base to my earbuds downstairs and connected to this Pi.  Some
> notes:
>
> Some of these things get cached, here B1 shows up twice at different
> addresses:
>
> devices
> Device CB:20:07:42:99:64 B1
> Device F3:66:48:29:CA:7D IDTW211R
> Device FE:46:6D:40:FC:43 B1
> [CHG] Controller B8:27:EB:1F:69:7C Discoverable: no
>
> info FE:46:6D:40:FC:43
> Device FE:46:6D:40:FC:43 (public)
> Name: B1
> Alias: B1
> Class: 0x00240404
> Icon: audio-card
> Paired: no
> Trusted: no
> Blocked: no
> Connected: no
> LegacyPairing: no
> ManufacturerData Key: 0x2549
> ManufacturerData Value:
>   96 52 ef 52 40 dc ca da  .R.R@...
> RSSI: -57
>
> trust FE:46:6D:40:FC:43
> [CHG] Device FE:46:6D:40:FC:43 Trusted: yes
> Changing FE:46:6D:40:FC:43 trust succeeded
> [bluetooth]# pair FE:46:6D:40:FC:43
> Attempting to pair with FE:46:6D:40:FC:43
> [CHG] Device FE:46:6D:40:FC:43 Connected: yes
> [CHG] Device FE:46:6D:40:FC:43 Modalias: bluetooth:v05D6p000Ad0240
> [CHG] Device FE:46:6D:40:FC:43 UUIDs: 110b--1000-8000-00805f9b34fb
> [CHG] Device FE:46:6D:40:FC:43 UUIDs: 110c--1000-8000-00805f9b34fb
> [CHG] Device FE:46:6D:40:FC:43 UUIDs: 110e--1000-8000-00805f9b34fb
> [CHG] Device FE:46:6D:40:FC:43 UUIDs: 111e--1000-8000-00805f9b34fb
> [CHG] Device FE:46:6D:40:FC:43 UUIDs: 1124--1000-8000-00805f9b34fb
> [CHG] Device FE:46:6D:40:FC:43 UUIDs: 1200--1000-8000-00805f9b34fb
> [CHG] Device FE:46:6D:40:FC:43 ServicesResolved: yes
> [CHG] Device FE:46:6D:40:FC:43 Paired: yes
> Pairing successful
> [CHG] Device FE:46:6D:40:FC:43 ServicesResolved: no
> [CHG] Device FE:46:6D:40:FC:43 Connected: no
>
>  connect FE:46:6D:40:FC:43
> Attempting to connect to FE:46:6D:40:FC:43
> [CHG] Device FE:46:6D:40:FC:43 Connected: yes
> Connection successful
> [CHG] Device FE:46:6D:40:FC:43 ServicesResolved: yes
>
> :info FE:46:6D:40:FC:43
> Device FE:46:6D:40:FC:43 (public)
> Name: B1
> Alias: B1
>  

Re: bt question

[Alan Corey]

I moved the base to my earbuds downstairs and connected to this Pi.  Some notes:

Some of these things get cached, here B1 shows up twice at different
addresses:

devices
Device CB:20:07:42:99:64 B1
Device F3:66:48:29:CA:7D IDTW211R
Device FE:46:6D:40:FC:43 B1
[CHG] Controller B8:27:EB:1F:69:7C Discoverable: no

info FE:46:6D:40:FC:43
Device FE:46:6D:40:FC:43 (public)
Name: B1
Alias: B1
Class: 0x00240404
Icon: audio-card
Paired: no
Trusted: no
Blocked: no
Connected: no
LegacyPairing: no
ManufacturerData Key: 0x2549
ManufacturerData Value:
  96 52 ef 52 40 dc ca da  .R.R@...
RSSI: -57

trust FE:46:6D:40:FC:43
[CHG] Device FE:46:6D:40:FC:43 Trusted: yes
Changing FE:46:6D:40:FC:43 trust succeeded
[bluetooth]# pair FE:46:6D:40:FC:43
Attempting to pair with FE:46:6D:40:FC:43
[CHG] Device FE:46:6D:40:FC:43 Connected: yes
[CHG] Device FE:46:6D:40:FC:43 Modalias: bluetooth:v05D6p000Ad0240
[CHG] Device FE:46:6D:40:FC:43 UUIDs: 110b--1000-8000-00805f9b34fb
[CHG] Device FE:46:6D:40:FC:43 UUIDs: 110c--1000-8000-00805f9b34fb
[CHG] Device FE:46:6D:40:FC:43 UUIDs: 110e--1000-8000-00805f9b34fb
[CHG] Device FE:46:6D:40:FC:43 UUIDs: 111e--1000-8000-00805f9b34fb
[CHG] Device FE:46:6D:40:FC:43 UUIDs: 1124--1000-8000-00805f9b34fb
[CHG] Device FE:46:6D:40:FC:43 UUIDs: 1200--1000-8000-00805f9b34fb
[CHG] Device FE:46:6D:40:FC:43 ServicesResolved: yes
[CHG] Device FE:46:6D:40:FC:43 Paired: yes
Pairing successful
[CHG] Device FE:46:6D:40:FC:43 ServicesResolved: no
[CHG] Device FE:46:6D:40:FC:43 Connected: no

 connect FE:46:6D:40:FC:43
Attempting to connect to FE:46:6D:40:FC:43
[CHG] Device FE:46:6D:40:FC:43 Connected: yes
Connection successful
[CHG] Device FE:46:6D:40:FC:43 ServicesResolved: yes

:info FE:46:6D:40:FC:43
Device FE:46:6D:40:FC:43 (public)
Name: B1
Alias: B1
Class: 0x00240404
Icon: audio-card
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
UUID: Handsfree (111e--1000-8000-00805f9b34fb)
UUID: Human Interface Device... (1124--1000-8000-00805f9b34fb)
UUID: PnP Information   (1200--1000-8000-00805f9b34fb)
Modalias: bluetooth:v05D6p000Ad0240
ManufacturerData Key: 0x2549
ManufacturerData Value:
  96 52 ef 52 40 dc ca da  .R.R@...
RSSI: -57

rebooting for alsa to maybe pick it up

Still paired?:  [yes]
info  FE:46:6D:40:FC:43
Device FE:46:6D:40:FC:43 (public)
Name: B1
Alias: B1
Class: 0x00240404
Icon: audio-card
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
UUID: Advanced Audio Distribu.. (110d--1000-8000-00805f9b34fb)
UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
UUID: Handsfree (111e--1000-8000-00805f9b34fb)
UUID: Human Interface Device... (1124--1000-8000-00805f9b34fb)
UUID: PnP Information   (1200--1000-8000-00805f9b34fb)
Modalias: bluetooth:v05D6p000Ad0240

alsa didn't find it yet, probably because it's a HID.  More research needed.

 aplay -l
 List of PLAYBACK Hardware Devices 
card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
  Subdevices: 4/4
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
card 1: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones
[bcm2835 Headphones]
  Subdevices: 4/4
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3

It's only seeing native Pi stuff.  But that's an alsa thing, not a bluetooth
one.  I knew this was a HID device but my phone didn't care, it just
connected to the audio sink in it.  That's what I want the Pi to do
too, at least now.  But according to the advertising these also have
microphones in them.

On 9/26/20, Alan Corey  wrote:
> bluetoothctl's info feature can be useful to see what states devices
> are in even if you're not pairing with them.  Especially devices with
> few buttons.
>
> Yes there's a time limit because being discoverable is considered
> vulnerable.
>
> On 9/26/20, Gene Heskett  wrote:
>> On Saturday 26 September 2020 06:48:11

Re: bt question

[Alan Corey]

bluetoothctl's info feature can be useful to see what states devices
are in even if you're not pairing with them.  Especially devices with
few buttons.

Yes there's a time limit because being discoverable is considered vulnerable.

On 9/26/20, Gene Heskett  wrote:
> On Saturday 26 September 2020 06:48:11 Alan Corey wrote:
>
>> Bring your devices closer together at least until you get them paired.
>>  BT doesn't have great range.  There are covid tracing schemes which
>> figure if you got within BT range you're in danger. 20 feet or so
>> should be OK.  Also heavy WiFi use disrupts it since they're both in
>> the same frequency band.
>>
>> A device may be discoverable only when it's first turned on but there
>> has to be a way.  My ear buds have one button each and the LEDs flash
>> differently: red and blue instead of just red.  It's easiest to start
>> with them all within reach until they're set up.  Playing sound my ear
>> buds aren't 100% reliable 20 feet away.  At one job a receptionist had
>> a BT headset, they worked within that room, not beyond.  A niece had a
>> BT headset for hands-free driving on her cell phone, mostly didn't
>> work outside her car.
>>
>> With my ear buds a long press on the one button powers them on and
>> makes them discoverable for about 1 minute.
>
> I wasn't aware there was a time limit. Anyway, the transmitter the phone
> will need to pair with is about 3 weeks away, so I'll suggest we shelve
> this until that kit arrives.
>
>> On Sat, Sep 26, 2020, 4:22 AM deloptes  wrote:
>> > Gene Heskett wrote:
>> > > Can anyone else contribute here?
>> >
>> > for the audio you may need the pulse bluetooth module package.
>> > pulseaudio-module-bluetooth
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: bt question

[Alan Corey]

Bring your devices closer together at least until you get them paired.  BT
doesn't have great range.  There are covid tracing schemes which figure if
you got within BT range you're in danger. 20 feet or so should be OK.  Also
heavy WiFi use disrupts it since they're both in the same frequency band.

A device may be discoverable only when it's first turned on but there has
to be a way.  My ear buds have one button each and the LEDs flash
differently: red and blue instead of just red.  It's easiest to start with
them all within reach until they're set up.  Playing sound my ear buds
aren't 100% reliable 20 feet away.  At one job a receptionist had a BT
headset, they worked within that room, not beyond.  A niece had a BT
headset for hands-free driving on her cell phone, mostly didn't work
outside her car.

With my ear buds a long press on the one button powers them on and makes
them discoverable for about 1 minute.

On Sat, Sep 26, 2020, 4:22 AM deloptes  wrote:

> Gene Heskett wrote:
>
> > Can anyone else contribute here?
>
> for the audio you may need the pulse bluetooth module package.
> pulseaudio-module-bluetooth
>
>
>
>

Re: bt question

[Alan Corey]

Heh-heh, I'm putting off setting up another one.  What I have
installed is just libbluetooth3, lxplug-bluetooth, pi-bluetooth.
First of all there's low power (newer) and older bluetooth, there
aren't many chances of mixing them.  If you scan from some device and
don't see everything it's probably because what you don't see is
incompatible.  Also pairing is at least mostly an exchanging of keys.
And I can pair my bt earbuds to my phone very easily: my phone sees
them, I click on them, they're paired, they've stayed paired a few
weeks now.  Can I pair them to a Pi?  Not yet.  And pairing is
sometimes exclusive, sometimes not.  I have a bt keyboard I can use
with multiple computers.  Sometimes one device will display a number
and you have to enter that in the other.

I like bluetoothctl at least partly because it's text-based.  Do agent
on because that's for connecting.  And dscoverable on.  Then if I do
"scan on" I see a list:
scan on
Discovery started
[CHG] Controller B8:27:EB:1F:69:7C Discovering: yes
[NEW] Device F3:66:48:29:CA:7D IDTW211R
[NEW] Device 74:D6:37:72:AE:37 Ruth's 3rd Fire
[CHG] Device 74:D6:37:72:AE:37 RSSI: -59
[CHG] Device 74:D6:37:72:AE:37 RSSI: -68

And there's an info command showing status:
info F3:66:48:29:CA:7D
Device F3:66:48:29:CA:7D (random)
Name: IDTW211R
Alias: IDTW211R
Paired: no
Trusted: no
Blocked: no
Connected: no
LegacyPairing: no
UUID: Vendor specific   (74e7fe00-c6a4-11e2-b7a9-0002a5d5c51b)
RSSI: -47

There are several stages to connecting and pairing.  The device has to
be not blocked, yes to trusted, paired, connected.  And you have to do
them in the correct order or they don't work, connected is last, I
don't remember the rest.  But keep doing info on the device and
setting one at a time.

bluetoothctl has a man page (tiny) and an internal help option that
lists commands (useful).  Each device has an address and an alias, you
can mostly use either.  Most devices have a discoverable mode they
need be in at least to pair, and quite often you'll need to keep
checking that and turning it back on.


On 9/25/20, Gene Heskett  wrote:
> Greetings all;
>
> I have a set of bluetooth or wired headphones.
>
> A keyboard I just bought has bluetooth but doesn't pair with the phones.
>
> Whats the chance of pairing with them to an rpi4 running buster and
> listening to the rpi's audio?
>
> Start me from square one as this will be a brand new play for me.  What
> modules do I load, and what command will I need to run to scan and ID
> whats in the rpi4's near field?
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Debian with Debian kernel on Pinebook Pro

[Alan Corey]

I think it's not officially released yet from Debian.  I have one, I just
use the stock emmc for now.  My SSD in there isn't doing anything yet
either.  But then I'm retired now, don't use a laptop that much anymore.

On Sat, Aug 29, 2020, 4:06 PM Birger Schacht  wrote:

> Hello *,
>
> I am trying to get a Debian (bullseye) installation to work on the
> Pinebook Pro with the Debian kernel package. I managed to install Debian
> back in February, but back then this was with a custom kernel with a lot
> of patches [0]. As far as I know most if not all of the relevant patches
> where merged upstream. Yet I am failing to get a working display.
>
> I am building an image for my sdcard using vmdb2 with a config [1] based
> on the excellent Raspberry Pi vmdb2 recipes. I tried with the 5.8 kernel
> from experimental.
> The image boots, but it does not show anything on the display of the
> Pinebook Pro. I have attached a serial cable and extracted a the dmesg
> output (attached). I am also able to log in on tty1 without seeing any
> output- when I type the username and hit enter I can see the user being
> logged in on tty1 when checking via the serial connection.
> I looked through the dmesg output but was not able to find what the
> missing part was. It might have to do with the error message
> 'rockchip-usb2phy [...] failed to create phy', which occurs multiple times.
>
> I thought maybe someone on debian-arm has an idea? Maybe a kernel module
> or some firmware is missing?
>
> thanks and cheers,
> Birger
>
>
> [0] https://bisco.org/notes/installing-debian-on-the-pinebook-pro/
> [1] https://paste.debian.net/1161757/
>

Re: Selecting compatible Raspberry Pi components

[Alan Corey]

I was talking about the original official 7 inch display from Raspberry Pi:
https://www.raspberrypi.org/products/raspberry-pi-touch-display/

I have one, the resolution's not wonderful (800 x 480) but it just
works.  I changed from Stretch to Buster (Raspbian) with a blank SD,
the display works without doing anything extra.  The touchscreen is a
capacitive or resistive matrix on the screen feeding an A/D converter
and it works: where you touch the screen is the same as a mouse click
there.  Not sure about HDMI ones.  This uses the DSI connector on the
board, doesn't involve the GPIO or HDMI at all.  They power it from 2
pins on the GPIO but you can change that, it just needs 5 volts.  Or
use that connection as the 5 volt input to the Pi and display both and
bypass the silly microusb.

BTW to emulate a Blackberry a Raspberry Pi ZeroW might be adequate.
It's single core so slower but much lower power.  They have been run
on a single lithium cell but they complain about low voltage I think.
https://www.raspberrypi.org/products/raspberry-pi-zero-w/  There's no
DSI connector though.

On 5/4/20, Richard Owlett  wrote:
> On 05/03/2020 02:23 PM, Jeffrey Walton wrote:
>> On Sun, May 3, 2020 at 12:59 PM Richard Owlett 
>> wrote:
>>>
>>> I've been thinking about what a handheld computer COULD be.
>>> My image is heavily influenced by my recollection of Palm Pilot.
>>>
>>> My project goals are two-fold
>>> 1. create a personal data logger reminiscent of a Palm Pilot
>>> 2. become familiar with Raspberry Pi while using Debian as the OS
>>>
>>> My needs include:
>>>>2 hours battery life
>>>4" by 7" nominal form factor
>>>touch screen input using a stylus
>>>display will be entirely character mode (40 chars/line would be OK)
>>>OS GUI not required except to say where stylus is
>>>OS shall be Debian {possibly with non-free drivers}
>>>
>>> I've not found found user friendly selection guides.
>>> A typical problem was not being able to know if a selection of
>>> components had mutually compatible I/O (electrical and physical).
>>
>> I can't speak for others, but I once I select the RPI (usually a RPI3
>> or RPI4), head over to Amazon and look for the accessories. Cases are
>> $10 to $30 USD, screens are $20 to $50 USD, etc. I've never shopped
>> for a battery so I can't really say anything about them.
>>
>> The only tricky thing I have encountered is screens. If you want to
>> keep the GPIO pins available for other work, like signals for buttons,
>> then you need SPI data connection for the LCD screen. The problem is,
>> SPI connectors are only available for 7" screens or above, which are
>> usually larger than I need.
>
> The page [1] for Adafruit's 3.5" display seems to say it can use either
> the GPIO connector or SPI. Determining which display worked with which
> Pi was a sticking point when I pursued this last year.
> [1] https://www.adafruit.com/product/2441
>>
>> You might also have some trouble with a case. Most cases have openings
>> for ports but not much more. If you are having trouble finding a case,
>> then buy one of those inexpensive 3D printers and make your own.
>>
>> Jeff
>>
>>
>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Selecting compatible Raspberry Pi components

[Alan Corey]

As a data logger you can get A/D converter boards under $10 for a Pi GPIO.
On May 3, 2020 1:23 PM, wrote:

I'd go with a Pi 3, 7 inch touchscreen, and 3 - 10 18650 lithium cells.
You can get little switch mode voltage regulators on Aliexpress or eBay for
a couple bucks.  When you're not using it as a portable you've got 4 USB
jacks, WiFi, Bluetooth, CAT5 ethernet., HDMI.  Not sure about Debian
drivers for the display, they come with Raspbian (almost the same).
On May 3, 2020 12:59 PM, "Richard Owlett"  wrote:

I've been thinking about what a handheld computer COULD be.
My image is heavily influenced by my recollection of Palm Pilot.

My project goals are two-fold
  1. create a personal data logger reminiscent of a Palm Pilot
  2. become familiar with Raspberry Pi while using Debian as the OS

My needs include:
 >2 hours battery life
 4" by 7" nominal form factor
 touch screen input using a stylus
 display will be entirely character mode (40 chars/line would be OK)
 OS GUI not required except to say where stylus is
 OS shall be Debian {possibly with non-free drivers}

I've not found found user friendly selection guides.
A typical problem was not being able to know if a selection of components
had mutually compatible I/O (electrical and physical).

Suggestions for suitable selection guides?
TIA

Re: Selecting compatible Raspberry Pi components

[Alan Corey]

I'd go with a Pi 3, 7 inch touchscreen, and 3 - 10 18650 lithium cells.
You can get little switch mode voltage regulators on Aliexpress or eBay for
a couple bucks.  When you're not using it as a portable you've got 4 USB
jacks, WiFi, Bluetooth, CAT5 ethernet., HDMI.  Not sure about Debian
drivers for the display, they come with Raspbian (almost the same).
On May 3, 2020 12:59 PM, "Richard Owlett"  wrote:

> I've been thinking about what a handheld computer COULD be.
> My image is heavily influenced by my recollection of Palm Pilot.
>
> My project goals are two-fold
>   1. create a personal data logger reminiscent of a Palm Pilot
>   2. become familiar with Raspberry Pi while using Debian as the OS
>
> My needs include:
>  >2 hours battery life
>  4" by 7" nominal form factor
>  touch screen input using a stylus
>  display will be entirely character mode (40 chars/line would be OK)
>  OS GUI not required except to say where stylus is
>  OS shall be Debian {possibly with non-free drivers}
>
> I've not found found user friendly selection guides.
> A typical problem was not being able to know if a selection of components
> had mutually compatible I/O (electrical and physical).
>
> Suggestions for suitable selection guides?
> TIA
>
>
>
>

Re: Raspberry Pi images SSH access

[Alan Corey]

Or just use su after you connect
On Apr 29, 2020 9:57 AM, "Reco"  wrote:

> Hi.
>
> On Wed, Apr 29, 2020 at 02:43:47PM +0200, fl4co wrote:
> > Since I use this Pi headless and don’t have a monitor or a USB
> > keyboard available for the first boot, I’d like to know if it’s
> > possible to enable the SSH daemon by placing a file called ssh or
> > ssh.txt on the /boot FAT32 partition of the SD card, just like in
> > Raspbian
>
> No, this file should be ignored.
> But there's no need to *enable* the sshd in Debian. It's enabled by
> default.
>
> > Or, if sshd is already enabled, does adding a password to the root
> > account in /boot/firmware/sysconf.txt, ...  enable SSH access?
>
> Not for the root user. These images have Debian default set in
> sshd_config, and for this specific case it's "PermitRootLogin
> prohibit-password".  You'll probably need to change that. Or get
> yourself USB TTL adapter and hook up to the UART.
>
> Reco
>
>

Re: The state of Arm64 on Raspberry Pi (and its Documentation

[Alan Corey]

Can't be a real program, it doesn't have a man page.  I just installed
it (on a Pi under Raspbian) because I'm looking for a way to put
Buster or Bullseye on my Pinebook Pro SSD.  Which is going to need
drivers and firmware.  The best thing I've seen is
https://github.com/daniel-thompson/pinebook-pro-debian-installer but
it uses GPT.  It's a script for running debootstrap and it gets the
drivers and firmware from somewhere.  I just need to figure out how to
not have it use GPT.

Anyway I don't see anything in this vmdb2 about drivers and firmware.
vmdb2 --help gets me:
Usage: vmdb2 [options]

Options:
  --version show program's version number and exit
  -h, --helpshow this help message and exit
  --generate-manpage=TEMPLATE
fill in manual page TEMPLATE
  --output=FILE write output to FILE, instead of standard output
  --image=FILE  create image file FILE
  -v, --verbose verbose output
  --no-verbose  opposite of --verbose
  --size=SIZE   size of output image
  --rootfs-tarball=FILE
store rootfs cache tar archives in FILE

  Configuration files and settings:
--dump-setting-names
write out all names of settings and quit
--dump-config   write out the entire current configuration
--no-default-configs
clear list of configuration files to read
--config=FILE   add FILE to config files
--list-config-files
list all possible config files
--help-all  show all options

  Logging:
--log=FILE  write log entries to FILE (default is to not write log
files at all); use "syslog" to log to system log,
"stderr" to log to the standard error output, or
"none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
critical, fatal (default: debug)
--log-max=SIZE  rotate logs larger than SIZE, zero for never (default:
0)
--log-keep=Nkeep last N logs (10)
--log-mode=MODE set permissions of new log files to MODE (octal;
default 0600)

  Peformance:
--dump-memory-profile=METHOD
make memory profiling dumps using METHOD, which is one
of: none, or simple (no meliae support
anymore)(default: simple)
--memory-dump-interval=SECONDS
make memory profiling dumps at least SECONDS apart


On 4/5/20, Florian La Roche  wrote:
> Hello deloptes,
>
>
> Am Di., 31. März 2020 um 19:37 Uhr schrieb deloptes :
>>
>> Pete Batard wrote:
>> > Also please bear in mind that the Pi Foundation adds a lot of quirks to
>> > their 32-bit kernels, some of which have yet to find their way in
>> > mainline aarch64. Raspbian is a very custom as a kernel.
>>
>> Very interesting notes. I was planning to try debian kernel or custom
>> kernel
>> build on debian. What I tried recently is do raspbian network boot
>> (diskless) and yesterday did debootstrap from within raspbian of a debian
>> buster armhf. The supplied kernel did not work (of course), so I was
>> going
>> to look into that, but I am wondering now, after reading this, if I
>> should
>> take arm64 instead of armhf.
>>
>> For now I use the raspbian kernel in debian, but as you say it is 32 and
>> I
>> am not into the details, so thank you for the hints.
>>
>> Does it mean one should prefer arm64 and take a newer 5.x kernel?
>
>
> I am using a 5.6.2 arm64 kernel without any GUI on a raspi3, works for me.
>
> You can use the current Debian kernel and add also current
> raspberry-pi-patches to
> recompile the kernel. A script doing this is available here (also
> works as native compile
> as well as a cross-compile):
> https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/kernel5.sh
>
> Compiled binary kernels (for armhf and arm64) can also be downloaded
> for kernel 5.4.20, 5.4.28, 5.5.15, 5.6.2 from:
> https://github.com/laroche/arm-devel-infrastructure/releases
> I often try to also compile newer upstream releases, even if the
> Debian kernel sources
> are not yet rebased (mostly just disabling patches completely if I
> don't need them).
>
> Instead of using the Debian installer, I can also recommend to use
> "vmdb2"  to create a
> ready-to-use image. That can also be generated on any normal
> amd64/x86_64-PC and does
> not require a running arm64/armhf setup:
> https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/debian-rpi3-arm64.yaml
>
> best regards,
>
> Florian La Roche
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  

Re: Resize a disk image from 32G to 4G or copy u-boot?

[Alan Corey]

If you say so, it wasn't aparent that was what the problem was.  Lots
of things can manipulate UUIDs.  apropos uuid on this Pi says:

dbus-uuidgen (1) - Utility to generate UUIDs
FcDirCacheCreateUUID (3) - Create .uuid file at a directory
FcDirCacheDeleteUUID (3) - Delete .uuid file
findfs (8)   - find a filesystem by label or UUID
swaplabel (8)- print or change the label or UUID of a swap area
uuid (1) - Universally Unique Identifier Command-Line Tool
uuid (3) - DCE compatible Universally Unique Identifier library
uuid_clear (3)   - reset value of UUID variable to the NULL value
uuid_compare (3) - compare whether two UUIDs are the same
uuid_copy (3)- copy a UUID value
uuid_generate (3)- create a new unique UUID value
uuid_generate_random (3) - create a new unique UUID value
uuid_generate_time (3) - create a new unique UUID value
uuid_generate_time_safe (3) - create a new unique UUID value
uuid_is_null (3) - compare the value of the UUID to the NULL value
uuid_parse (3)   - convert an input UUID string into binary representation
uuid_time (3)- extract the time at which the UUID was created
uuid_unparse (3) - convert a UUID from binary representation to a string

I've got at least half a dozen 128 GB sds:
https://www.bhphotovideo.com/c/product/1466563-REG/sandisk_sdsqqnr_128g_an6ia_high_endurance_microsd_128gb.html

Haven't bought any bigger ones but you can get them up to 1 TB.


On 3/26/20, Nate Bargmann  wrote:
> This is now resolved thanks to the help of user Klaus on the Olimex
> forum.  The trick was to use dtrfstune to change the p2 UUID of the
> 4G micro-SD to match that of the p@ UUID of the 32 GB card.
>
> All is working well now.  I now have the 32 GB card available to work
> with the Raspberry Pi 4B that arrived today.  :-)
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Resize a disk image from 32G to 4G or copy u-boot?

[Alan Corey]

Try your kernel config string.  On this Pi /boot/cmdline.txt has
root=PARTUUID=d9b3f436-02

I copied an sd to a hard drive once and it wouldn't boot until I put
the partuuid from the hard drive in there.  That and the fstab were
the only changes I had to make.  Should have put rootwait in there too
because it would crash waiting fo the hard drive to spin up.

On 3/24/20, Nate Bargmann  wrote:
> Grep on the 32 GB card for the root UUID only turns up the value in
> p2/etc/fstab.  Nothing turned up in p1 though I can manually look into
> either of the initrd images with Midnight Commander and find it in the
> aforementioned dafault_root file.
>
> I did see where the 32 GB card has p2 labeled as "root" so I set the
> label on th 4 GB's p2 to "root" as well, but the kernel still panics.
>
> Oh well, I'll sleep on it.
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Resize a disk image from 32G to 4G or copy u-boot?

[Alan Corey]

Grep for the UUID?  Including grep -r to recurse directories.  You'll
probably need to do it once per partition.  gpartid has some serous
bugs when it comes to resizing I think.  If you're really careful with
your math you can control fdisk at a sector level. Actually I've done
it in OpenBSD, not Linux.  apcalc will handle the big numbers.  You
can copy and paste the inputs and outputs, it's just text.  And keep
files of notes.  I've never used truncate.

On 3/24/20, Nate Bargmann  wrote:
> * On 2020 24 Mar 15:46 -0500, Alan Corey wrote:
>> Downsizing requires that no files are in the part you trim off.
>
> Ahhh.  Makes sense.
>
> The mmc has two partitions, p1 an ext2 of 128 MB and p2 a btrfs with the
> rest of the space.
>
> Since I had the files of p2 on the 4 GB card, I went ahead and deleted
> the p2 partition in the image file and then created a 3 GB btrfs
> partition and then I could use the truncate command to resize the file,
> Then I rsync'd the files from the card to the file and dd'd that to the
> card.  Afterward Gparted would not upsize the btrfs partition, so I
> deleted it and created it anew and then rsync's the files from the file
> to the card!
>
> Having gone through this, I think it would have worked as well to make a
> copy of the original image file and truncate that to just after the end
> of the p1 partition, dd'd that to the card, use Gparted (or parted) to
> create the btrfs partition on the card, then rsync's things over from
> image file 1.
>
> Now the problem is that I get a kernel panic that the rootfs isn't
> found.  On the 4 GB card I edited /etc/fstab with the new P2 UUID and
> decompressed the initrd images and edited /conf/conf.d/default_root with
> the new UUID and compressed them and copied them back to p1.  Of course
> everything works with the 32 GB card.
>
> At this point I am still puzzled where else the rootfs UUID is saved.
> I've looked through the uboot environment and see nothing obvious there.
> I do have a serial cable connected to the UART pins on the LIME2.
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Resize a disk image from 32G to 4G or copy u-boot?

[Alan Corey]

Have you tried partimage?  Maybe it only does one partition, I was
looking for something that can make images like the ones you download
when youj insttall.  Just saw this today, haven't tried it yet.

Partition Image is a partition imaging utility. It has support for the
following file systems:
 * Ext2/3, the Linux standard
 * ReiserFS, a journalised and powerful file system
 * FAT16/32, DOS and Windows file systems
 * HPFS, IBM OS/2 file system
 * JFS, journalised file system, from IBM, used on AIX
 * XFS, another journalised and efficient file system, from SGI, used on Irix
 * UFS (beta), Unix file system
 * HFS (beta), MacOS File system
 * NTFS (experimental), Windows NT, 2000 and XP
Only used blocks are copied and stored into an image file.
The image file can be compressed in the GZIP/BZIP2 formats to save disk space,
and split into multiple files to be copied onto removable media (ZIP for
example), burned on a CD-R, etc.

This makes it possible to save a full Linux/Windows system with a single
operation. In case of a problem (virus, crash, error, etc.), you just have
to restore, and after several minutes, your entire system is restored
(boot, files, etc.), and fully working.

This is very useful when installing the same software on many machines: just
install one of them, create an image, and restore the image on all other
machines.

On 3/24/20, Gene Heskett  wrote:
> On Tuesday 24 March 2020 16:44:42 Alan Corey wrote:
>
>> Downsizing requires that no files are in the part you trim off.
>> Upsizing can sometimes be done by deleting the partition and
>> recreating letting fdisk use the maximum size.  Don't format between
>> or anything and in case you have to type the numbers in you should
>> have a copy of them handy like
>> Device Boot StartEndSectors  Size Id Type
>> /dev/sda1  6320563192056257 1004M  6 FAT16
>> /dev/sda2 2056320   43022069   40965750 19.5G 83 Linux
>> /dev/sda343022070  657427994  614405925  293G 83 Linux
>> /dev/sda4   657427995 1953520064 1296092070  618G  5 Extended
>> /dev/sda5   657428058 1953520064 1296092007  618G 83 Linux
>> I used to hide a partition on a Windows machine by deleting it then
>> recreating it when I wanted it, the data in it was fine.  This scheme
>> may not work on GPT especially because it puts the partition table at
>> the end of the disk.
>>
>> I would try using dd to copy the whole device like /dev/sda instead of
>> /dev/sda1 which should get the uboot.,  Then you just need to upsize
>> the second partition.  Or use dd to copy the uboot partition then
>> create and format the 2nd one manually and copy the files over with
>> cp.  Unless uboot needs to know the offset of something in the 2nd
>> partition.
>>
>> Such tiny SD cards...
>
> And nothing so far, and I have been watching, in the way of reducing a
> filesystem to only the actual size occupied. Then it can be backed up
> with dd and recovered, rewritten by dd, at a reasonable size for
> storage.  And re-expanded to fit the media it finds. All of my attempts
> to do that with dd alone have been thwarted by the fact that I have yet
> to find two u-sd's marked as such and such a capacity, that actually
> were the same size.
>
> Our tools simply have not kept up with the technology. So I wind up doing
> my backups with amanda and that hasn't kicked my applecart and spilled
> it yet. But amanda works a bit different and most read the docs and run
> screaming to the hills because theres no easy way to make a full backup
> on Friday nights. Amanda doesn't need to, its got your data covered
> anyway.
>
>> On 3/24/20, Nate Bargmann  wrote:
>> > Hi All.
>> >
>> > I have an Olimex LIME2 based Freedombox (Debian Buster) and as I am
>> > using an external hard drive with it, less than 2 GB of the 32 GB
>> > micro-SD card capacity is being used.  I have a spare 4 GB card that
>> > I would like to use instead, but haven't figured out how to downsize
>> > the root partition in the disk image file after using dd to make an
>> > image from the 32 GB card.
>> >
>> > I tried the steps at:
>> >
>> > https://softwarebakery.com/shrinking-images-on-linux
>> >
>> > and gparted fails at the resize step with an error of:
>> >
>> >btrfs filesystem resize 1:2234368K ʼ/tmp/gparted-3ExAC9ʼ
>> > 00:00:05( ERROR )
>> >
>> >Resize ʼ/tmp/gparted-3ExAC9ʼ of ʼ1:2234368Kʼ
>> >ERROR: unable to resize ʼ/tmp/gparted-3ExAC9ʼ: No space left on
>> > device
>> >
>> > Even if I manually try to use the btrfs command to attempt the

Re: Resize a disk image from 32G to 4G or copy u-boot?

[Alan Corey]

Downsizing requires that no files are in the part you trim off.
Upsizing can sometimes be done by deleting the partition and
recreating letting fdisk use the maximum size.  Don't format between
or anything and in case you have to type the numbers in you should
have a copy of them handy like
Device Boot StartEndSectors  Size Id Type
/dev/sda1  6320563192056257 1004M  6 FAT16
/dev/sda2 2056320   43022069   40965750 19.5G 83 Linux
/dev/sda343022070  657427994  614405925  293G 83 Linux
/dev/sda4   657427995 1953520064 1296092070  618G  5 Extended
/dev/sda5   657428058 1953520064 1296092007  618G 83 Linux
I used to hide a partition on a Windows machine by deleting it then
recreating it when I wanted it, the data in it was fine.  This scheme
may not work on GPT especially because it puts the partition table at
the end of the disk.

I would try using dd to copy the whole device like /dev/sda instead of
/dev/sda1 which should get the uboot.,  Then you just need to upsize
the second partition.  Or use dd to copy the uboot partition then
create and format the 2nd one manually and copy the files over with
cp.  Unless uboot needs to know the offset of something in the 2nd
partition.

Such tiny SD cards...


On 3/24/20, Nate Bargmann  wrote:
> Hi All.
>
> I have an Olimex LIME2 based Freedombox (Debian Buster) and as I am
> using an external hard drive with it, less than 2 GB of the 32 GB
> micro-SD card capacity is being used.  I have a spare 4 GB card that I
> would like to use instead, but haven't figured out how to downsize the
> root partition in the disk image file after using dd to make an image
> from the 32 GB card.
>
> I tried the steps at:
>
> https://softwarebakery.com/shrinking-images-on-linux
>
> and gparted fails at the resize step with an error of:
>
>btrfs filesystem resize 1:2234368K ʼ/tmp/gparted-3ExAC9ʼ  00:00:05(
>ERROR )
>
>Resize ʼ/tmp/gparted-3ExAC9ʼ of ʼ1:2234368Kʼ
>ERROR: unable to resize ʼ/tmp/gparted-3ExAC9ʼ: No space left on device
>
> Even if I manually try to use the btrfs command to attempt the resize I
> get the same error which seems weird as I am *shrinking* the file
> system..
>
> As an alternative, I created the proper partitions on the 4 GB card and
> used rsync to copy the relevant data over.  That is all well and good
> except that now I don't have u-boot in the first 1 MB of the 4 GB card
> (the boot partition starts at sector 2048 in both the disk image and the
> 4 GB card).  I'm unsure of the exact offsets or I would simply use dd to
> copy that data from the 32 GB image to the 4 GB card and be on my way.
>
> Ideas?
>
> TIA
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: RockPro64 - Boot fails if fstab has volumes on PCIe SSD

[Alan Corey]

Yes, staring at a blank screen while important stuff is happening
sucks.  A serial console might show more, I haven't tried it.  OK, you
did.  If there's a quiet in your kernel command line options get rid
of it, also splash.  The list keeps changing and moving but see
https://www.kernel.org/doc/html/v4.10/admin-guide/kernel-parameters.html
 earlyprintk sounds worth trying in there.  Printk is messages from
the kernel.

I don't have an answer but my guess is it's a matter of timing, you're
trying to access something before it's ready because something is
quicker than something else.  In the old days they used to do stuff
like hold the reset line active for N seconds to give everything
chance to boot then release reset.  This isn't so different from
waiting for a hard drive to spin up.  Or drives, worse yet, thinking
of those big cases with 4 5-1/4 SCSI drives in a RAID.  They drew so
much power the controller was programmed to not start them all at
once, so you'd hear drives spinning up for 20-30 seconds.  Without
holding down reset the sequence has to be right.

My SSD sits here in a box while I research things like how to put
multiple OSes on it, it's going into a Pinebook Pro.

On 3/21/20, David Pottage  wrote:
> Hello,
>
> I have a RockPro64 running Armbian buster version 20.02.1 (Linux kernel
> 5.4.20-rockchip64)
>
> I have connected an M.2 SSD via an adapter in the PCIe slot, and have
> setup an LVM PV on it, with a number logical ext4 and btrfs volumes on it.
>
> All this worked fine when I set it up, but when I went to reboot the
> system, it never came back. On the serial console, I got a series of
> message from the firmware and U-Boot, then "Starting kernel ..." and
> nothing. (I waited about half an hour)
>
> Suspecting the SSD, I powered off, disconnected it, and rebooted. After
> a delay of about 2 minutes I got "Give root password, or Ctrl-D to
> continue" (Not sure of the exact wording), so Iogged in, and edited
> /etc/fstab to comment out or add "noauto" to the lines for all file
> systems on the SSD. I was then able to reboot successfully.
>
> Those volumes on the SSD will mount fine from the command line after
> boot, but it looks like they don't mount successfully during boot, and
> are preventing boot.
>
> I suspect that there is some sort of issue with dependencies in systemd.
> Perhaps the PCI bus or the LVM2 mapper is not ready when the kernel
> attempts to mount the filesystems, but why would that block the boot,
> rather than just adding a delay?
>
> On one occasion, I attempted to boot with just a swap volume on the SSD
> name in /etc/fstab, and I saw this in syslog:
>
> Mar 21 19:52:57 jupiter systemd[1]: dev-jupiter\x2dvg1-swap.device: Job
> dev-jupiter\x2dvg1-swap.device/start timed out.
> Mar 21 19:52:57 jupiter systemd[1]: Timed out waiting for device
> /dev/jupiter-vg1/swap.
> Mar 21 19:52:57 jupiter systemd[1]: Dependency failed for
> /dev/jupiter-vg1/swap.
> Mar 21 19:52:57 jupiter systemd[1]: dev-jupiter\x2dvg1-swap.swap: Job
> dev-jupiter\x2dvg1-swap.swap/start failed with result 'dependency'.
> Mar 21 19:52:57 jupiter systemd[1]: dev-jupiter\x2dvg1-swap.device: Job
> dev-jupiter\x2dvg1-swap.device/start failed with result 'timeout'.
>
> Does anyone have an idea how I can fix this, or how to investigate
> further, given that I don't see any output on the serial console or the
> HDMI monitor when the boot fails?
>
> Thanks,
>
> --
>
> David Pottage
>
>
>
>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi

[Alan Corey]

Interesting, there are probably counts of the sales of the models
somewhere.   My suspicion is that the popularity increased over time
so that there were probably more 3Bs than anything else.  I have 3 3Bs
and 4 Zeros.  I had a model B and a Zero die.  I guess I've just
gotten used to it but these 3Bs seem about as fast what I would have
considered a "standard" Dell Intel workstation 10 years ago, but that
was Windows too.  At about 1/10 of the price with much less energy.
Any program that's too slow I consider bloatware and get rid of it.
My phones are armv7 too.

On 3/2/20, Vagrant Cascadian  wrote:
> On 2020-03-02, Alan Corey wrote:
>> That poses an interesting question: can you install Debian debs on a
>> Raspbian system and vice versa?  Never thought about it.  I've maybe
>> used Ubuntu ones a couple times.  I suppose each case is unique and
>> the worst casualty would be to the apt system and it's record-keeping.
>> You don't want foreign repos in your sources.list but just snagging a
>> deb from somewhere wouldn't be bad I think as long as the dependencies
>> worked out.  But what about the install paths for files, the dirs
>> might not exist?
>
> Raspbian armhf is built for armv6, and Debian armhf is built for armv7,
> so they're not strictly compatible. You might get away with it on rpi2,
> rpi3 or rpi4, since they support armv7. But rpi1 and rpi0 only support
> armv6. Mixing and matching incompatible ABIs could cause all sorts of
> issues...
>
> *If* the rpi1 had supported armv7, raspbian probably would have never
> existed, or just be a small number of tweaked packages on an otherwise
> plain debian armhf system.
>
>
> live well,
>   vagrant
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi

[Alan Corey]

That poses an interesting question: can you install Debian debs on a
Raspbian system and vice versa?  Never thought about it.  I've maybe
used Ubuntu ones a couple times.  I suppose each case is unique and
the worst casualty would be to the apt system and it's record-keeping.
You don't want foreign repos in your sources.list but just snagging a
deb from somewhere wouldn't be bad I think as long as the dependencies
worked out.  But what about the install paths for files, the dirs
might not exist?

I do stuff from outside the debs system all the time, seems safer somehow.

On 3/2/20, Reco  wrote:
> On Mon, Mar 02, 2020 at 01:17:25PM -0500, Gene Heskett wrote:
>
>> Unforch here, glmark can't be found by apt on a raspi buster 10.3 on an
>> rpi4b.
>
> So? If *Debian* main archive does not have it - that's trouble.
> If some Debian derivative chooses to exclude some packages - that's to
> be expected.
>
> Reco
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi

[Alan Corey]

Gene was complaining about speed and at times video has been part of
the problem.  Yes, the Pinebook Pro has a T860 Mali which supposedly
is compatible with Vulkan. https://www.pine64.org/pinebook-pro/   I've
been trying to find something to learn Vulkan on, I can't quite do it
on an RPI 3B, Rock64, or Odroid N2 which I have.  I would consider a
limit a defect if there's no way to disable it for benchmarking
purposes,  I thought I was seeing around 300 FPS a couple years ago on
my Rock64 from Glxgears but I can't duplicate it now.  I'm considering
it a measure of efficiency and lack of software emulation.

There's no Mali driver for an RPI of course but some of the demos that
come in /opt/vc/src are impressive.  Unfortunately they all seem to
use Dispmanx, might be adaptable to GLFW.  But I don't know OpenGL,
Vulkan seems  more interesting.  I want to write shaders or the
equivalent and get those little processors in the GPU doing useful
stuff.  Not with making pretty pictures in mind.  Low level stuff but
not as low as qasm because that's not portable.

On 3/1/20, Stefan Monnier  wrote:
>> In Raspbian Buster on my Pi 3B
>> es2gears
> [...]
>> 718 frames in 5.0 seconds = 143.600 FPS
>> root@upstairs:/usr# glxgears
> [...]
>> 838 frames in 5.0 seconds = 167.566 FPS
> [...]
>> Debian Stretch on my Pinebook Pro has the 60 hz limit in effect.
>
> Not sure in which way these data points are relevant.  A "60hz limit" is
> not a defect, AFAIK, and you're comparing Debian on a Pinebook to
> Raspbian on a rpi3, whereas AFAIK the message to which I was responding
> was arguing (IIUC) that Debian-on-rpi3 has a problem with the GPU
> because it doesn't include the mali driver.
>
> If you hit a 60hz limit on the Pinebook it shows that there *is* a driver
> for its GPU.
>
>
> Stefan
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi

[Alan Corey]

Check that your file manager isn't set to automount, Ir's very annoying.
It's in preferences there.
On Mar 2, 2020 1:00 AM, "Keith Bainbridge"  wrote:

> On 1/3/20 3:31 pm, Keith Bainbridge wrote:
>
>> Good afternoon
>>
>> I have tried a couple of times to run my Pi on debian, using
>> debian-10.3.0-arm64-xfce-CD-1.iso   at 630M
>>
>> But I have never got to XFCE log-in
>>
>>
>> Is there a preferred debian arm that people here use basically trouble
>> free?
>>
>> This is for Pi3B
>>
>>
>>
>> I am get a Pi4 shortly. The last I have seen is that debian hasn't been
>> given drivers for the Pi4. Any info on when that will change? please
>>
>> Thanks
>>
>>
>
> Thankyou all. I didn't have time this morning to look through what people
> had said.
>
>
> All very interesting.
>
>
> I wanted to switch because I had had a couple of niggles that I hadn't see
> in my debian system.  The most annoying is that the Pi doesn't always keep
> ssh log in id
>
> Now, I have moved ~500G of data from one drive /mnt/k3t to another
> /mnt/g750  but a df shows the source drive space used and space free are
> still the same as before the transfer.
>
> This afternoon when searching for the moved files, I see lots of file
> paths starting /mnt/k3t/mnt/k2t/mnt/k3t   and often more repeats. And no, I
> didn't think to keep a copy of the output.
>
> /mnt/k3t is a different drive from /mnt/k2t  Both are connected to the Pi
> via USB
>
> I was hoping that using pure debian would correct at least the ssh issue.
>
> --
> Keith Bainbridge
>
> ke1th3...@zoho.com
> +61 (0)447 667 468
>
>

Re: Raspberry Pi

[Alan Corey]

In Raspbian Buster on my Pi 3B

es2gears
libEGL warning: DRI2: failed to authenticate
EGL_VERSION = 1.4
vertex shader info:
fragment shader info:
info:
743 frames in 5.0 seconds = 148.541 FPS
751 frames in 5.0 seconds = 150.110 FPS
765 frames in 5.0 seconds = 152.908 FPS
743 frames in 5.0 seconds = 148.600 FPS
718 frames in 5.0 seconds = 143.600 FPS
^C
root@upstairs:/usr# glxgears
757 frames in 5.0 seconds = 151.227 FPS
872 frames in 5.0 seconds = 174.272 FPS
838 frames in 5.0 seconds = 167.566 FPS
^C
root@upstairs:/usr# uname -a
Linux upstairs 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020
armv7l GNU/Linux

Debian Stretch on my Pinebook Pro has the 60 hz limit in effect.
That's a Mali.  Probably works fine under Android which is their bread
and butter.  Actually I could try that, the PBP has an Android image
available, it just doesn't sound very interesting so I didn't bother.


On 3/1/20, Stefan Monnier  wrote:
>> The whole point of my rant is that the instant folks find out that 64 bit
>>
>> will run on whatever platform we are discusing, and armhf needs more
>> attention paid to details like addressing beyond 3 gigs, PAE IOW, 6
>> months later there are no armhf distros left.
>
> FWIW, I'm finding hard to believe that the AArch64 architecture
> necessarily suffers from 10 times higher latency than the AArch32.
>
> I suspect that your problems with the Aarch64 architecture are due to
> the fact that there have been less efforts at keeping the latency of
> Linux-on-AArch64 under control, and that should improve over time.
>
> It's possible that the best latency will still be worse than what you
> can get with AArch32, but not as bad as 10 times as bad.
>
>> That, and only the raspi supplied srcs know about the mali video,
>> giving us full screen glxgears at 60 fps since buster 10.2.
>
> Really?  I can't see any trace of Mali hardware in the Raspberry Pi
> specification.  AFAICT the rpi3 comes with a Videocore IV while the rpi4
> comes with a Videocore VI.
> So I'm not sure what good software support for mali would do.
>
>> That  mali video is not now nor from statements made by debian folks,
>> will
>> never be available from debian so debian is doomed to 3 fps framebuffer
>> displays.
>
> The official Mali driver from ARM is proprietary and there are no signs
> of ARM getting their head out of the asses in this regard, so indeed in
> the foreseeable future there's no plan to incorporate the Mali driver
> into Debian.  This said, there's a Free Software driver and it's
> definitely included in Debian (the kernel part included since Linux-5.2
> and the userland part since Mesa-19.1)
>
>
> Stefan
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi

[Alan Corey]

Geez, I remember 8-bit CPUs, and computers with vacuum tubes.  But
every time the word size doubles there's a transition period then it
becomes the norm.  Maybe the hardware design is capable but not
optimized for the difference at first.  Maybe the fact that a Pi 3B
can run either as 32 or 64 bit means it's slower at 64 than something
that's 64 only.  There were weird CPUs like the 8088 and 8086 where
(if I remember this right) the 8086 was wide enough but the 8088 had
to do an extra cycle or two. And 640k max memory, don't want to go
back to that.  Or 64k.

On 3/1/20, Pete Batard  wrote:
> On 2020.03.01 16:30, Gene Heskett wrote:
>>> Debian 10.3 ARM64 should install and work just fine on the Pi 3,
>>> including full graphical mode. No need for 32-bit.
>>
>> Yes, I've done it, works fine, with one glaring exception all the 64 bit
>> fans refuse to recognize.
>
> I think you're assuming a bit too much with that statement with the idea
> that the world is populated by close-minded 64-bit ARM "fans".
>
> I don't have a particular bone with either. OP mentioned that they had
> been trying to install "debian-10.3.0-arm64-xfce-CD-1.iso", then someone
> replied that they should got with ARM 32 and raspbian instead, and all I
> said is that it wasn't necessary when you can get
> debian-10.3.0-arm64-xfce-CD-1.iso installed on a Pi 3 without too much
> trouble.
>
> So this is not exactly a "You *should* use 64-bit" matter. I just stated
> that OP could install the distro they were originally planning to
> install, and pointed to guides that explain how they should proceed to
> do so.
>
>> When called upon to run machinery that demands microsecond responses in
>> order to run that machinery smoothly AND accurately, the increased
>> latency caused by the 64 bits much larger stack frame to be stored, and
>> pulled back into active service when an interrupt from the machine is
>> received, slowing the response to the interrupt from 5 microseconds to
>> 50 or more is not tolleratable.  armhf is much faster, and  when doing
>> software stepping, which when the step timing has jitter in its timed
>> pulses, very rapidly kills motor torque with increases in the timeing
>> jitter, with a 50 microsecond jitter killing over 75% of a motors usable
>> power.
>
> Yes. All archs and software implementations on top of specific archs
> have advantages and drawbacks. But it seems to me like you are trying to
> imply that 64-bit should be avoided altogether on account of the one
> scenario you exposed above, whereas, just like there exists scenarios
> where 32-bit has the edge over 64-bit, there also exist scenario where
> 32 vs 64-bit won't make much of a significant difference, which, in lack
> of further indication, we can probably assume is OP's planned use.
>
> OP expressed their interest to use 64-bit Debian and said nothing about
> running machinery with it, so I hope you can appreciate that an answer
> that aims at helping OP go with the original arch they said they wanted
> to install, but seemed to have trouble installing, is not exactly
> invalidated by the point you raise.
>
> In other words, the point you make is very valid and something 64-bit
> users might indeed want to be made aware of. But it would have been made
> better without preceding it with what seems to me a rather reductive
> opinion of folks who do think that, just like 32-bit, 64-bit has its place.
>
> Regards,
>
> /Pete
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi

[Alan Corey]

Tell us more technical details.  That's like saying there was a problem but
not saying what it was. Seems odd you'd be trying a CD Iso file and not
some IMG file but it might work.  Write it to an SD card in block mode.
Yes, I had mine running Debian a couple years ago.  Raspbian from
raspberrypi.org is probably easier since it's made for that.
On Feb 29, 2020 11:47 PM, "Keith Bainbridge"  wrote:

> Good afternoon
>
> I have tried a couple of times to run my Pi on debian, using
> debian-10.3.0-arm64-xfce-CD-1.iso   at 630M
>
> But I have never got to XFCE log-in
>
>
> Is there a preferred debian arm that people here use basically trouble
> free?
>
> This is for Pi3B
>
>
>
> I am get a Pi4 shortly. The last I have seen is that debian hasn't been
> given drivers for the Pi4. Any info on when that will change? please
>
> Thanks
>
> --
> Keith Bainbridge
>
> ke1th3...@zoho.com
> +61 (0)447 667 468
>
>

Re: Raspberry Pi

[Alan Corey]

I was running a 64 bit Buster in 2018 from somebody's debootstrap
script.  Fairly stable for a year or so until I got rid of it.  It was
what I'd call "smooth", but 64 bit isn't faster than 32 for the most
part.  Everything's twice as big and a Pi 3B can only have 1 GB of RAM
by the design of the SOC so you go into swap more easily, which
crawls.  There's some current version that (I read somewhere) has the
OS at 64 bits but the userland is 32 bit.  They did it I think because
a couple of programs (You Tube is one) they only had a 32-bit blob for
so all the userland stuff is 32 bit.

I finally switched back to Raspbian because I missed the Pi-specific
stuff like vc4 and camera support, still using it.  So I have 3
superior machines but I spend  most of my time on a Pi 3B, just
upgraded to Buster a couple months ago.

I set them to boot to a command line on purpose, then I type startx.
You can set that easily with raspi-config.  Once in a while I play
with Wayland instead of x.

On 3/1/20, Pete Batard  wrote:
> On 2020.03.01 08:23, Keith Bainbridge wrote:
>> On 1/3/20 6:22 pm, deloptes wrote:
>>> Keith Bainbridge wrote:
>>>
 Is there a preferred debian arm that people here use basically trouble
 free?

 This is for Pi3B
>>>
>>> many suggest 32bit for the Pi3 incl. raspbian.
>
> Debian 10.3 ARM64 should install and work just fine on the Pi 3,
> including full graphical mode. No need for 32-bit.
>
> Please see either:
> https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html
> or
> https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=249449&sid=84febcd504e6159355215ff8b8fa6d67
>
> Regards,
>
> /Pete
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Y2038 - best way forward in Debian?

[Alan Corey]

What if we define an epoch to be 50 years and the epoch number becomes
part of how the computer keeps track of the date.  Something similar
is done in astronomy I think, star charts always have an epoch.  So
epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050.   Then we can keep
a time_t at 32 bits.  Things like strptime() and strftime() and
ctime() would need changing but since they were valid in epoch 0
they'd only need to change for epoch 1 and later.  A day will continue
to be 86400 seconds of a 32-bit number but every 50 years the epoch
would change.  Dates can overlap epochs so 2020 could be part of epoch
0 and epoch 1.  The year part of a time_t and struct tm ceases to be
absolute like an hour isn't absolute on a 12-hour clock.  It's
probably been thought of.

On 2/14/20, John Goerzen  wrote:
> On Tue, Feb 04 2020, Steve McIntyre wrote:
>
>> Arnd scanned the library packages in the Debian archive and identified
>> that about one third of our library packages would need rebuilding
>> (and tracking) to make a (recursive) transition. We can see two
>> different possible routes to follow:
>>
>>  A Follow a similar path to last time (rename library packages). This
>>will allow us to do partial upgrades, but the cost is that a vast
>>number of packages will need work to make this happen,
>>*potentially* building library packages twice to allow us to
>>continue both 32-bit and 64-bit time_t support forwards for a
>>while. This effort will be *needed* only for the sake of our 32-bit
>>ports, but would affect *everybody*.
>
> The thing that we have to remember is that an operating system is a
> platform for running software.  This problem is rather thorny, because:
>
> 1) Some software is provided in only binary form and cannot be
> recompiled
>
> 2) Some software can be recompiled but makes assumptions about the size
> of variables, may use int instead of time_t, and other assorted
> messiness
>
> 3) Some software is going to break now, due to forward-looking time
> calculations, and for others, it may be fine (or nearly so) even past
> 2038 due to timekeeping being only ancillary to its purpose.  For
> instance, I have some old games that are binary-only and really don't
> care what time it is.
>
> This option #1 sounds like a significant effort (because not only would
> we need two versions of libraries, but also of include files).  But it
> certainly passes the "correctness" test better than your option #2.
>
> John
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Armbian

[Alan Corey]

Arnbian is too much of what I don't like about Debian, full of little
specialized scripts for this and that with new ones coming out
practically weekly.  If you're used to living without them and they
break something because they're suddenly required it isn't
appreciated.  I don't re-read documentation to see if somebody changed
something.

The best thing about Armbian is that it's a good way to test a board
that may not be working.  I used it on my Rock64 that I thought might
be dead, it wasn't, then I went on to an Ayufan image.  They're
working hard at making these little things into appliances that
anybody can run and having them mostly all work the same.  Not for
everybody.

On 2/2/20, Reco  wrote:
>   Hi.
>
> On Sun, Feb 02, 2020 at 05:33:43PM +, Phil Endecott wrote:
>> What do you know about Armbian?  What do you think?
>
> Own kernel, mostly Debian userland.
> An interesting set of patches on top of vanilla kernel, definitely
> controversial approach to DFSG.
> Also, Armbian uses cross-compilation to build their packages, and it's a
> good question if someone there had a single thought about building
> packages in a reproducible way.
>
>
>> I recently bought an ODROID-HC1 to use as a basic NAS.
>
> ORDOID HC2 works perfectly with the stock Debian packages only from the
> main archive (as of buster), and a couple of blobs. Judging from [1] -
> same goes for HC1, save for the bootloader and blobs.
>
>
>> It's an interesting board with an Exynos Coretex-A15 SoC and Ethernet
>> and SATA connectors,
>
> USB-based Ethernet and a single SATA connector, to be specific.
> That severely limits overall usefulness of the board for NAS purpose.
> Of course, if 300Mbps over unencrypted NFSv4 and a lack of disk
> redundancy is something you're content with - my congratulations with
> the purchase.
> I use HC2 as a backup host only.
>
>
>> and a nice mechanical design for a single-disk NAS.
>
> Passive cooling is not enough for HC2.
> I had to resort to putting two HC2s to USB-powered laptop cooling pad,
> else prolonged use of HDD heated the boards to 70C and more.
> YMMV if your plan to use SSD.
>
>
>> Typically for ODROID it has manufacturer support only Ubuntu and
>> Android,
>
> ... and said support is not that great in my experience.
> Also, if ODROID says "Ubuntu", they really mean "Ubuntu with our 4.9
> Android kernel and a ungodly pile of blobs just for the fun of it".
>
>
>> so I looked for good ways to install Debian.  There is a DebianOn wiki
>> page but it's very convoluted.
>
> [1] basically tells you that some assembly is required, and tells about
> the process. Not that hard, if you ask me.
> Of course, it would be better if the page told about running d-i on a
> board (perfectly possible BTW save the u-boot part) - but apparently
> page's author is a big fan of debootstrap.
> There are harder ARM boards in that regard (Raspberry Pi 4 or ODROID N2
> to name a few).
>
>
>> Very briefly, Armbian's main strength seems to be that they
>> have configurations and/or patches for U-Boot, the kernel, and
>> related stuff for a good selection of ARM boards which are
>> kept up to date and seem to work pretty reliably.
>
> I've yet to see an announcement from Armbian at oss-security maillist.
> E-mails from Debian Developers land at oss-security within a day of
> publishing DSA.
>
> Reco
>
> [1] https://wiki.debian.org/InstallingDebianOn/OdroidHC1
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Support for accelerated graphics and video decoding on PINE A64+ in bullseye

[Alan Corey]

The issue probably centers around the Mali GPU if it has one.   ARM stopped
providing x11 drivers, expect everyone to jump to Wayland.  Hope they get
sued.  I've spent most of a week trying to get Vulkan or OpenGL ES running
on an Odroid N2 and a Rock64.  Gross misrepresentation in my opinion.
On Dec 6, 2019 8:19 AM, "Andrei POPESCU"  wrote:

> Hello,
>
> I'm trying to get accelerated video and/or decoding working on a PINE
> A64+ (2 GiB RAM) on bullseye.
>
>
> With xserver-xorg-video-fbdev I get about 180 frames in glxgears with
> 1.4 load (openbox at 1920 x 1080).
>
> This is usable only for basic tasks, e.g. Kodi starts, but the interface
> has significant lag.
>
> Should xserver-xorg-video-fbturbo (ITP #760025) help? I tried installing
> the package from Debian Multimedia, but I only get a blank screen.
>
> The upstream project[1] seems unmaintained (latest commit Oct.2015).
>
> What (else) is still missing for accelerated video?
>
>
> Playing 1080p videos (VLC or Kodi) works, but is way to slow (software
> decoding only).
>
> According to [2] Cedrus support was merged in Linux 5.0, but there is no
> CONFIG_VIDEO_SUNXI_CEDRUS as mentioned on [3].
>
> Additionally, as far as I understand, for accelerated video decoding the
> VAAPI backend libva-v4l2-request is also needed, but it's not packaged
> for Debian (yet?).
>
> Should I file an RFP for it?
>
>
> [1] https://gihub.com/ssvb/xf86-video-fbturbo
> [2] https://linux-sunxi.org/Linux_mainlining_effort
> [3] https://linux-sunxi.org/Sunxi-cedrus
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

Re: Lowest power Debian SBC

[Alan Corey]

A PocketBeagle might be close, seems slower than a Zero.  Mine's
gathering dust somewhere.  http://beagleboard.org/pocket or
https://www.mouser.com/new/beagleboardorg/pocketbeagle/  Lots of I/O
options but I don't think it has real ethernet.

On 11/25/19, john cooper  wrote:
> On 11/24/2019 06:15 PM, Martin wrote:
>> On 2019-11-24 23:42, Rainer Dorsch wrote:
>>> Is there a Debian based SBC which goes close to or even below 1W?
>> According to https://www.taskit.de/stamp-overview.html their
>> different boards have between 0.12 and 0.42 W consumption, but
>> that is without the actual Ethernet hardware (phy) etc. Real
>> power consumption depends on your peripheral electronics.
>> The boards run Debian armel (ARM926EJ-S) or armhf (Cortex A5)
>> just fine. Only kernel needs a little bit of customisation.
>>
>
> I recall a Raspberry Pi Zero to be under 1W with a USB 100Mb/s
> ethernet interface.  Actually I'd expect a Pi Zero wireless to consume
> less if that type of connectivity would work in your application.
>
> If you really need wired ethernet, with a cable making its way to the
> device, would the possibility of PoE relax the need for <1W power
> consumption?
>
>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: MP30-AR0 arm64 sdcard slot not detected

[Alan Corey]

Do you have a way to boot a generic kernel as a test?  What does ls
/dev/sd* look like?  How about a USB SD card reader?  Reminds me of
building a custom kernel and leaving something out by accident.  Maybe a
dependency of the SD card slot.  Weird though.
On Oct 20, 2019 8:30 AM, "Gene Heskett"  wrote:

> On Saturday 19 October 2019 02:29:41 Michael Howard wrote:
>
> > Posted this to wrong list initially, sorry all!
> >
> > I've just re-installed debian (stretch) on the Gigabyte MP30-AR0 board
> > using the installer netinst iso (any later install images fail) and
> > the sdcard slot is not showing up. The kernel is
> > vmlinuz-4.9.0-11-arm64 and I have also rebuilt it ensuring all the MMC
> > options I should need are selected.
> >
>
> I've not run into that, but it my understanding that an sd slot is an
> entirely different critter from MMC.  So you may want to go thru
> your .config again with that in mind.
>
> > I'm now suspecting a devicetree issue. Checking the output from dtc,
> > using 'dtc -I fs -O dts /sys/firmware/devicetree/base' there is no
> > mention of mmc. However, an 'mmc' entry exists in the source code file
> > 'apm-storm.dtsi', which is 'included' by  'apm-mustang.dts', which I'm
> > assuming is the dts file used by the kernel build system, I used
> > bindeb-pkg to build the debs.
> >
> > Previously, I've manually built the image, modules and dtb (last
> > occasion using mainline 4.9.2) and the card slot was not a problem.
> >
> > Anybody any ideas as to what's happening? Can I ensure that
> > 'bindeb-pkg' uses a specific dts? If so, how?
> >
> > This system dual boots with RedSleeve and that side is not a problem.
> >
> > Cheers,
> >
> > Mike.
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>

libxp-dev and libxp6 for aarch64 and forward?

[Alan Corey]

They seem to be missing from Stretch but they're in Buster.  Maybe, by
pkgs.org, and they only have the i386 and amd64 versions.  They don't
show up using this sources.list

deb http://ftp.us.debian.org/debian stretch main contrib non-free
#deb-src http://ftp.us.debian.org/debian stretch main contrib non-free
deb http://ftp.us.debian.org/debian stretch-updates main contrib non-free
#deb-src http://ftp.us.debian.org/debian stretch-updates main contrib non-free
deb http://security.debian.org/debian-security stretch/updates main
contrib non-free
#deb-src http://security.debian.org/debian-security stretch/updates
main contrib non-free

I'm on an aarch64 machine (Odroid N2).  Raspbian has them.

-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: loss of synaptic due to wayland

[Alan Corey]

So?  You don't need it that often.  I don't get why you can't start up
X and run Synaptic, then switch to something under Wayland.  There's
also some compatibility thing where you can run an X program in a
window under Wayland, don't remember what it's called.

I just ordered an Odroid N2, instead of a Pi 4.

On 7/9/19, Gene Heskett  wrote:
> On Tuesday 09 July 2019 11:37:17 Alan Corey wrote:
>
>> I thought it was possible to have both X and Wayland installed and
>> just start the one you want to use.  Pretty sure I did that when I was
>> playing with Buster.
>
> I've  no clue what they did, but after the update that tipped the nitrous
> can way high for video speeds, synaptic is running on buster, but only
> on the pi's own screen.
>
>> I can do
>> apt search
>> but then I have apt installed.  There are several package management
>> tools.  What I like Synaptic for besides the obvious is finding and
>> fixing broken packages.  You can get in there and take out what's
>> causing the problem, if it doesn't do it from the menu.  The package
>> tools work differently in that situation.  I seem to get broken
>> packages a lot.  apt isn't apt-get or aptitude or synaptic or wajig or
>> apt-cache or dpkg, but they probably all use the APT library.
>>
>> On 7/9/19, Luke Kenneth Casson Leighton  wrote:
>> > (hi gene, hope you don't mind, i'm cc'ing the list back again, i
>> > assume you accidentally didn't hit "reply-to-all?"  or that i did,
>> > if so, whoops...)
>> >
>> > On Mon, Jul 8, 2019 at 7:20 PM Gene Heskett 
> wrote:
>> >> On Monday 08 July 2019 08:37:14 Luke Kenneth Casson Leighton wrote:
>> >> > On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett
>> >> > 
>> >>
>> >> wrote:
>> >> > > yes it was, and no solution was offered that I read about. And
>> >> > > no, aptitude is not a replacement.
>> >> >
>> >> >  used it once or twice, wasn't impressed, returned to apt-get and
>> >> > apt-cache search, which work extremely well, and have done since
>> >> > debian began.
>> >>
>> >> What I am trying to do is build a much newer, rt-preempt kernel for
>> >> buster on an armhf, aka a pi3b.  After having configured it, I try
>> >> a "make" and in about a minute, am getting a missing openssl/bio.h
>> >> exit:
>> >>
>> >> pi@picnc:/media/pi/workpi120/buildbot/linux-5.1.14 $ make
>> >>   HOSTCC  scripts/extract-cert
>> >> scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such
>> >> file or directory
>> >>  #include 
>> >>   ^~~
>> >> compilation terminated.
>> >> make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error
>> >> 1 make: *** [Makefile:1065: scripts] Error 2
>> >>
>> >>
>> >> not at all fam with apt-cache search, I have not found a bio.h
>> >> except in some obvious biology related programs. unrelated to
>> >> openssl IOW.
>> >>
>> >> The man page is so long I quickly lose track of all the options.
>> >>
>> >> So how would I state the search that will find it if it exists in
>> >> the repo's?
>> >
>> >  there's a file search "thing" somewhere, for apt... it's a plugin
>> > (i think)... although i suspect you simply have the wrong version of
>> > openssl installed.
>> >
>> >  ok so i do have /usr/include/openssl/bio.h (makes it easier if
>> > someone else has it) and so i can find it with:
>> >
>> > $ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
>> >
>> > and that gives:
>> >
>> > /var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
>> > /var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
>> >
>> > shriik wtf am i doiiing with nodejs installed, dieee nodejs,
>> > die sorry about that, adverse reaction to node.js
>> >
>> > ok so you'll need to do "apt-get install libssl-dev" and that
>> > *should* get you the missing openssl/bio.h file.
>> >
> Nope.
>
>> > if you run into any other difficulties with missing packages, try
>> > this:
>> >
>> > "apt-get build-dep linux-image-4.something.something"
>> >
>> > that will install *all* build d

Re: loss of synaptic due to wayland

[Alan Corey]

I thought it was possible to have both X and Wayland installed and
just start the one you want to use.  Pretty sure I did that when I was
playing with Buster.

I can do
apt search
but then I have apt installed.  There are several package management
tools.  What I like Synaptic for besides the obvious is finding and
fixing broken packages.  You can get in there and take out what's
causing the problem, if it doesn't do it from the menu.  The package
tools work differently in that situation.  I seem to get broken
packages a lot.  apt isn't apt-get or aptitude or synaptic or wajig or
apt-cache or dpkg, but they probably all use the APT library.



On 7/9/19, Luke Kenneth Casson Leighton  wrote:
> (hi gene, hope you don't mind, i'm cc'ing the list back again, i
> assume you accidentally didn't hit "reply-to-all?"  or that i did, if
> so, whoops...)
>
> On Mon, Jul 8, 2019 at 7:20 PM Gene Heskett  wrote:
>>
>> On Monday 08 July 2019 08:37:14 Luke Kenneth Casson Leighton wrote:
>>
>> > On Mon, Jul 8, 2019 at 12:55 PM Gene Heskett 
>> wrote:
>> > > yes it was, and no solution was offered that I read about. And no,
>> > > aptitude is not a replacement.
>> >
>> >  used it once or twice, wasn't impressed, returned to apt-get and
>> > apt-cache search, which work extremely well, and have done since
>> > debian began.
>> >
>> What I am trying to do is build a much newer, rt-preempt kernel for
>> buster on an armhf, aka a pi3b.  After having configured it, I try
>> a "make" and in about a minute, am getting a missing openssl/bio.h exit:
>>
>> pi@picnc:/media/pi/workpi120/buildbot/linux-5.1.14 $ make
>>   HOSTCC  scripts/extract-cert
>> scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or
>> directory
>>  #include 
>>   ^~~
>> compilation terminated.
>> make[1]: *** [scripts/Makefile.host:92: scripts/extract-cert] Error 1
>> make: *** [Makefile:1065: scripts] Error 2
>>
>>
>> not at all fam with apt-cache search, I have not found a bio.h except in
>> some obvious biology related programs. unrelated to openssl IOW.
>>
>> The man page is so long I quickly lose track of all the options.
>>
>> So how would I state the search that will find it if it exists in the
>> repo's?
>
>  there's a file search "thing" somewhere, for apt... it's a plugin (i
> think)... although i suspect you simply have the wrong version of
> openssl installed.
>
>  ok so i do have /usr/include/openssl/bio.h (makes it easier if
> someone else has it) and so i can find it with:
>
> $ grep bio.h /var/lib/dpkg/info/*.list | grep openssl
>
> and that gives:
>
> /var/lib/dpkg/info/libssl-dev:amd64.list:/usr/include/openssl/bio.h
> /var/lib/dpkg/info/nodejs.list:/usr/include/node/openssl/bio.h
>
> shriik wtf am i doiiing with nodejs installed, dieee nodejs,
> die sorry about that, adverse reaction to node.js
>
> ok so you'll need to do "apt-get install libssl-dev" and that *should*
> get you the missing openssl/bio.h file.
>
> if you run into any other difficulties with missing packages, try this:
>
> "apt-get build-dep linux-image-4.something.something"
>
> that will install *all* build dependencies for a *debian* kernel build
> process... which (warning) may be a little bit more than you bargained
> for, you'll have to review what it recommends to install before
> proceeding, ok?
>
> basically when doing a build of a package that's similar (or
> identical) to an existing debian one, the trick of installing
> *debian's* build dependencies for the same name uuusuuually does the
> trick of getting you everything you'll need to build that "vanilla"
> upstream {whatever}.
>
> problems come when debian sets different options from the default, and
> you can always inspect the debian/rules file for what they are.
>
>
>> My /e/a/sources.list:
>>
>> deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib
>> non-free rpi
>> # Uncomment line below then 'apt-get update' to enable 'apt-get source'
>> deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib
>> non-free rpi
>>
>> >  never had *any* problems - at all -  that weren't caused by doing
>> > something incredibly stupid such as "ctrl-c" in the middle of an
>> > installation (at the point where dpkg is being called), and even then,
>> > apt-get -f install in almost 100% of cases fixed the "problem that i
>> > had myself caused".
>> >
>> >  really: if you ask me, relying on GUIs for something as
>> > mission-critical as installation of packages is asking for trouble.
>>
>> What the gui is good for is showing you the exact package name to install
>> or purge. Nothing else, however capable it might be, can really replace
>> the look and feel of a good gui. But I've been corrected before.  Teach
>> me!
>
>  :)
>
>  on-list is better (other people benefit too).  these are what i use:
>
> for source stuff:
>  * apt-get source {package} - gets the *source code* of a package
>  * apt-get build-dep {package} - gets you the (full) build
> dependenci

Re: heatsink -- was [Re: Raspberry Pi 4 is announced]

[Alan Corey]

I have an aluminum case, not using it lately.  I mostly use a USB wifi
adapter.  If you clone a Pi SD card it ends up on the same IP address as
the original.  I couldn't get it through anybody's head at raspberry pi.org
that this is a problem.  USB wifi is at least different, haven't tried 2 of
them.  Possibly it only happens with Raspbian, not Debian.

Sent from my Motorola XT1527

On Thu, Jul 4, 2019, 1:14 PM Larry Dighera  wrote:

>
> From the information provided in this video
> https://youtu.be/26OxCwEHoTk there appears to be about a 15 dB
> reduction is WiFi signal strength with the FLIRC aluminum case
> installed.
>
> If WiFi signal strength is an issue, how difficult would it be to
> install an external antenna (or two)?
>
> This review provides information comparing the RPi 3b+ to the 4B:
> https://www.tomshardware.com/reviews/raspberry-pi-4-b,6193.html
> It provides heat maps (attached) and CPU thermal throttling
> information:
>
> "While running a CPU-intensive workload for 10 minutes, the processor
> hit 81 degrees and began throttling down from 1.5 to 1 GHz after 3
> minutes. However, the system kept bringing itself back to the full 1.5
> GHzas when it dipped down to around 80 degrees, but then it would get
> warm again and go down to 1 GHz. If you want to have better sustained
> performance under load, consider getting an active cooler for the
> Raspberry Pi 4 or, at the very least, attach a passive heat sink."
>
>
> Here's an alternative plastic case:
> https://www.pishop.us/product/highpi-raspberry-pi-case-for-pi4/
>
> HIGHPI CASE FEATURE LIST
> High quality ABS plastic case, designed and made in Canada
> Industry-leading ease of use, rapid tool-free assembly and disassembly
> Large internal volume for HATs, break-out boards, or heat sinks
> Vents on three sides double as fly-through cable ports
> Two-section breakout on A/V side for HAT board I/O
> Large vent opposite A/V side allows GPIO ribbon cable pass-through
> Micro SD card access port
> Mounting option 1: two M3.5/M3/#6 screws slide into wall mounts
> for easy removal, horizontal orientation with A/V side down, 40mm
> spacing
> Mounting option 2: four M3.5/M3/#6 screws through feet from inside for
> secure mounting in any orientation, 68.3 x 38.8mm spacing
> Self-adhesive rubber feet included, set of 4
> Matte finish hides fingerprints
> DIMENSIONS
> External dimensions: 97 x 66 x 41mm
> Internal volume for breakout boards: 90 x 60 x 28.8mm
>
>
>
>
> On Fri, 28 Jun 2019 20:54:39 -0400, Alan Corey 
> wrote:
>
> >Unless you're going to overclock it (which I'm not sure is possible,
> >probably) you don't need a heat sink.  It will throttle (reduce speed)
> >if it gets hot.  A heat sink keeps it from overheating so soon so it
> >can run at full speed longer.  If you run cpuminer (to mine Litecoin
> >or Bitcoin) it will overheat a Pi very quickly and slow down, even
> >without overclocking, because it's so CPU-intensive.  You can run less
> >threads to run cooler.
> >
> >What I'd like to see is a massive heat sink that dwarfs the circuit
> >board and becomes dominant, sort of like with Pentiums, could even
> >have a fan.  You'd mount the heat sink then bolt the Pi to it,
> >probably with heat sink compound or a heat-conductive washer.  The
> >connectors and wires would go wherever they ended up.  There could be
> >such setups as aftermarket addons.
> >
> >I don't like that they continue to push the power connector to its
> >limits instead of going to something else like a coaxial plug like the
> >Rock64 uses.  I'm not sure it it's still a microusb or not.  But you
> >can always power through the GPIO connector.
> >
> >And this uses _micro_ HDMI connectors, as opposed to the Zero which
> >uses _mini_ or the earlier Pis which have just a regular HDMI.  So if
> >you have a slew of Pis and Zeros you need 2 adapters for video.
> >
> >GPIO pinout at
> https://www.element14.com/community/docs/DOC-92640/l/raspberry-pi-4-model-b-gpio-pinout-with-poe-header?ICID=rpimain-smartpanel-pi4doc
> >I'm not sure how different it is.  The Pi GPIO has gotten to be a
> >defacto standard that other manufacturers also use.  I see there are
> >still multiple 5 volt and ground pins so they can be paralleled for
> >more current capability.
> >
> >I welcome the 4 GB of RAM the most, I use 2 swap files and get tired
> >of waiting for swapping and unswapping.  Hopefully the ethernet is no
> >longer tied to the USB.
> >
> >There is a new case and power supply, at least partly for the 2
> >micro-HDMIs.  A Rock64 fits into

Re: Hostname v buster

[Alan Corey]

BitTorrent is also good when you can use it.  The site has to have a
torrent link.  The Raspberry Pi site does this for their images.  I
used to use Transmisssion as a client, now I use Deluge (It's in the
debs).

If you have cell phone service where you live you can get an
"unlimited" plan from Straight Talk (AT&T towers) with a limit of
50-60 GB/month for about $60/month.  This does voice/text/data.  It's
at least 10x dialup, maybe 100x, haven't timed it.  I've been on
unlimited about a year.  Turn on the wifi hotspot option on your phone
and use wifi to connect everything through it.  Phones you buy from a
company like Verizon can't do this, they've been crippled at the
factory because the carrier doesn't want you doing it.  I've had 4
Motorolas, 2 came from Motorola, 2 from eBay.  Same model # as a
contract phone but they aren't crippled.  You can also unlock the
bootloader, root it, install Ubuntu Touch instead of Android, etc.  I
got my first cell phone to text with, never expected to get on the
internet through it.  Straight Talk mostly uses unlocked phones.




On 7/1/19, Cindy Sue Causey  wrote:
> On 7/1/19, gru...@mailfence.com  wrote:
>>> I had a hell of a time pulling it as I did a google search, and when the
>>> download had started, google was still in the firefox address  bar, and
>>> I had to restart a timedout fail several hundred times.  So I'm doing it
>>> again, and its coming it at an average of 1 meg/sec this time. I got the
>>> sha512 and info files too.
>>>
>>
>> try wget
>
>
> Oh, my gosh, YES! "wget -c" rocks on dialup!
>
> After a quick search, from "man wget" comes:
>
> -t number OR --tries=number: Set number of tries to number. Specify 0
> or inf for infinite retrying. The default is to retry 20 times, with
> the exception of fatal errors like "connection refused" or "not found"
> (404), which are not retried.
>
> For the "-c" flag:
>
> -c OR --continue: Continue getting a partially-downloaded file.  This
> is useful when you want to finish up a download started by a previous
> instance of Wget, or by another program.
>
> "wget -c" has been a HUGE HERO in last few weeks. For some reason,
> "apt-get install" has multiple times now DELETED partial downloads and
> started over when it's for same upgrade version number. Never had that
> happen before.
>
> That's a pain when it's e.g. 20 or 30MB partials that represent 2 or 3
> hours of download wear-and-tear time. "wget -c" gets in there and
> successfully FINISHES off that exact same partial dotDEB archive
> download now. YES... I've had to learn to... incrementally backup even
> partial dotDEB downloads for moments just like this. You do what you
> gotta do when *IT WORKS!*
>
> PS #ThankYou, Developers!
>
> Cindy :)
> --
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
>
> * runs with birdseed.. and possibly even a Raspberry Pi sooner than
> later! k/t #OSNews for being the first to get giddy with that news in
> my inbox last week. *
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Hostname v buster

[Alan Corey]

Absolutely. Or maybe curl.  If you can get the file's URL, and if the
site you're downloading from will let you, some won't.  Usually you
can right-click on a link and do "copy link location" then type
wget 

You can also start the download (or on a failed one), go to tools ->
downloads, right-click on the file in there and do copy link location.

In the past years few some sites won't let you do this because it
somehow knows it's not your browser anymore.  Then you're doomed to
download with Firefox.  I used to do this on dialup at 10 MB/hour at
best.

I'd make a file where I wanted the download called url.txt (they come
in handy later too sometimes) with just the url in it.  Then call wget
from a script that loops until it's done.  I call this getit, chmod +x
so it's executable, and keep it in the path like /usr/local/bin

---
#!/bin/sh
# Wget gives up on being unable to resolve a host and quits returning an
# error.  This retries until no error is returned.

# Problem is:
# 416 Requested Range Not Satisfiable
# The file is already fully retrieved; nothing to do.
# also returns non-zero so it gets into a loop sometimes at the end

while true
do
wget -c --no-check-certificate -i url.txt && break
echo "Restarting wget"
sleep 2
done
---


On 7/1/19, gru...@mailfence.com  wrote:
>> I had a hell of a time pulling it as I did a google search, and when the
>> download had started, google was still in the firefox address  bar, and
>> I had to restart a timedout fail several hundred times.  So I'm doing it
>> again, and its coming it at an average of 1 meg/sec this time. I got the
>> sha512 and info files too.
>>
>
> try wget
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: heatsink -- was [Re: Raspberry Pi 4 is announced]

[Alan Corey]

Thank you, I hadn't looked at that.  So there's Debian for it, not
just Ubuntu?  I have 3 Raspberry Pi 3s but for a higher performance
machine I have a Rock64, which isn't entirely satisfactory.  I'll poke
around Odroid's forums a little and probably order one.  It looks more
like a car stereo and in fact it even has audio DACs.  Support for the
Rock64 is mostly in Chinese, this is Korean, we'll see.

On 6/29/19, andreimpope...@gmail.com  wrote:
> On Vi, 28 iun 19, 20:54:39, Alan Corey wrote:
>>
>> What I'd like to see is a massive heat sink that dwarfs the circuit
>> board and becomes dominant, sort of like with Pentiums, could even
>> have a fan.  You'd mount the heat sink then bolt the Pi to it,
>> probably with heat sink compound or a heat-conductive washer.  The
>> connectors and wires would go wherever they ended up.  There could be
>> such setups as aftermarket addons.
>
> The ODroid N2 is built like this.
>
> https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram/
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: heatsink -- was [Re: Raspberry Pi 4 is announced]

[Alan Corey]

Unless you're going to overclock it (which I'm not sure is possible,
probably) you don't need a heat sink.  It will throttle (reduce speed)
if it gets hot.  A heat sink keeps it from overheating so soon so it
can run at full speed longer.  If you run cpuminer (to mine Litecoin
or Bitcoin) it will overheat a Pi very quickly and slow down, even
without overclocking, because it's so CPU-intensive.  You can run less
threads to run cooler.

What I'd like to see is a massive heat sink that dwarfs the circuit
board and becomes dominant, sort of like with Pentiums, could even
have a fan.  You'd mount the heat sink then bolt the Pi to it,
probably with heat sink compound or a heat-conductive washer.  The
connectors and wires would go wherever they ended up.  There could be
such setups as aftermarket addons.

I don't like that they continue to push the power connector to its
limits instead of going to something else like a coaxial plug like the
Rock64 uses.  I'm not sure it it's still a microusb or not.  But you
can always power through the GPIO connector.

And this uses _micro_ HDMI connectors, as opposed to the Zero which
uses _mini_ or the earlier Pis which have just a regular HDMI.  So if
you have a slew of Pis and Zeros you need 2 adapters for video.

GPIO pinout at 
https://www.element14.com/community/docs/DOC-92640/l/raspberry-pi-4-model-b-gpio-pinout-with-poe-header?ICID=rpimain-smartpanel-pi4doc
I'm not sure how different it is.  The Pi GPIO has gotten to be a
defacto standard that other manufacturers also use.  I see there are
still multiple 5 volt and ground pins so they can be paralleled for
more current capability.

I welcome the 4 GB of RAM the most, I use 2 swap files and get tired
of waiting for swapping and unswapping.  Hopefully the ethernet is no
longer tied to the USB.

There is a new case and power supply, at least partly for the 2
micro-HDMIs.  A Rock64 fits into a Pi case but the power connector is
different so it needs some filing.  The cases are sort of a nuisance
because the wires dominate everything and are much heavier.



On 6/28/19, Rick Thomas  wrote:
> So when I buy one of these in a couple of months, do I need to buy the
> heatsink too?  Will the heatsink fit into the standard case?  If not, is
> there a case that will fit?
>
> And, finally, is there a version of Debian that will run on one of these?
> Or should I just plan on running Raspbian?
>
> Thanks!
> Rick
>
>> On Jun 28, 2019, at 12:32 PM, Alan Corey  wrote:
>>
>> No big surprise there.  Something about 1500 more on 7/4.  I got on
>> the list to get emailed when they get them.  Oh well, time to get
>> adapters ordered, and a different power supply.  Looks like they built
>> it to bolt a heat sink onto, there's free space around the CPU.
>>
>> The real announcement page:
>> https://www.raspberrypi.org/products/raspberry-pi-4-model-b/
>>
>> On 6/28/19, Mauricio Tavares  wrote:
>>> On Fri, Jun 28, 2019 at 2:57 PM Alan Corey  wrote:
>>>>
>>>> Tech specs at Element14
>>>> https://www.element14.com/community/docs/DOC-92643/l/meet-the-new-raspberry-pi-4-model-b-with-technical-specifications?CMP=e-email-ADH-e14-NA-280619-RPITechSpec-H&mkt_tok=eyJpIjoiTldRNE56VTJOVGxqWldabCIsInQiOiIyMllcLzZiS2FQb1NpVWt6Q2pkamNnUTVXSThMTGtISWJMZWVRXC9XQVlOWEFLa3dSMGNIMVA4VGdpWTZTRVlhN0ZZd2t5QysrVFF1Mm80WEpjQmxZVEsya0FyeVRYcTR0Z3pPN3hTMXdzY01UNnVFN0FiTW8zRTBYYzl6SjJESmhsIn0%3D
>>>>
>>>> Up to 4 GB RAM, gigbit ethernet, dual micro-HDMI, dual-band wifi,
>>>> OpenGL ES 1.1, 2.0, 3.0, 2 USB 3.0 ports (+ 2 USB 2.0), Broadcom 2711,
>>>> Quad-core Cortex-A72 64-bit SoC @ 1.5 GHz
>>>>
>>>> Element14 doesn't have them in stock yet but the 4 GB is listed at
>>>> $55.  Sounds like a Rock64 killer
>>>>
>>>  I think they have been out of stock since Monday. Sold out quickly
>>>
>>>> --
>>>> -
>>>> No, I won't  call it "climate change", do you have a "reality problem"?
>>>> -
>>>> AB1JX
>>>> Cities are cages built to contain excess people and keep them from
>>>> cluttering up nature.
>>>> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>>>>
>>>
>>
>>
>> --
>> -
>> No, I won't  call it "climate change", do you have a "reality problem"? -
>> AB1JX
>> Cities are cages built to contain excess people and keep them from
>> cluttering up nature.
>> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Raspberry Pi 4 is announced

[Alan Corey]

No big surprise there.  Something about 1500 more on 7/4.  I got on
the list to get emailed when they get them.  Oh well, time to get
adapters ordered, and a different power supply.  Looks like they built
it to bolt a heat sink onto, there's free space around the CPU.

The real announcement page:
https://www.raspberrypi.org/products/raspberry-pi-4-model-b/

On 6/28/19, Mauricio Tavares  wrote:
> On Fri, Jun 28, 2019 at 2:57 PM Alan Corey  wrote:
>>
>> Tech specs at Element14
>> https://www.element14.com/community/docs/DOC-92643/l/meet-the-new-raspberry-pi-4-model-b-with-technical-specifications?CMP=e-email-ADH-e14-NA-280619-RPITechSpec-H&mkt_tok=eyJpIjoiTldRNE56VTJOVGxqWldabCIsInQiOiIyMllcLzZiS2FQb1NpVWt6Q2pkamNnUTVXSThMTGtISWJMZWVRXC9XQVlOWEFLa3dSMGNIMVA4VGdpWTZTRVlhN0ZZd2t5QysrVFF1Mm80WEpjQmxZVEsya0FyeVRYcTR0Z3pPN3hTMXdzY01UNnVFN0FiTW8zRTBYYzl6SjJESmhsIn0%3D
>>
>> Up to 4 GB RAM, gigbit ethernet, dual micro-HDMI, dual-band wifi,
>> OpenGL ES 1.1, 2.0, 3.0, 2 USB 3.0 ports (+ 2 USB 2.0), Broadcom 2711,
>> Quad-core Cortex-A72 64-bit SoC @ 1.5 GHz
>>
>> Element14 doesn't have them in stock yet but the 4 GB is listed at
>> $55.  Sounds like a Rock64 killer
>>
>   I think they have been out of stock since Monday. Sold out quickly
>
>> --
>> -
>> No, I won't  call it "climate change", do you have a "reality problem"? -
>> AB1JX
>> Cities are cages built to contain excess people and keep them from
>> cluttering up nature.
>> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Raspberry Pi 4 is announced

[Alan Corey]

Tech specs at Element14
https://www.element14.com/community/docs/DOC-92643/l/meet-the-new-raspberry-pi-4-model-b-with-technical-specifications?CMP=e-email-ADH-e14-NA-280619-RPITechSpec-H&mkt_tok=eyJpIjoiTldRNE56VTJOVGxqWldabCIsInQiOiIyMllcLzZiS2FQb1NpVWt6Q2pkamNnUTVXSThMTGtISWJMZWVRXC9XQVlOWEFLa3dSMGNIMVA4VGdpWTZTRVlhN0ZZd2t5QysrVFF1Mm80WEpjQmxZVEsya0FyeVRYcTR0Z3pPN3hTMXdzY01UNnVFN0FiTW8zRTBYYzl6SjJESmhsIn0%3D

Up to 4 GB RAM, gigbit ethernet, dual micro-HDMI, dual-band wifi,
OpenGL ES 1.1, 2.0, 3.0, 2 USB 3.0 ports (+ 2 USB 2.0), Broadcom 2711,
Quad-core Cortex-A72 64-bit SoC @ 1.5 GHz

Element14 doesn't have them in stock yet but the 4 GB is listed at
$55.  Sounds like a Rock64 killer

-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: screen update rate on a pi3b+ running stretch?

[Alan Corey]

It's possibly easiest to hack whatever's driving it and stick in a
counter that increments every frame and check 100 or so of them
against the output of gettimeofday() or clock_gettime().  That's the
way I've always done it, which was maybe twice.

xrandr, xdpyinfo, fbset don't do it.  You can try tvservice -s but I
think vertical refresh rate isn't what you're looking for exactly.

upstairs# tvservice -s
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive

That 60.00Hz doesn't change I think since the monitor depends on it.
And if it's double-buffered good luck, you really need how often the
first buffer fills up.  Drawing usually happens into an offscreen
buffer then they get swapped, which could mean a pointer points to a
different place.


On 6/25/19, Gene Heskett  wrote:
> Greetings all;
>
> So, do we have a utility that can measure the frame rate achieved, for a
> full screen 1920x1080 32 bit display?
>
> Thanks a bunch.
>
> Cheers, Gene Heskett
>
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: hidden help in make

[Alan Corey]

Yeah, I use a 1 TB spinning drive by USB.  In Gimp with 6000x4000
images it's pretty slow but I just live with it, do less intermediate
saves.  I haven't looked at their source but I think mc calls unzip,
seems like it's a dependency.  Haven't messed with zips that big in a
few months.

I'm almost ready to put in a feature request to have mc work with adb
(for Android) in shell mode so you can plug in a phone and mc around.
Seems like it could be a filesystem plugin.  You can do adb shell and
you're looking into the phone but you spent a lot of time doing cd
this and that and working blind.  You can do adb push and pull for
file transfers.

On 6/21/19, Gene Heskett  wrote:
> On Friday 21 June 2019 20:23:17 Alan Corey wrote:
>
>> unzip is much faster than mc on big files.  mc is just convenient for
>> small stuff.
>>   unzip file
>> or see the man page
>
> I have wondered about that, but in this case the BIG  bottleneck is the
> pinhole sized channel thru usb2 to that drive..  The network is all
> gigabit stuff, and mc can keep it fairly busy.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> On 6/21/19, Gene Heskett  wrote:
>> > On Friday 21 June 2019 10:29:20 Gene Heskett wrote:
>> >> Which makes it easier to build/install an rt kernel, BUT
>> >>
>> >> now I need to define for an rpi 3b, LOADADDR, as applied to
>> >> building a uImage.
>> >>
>> >> Where can I find this info for an r-pi-3b?
>> >
>> > Seems I found that, but without any further real progress, it needs
>> > a copy of mkimage which is part of raspberrypi-tools according to
>> > google, get it from github, its not in the repos by any recognizable
>> > name. Found the zip, 300+ megabytes, and now mc has cracked the zip
>> > and it is copying 907 megabytes worth of stuff to the 120GB ssd on
>> > the pi as build scratchpad over my local network, with an estimated
>> > completion time of about 13.5 HOURS, but thats growing by nominally
>> > 30 secs everytime mc updates its progress.  Then I expect I have to
>> > process it with dpkg-buildpackage, probably at least another DAY to
>> > generate and install the deb.
>> >
>> > All because I need whats likely less than a megabyte of executable
>> > code thats in there somewhere. Seems to me that binary ought to be
>> > included in build-essential...  Sigh.
>> >
>> > Several hours Later, 40% copied, 4 hrs 31 minutes to go. Dinner is
>> > in the oven and my last load of laundry is in the washer.
>> >
>> >> Thanks anybody.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: hidden help in make

[Alan Corey]

unzip is much faster than mc on big files.  mc is just convenient for
small stuff.
  unzip file
or see the man page

On 6/21/19, Gene Heskett  wrote:
> On Friday 21 June 2019 10:29:20 Gene Heskett wrote:
>
>> Which makes it easier to build/install an rt kernel, BUT
>>
>> now I need to define for an rpi 3b, LOADADDR, as applied to building a
>> uImage.
>>
>> Where can I find this info for an r-pi-3b?
>
> Seems I found that, but without any further real progress, it needs a
> copy of mkimage which is part of raspberrypi-tools according to google,
> get it from github, its not in the repos by any recognizable name.
> Found the zip, 300+ megabytes, and now mc has cracked the zip and it is
> copying 907 megabytes worth of stuff to the 120GB ssd on the pi as build
> scratchpad over my local network, with an estimated completion time of
> about 13.5 HOURS, but thats growing by nominally 30 secs everytime mc
> updates its progress.  Then I expect I have to process it with
> dpkg-buildpackage, probably at least another DAY to generate and install
> the deb.
>
> All because I need whats likely less than a megabyte of executable code
> thats in there somewhere. Seems to me that binary ought to be included
> in build-essential...  Sigh.
>
> Several hours Later, 40% copied, 4 hrs 31 minutes to go. Dinner is in the
> oven and my last load of laundry is in the washer.
>
>> Thanks anybody.
>>
>> Cheers, Gene Heskett
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: need recommendation for a realtime kernel to build for an armhf

[Alan Corey]

On 6/15/19, Gene Heskett  wrote:
> On Saturday 15 June 2019 04:07:36 pm Alan Corey wrote:
>

> Get familiar with it Alan, despite our objections, both ifconfig and
> route have been expunged from the stretch and newer repo's. I haven't
> figured it out either. And the man pages may as well have been written
> in swahili or navajo. Even the so-called examples can't be made to work.
-

Bah, if that happens I'm going to netbsd.  I'm on the netbsd-arm
mailing list so I see what they're chatting about.  Last time I tried
it the Pi support wasn't very good but that was at least a year ago,
now they're into fancier stuff than I care about.  No real experience
with netbsd but openbsd borrows/steals a lot from them and I used that
for 15 years or so.  Linux gets on my nerves after a while.
Especially everything being deprecated and having to learn a new way
to do something because somebody had a bright idea.  systemctl?  Yuck.
Just let me do it the old way I learned years ago and get out from
underfoot.  Stability is my highest priority, they probably call that
stagnation.

But more stuff compiles under Linux and the BSDs are a little slower
and don't have fancy stuff like realtiime kernels.

Re: need recommendation for a realtime kernel to build for an armhf

[Alan Corey]

What does just ifconfig (by itself) say?  And route by itself?  What's
your /etc/network/interfaces file like?

I think the 69.254.163.253 is the IP assigned dynamically by your
router.  Or it's your router's IP.  But I think 69.254.163.x is your
outside IP.

I'm not familiar with ip.  Route shows me:
upstairs# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
default phone   0.0.0.0 UG0  00 wlan0
192.168.0.0 0.0.0.0 255.255.255.0   U 0  00 eth0
192.168.43.00.0.0.0 255.255.255.0   U 0  00 wlan0
upstairs#

Where phone (in my hosts file as 192.168.43.1) is my default gateway,
I think DHCP ,makes that the default route, maybe I set it manually
(not in a year or more).

You can play with the metric numbers too if you want to assign
priorities.  I'm procrastinating trying to get wifi, dialup and an
ethernet printer working on an XP box.  It thinks the internet is the
printer, it goes nowhere until I disable that interface.

Ah, OK, I cheated and looked it up:
route add default gw {IP-ADDRESS} {INTERFACE-NAME}
from 
https://www.cyberciti.biz/faq/linux-setup-default-gateway-with-route-command/

You need both "default and "gw" in there.



On 6/15/19, Gene Heskett  wrote:
> Greetings;
>
> I am about to install a stretch on an r-pi-3b. Then let it update to the
> latest, with an eye toward a buster update when its released.
>
> But this will be driving a lathe, so it needs the best latency figures
> that can be obtained by later linux-rt kernels, prefereably in the
> 4.19.whatever category.  I have some debs already built that once
> installed, should handle that.
>
> Some later:
>
> armhf Stretch is now installed but host file style networking is not
> making the transition from local domain to outside network because any
> ping to an outside address such as yahoo.com IS NOT coming from the
> local domain address, but the avahi-daemon returned address. I my
> networking scheme there is no such machine defined anyplace.
> Only "localhost" defined anyplace is 127.0.0.1 in the /etc/hosts file
>
> A sudo grep -R 169. * returns only those lines I commented out. and
> restarted networking each time.
>
> Where the heck is machinename.local, defined as 169.254.x.x coming from,
> and more importantly how do I get rid of it once and forever?
>
> ip a shows duplicate inet lines for eth0 and I can't get rid of this one:
>
>inet 169.254.163.253/16 brd 169.254.255.255 scope global eth0
>valid_lft forever preferred_lft forever
>
> ip r returns this:
>
> default dev eth0 proto kernel scope link src 169.254.163.253 metric 202
> 169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.163.253
> metric 202
> 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
>
> And obviously I need to make the 3rd line the default.
>
> How do I fix this?
>
> Thanks all.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: a Debian executable on Android

[Alan Corey]

There are also odd ways of running Debian under Android like the
Debian kit.  They use Android's Linux kernel and supply most of a
Debian userland.  The trouble is it's pretty busy accomplishing
nothing in Android, the load average in Debian is pretty high.  Search
Debian on Google Play if you're interested.  I haven't bothered with
it in a while.

On 3/25/19, Tony Godshall  wrote:
>> Also, any device that has a yes in the mainline column for postmarketOS:
>>
>> https://wiki.postmarketos.org/wiki/Devices
>
> OK, so that's a precious short list, many not actual hardware, with
> two surprises (Sony).
>
> Generic Generic x64 uefi
> LG Nexus 5 lg-hammerhead
> Nokia N9
> Nokia N900
> Pine A64-LTS
> Qemu aarch64
> QEMU amd64
> Qemu vexpress
> Raspberry Pi Foundation Raspberry Pi 1 & 2
> Raspberry Pi Foundation Raspberry Pi 3
> Raspberry Pi Foundation Raspberry Pi Zero
> Sony Xperia Z2
> Sony Xperia Z2 Tablet
> Teclast X80 Pro
> TrekStor Surftab Wintron 7.0
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Does ARMEL toolchain include NEON support?

[Alan Corey]

I ran into something similar once.  Don't use the -neon switch for
AARCH64 because it's built in.

On 2/27/19, Steve McIntyre  wrote:
> On Wed, Feb 27, 2019 at 06:30:36PM -0500, Jeffrey Walton wrote:
>>On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre  wrote:
>>>
>>> So, I've got to ask - what hardware are you likely targeting here
>>> where it matters to build stuff for armel yet also use NEON if it's
>>> available? Most people with hardware that *can* do NEON should be
>>> using armhf, surely?
>>
>>Yeah, I know what you are saying.
>>
>>The problem in practice with mainstream compilers is (1) ARM and the
>>ACLE defines are a mess, (2) -march=native does not work like on i686
>>or x86_64, and (3) RTFM does not work.
>>
>>For a regular user who wants to use Debian on ARM we need to figure
>>out how to build to the least capable machine (like ARMv5 or ARMv6)
>>while making more capable features (like NEON) available.
>
> So this is a place where the world is just *different* compared to x86
> - the different versions of the ARM architectures have signficantly
> different capabilities. If you're looking to build something that
> performs well on a modern v7 CPU, compilling for v5 is a
> mistake. You'll be using the wrong locking primitives, barriers,
> etc. Equally, the features you're going to be looking for (like SMP,
> NEON) just don't make sense / don't exist on v5 CPUs.
>
>>User's don't want to RTFM to figure out what compiler switches to use.
>>They just want things to work. The compilers don't make it any easier
>>because -march=native does not work on ARM.
>
> It's a much wider world out there. :-/
>
>>So the use case we target is, user want the most from their hardware
>>without reading the manual to configure properly. That means we have
>>to go through extra gyrations when building.
>>
>>(I know we bring it on ourselves. We could easily say fuck it - the
>>user did not bother to read a man page so its the user's problem. But
>>I'm in the camp that common cases should just work for folks. Folks
>>should not need to read a manual to make the common case work).
>
> Agreed. But it might not actually be *possible* to do some of the
> optimisation stuff you're looking at, depending on the CPUs
> involved. This is basically one of the reasons we started the armhf
> port - it's a higher baseline that makes more sense for modern ARMv7
> CPUs, while still making it possible for people to use the older ARMv5
> cores out there.
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "Yes, of course duct tape works in a near-vacuum. Duct tape works
>  anywhere. Duct tape is magic and should be worshipped."
>-― Andy Weir, "The Martian"
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Upcoming Qt switch to OpenGL ES on arm64

[Alan Corey]

I think not pulling it to full screen puts everybody in the same boat
by using the default size.  But I can watch videos with smplayer on my
Rock64, on a Pi I need to use omxplayer because smplayer is too low.
There was some mention on the pine64.org page about using the Rock64
as a multimedia machine.

Ah, does linuxcrc do any kind of video acceleration?  Never seen it.
It could with DRI I think.

On 11/26/18, Gene Heskett  wrote:
> On Monday 26 November 2018 09:40:34 Alan Corey wrote:
>
>> Try glxgears and es2gears on few different platforms.  On a Pi 3b
>> glxgears runs at about 45 FPS, es2gears slightly lower.  On my Rock64
>> it's in the hundreds of FPS but that's Mali.  Look at omxplayer, full
>> screen HD video while the CPU idles (on a Pi).  The GPU is more
>> capable than the CPU.  You can do software-emulated OpenGL on
>> anything, the question is how efficient it is.
>
> glxgears is all I have, on both an rpi3b and a rock64
>
> But lets be realistic, what good is either if not pulled out to full
> screen?,
>
> Here, on the rpi3b its less than 1 FPS! This is because the realtime
> kernal is pinned to keep apt from replacing it with something that
> linuxcnc won't run on. With the actual size of lcnc's gui being about
> 1/2 screen I get about 4 FPS for a refresh rate on a 1920 by 12xx
> monitor. But because the backplot is so slow anything that smells like a
> collision with a fixture is done really slow, else the collision will
> have already happened long before I can take corrective action
>
> On the rock64, its around 4.5 FPS near full screen, rangeing up to 35 at
> its launch it size, on a 1366x768 monitor.
>
> I have other machines running on intel x86 hardware that give me
>
> close enough to real time its not been a problem. So videowise, on the
> arms, I could use every bit of help I can get.
> .
>> On 11/26/18, bret curtis  wrote:
>> > Hello Ian,
>> >
>> > On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell  wrote:
>> >> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
>> >> > The hardware that supports GLES also supports OpenGL because GLES
>> >> > is a subset of OpenGL.
>> >>
>> >> I'm confused by this inference. If GLES is a subset of OpenGL then
>> >> surely hardware which claims to implement GLES is at liberty to
>> >> only implement that subset and would therefore not necessarily
>> >> support OpenGL.
>> >>
>> >> Ian.
>> >
>> > I believe this is a purely a driver/firmware distinction. So whoever
>> > implements this is at liberty to do whatever they want so long as
>> > the hardware supports it.
>> >
>> > Meaning that if something advertises GLESv2 support then it has, at
>> > least, OpenGL 2.0 support in hardware because without that, they
>> > couldn't have supported GLESv1.
>> >
>> > GLES1.1 is fixed-function pipeline that is compatible with OpenGL
>> > 2.0, you're not going to create hardware to support GLES1.1 that
>> > doesn't also support at least OpenGL 2.0
>> >
>> > GLESv2 is another beast, it dropped fixed-function pipeline because
>> > that was the spec, but it is still a software implementation and
>> > doesn't mean that it no longer exists in hardware.
>> >
>> > Take for example the Nvidia Tegra:
>> > https://opengles.gpuinfo.org/displayreport.php?id=690  <-- SHIELD
>> > Android TV which happens to be a Tegra SoC  supports OpenGL ES 3.2
>> > https://opengl.gpuinfo.org/displayreport.php?id=2377  <-- Tegra as
>> > integrated with CPU (nvgpu), supports OpenGL 4.6.0
>> >
>> > Similar (if not the same?) hardware, running aarch64, the only real
>> > difference is the driver.
>> >
>> > That being said, I would love to hear from someone who actually
>> > makes these things to comment. It is entirely possible that there is
>> > a chip out there that supports GLES 3.2 and only that in hardware. I
>> > would be amazed but I'm reluctant to ever use the words never and
>> > ever. So far, the hardware that supports that are[1]:
>> >
>> > Adreno 420 and newer
>> > AMD GCN-architecture
>> > Intel HD Graphics Skylake and higher
>> > Mali-T760 and newer
>> > Nvidia GeForce 400 series (Fermi)
>> >
>> > As I said, I would be amazed if these GPUs didn't support some
>> > minimal version OpenGL in hardware. As I said elsewhere, most free
>> > and open-source drivers (mesa) support both some version of GLES
>> > along with some version of GL. [2]
>> >
>> > Cheers,
>> > Bret
>> >
>> >
>> > [1] https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_3.2_2
>> > [2] https://mesamatrix.net/
>
>
>
> --
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Alan Corey]

Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program?  Supply both libraries?  ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.

On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
>> Hello Lisandro,
>>
>> TLDR: thank you for starting this discussion, it was required as it's not
>> an easy decision to take as there is no realistic perfect solution,
>
> Our (team-wide) pleasure. This is something we have been digging since
> 2015.
>
>> but I
>> believe you took the wrong decision. Please consider deferring the
>> decision to the technical committe by seeking his advice (point 6.1.3
>> of the constitution
>> https://www.debian.org/devel/constitution.en.html#item-6).
>
> Will "kind of" do. Read below.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = Qt available for both Desktop and ES OpenGL flavours
>> > = If no change is possible, keep arm64 with Desktop OpenGL support
>>
>> I'm not pleased with how this discussion was handled. First of all,
>> you did not leave enough time for all stakeholders to participate in
>> the discussion (started on November 22th, closed November 25th, 3 days,
>> that's not a reasonable timeframe in particular when 2 of the 3 days
>> were in the week-end).
>
> My most sincere apologies if our timeframe do not fit yours.
>
> Now, wrt the decision: clearly the situation is very complex, involving many
>
> different kinds of arm64 devices, drivers, libraries et all. People involved
>
> have different opinions. We so far have been the proxy between them, be it
> on
> bugs, IRC or whatever other channels our users have to contact us. We prefer
>
> not to be this proxy anymore (again, read below).
>
> Besides we (Qt's team) have just learned that the Desktop/ES support is not
>
> tied to the hardware but to the driver. That's a particularly interesting
> point.
>
> So:
>
> To quote my original mail, the "Qt available for both Desktop and ES OpenGL
>
> flavours" point remains unchanged: if someone wants to make it happen [s]he
>
> must join the team and support it from the inside. Remember there are little
>
> chances for this to happen in time for Buster.
>
> For the second point, "If no change is possible, keep arm64 with Desktop
> OpenGL support", we have this position: we will keep the status quo,
> deferring
> users who want GLES support to Ubuntu.
>
> *But* we are open to change this for any arch (read it: support either one
> or
> the other technology) as long as the decision is taken by the technical
> committee. As I wrote before, we will keep the status quo, so if anyone is
> interested in any change feel free to contact the TC.
>
> Regards, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Upcoming Qt switch to OpenGL ES on arm64

[Alan Corey]

Try glxgears and es2gears on few different platforms.  On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower.  On my Rock64
it's in the hundreds of FPS but that's Mali.  Look at omxplayer, full
screen HD video while the CPU idles (on a Pi).  The GPU is more
capable than the CPU.  You can do software-emulated OpenGL on
anything, the question is how efficient it is.

On 11/26/18, bret curtis  wrote:
> Hello Ian,
>
> On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell  wrote:
>>
>> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
>> > The hardware that supports GLES also supports OpenGL because GLES is
>> > a subset of OpenGL.
>>
>> I'm confused by this inference. If GLES is a subset of OpenGL then
>> surely hardware which claims to implement GLES is at liberty to only
>> implement that subset and would therefore not necessarily support
>> OpenGL.
>>
>> Ian.
>>
>
> I believe this is a purely a driver/firmware distinction. So whoever
> implements this is at liberty to do whatever they want so long as the
> hardware supports it.
>
> Meaning that if something advertises GLESv2 support then it has, at
> least, OpenGL 2.0 support in hardware because without that, they
> couldn't have supported GLESv1.
>
> GLES1.1 is fixed-function pipeline that is compatible with OpenGL 2.0,
> you're not going to create hardware to support GLES1.1 that doesn't
> also support at least OpenGL 2.0
>
> GLESv2 is another beast, it dropped fixed-function pipeline because
> that was the spec, but it is still a software implementation and
> doesn't mean that it no longer exists in hardware.
>
> Take for example the Nvidia Tegra:
> https://opengles.gpuinfo.org/displayreport.php?id=690  <-- SHIELD
> Android TV which happens to be a Tegra SoC  supports OpenGL ES 3.2
> https://opengl.gpuinfo.org/displayreport.php?id=2377  <-- Tegra as
> integrated with CPU (nvgpu), supports OpenGL 4.6.0
>
> Similar (if not the same?) hardware, running aarch64, the only real
> difference is the driver.
>
> That being said, I would love to hear from someone who actually makes
> these things to comment. It is entirely possible that there is a chip
> out there that supports GLES 3.2 and only that in hardware. I would be
> amazed but I'm reluctant to ever use the words never and ever. So far,
> the hardware that supports that are[1]:
>
> Adreno 420 and newer
> AMD GCN-architecture
> Intel HD Graphics Skylake and higher
> Mali-T760 and newer
> Nvidia GeForce 400 series (Fermi)
>
> As I said, I would be amazed if these GPUs didn't support some minimal
> version OpenGL in hardware. As I said elsewhere, most free and
> open-source drivers (mesa) support both some version of GLES along
> with some version of GL. [2]
>
> Cheers,
> Bret
>
>
> [1] https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_3.2_2
> [2] https://mesamatrix.net/
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Is there a way to make the pi use swap?

[Alan Corey]

Even this Android phone has it set to 100 by default. Funny, in the BSDs I
think it's more like swap strategy.

apropos helps sometimes but can't help if your man pages are incomplete.
At least you quickly find out if you misspelled apropos.

Then Google (or ducky).  Googling error messages is also useful.

Sent from my Motorola XT1527

On Mon, Sep 17, 2018, 4:17 AM Ian Campbell  wrote:

> On Mon, 2018-09-17 at 09:18 +0200, Philip Hands wrote:
> > Gene Heskett  writes:
> > > And pray tell, where does one set that swappiness?
> > > Sounds like something that could be handy.
> >
> > When wondering that sort of thing, I generally try this sort of command
> > to find out:
>
> Or one could try, for example:
>https://www.google.com/search?&q=linux%20swapiness
> (which works even though I seemingly can't spell swappiness!)
>
> It turns out there is a full-on wikipedia article on it, with links to
> the documentation in the kernel source and everything...
>
> Ian.
>
>

Re: Is there a way to make the pi use swap?

[Alan Corey]

Make sure you have rootwait in your cmdline.txt.  Just that word.  It tells
the kernel to wait for a drive to spin up if needed.  I had several nasty
hard crashes requiring repowering the Pi without it.  It would swap
something out and expect to read it back instantly.  Meanwhile the drive
had gone to sleep. Happened .most with memory hogs like Firefox and Gimp
running when I'd walk away for >10 minutes.  With an SD card in a USB
reader too, not just the hard drive. Maybe it's the Pi USB.  I was in chat
with Startech tech support a bunch until I tried the drive on an i386
machine and it didn't happen. I try to not leave it mounted though.


Sent from my Motorola XT1527

On Sat, Sep 15, 2018, 9:20 AM Gene Heskett  wrote:

> On Friday 14 September 2018 23:36:27 Gene Heskett wrote:
>
> > On Friday 14 September 2018 23:12:35 Alan Corey wrote:
> > > Yeah, vmstat shows me
> > >
> > > procs ---memory-- ---swap-- -io -system--
> > > --cpu- r  b   swpd   free   buff  cache   si   sobi
> > > bo in   cs us sy id wa st 0  1 423424  43348  16380 21282800
> > > 6 632  8  1 92  0  0
> > >
> > > Do you have the sw field in your fstab?
> >
> > Do now, its down below but TLDR, so copied it again.
> >
> > > /var/swap2 none swap sw 0 0
> >
> > That's a swap"file". Using it is hard on the u-sd card. This swap is
> > on a 300 meg/sec 120GB SSD. Ought to be 50x faster, making it
> > semi-usable.
> >
> > > By the fsstab man page it's the type of the file system.  Or maybe
> > > not.The last 2 numbers have to do with dump/restore and fsck.
> >
> > Which don't apply to swap, so they could be removed.
> >
> > New line in etc/fstab that works for swapon -a now is:
> >
> > UUID=7b06d9bc-18f2-4c25-957d-f426141664b3 none swap defaults,nofail 0
> > 0
> >
> > I nuked the /var/swap file, so we'll see how amanda works in 4 or 5
> > hours.
> >
> > Thanks Alan.
>
> Worked fine, shows amanda used a meg of that swap, with nothing left in
> the si/so columns. Tonight I'll leave LCNC running for S&G.
>
>
> --
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>

Re: Is there a way to make the pi use swap?

[Alan Corey]

Yeah, vmstat shows me

procs ---memory-- ---swap-- -io -system-- --cpu-
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 0  1 423424  43348  16380 21282800 6 632  8  1 92  0  0

Do you have the sw field in your fstab?
/var/swap2 none swap sw 0 0
By the fsstab man page it's the type of the file system.  Or maybe
not.The last 2 numbers have to do with dump/restore and fsck.

On 9/14/18, Gene Heskett  wrote:
> On Friday 14 September 2018 21:39:02 Alan Corey wrote:
>
>> I don't know about that, I think it's the same in the BSDs and they
>> don't have udev.  It's maybe more memory than file.
>>
>> vmstat should show it, and I think there's a swapctl, but those are
>> optionally installed things.
>>
> vmstat seems to be installed, but the system is inactive except
> for a pair of ssh -Y logins from me. It reports:
> $ vmstat
> procs ---memory-- ---swap-- -io -system--
> --cpu-
>  r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id
> wa st
>  2  0  0 605904  34156 1728240014 0  723  539  0  5 94
> 0  0
>
> This in spite of htop saying theres 999 megs of swap available. So the
> above
> needs a good manpage read to decode it. The 0 0 bothers me. Its supposed to
> take an optional delay 10 for and infinite number of updates at 10 second
> intervals, but barfs of the delay keyword. Lotta help that is.
>
> swapctl can't be found.
> pi@picnc:~ $ sudo apt install swapctl
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package swapctl
>
>> If you use Firefox you probably need it:
>> KiB Mem :   949444 total,30988 free,   678588 used,   239868
>> buff/cache KiB Swap:  4538548 total,  4113588 free,   424960 used.
>> 248532 avail Mem after 6 days of uptime
>
> firefox is  not installed.
>
>> On 9/14/18, Gene Heskett  wrote:
>> > On Friday 14 September 2018 20:56:28 Gene Heskett wrote:
>> >> On Friday 14 September 2018 20:16:32 Alan Corey wrote:
>> >> > My /etc/fstab just has
>> >> >  /var/swap2 none swap sw 0 0
>> >> > That's for a swap file which was made by dding 0s into it, then
>> >> > running mkswap.
>> >> >
>> >> > You'd replace /var/swap2 with /dev/sda2
>
> I just nuked the swapfile in /var. We'll see what amanda does to
> the swap in the morning. ;-)
>
>> >> > Sounds like you're just not loading it from your fstab.  Should
>> >> > load every boot.  Nothing new or tricky there.
>> >>
>> >> I found an error in the line above that in fstab, # it out.
>> >> Using htop as a swap monitor I can make the swap come and go.
>> >>
>> >> Heres the fstab now:
>> >>
>> >> proc/proc   procdefaults
>> >>  0   0 PARTUUID=4fb6ef8f-01/boot   vfat
>> >> defaults0   2 PARTUUID=4fb6ef8f-02/
>> >>ext4defaults,noatime  0   1 # but lets see if a swap can
>> >> be made to work
>> >> PARTUUID="000ba889-02"  noneswap
>> >> defaults,nofail 0   0 #/dev/sda2  noneswapsw,nofail
>> >> # a swapfile is not a swap partition, no line here
>> >> #   use  dphys-swapfile swap[on|off]  for that
>> >> LABEL=bootpi/media/boot vfatdefaults
>> >>  0   2 LABEL=workpi1   /media/slashext4
>> >> defaults,noatime0   1 LABEL=backuppi  /media/backupsd
>> >>ext4defaults,noatime0   1 LABEL=workpi120
>> >> /media/work ext4defaults,noatime0 1
>> >>
>> >> But it doesn't show in a mount, nor does it show in a cat
>> >> /etc/mtab:
>> >>
>> >> /dev/root / ext4 rw,noatime,data=ordered 0 0
>> >> devtmpfs /dev devtmpfs
>> >> rw,relatime,size=468264k,nr_inodes=117066,mode=755 0 0 sysfs /sys
>> >> sysfs rw,nosuid,nodev,noexec,relatime 0 0
>> >> proc /proc proc rw,relatime 0 0
>> >> tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
>> >> devpts /dev/pts devpts
>> >> rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs
>> >> /run tmpfs rw,nosuid,nodev,mode=755 0 0
>> >> tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0
>>