Re: Raspberry Pi: gpiomem device support

[gene heskett]

On 4/3/24 18:36, Hank Barta wrote:
I'm not sure if this will help. I explored GPIO on Debian a bit and 
posted my code at https://github.com/HankB/GPIOD_Debian_Raspberry_Pi 
<https://github.com/HankB/GPIOD_Debian_Raspberry_Pi>


I have NDI if its usable for you, but linuxcnc for the pi's has a driver 
module intended for the mesa 7i90HD & similar interface boards, which 
can be configured for high speed spi interfacing that talks spi over 3 
gpio pins, talking to the 7i90HD in 32 bit packets at 42+ megabaud, and 
gets 32 bit status packets back from the 7i90HD card at 25 megabaud.
Been rock solid thru rpi3b/rpi4b's to run by late WW-II vintage 11x54 I 
converted to lcnc nearly a decade back just to see if I could do it, 
teaching my old lathe all the new dances that come with linuxcnc. The 
limits of what it can do today is limited only by your imagination.

best,

On Wed, Apr 3, 2024 at 12:42 AM Thomas Lehmann 
mailto:lehmann-56d5e%2b...@posteo.de>> wrote:


Good Day!

I've tried to get GPIO access working on 1B (Raspberry Pi B+) images
from [1], however, the "/dev/gpiomem" device is missing and access to
"/dev/mem" (some libaries fall back to that device) is denied (even as
root, and I don't even want to use "/dev/mem").

Searching the internet brough up some udev rules. So I tried thse
without success:

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
KERNEL=="gpiomem", GROUP="gpio", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", KERNEL=="gpiomem", GROUP="gpio",
MODE="0660"

I later found /lib/udev/rules.d/60-rpi.gpio-common.rules and added
these
rules. Also no success.

I can't find "gpiomem" in the kernel config.

In the official Raspberry Pi repository there once was a request [2] to
enable a kernel config "CONFIG_BCM2835_DEVGPIOMEM". This module was
apparently replaced by something called "raspberrypi-gpiomem" in commit
27543eeff4553f5caf7c6d8763c566042b047af0. Interestingly I can't find
that phrase in any other commit in their repo.

(Note: I'm aware that Debian does not refer to the Raspberry Pi [2]
repo, this just came up in my research.)

    To me there seems to be kernel support missing or a config is not set.

Can someone please clarify on this?


Thank you.

Best regards,
Thomas.



--
Beautiful Sunny Winfield


Cheers, Gene Heskett, CET.
--
"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

Re: Ability to further support 32bit architectures

[gene heskett]

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 <mailto: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

Re: What to do with d-i on armel?

[gene heskett]

On 1/9/24 17:22, Martin wrote:

On 2024-01-09 19:56, Emanuele Rocca wrote:

though. Any armel users out there? :-)


My employer uses Debian on armel, but not d-i :-)

.
3d printing environment relies heavily on whatever runs the rp2040. A 
whole industry has grown up around the combo of the adxl345 and an 
rp2040 to measure resonances and tune them out, allowing the printer to 
run several times faster with what is called "input shaping"  The actual 
device is about the size of a postage stamp on a teeny pcb. I do not 
know which version of linux it is that the rp2040 is actually running. 
For us, its one of those things that Just Works.


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

Re: Can't connect Raspberry Pi 3B+ Rev. 1.3 to Wifi 5G

[gene heskett]

On 11/17/23 11:28, basti wrote:

Hello,

i have a Raspi 3B+ and try to connect to WIFI 5G.

The Access Point is OpenWRT and operate in
AC mode, Channel 64 (5320 MHz).

On the pi side:

root@debian:~# cat /proc/device-tree/model ; echo " ";
Raspberry Pi 3 Model B Plus Rev 1.3
root@debian:~# iwlist wlan0 scanning| grep Freq
     Frequency:2.412 GHz (Channel 1)
     Frequency:2.437 GHz (Channel 6)
     Frequency:2.437 GHz (Channel 6)
     Frequency:2.462 GHz (Channel 11)
     Frequency:2.462 GHz (Channel 11)
     Frequency:2.462 GHz (Channel 11)

root@debian:~# iw reg get
global
country DE: DFS-ETSI
 (2400 - 2483 @ 40), (N/A, 20), (N/A)
 (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
 (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
 (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
 (5725 - 5875 @ 80), (N/A, 13), (N/A)
 (5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
 (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0
country 99: DFS-UNSET
 (2402 - 2482 @ 40), (6, 20), (N/A)
 (2474 - 2494 @ 20), (6, 20), (N/A)
 (5140 - 5360 @ 160), (6, 20), (N/A)
 (5460 - 5860 @ 160), (6, 20), (N/A)

There is no Wifi 5G found.
I have no idea what is wrong there.

Its been yonks since I retired my 3b, but I don't recall it having 5G in 
its radio, only the 2G 11 channel.  And I can't scan with the rpi4b that 
replaced it, nasty neighbor was stealing my bandwidth to the tune of 
80Gigs a month, so all radios are disabled here. Karma caught up to him 
and he did a year n the gov's economy hotel. His woman threw him out, 
but I've never bothered to turn my radios back on, lots more peaceful 
that way when you need a piece of cat6 to get into my machines.



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

Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection onarmhf/armel

[gene heskett]

On 10/27/23 09:30, Steve McIntyre wrote:

On Fri, Oct 27, 2023 at 03:23:10PM +0200, Emanuele Rocca wrote:

Hi Guillem,

On 2023-10-27 04:33, Guillem Jover wrote:

Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),


Correct, there has been no testing done on armeb/arm64ilp32 as far as
I'm aware. I'd suggest enabling the feature only on armhf/armel for the
time being.


Are either of those ports (armeb/arm64ilp32) actually useful / alive
at this point?

Another architecture you might consider adding is whatever is used in 
the banana-pi-m5 boards, its an improvement on the rpi4b, without the 
radio, and with all 4 usb ports running at usb3 speeds. With a 4 core 
arm64 running at 2GHz, so its a bit faster than the rpi4. With spi 
support, it would make a great replacement for the rpi4b. At under $90 
USD. Currently running ubuntu-jammy based distro in arm64 flavor, called 
armbian. And running several 3d printers here. Good stable boards.


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

need a gparted clone that works as root

[gene heskett]

Wayland don't let it run and I need a partitioner.
??
Tnx
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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Just tried arm64 netinstall on a bananai-m5

[gene heskett]

On 8/20/23 05:40, Marco d'Itri wrote:

ghesk...@shentel.net 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?

As explained, this board is not supported by the Debian Installer and it
will probably never be since it requires a custom u-boot with
binary-only parts.

But if you recover the u-boot from an Armbian image then you can still
install plain Debian:

https://blog.bofh.it/debian/id_466


That probably works, but is a long & complex procedure for some not 
intimately fam with uboot. + I'm already using mmcblk1p1 for other 
purposes. Also the current jammy does not have the udev bug debian has 
said will not be fixed until the release /after/ trixie.  Thats 
unfortunate because it disables many 3d printers from running the better 
klipper instead of marlin. klipper for errorless com demands the 
/dev/serial/by-id, matching the chipmakers SN to the exact board.


Armbian Jammy Just Works here and has been for months, where/what is the 
uboot bug mentioned in that blog? In this case, details matter, a lot.


Thank you.


(As long as you do not care about the SD card reader, at this point.)






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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Just tried arm64 netinstall on a bananai-m5

[gene heskett]

On 8/15/23 15:52, Marcin Juszkiewicz wrote:

W dniu 15.08.2023 o 20:57, peter green pisze:

On 15/08/2023 17:44, gene heskett wrote:



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

It is not "U-Boot versus UEFI" problem.

The problem is SBC vendors who go with "Shitty Bargain Crap" explanation 
of acronym instead of "Small Board Computer" one.


When you have SBC without any on-board storage for boot firmware 
(nevermind is it U-Boot, UEFI, Barebox or whatever) then you need to 
provide (usually) microsd with firmware stored at some magical places.


One of solutions then is to make microsd card with firmware, put it into 
a slot and forget that microsd slot exists. Then you can plug USB stick 
with Debian installer (just "dd if=debian.iso of=/dev/usbstick") and boot.


This is how raspberry/pi 1/2/3 and several other SBC work.

That is an option I've not been advised of, I'll get some usb keys and 
try it. Thank you.

.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Just tried arm64 netinstall on a bananai-m5

[gene heskett]

On 8/15/23 14:57, 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.


All no doubt true. But once this board is booted, its 20% faster than 
any pi, but doesn't have, and I don't need, a wifi radio.  And every usb 
port is usb3.

\
Thank you Peter Green.


.

.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Just tried arm64 netinstall on a bananai-m5

[gene heskett]

On 8/15/23 14:53, Vagrant Cascadian wrote:

On 2023-08-15, 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?


Hard to say based on so little information...

My wild guess is the Armbian-jammie-full-desktop iso includes boot
firmware.


unk to me


Do you have a URL to the exact image you used?
The most recent build, 12-1 of the arm64 menu on debians quite confusing 
web page. I didn't bookmark the URL


Do you have any output from the serial console when trying to boot the
Debian image? Armbian?

debian-12.1.0-arm64-netinst.iso
Armbian_23.5.1_Bananapim5_jammy_current_6.1.30.img


The only way what you did might work is if you have boot firmware
present on some other media (e.g. SPI, eMMC, etc.) that implements EFI,
such as edk2/tianocore or u-boot.

I take it that debian is not ready to boot on just any old arm64. So 
while I've installed about 4 more gigs of jammie, I have yet to see a 
gui package manager because its usung wayland and wayland doesn't allow 
anything needing root. wayland will have arrived when we have a gui 
based package manager that unlike aptitude, speaks english. Something 
that tells us whats its going to do BEFORE it does it.


So what I am in the midst of doing, is with the huge amount of trash 
installed, used gparted for partition and label the 16Gb emmc that it 
not used into something I can save the working network stuff to, saved 
it all and will now start with a new card with the bare jammie on it, 
boot that, mount the 16G emmc, restore the networking stuff reboot and 
continue my search for enough stuff including xorg & nginx, to run a 3d 
printer with kiauh handling that install on a system that is not 
contaminated with the 800 pkgs gnome pulled in.



live well,


I have indeed done that for 88 years.  I wish I had room left in the wet 
ram for half of what you've done.  Thank you, a lot.



   vagrant


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
Genes Web page <http://geneslinuxbox.net:6309/>

Just tried arm64 netinstall on a bananai-m5

[gene heskett]

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?

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

[gene heskett]

On 7/21/23 09:19, Theodore Ts'o wrote:

On Fri, Jul 21, 2023 at 06:14:04PM +1000, Finn Thain wrote:


I'm not blaming the unstable API for the bugs, I'm blaming it for the
workload. A stable API (like a userspace API) decreases the likelihood
that overloaded maintainers have to orphan a filesystem implementation.


You are incorrect.  The HFS file system has gotten zero development
attention and the bugs were not the result of the API changes.  The
main issue here is that the HFS file system does not have maintainer,
and decreasing the workload will not magically make someone appear
with deep knowledge of that particular part of the code base.

It's also the case that the actual amount of work on the "overloaded
maintainers" caused by API changes is minimal --- it's dwarfed by
syzbot noise (complaints from syzbot that aren't really bugs, or for
really outré threat models).

API changes within the kernel are the responsibility of the people
making the change.  For example, consider all of the folio changes
that have been landing in the kernel; the amount of extra work on the
part of most file system maintainers is minimal, because it's the
people making the API changes who update the file system.  I won't say
that it's _zero_ work, because file system maintainers review the
changes, and we run regression tests, and we sometimes need to point
out when a bug has been introduced --- at which point the person
making the API change has the responsibility of fixing or reverting
the change.

An unstable API are much painful for out-of-tree kernel code.  But
upstream kernel developers aren't really concerned with out-of-tree
kernel code, except to point out that the work of the people who are
promulgated out-of-tree modules would be much less if they actually
got them cleaned up and made acceptable for upstream inclusion.

- Ted

A much more sensible answer.  Thank you Ted.


.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

[gene heskett]

On 7/21/23 04:31, Finn Thain wrote:

On Fri, 21 Jul 2023, Matthew Wilcox wrote:



You've misunderstood.  Google have decided to subject the entire kernel
(including obsolete unmaintained filesystems) to stress tests that it's
never had before.  IOW these bugs have been there since the code was
merged.  There's nothing to back out.  There's no API change to blame.
It's always been buggy and it's never mattered before.




My oar in this resembles a toothpick.

That does change the complexion of this problem quite a bit. So the 
folks in charge should first, find out how many actual users of it there 
are considering the last commit was roughly a decade after the last 
machine was built, and from my experience with them which forced a fire 
extinguisher in every edit bay containing a pair of them, their survival 
rate might total to 10 on this pale blue dot.


The rest have had a fan fail, which started a fire and they wound up in 
the dumpster.  If by some stroke of good luck, there are more, work out 
a backup that can be recovered on some other known good filesystem, 
advise the users of the existence of that method of updating to a newer 
filesystem, disco the old one and get a good nights sleep.


Frankly support for NTFS-3.51 if it exists, should also join the parade 
going out the door.  It's housekeeping had no problem deleting its main 
.dll. Much to M$ delight as at the time it was another $400 sale to 
restore the machine and anybody who asked about it was called a pirate 
by support.



I'm not blaming the unstable API for the bugs, I'm blaming it for the
workload. A stable API (like a userspace API) decreases the likelihood
that overloaded maintainers have to orphan a filesystem implementation.

.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian(not Raspbian)

[gene heskett]

On 4/16/23 04:01, Diederik de Haas wrote:

On Sunday, 16 April 2023 04:47:37 CEST Rick Thomas wrote:

I've got a Raspberry Pi 4B (4GB) with a DS3231 RTC module.  I can make the
combo work with Ubuntu and RaspberryPI-OS.  I'd like to try it with the
plain-vanilla Debian from <https://raspi.debian.net/tested-images/> but I
can't find instructions for activating the I2C and RTC hardware in that OS.


Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml in the kernel source
describes how one could use it ('compatible = "maxim,ds3231"' for DS3231).
I think you should make a DeviceTree Overlay, but I don't know how to do that.


The last time I made a realtime preempt kernel for an armhf, the 
makefile did that.  Std output from a make menuconfig, an rpi4b runs it 
just as if it doesn't know any better, has been since Feb 20, 2020.


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
Genes Web page <http://geneslinuxbox.net:6309/>

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

[gene heskett]

On 3/21/23 03:45, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 11:17:50AM +0800, 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.


Mostly, I wanted to understand the main alternatives and their level
of freedom. In an ideal world, I'd like every bit of software,
drivers, firmware, etc to be FLOSS. Pragmatically, I won't reject a
platform that is "less bad" than the amd64 I'd get from the store.

Thank you for the good overview!


For example, the RPi devices start the VideoCore GPU first,
proprietary firmware then starts the ARM cores, then starts the ARM
boot process.


Oh. So less good than I expected.


On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform,
other devices have less mainline Linux support or worse freedom
issues.


Mobile... let's say I consider this a different subject, sadly. we've
been having different projects for a long time (I remember OpenMoko /
GTA0x, also some early Compaq PDAs??) but IMO nothing I can use in
daily life. I have a Librem 5, I ordered it... I think in 2017. I
don't consider it usable for daily life, at least "out of the box +
install available OS upgrades".


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.


Yes, I've been excited about it since they started; recently I took a
look at
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon
they say "somewhere between x86 PCs and a libre-first system like the
Talos II in terms of freedom to replace firmware and boot components;
while a number of blobs are required in order to boot the system, none
of those have the ability to take over the OS or compromise it
post-boot", but also:

  * Brick recovery / total system flash (DFU) requires phoning home

Which I understand an Apple account, tying the hardware to the Apple
account, and Apple's permission to do a "total system flash". Err...
feels like jumping out of the frying pan into the fire?


Otherwise Lenovo and other vendors have some ARM laptops.


Oh, I'll try to find them.


Or there is the PineBook or MNT Reform for more esoteric devices.


The PineBook shop page explicitly says "don't order if you are looking
for a substitute for your x86 laptop" :-|



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.


"Some work", like submitting patches to fix that-or-that package for
the architecture, yes, that's part of FLOSS developer / enthusiast
life, and I'd probably enjoy the work. Even running a buildd, if
that's what lacking. But I don't want it to be the majority of my
"free software time" either. And I need a machine that works to do the
work, obviously.

.
If I can chime in here, the 3d printer world has embraced the arms quite 
well. I have a half assembled voron kit, comes with an orange pi to run 
klipper and octoprint. And I am also running the same recipe on a 4 pack 
of banana pi m5's, with 4G of dram, using the armbian version of 
bullseye. The only failures so far have been the gnome screenblanker and 
printing to cups shared printers. The bpi is a 4 core running at 2 ghz 
and otherwise runs everything else nicely.


Adding a $5 pi case, and a separate 5 volt 5 amp supply, it runs a 27" 
hp monitor just as well as this asus mobo with 32g of dram and a 6 core 
i5.  The big monitor actually costs a little more but a working system 
here was about $240. And stability? Power failure to power failure has 
been my experience. A ups and a standby in the back yard that makes 
power failures an 8 second thing renders that moot.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: what is codium?

[gene heskett]

On 1/19/23 06:24, RobJE wrote:

On 19-01-2023 11:36, gene heskett wrote:

I see it being updated on my banana pi m5's, but it has no man page.
Its apparently not an editor, so what is it?


without knowing the details of the installed OS, etc. my first guess 
would be the open-source version of vscode aka vscodium



Thanks.

Cheers, Gene Heskett.


GRTNX,
Rob J. Epping

.
Uptodate armbian, your sid for arm64's these days. And Marlin for 3d 
printers indicates vscode is the preferred build tool. I refuse to 
contaminate my system with M$ code.


So I've not been successful at building marlin with the tools available, 
besides klipper is a better tool, and I've been able to build klipper 
dozens of times using platform.io. If its supposed to be an opensource 
version of visual studio, whyintunket does it not say so?  Boggles my 
mind.  Needs a real manpage for starters.


Thank you Rob. Take care and say well.

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
Genes Web page <http://geneslinuxbox.net:6309/>

what is codium?

[gene heskett]

I see it being updated on my banana pi m5's, but it has no man page.
Its apparently not an editor, so what is it?

Thanks.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Help with testing u-boot!

[gene heskett]

On 12/29/22 05:06, Vagrant Cascadian wrote:

On 2022-12-29, gene heskett wrote:

On 12/28/22 19:17, Diederik de Haas wrote:

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)

...

But a bpi m5 makes no attempt to boot it green led remains dim
forever.


Presuming you mean bananapi-m5, it is not enabled yet in the Debian
packages of u-boot...


I can mount it in my reader, a iso-9660 and its not a u-boot, its
grub. So which of the arm64 iso's is u-booter?


None of the debian-installer iso images contain u-boot. They only work
with systems with EFI firmware installed (which, somewhat confusingly,
u-boot could provide in some cases).

U-boot is board-specific, so a single image will almost never support
booting more than a very small number of systems.

Supported debian-installer platforms that have at some point in history
been tested to work are:

   https://d-i.debian.org/daily-images/arm64/daily/u-boot/

There are SD card images you can build, see the
README.concatenatable_images at:

   https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

You can typically using the firmware.none.img and manually add
u-boot. Which offsets to write to are board-specific, though there are
often common patterns for various board families (e.g. sunxi SoCs mostly
have the same offsets, rockchip SoC mostly use same offsets)...


The bananapi-m5 appears to be amlogic based, and there are a few other
amlogic based boards enabled in Debian's u-boot-amlogic package, but
unfortunately they require quite a few extra hoops to jump through that
make it difficult for Debian to ship images that you can just write to
boot media.

There are hints at fixing part of the problem at
u-boot.git/doc/board/amlogic/libretech-cc.rst:

   Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
   source code. Should you prefer to avoid that, there are open source reverse
   engineered versions available:
   
   1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy

  Makefile that automates the whole process.
   2. meson-tools <https://github.com/afaerber/meson-tools>
   
   However, these community-developed alternatives are not endorsed by or

   supported by Amlogic.


live well,
   vagrant
You too. I did find out the dfu problem is the robin nano boards, I 
cloned the gitub version 0.11, built and installed it on the bpi5 only 
to get the exact same failure message, finding in an old old klipper 
config that dfu didn't work on robin nano boards but they also have a 
recipe to upload to a nano.  But that build is for the wrong mcu.


but the klipper board files are even older than Marlins so I'm still 
screwed.


Thanks Vagrant.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: armbian for arm64's is 99% debian testing for arm64's.

[gene heskett]

On 12/28/22 22:41, Jeffrey Walton wrote:

On Wed, Dec 28, 2022 at 4:17 PM gene heskett  wrote:


But its dfu-util is truly ancient at version 0.9
version 0.10 has been available for several years if I read ticket dates
on sourceforge correctly.

dfu-util-v0.9 on a banana pi m5, cannot do any dfu-utils duties. sudo
dfu-util -l only lists the authors, no dfu capable devices on the bpi5

Where can I get version 0.10? Or 0.11 if that is out?


The search results for "armbian package search" suck. The only hit is
a static page at https://www.armbian.com/kernel/ .

An 'apt-cache show dfu-util' shows some information, but not the
upstream source code repository.

It looks like Debian's dfu-util package page at
https://packages.debian.org/bullseye/dfu-util says
dfu-util.sourceforge.net, but I am not sure how accurate it is for
Armbian. The Sourceforge pasy says the current release is 0.11.

Jeff
.
I'm the OP and what is in the recent armbian they claim is debian 
testing is 0.9, years old, and apparently hasn't a clue how to work with 
usb-3 ports like the bpi5 has 4 of. Yet octoprint works just fine thru 
the same port and cabling. Mutter.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Help with testing u-boot!

[gene heskett]

On 12/28/22 19:17, Diederik de Haas wrote:

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)

# arm64
...
rock64-rk3328


I don't recall ever having issues with u-boot on my Rock64's, so for me
2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I generate my own images for Rock64 and that uses 'dd ... seek=' of
idbloader.img and u-boot.itb from the u-boot-rockchip package.
I have been doing that since 2021-03, so it's very likely that I haven't seen
an issue since then.

HTH,
   Diederik


Humm, I thought I'd see if dfu-util-0.11 worked so I just pulled the 
arm64 daily netinstall iso and put it on a u-sd card. But a bpi m5 makes 
no attempt to boot it, green led remains dim forever. I can mount it in 
my reader, a iso-9660 and its not a u-boot, its grub. So which of the 
arm64 iso's is u-booter?


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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: armbian for arm64's is 99% debian testing for arm64's.

[gene heskett]

On 12/28/22 16:27, John Paul Adrian Glaubitz wrote:

Hello Gene!

On 12/28/22 21:59, gene heskett wrote:

But its dfu-util is truly ancient at version 0.9
version 0.10 has been available for several years if I read ticket 
dates on sourceforge correctly.


dfu-util-v0.9 on a banana pi m5, cannot do any dfu-utils duties. sudo 
dfu-util -l only lists the authors, no dfu capable devices on the bpi5


Where can I get version 0.10? Or 0.11 if that is out?


Both Debian testing and unstable have 0.11, so you might want to update 
your

system to Debian testing or ask the maintainer to make an upload to Debian
Backports for Debian bullseye.

Adrian

I have 4 of the bpi5'd and I know how to run dd. Will the weekly work on 
a bpi5, gradually becoming bookworm if kept up to date?


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
Genes Web page <http://geneslinuxbox.net:6309/>

armbian for arm64's is 99% debian testing for arm64's.

[gene heskett]

But its dfu-util is truly ancient at version 0.9
version 0.10 has been available for several years if I read ticket dates 
on sourceforge correctly.


dfu-util-v0.9 on a banana pi m5, cannot do any dfu-utils duties. sudo 
dfu-util -l only lists the authors, no dfu capable devices on the bpi5


Where can I get version 0.10? Or 0.11 if that is out?

Thanks.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: how to enable spi on Raspberry Pi 4 (bookworm)?

[gene heskett]

On 10/30/22 13:05, Sebastian Kuzminsky wrote:

On 10/25/22 12:03, Sebastian Kuzminsky wrote:
I'm using the 2022-08-08 bookworm rpi4 image from 
<https://raspi.debian.net/tested-images/>, it's got linux-image-arm64 
5.18.14-1 and raspi-firmware 1.20220331+ds-2.


It's working great, except I can't use the SPI devices.

SPI works on same hardware when running Raspbian's Buster image, 
after running "dtparam spi=on" (or adding "dtparam=spi=on" to the 
firmware config.txt file).


Raspbian Buster's dtparam program is not available on Debian Bookworm.

On Raspbian it comes from the libraspberrypi-bin deb, which is made 
from the raspberrypi/firwmware git repo on github (the same repo that 
supplies all the dtb files in /boot).  dtparam and the other programs 
there are provided in binary form (for armhf), not source :-(


I don't have this working yet but I've made a little bit of progress.

The Raspbian Buster armhf binaries can be made to run on Debian 
Bookworm arm64 with a little bit of coaxing, but they rely on kernel 
features that are not in Bookworm's arm64 kernel, so that's a bit of a 
dead end.


I then tried editing the dtb directly:

I "decompiled" the dtb `/boot/firmware/bcm2711-rpi-4-b.dtb` into an 
editable dts with `dtc -I dtb -O dts $DTB > $DTS`.


I edited the dts to change the spi0 "status" field from "disabled" to 
"ok".


I "compiled" the edited dts with `dtc -I dts -O dtb $DTS > $DTB`.

I then replaced the old dtb with the new one and rebooted.

The spi port seems to be present/enabled now: dmesg includes 
"spi-bcm2835 fe204000.spi: no tx-dma configuration found - not using 
dma mode", and /sys/bus/platform/drivers/spi-bcm2835/fe204000.spi 
shows up.


But something is still wrong, there are still no /dev/spi* device 
files like i get with Raspbian Buster.


So I'm closer, but I'm still missing something.  The quest goes on!


Bored, I tried my make-debs script on the rpi4b running buster rasppios 
today, but it bailed out with can't find

Documentation.de error.

Is there anything I can do?

Thanks Sebastian Kuzminsky. Take care & stay well.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: rock64's dead w/update, have latest bannana pi's coming

[gene heskett]

On 10/28/22 03:00, Tobias Frost wrote:

On Thu, Oct 27, 2022 at 01:55:16PM -0400, gene heskett wrote:

Greetings all;

My 3d printer farm is out of business, all the rock64's died, as in no hdmi
video anymore, and the rock64's weren't
that great due to extreme interference between the video and usb activity. I
can still log into them and can run
stuff from here, but its a bit useless to try and run a 3d printer from out
of sight 3 rooms away.

So I have a question for your arm folks, as I have a 4 pack of the latest
4gig bannana pi's on order.

FWWIW, I do run octoprint on a BananaPI (older 1GB model, don't recall the exact
modell, but I *think* it is an BananaPI BPI-M1
  

Can it can now run an xfce4 desktop, just like an rpi4b, giving good video
for octoprint?

I'm not using a DE on the banapi, I login remotely to octoprint from another
machine or using OctoRemote on Android.

If it can, a URL for the latest image would be very appreciated.

Not sure what you mean with image. AFAIC there is no "octopi-style, ready to
run" image for the BananaPi.  /me installed it ages ago, and IIRC I used a
Debian installer for that.  Said that, I'm not sure what BananaPi you are
getting, but https://wiki.debian.org/InstallingDebianOn/Allwinner lists a few,
and a few as
marked as "unsupported bootstraping."

I found, late last night, that I had a newer image, not based on ubu's 
jammy, but on our sid!
And it works! so one printer is about ready and the 2nd one is busy 
updating 618 pkgs right now.
The  bananna pi's I was asking about are BPI-M5's, 4 gigs of dram. All 4 
usb sockets are blue! $89

from amazon.

Thanks Tobias, take care & stay well.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: rock64's dead w/update, have latest bannana pi's coming

[gene heskett]

On 10/27/22 20:31, gene heskett wrote:

On 10/27/22 14:21, Andrew M.A. Cater wrote:

On Thu, Oct 27, 2022 at 01:55:16PM -0400, gene heskett wrote:

Greetings all;

My 3d printer farm is out of business, all the rock64's died, as in 
no hdmi

video anymore, and the rock64's weren't
that great due to extreme interference between the video and usb 
activity. I

can still log into them and can run
stuff from here, but its a bit useless to try and run a 3d printer 
from out

of sight 3 rooms away.

So I have a question for your arm folks, as I have a 4 pack of the 
latest

4gig bannana pi's on order.


No idea: probably.

Can it can now run an xfce4 desktop, just like an rpi4b, giving good 
video

for octoprint?

https://github.com/radxa/debos-radxa/releases/download/20220820-0621/rockpi-4b-debian-bullseye-xfce4-arm64-20220820-0811-gpt.img.xz 


If it can, a URL for the latest image would be very appreciated.

That's the image from Radxa - you are on your own. No idea about 
octaprint

or whether you'll have to compile/build that for yourself.

Although Debian has various images for rk3399 = 
http://ftp.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/


I've no idea whether any of these will work. As ever, this *isn't* 
Debian and

any support any of us can give is only best endeavours at best.
thanks Andy.  From the Readme , it sounds like I ought to be able to 
concoct something. OctoPrint is all python, and runs
in a python venv as if its on a real pi. So If I've good video on the 
reboot, I should be in high clover.


When the bananna pi's get here, middle of next month.

Thank you.

In the meantime, I found I had a slightly newer armbian xz, put it on 
the u-sd and just now made the
network work again. The other one was based on ubu's jammy, This ones on 
our sid. Video is still noisy
as can be, but its running. So in another day, I might get both going 
again.  That link to the rockpi version
wouldn't even try to boot on these old, original rock64's  They were new 
in 2016.


Thanks Andy.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: rock64's dead w/update, have latest bannana pi's coming

[gene heskett]

On 10/27/22 14:21, Andrew M.A. Cater wrote:

On Thu, Oct 27, 2022 at 01:55:16PM -0400, gene heskett wrote:

Greetings all;

My 3d printer farm is out of business, all the rock64's died, as in no hdmi
video anymore, and the rock64's weren't
that great due to extreme interference between the video and usb activity. I
can still log into them and can run
stuff from here, but its a bit useless to try and run a 3d printer from out
of sight 3 rooms away.

So I have a question for your arm folks, as I have a 4 pack of the latest
4gig bannana pi's on order.


No idea: probably.


Can it can now run an xfce4 desktop, just like an rpi4b, giving good video
for octoprint?


https://github.com/radxa/debos-radxa/releases/download/20220820-0621/rockpi-4b-debian-bullseye-xfce4-arm64-20220820-0811-gpt.img.xz
  

If it can, a URL for the latest image would be very appreciated.


That's the image from Radxa - you are on your own. No idea about octaprint
or whether you'll have to compile/build that for yourself.

Although Debian has various images for rk3399 = 
http://ftp.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/

I've no idea whether any of these will work. As ever, this *isn't* Debian and
any support any of us can give is only best endeavours at best.
thanks Andy.  From the Readme , it sounds like I ought to be able to 
concoct something. OctoPrint is all python, and runs
in a python venv as if its on a real pi. So If I've good video on the 
reboot, I should be in high clover.


When the bananna pi's get here, middle of next month.

Thank you.



Thank you all. Take care & stay well.

Cheers, Gene Heskett.

All the very best, as ever,

Andy Cater

--
"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
Genes Web page <http://geneslinuxbox.net:6309/>


.



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
Genes Web page <http://geneslinuxbox.net:6309/>

rock64's dead w/update, have latest bannana pi's coming

[gene heskett]

Greetings all;

My 3d printer farm is out of business, all the rock64's died, as in no 
hdmi video anymore, and the rock64's weren't
that great due to extreme interference between the video and usb 
activity. I can still log into them and can run
stuff from here, but its a bit useless to try and run a 3d printer from 
out of sight 3 rooms away.


So I have a question for your arm folks, as I have a 4 pack of the 
latest 4gig bannana pi's on order.


Can it can now run an xfce4 desktop, just like an rpi4b, giving good 
video for octoprint?


If it can, a URL for the latest image would be very appreciated.

Thank you all. Take care & stay well.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Building (Debian) kernel optimized for RPi Zero (W) and 1

[gene heskett]

On 10/23/22 16:31, Diederik de Haas wrote:

Hi,

Debian provides a kernel for Raspberry Pi Zero (W) and 1, but that targets
the armel architecture. I want to compile a/the Debian kernel that does use the
HW capabilities of the RPi 0/1, similarly to how raspbian.org recompiles
the Debian packages. Except AFAIK the Debian kernel.

I know that Debian won't change their RPi kernel for armel, but this is for
private use. But I don't know what the best way to go about that is.

I found the following link wrt building a cross compiler
https://solarianprogrammer.com/2018/05/06/building-gcc-cross-compiler-raspberry-pi/
which in turn references
https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
and that does look promising.

But before diving full into it, I'd like to know whether this is the proper
approach or not. And if someone has good/better links, I'd appreciate it if
you'd share them :-)

While I (technically) could setup a system to compile natively, I want to use
cross compilation (on amd64 PC). I think it would otherwise take days.
Probably an over estimate unless you don't have any SSD hardware for 
workspace.
 I do, 240Gigs on a startech usb to sata adaptor  and I have built an 
armhf version

of 4.19 in under an hour on an rpi4. Working on a u-sd card,
you'll be abusing the card and quite a few hours. I would not even try 
it on less than a 64G u-sd.

You'll surely kill an 8G u-sd card by writing it to death..

But knowing how to compile natively would be nice too.
I do know how to compile Debian's kernels, both natively and cross building.

Cheers,
   Diederik



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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 11:32, Lennart Sorensen wrote:

On Sat, Jul 16, 2022 at 08:41:07AM -0400, gene heskett wrote:

I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.

You said raspios which sure looks like raspian.  Raspian/Raspberry Pi
OS is armv6.  If you are running Debian armhf, then it is armv7 but it
would be a lot less confusing to call it Debian and not raspios in
that case.

raspian/raspios is available in all 3 flavors.

Doesn't matter what your kernel is.  What is your userspace you are
actually running?


The card its running on right now is over 2 years old, zero problems,
and has had all updates, including a daily update of linuxcnc from the
the buildbot, or if the buildbot is down, my own scripts also building
installable deb's. The secret is use a big enough card that it has enough
room to do its maintenance. 64G card has around 15G's on it.

Backups once in a while of the card is still nice to have.

True, but when those two seagate 2T drives puked in quick succession, I 
lost all

my patched amanda sources. I'd only been running amanda since 1998.
I figured if bullseye ever stabilizes I might see about starting it up 
again. But UM

sold it to zmanda so progress stopped, and then was sold to Betsol about 2
years back, and so far they've been all hat and no cattle. As far as I'm
concerned its time to look for a new backup strategy that mimics how amanda
worked. IOW I'm still building this box, almost from scratch. Its been 
very painful

so far with bullseye.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 10:33, Arnd Bergmann wrote:

On Sat, Jul 16, 2022 at 2:41 PM gene heskett  wrote:

On 7/16/22 08:10, Arnd Bergmann wrote:

- 4.19 is four years old, and both the mainline kernel and the
preempt-rt patches have changed a lot in the meantime. It's
possible that a current preempt-rt has regressed compared to
the version you are running. If so, we can work on fixing the
regression for future kernels, but there won't be much interest
in working on the old kernel

- Raspberry Pi OS (and Raspbian before that) has a number of
platform specific kernel patches that are neither in mainline
Linux nor in the Debian kernel packages. It is possible that they
have already identified and fixed a source of latency in their
kernels but not managed to upstream that fix for a number of
reasons.

Their kernels are uniformly horrible with latency's ranging to above a
millisecond.
Linuxcnc simply refuses to run on those kernels.

I think this is simply because raspbian does not ship any preempt-rt
kernel themselves, so clearly their kernel binaries won't be low-latency.

You did not say where  you got the kernel that you are running
successfully, so as far as I could tell this might be a combination
of the raspbian patches and the preempt-rt patches.\

I got this as 4.19.y, and applied the realtime patch kit. I've not been
able to find another kernel src any newer that even admits to having a
realtime preempt in its config, it is conspicuously absent in anything
newer, and I am subbed to linux-rt so I see all the new stuff being
announced. But the .configs have not included a realtime you can
see, let alone turn on. This particular 4.19.y was obtained from a git
link I was supplied by a forum msg, about a day before I was black holed.

I've been on my own since, several years now. It was me that figured
out how to build it, and it was me who figured out a way to install it.

Up until now, when I've asked arm questions here, I've essentially been
told to bug/buzz off. Which is why I made the comment about a civil 
discussion.
Its a surprise, and I certainly welcome it. I've never had the intention 
of being

a PITA.

What you've seen in the uname -a output I've posted was my 2nd build, the
first one was built when 4.19 was fairly new but the video was still 
slow, this

one was after some patches that enable the specific gfx these arms used. And
TBT, I was amazed that it actually worked both times. I had been led to 
believe
that stability was not in the arm vocabulary, but this is at least as 
solid as
wintel stuff has ever been. OTOH, wheezy was a giant step fwd in that 
department.


I can put that src tarball up on my web page, but 4.19.y s/b available 
at faster
servers. I've only a 10 megabaud adsl, meaning slow slow downloads from 
my site.


Take care & stay well.

- The raspbian user space should have very little effect on
 latency but it's worth pointing out that you may see different
 performance between armv6 (raspbian)

I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.

This paragraph was about the user space, not the kernel.

The entire reason for Raspbian's existence is that it runs on armv6
hardware like the Raspberry Pi 1, which Debian armhf does not
run on. Building for armv6 means they can run the same user space
on all hardware generations from v6 to v8, and they advertise this
on their website:
https://www.raspberrypi.com/software/operating-systems/
ship at least two separate 32-bit kernels, since an LPAE-enabled
kernel is needed to access PCI and high memory but is incompatible
with Armv6 hardware.

  Arnd
.



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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 08:10, Arnd Bergmann wrote:

On Sat, Jul 16, 2022 at 5:05 AM gene heskett  wrote:

On 7/15/22 21:54, Paul Wise wrote:

On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote:


Because our latency-test results are better on armhf than on arm64,
we use armhf for its performance.

Are these results for armhf kernel with armhf userland?

The whole install of raspios is armhf. So I guess its yes.


Are the results for arm64 kernel with armhf userland similar?

I have not tried to build an aarch64 from the src I have.

How much worse are the results for arm64 kernel and userland?

No, not exact, but its roughly 4x longer when I can get it to run,
as it did check for a realtime preempt kernel and did a graceful
exit if not found. So its not been run on 64 bit Debian image since
stretch.

There are unfortunately a number of variables here that make things
really hard to compare, any of these can have an effect that dominates
your results:

- 4.19 is four years old, and both the mainline kernel and the
   preempt-rt patches have changed a lot in the meantime. It's
   possible that a current preempt-rt has regressed compared to
   the version you are running. If so, we can work on fixing the
   regression for future kernels, but there won't be much interest
   in working on the old kernel

- Raspberry Pi OS (and Raspbian before that) has a number of
   platform specific kernel patches that are neither in mainline
   Linux nor in the Debian kernel packages. It is possible that they
   have already identified and fixed a source of latency in their
   kernels but not managed to upstream that fix for a number of
   reasons.


Their kernels are uniformly horrible with latency's ranging to above a 
millisecond.

Linuxcnc simply refuses to run on those kernels.

- A lot of kernel configuration options can have a huge impact
   on latency, it's not just preempt-rt that can be turned on or off,
   but any device driver that disables preemption for too long can
   increase the maximum latency of the system.

- The raspbian user space should have very little effect on
latency but it's worth pointing out that you may see different
performance between armv6 (raspbian)

I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.

and armv7 (debian
armhf), between vfpv3-d16 (raspbian and debian armhf) and
neon-d32 (fedora and others), and between a32 (raspbian),
t32 (debian armhf) and a64 (debian arm64), instruction sets
running the same code. In most applications the effect is very
small, and it's not always the same one that's fast either.


It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since.

Do you have your latency-test output available for reference
somewhere?

To establish a baseline, it would be good if someone could run
the same test using debian armhf userland on similar hardware
with this kernel:
https://packages.debian.org/bookworm/linux-image-rt-arm64

If that can reproduce the bad numbers you observed, the next
step would be to try a corresponding 32-bit kernel and see if
that is better, but that requires building a custom package.
There is a linux-image-rt-armmp package in bookworm, but to
get PCI and USB3 working on Raspberry Pi 4, one needs to
enable both the PCI driver and CONFIG_ARM_LPAE, possibly
more.


It is now in testing so those of you w/o 5 years of history to lose
could try it for the price of a 64G u-sd card.

For some reason, linuxcnc is still missing for armhf. I managed
to build the source package, which had a minor issue finding the
libboost_python310 dependency, but it worked after I added
that. I don't have the right system to test on myself though.

[Side note: I hope you are not storing any important data on an
  SD card. Even with "industrial grade" ones, I would recommend
  doing regular backups to more permanent storage, and the
  usual consumer cards are not designed to handle running a
  general-purpose OS at all and will cause data corruption over
  time]

The card its running on right now is over 2 years old, zero problems,
and has had all updates, including a daily update of linuxcnc from the
the buildbot, or if the buildbot is down, my own scripts also building
installable deb's. The secret is use a big enough card that it has enough
room to do its maintenance. 64G card has around 15G's on it.

Take care and stay well everybody.


   Arnd
.



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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 05:59, Paul Wise wrote:

On Fri, 2022-07-15 at 23:05 -0400, gene heskett wrote:


The whole install of raspios is armhf. So I guess its yes.

I seem to remember them switching to arm64 recently?


They may have, I've had a total loss of history here with 2, 2T seagate
drives dieing within a couple weeks of each other. So let me see if I have
the bullseye image for arm I've tried.  Yes, and its:
2021-10-30-raspios-bullseye-armhf-full.img
Which ran fine, even with my now 2 yo kernel installed but the python
is too new for linuxcnc. With a second user wanting to dup what I did,
I've sent him two cards with the raspios buster for armhf, with my kernel
installed by my method. Linuxcnc has been advised of the python showstopper,
and that may have been fixed by now, but if so, its not caught my attention
in the email's I get from a 4x a day git pull keeping the pi up to date.

Since that master is now in testing for bookworm, I have to assume it 
has been fixed.


I also have 11-2 of yours, in netinstall flavor and labeled as armhf. As 
I recall

it had some sort of a showstopper, and I knew raspios worked, I don't recall
that  I investigated yours further. Is there a later netinstall for 
armhf or arm64

available now? u-sd cards I have.

I have not tried to build an aarch64 from the src I have.
I think, since the 240G I'm using for workspace is over 50% full, that I 
had better
replace the 120G I've used for a backup, with a 1T and copy the 240 to 
it, before
I do anything rash. That can be done but I'm in the middle of rebuilding 
a Prusa MK3S
with a better print head and that has priority at the moment. I am using 
it to make
the nuts for a woodworkers workbench vises, carving the screw from a 
2x2" stick
of hard maple about 20" long. See version #1 on my web page it the sig. 
Reshaping
the threads for a lot better fit, version #5 is waiting on a working 
printer to make

more nuts.

I think it would be helpful if someone with an RPi4 could do this.

That's probably me but its also likely a week on down the log.


It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since. It is now in testing so
those of you w/o 5 years of history to lose could try it for the price of a 64G 
u-sd card.

For those of you who are able to try this, sounds like you just install
linuxcnc-uspace and then run latency-test. Also install/try latencytop,
although Linux CONFIG_LATENCYTOP is not enabled in Debian probably.

$ apt-file search latency-test
linuxcnc-uspace: /usr/bin/latency-test
linuxcnc-uspace: 
/usr/share/doc/linuxcnc/examples/sample-configs/apps/latency/latency-test.demo
linuxcnc-uspace: /usr/share/man/man1/latency-test.1.gz


latencytop I've heard of, but haven't found, so no comparison comment.


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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/15/22 21:54, Paul Wise wrote:

On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote:


Because our latency-test results are better on armhf than on arm64,
we use armhf for its performance.

Are these results for armhf kernel with armhf userland?

The whole install of raspios is armhf. So I guess its yes.


Are the results for arm64 kernel with armhf userland similar?

I have not tried to build an aarch64 from the src I have.

How much worse are the results for arm64 kernel and userland?

No, not exact, but its roughly 4x longer when I can get it to run,
as it did check for a realtime preempt kernel and did a graceful
exit if not found. So its not been run on 64 bit Debian image since
stretch.

It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since. It is now in testing so
those of you w/o 5 years of history to lose could try it for the price
of a 64G u-sd card.

I want to thank you /all/ for a civil discussion. It has not been all that
welcoming  in the past.

Take care and stay well everybody.

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
Genes Web page <http://geneslinuxbox.net:6309/>
null

Re: armhf kernels on arm64 hardware

[gene heskett]

On 7/15/22 12:16, Wookey wrote:

On 2022-07-15 18:42 +0800, Paul Wise wrote:

On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote:


If you see /other/ problems with the 64-bit kernel (using the
same user space, kernel source and kernel config as the 32-bit
kernel), please report those to the respective upstream kernel
maintainers so we can fix those as well.

Gene's complaint is unrelated to this thread, but it is that Debian
refuses to support running the 32-bit ARMMP kernel on 64-bit hardware,
specifically on the RaspberryPi 4b. There wasn't any justification from
Debian given in the bug reports, but it sounds like only build config
options are needed to be enabled, but Debian refuses to do that:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12
https://bugs.debian.org/981586

Ah thanks Paul. I was wondering why we were being accused of 'Debian
abandonning armhf' when it was news to me, and I'm just writing the
'ARM ports status' talk for Debconf next week.

Clearly one normally does not run foreign-arch kernels on hardware so
we don't have to support it, and Ben is right to say 'this is not a
bug'.

On the other hand, if the armhf kernel does work on RPi4 with a few
config options, and there is an actual use case, then the question is
what is the downside of enabling the config options?

It, LinuxCNC, does indeed run on an armhf kernel built right on the pi
and has been since Jessie on a rpi3b.

Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on 
other 64-bit machines?
No. It runs with the same armhf kernel on an rpi3b, but the 3b is 
dragging its

tongue on the floor where the 4b has some leftover zip.

I'm driving an 80 yo Sheldon lathe with it, and a 3 axis Mazak mill is 
under

construction/conversion by another person out on the left coast as we're
discussing this. But the lack of armhf in Debian is why we're both running
raspian, I built his boot cards.

Because our latency-test results are better on armhf than on arm64, we 
use armhf

for its performance.

Do i386 kernels work on amd64 machines?

Different architecture. No relevance here.


Sounds like something that might be worth discussion at debconf next week. I'll 
mention it in the talk.

Wookey



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
Genes Web page <http://geneslinuxbox.net:6309/>

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

[gene heskett]

On 7/15/22 11:09, 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.

Ahh contraire, linuxcnc is at this moment and has been since the
rpi was a 3b, running on the armhf version quite well in fact.  With 
this kernel:
Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 
07:09:18 EST 2020 armv7l GNU/Linux

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

.



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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: [PATCH v2] arm64: compat: Implement misalignment fixups formultiword loads

[gene heskett]

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.

I built this kernel for an rpi4b quite a while ago, but none more recent
have been as usable. uname -a:

Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 
07:09:18 EST 2020 armv7l GNU/Linux


latency-test shows about 12 u-secs as long as I stay away from firefox.

That's good enough to run a cnc converted 80 yo 11x56 Sheldon lathe,
making it do dance steps that were not in its vocabulary 80 years ago.

Yet that raspios buster install is the full blown graphical install I 
also use

as a development platform, with big SSD's plugged into its usb3 ports for
workspace.

Is it stable? Absolutely, no splats since the above date unless caused by
me, uptimes are in the many months category as I try newer stuff now
and then and find it wanting.

The exception is right now, as libc6 was replaced and I rebooted it
2 days ago.

It would be running bullseye but the last time I switched boot cards to try
it, the python was too new to build LinuxCNC with but the built on buster
version still worked and so did the above kernel.

What I'd like to know, is why is armhf such a dirty word to debian?

Take care and stay well everybody.
  

Note to cc'ees: if this is something you would like to see merged,
please indicate so. This stuff is unlikely to get in if there are no
users.

Decent 32-bit arm hardware is thin on the ground these days. Debian
still has some but it's getting old and flaky. Being able to build
reliably on 64-bit hardware is important and useful. Unaligned
accesses are much less of a problem than they used to be, but they can
still happen, so having these fixups available is definitely a good
thing.

Debian runs its 32-bit buildds with alignment fixups turned on. It
looks like the boxes still hit about 1 per day.

We also do 32 bit builds on 64-bit kernels (in 32-bit userspaces) and
it mostly works. We do have packages that fail on 64-bit kernels and
have to be built on real 32-bit hardware, but I don't know how much of
that would be fixed by this patch. Some, presumably.

So yes, cheers for this. It is helpful in the real world (or at least
it should be).

Wookey


.

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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: [PATCH v2] arm64: compat: Implement misalignment fixups for multiword loads

[gene heskett]

)
+   return fault;
+
+   *inst = __le32_to_cpu(instr);
+   return 0;
+}
+
+static int alignment_get_thumb(struct pt_regs *regs, __le16 __user *ip, u16 
*inst)
+{
+   __le16 instr = 0;
+   int fault;
+
+   fault = get_user(instr, ip);
+   if (fault)
+   return fault;
+
+   *inst = __le16_to_cpu(instr);
+   return 0;
+}
+
+int do_compat_alignment_fixup(unsigned long addr, struct pt_regs *regs)
+{
+   union offset_union offset;
+   unsigned long instrptr;
+   int (*handler)(unsigned long addr, u32 instr, struct pt_regs *regs);
+   unsigned int type;
+   u32 instr = 0;
+   u16 tinstr = 0;
+   int isize = 4;
+   int thumb2_32b = 0;
+   int fault;
+
+   instrptr = instruction_pointer(regs);
+
+   if (compat_thumb_mode(regs)) {
+   __le16 __user *ptr = (__le16 __user *)(instrptr & ~1);
+
+   fault = alignment_get_thumb(regs, ptr, );
+   if (!fault) {
+   if (IS_T32(tinstr)) {
+   /* Thumb-2 32-bit */
+   u16 tinst2;
+   fault = alignment_get_thumb(regs, ptr + 1, 
);
+   instr = ((u32)tinstr << 16) | tinst2;
+   thumb2_32b = 1;
+   } else {
+   isize = 2;
+   instr = thumb2arm(tinstr);
+   }
+   }
+   } else {
+   fault = alignment_get_arm(regs, (__le32 __user *)instrptr, 
);
+   }
+
+   if (fault)
+   return 1;
+
+   switch (CODING_BITS(instr)) {
+   case 0x:/* 3.13.4 load/store instruction extensions */
+   if (LDSTHD_I_BIT(instr))
+   offset.un = (instr & 0xf00) >> 4 | (instr & 15);
+   else
+   offset.un = regs->regs[RM_BITS(instr)];
+
+   if ((instr & 0x001000f0) == 0x00d0 || /* LDRD */
+   (instr & 0x001000f0) == 0x00f0)   /* STRD */
+   handler = do_alignment_ldrdstrd;
+   else
+   return 1;
+   break;
+
+   case 0x0800:/* ldm or stm, or thumb-2 32bit instruction */
+   if (thumb2_32b) {
+   offset.un = 0;
+   handler = do_alignment_t32_to_handler(, regs, 
);
+   } else {
+   offset.un = 0;
+   handler = do_alignment_ldmstm;
+   }
+   break;
+
+   default:
+   return 1;
+   }
+
+   type = handler(addr, instr, regs);
+
+   if (type == TYPE_ERROR || type == TYPE_FAULT)
+   return 1;
+
+   if (type == TYPE_LDST)
+   do_alignment_finish_ldst(addr, instr, regs, offset);
+
+   perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, 1, regs, regs->pc);
+   arm64_skip_faulting_instruction(regs, isize);
+
+   return 0;
+}
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index c5e11768e5c1..b25119b4beca 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -687,6 +687,9 @@ static int __kprobes do_translation_fault(unsigned long far,
  static int do_alignment_fault(unsigned long far, unsigned long esr,
  struct pt_regs *regs)
  {
+   if (IS_ENABLED(CONFIG_COMPAT_ALIGNMENT_FIXUPS) &&
+   compat_user_mode(regs))
+   return do_compat_alignment_fixup(far, regs);
do_bad_area(far, esr, regs);
return 0;
  }



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
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Using a serial port

[gene heskett]

On 6/17/22 20:44, Lennart Sorensen wrote:

On Fri, Jun 17, 2022 at 06:45:02PM -0500, Steve Fatula wrote:

Is there anyway to get an attached serial port working on Debian and
raspberry PI 4? It appears the tested installs want to use it as a serial
console, I do not. I want to use UART1, the PL011, as an RS232 port to a
projector.

I can do this using Raspberry OS, but, not Debian using the tested installs.
There is no way to disable Bluetooth via the overlays used on Raspberry OS.
I can sort of mess around and stop the console from being started on ttyS1,
but no way to use the port as a serial port to send and received data.
Apparently the dtoverlays are not there.

So, is there any way to really use a serial port, attached to any GPIO pins,
as a real RS232 port using Debian images? if so, what do I need to disable
or enable?

As mentioned, had it working on Raspberry OS which is based on Bullseye. But
unfortunately I can't use Raspberry OS for our usage.

>From what I have read you should be able to enable uart2 through uart5
on the Pi4B using the dts overlays.  I don't have a Pi4 yet so no
experience with doing that unfortunately.

https://forums.raspberrypi.com/viewtopic.php?t=244827  seems to have some
talk about it though.


*I never have used a serial port on a pi, 3 or 4. I'm running an 80 
yo**Sheldon lathe with a pi4 now but used a pi3 before the 4 came 
out.My use of a mesa interface card ties up the gpio header as it talks to *

the mesa cards at ohmygawd baud rates, sending data to the mesa
card in 32 bit packets at 42 megabaud, and getting the reply's back
at 25 megabaud, The use of the SPI interface leaves the wired net
port open for normal use and my remote operating channel is over
its ipv4 address with ssh for terminal services, and sshfs for file
transfers.. And running on raspios buster version, it Just Works. other
than linuxcnc which needs a realtime kernel as the raspios kernel
has been replaced with one I built, right on the pi:

pi@rpi4:/media/pi/workspace $ uname -a
Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 
07:09:18 EST 2020 armv7l GNU/Linux


workspace is a 240gig sata ssd plugged into a usb3 adapter, only
about 20x faster than its 64G boot u-sd. Within its speed limits,
it can do anything the bigger, more power hungry intels can do.
Total power consumption, monitor and all the interfacing is about
22 watts. The lathes 250 supply is controlled by SSR's linuxcnc
controls.  And the lathe can do tricks that weren't even invented
yet when it was new. To an accuracy of about .002 mm.

There's lots of things the pi's can do if given the chance to try.
Needing a uart to talk to it is not a requirement here.

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

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Monday, January 24, 2022 1:50:55 PM EST Andrei POPESCU wrote:
> On Du, 23 ian 22, 20:23:18, gene heskett wrote:
> > I thought I had some cornered earlier today, but when written to u-sd
> > and booted, were arm64.
> > 
> > For low latency reasons when a realtime kernel is installed it must
> > be
> > for armhf.
> 
> Disclaimer: I don't know much about the RPi4b, take below with a big
> grain of salt.
> 
> 
> This wiki https://wiki.debian.org/RaspberryPi4#Booting_from_USB indeed
> mentions only ARM64 images, but it also suggests recent devices can
> boot from USB, in which case you might want to try images from here:
> 
> https://www.debian.org/devel/debian-installer/
> 
> 
> Another alternative might be to take the YAML spec files for vmdb from
> here and tweak to use armhf instead of arm64:
> 
> https://raspi.debian.net/daily-images/
> 
> (could be as easy as replacing 'arch: arm64' with 'arch: armhf' in the
> qemu-debootstrap step)

I have looked at some of that, seems stuck on arm64. Pass the salt ;o)

I'm about halfway thru building a 5.16.2-rt19 kernel7l right now on the 
rpi4. Maybe that will work.  That is about as bleeding edge as can be 
built right now. But I see it building modules it will never use on a pi. 
So I need to run menuconfig and turn a bunch of that stuff off.

> Hope this helps,
> Andrei


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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Tuesday, January 25, 2022 2:41:22 PM EST gene heskett wrote:
> On Tuesday, January 25, 2022 1:26:39 PM EST Andrew M.A. Cater wrote:
> > On Tue, Jan 25, 2022 at 06:17:16PM +0100, LinAdmin wrote:
> > > When on 16 Mar 2021 I gave the solution in
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
> > > 
> > > I was told from the omnipotent gurus of Debian that nobody needs 32
> > > Bit and the bug was closed.
> > > 
> > > After that, everybody requiring 32 Bit went with Ubuntu 20.4 LTS
> > > which is not as stubborn as Debian.
> > 
> > No - not quite. That's not what the bug history says. You will find
> > that Ubuntu isn't supported on all Pi models, for example, but only
> > on
> > later models that are ARMv7. In general, people are opting for 64 bit
> > for Pi 3 and Pi 4 - see also Fedora.
> > 
> > If you actually talk to the people doing the work, you often find the
> > reasons why - they're not all "omnipotent gurus" and they're
> > generally
> > approachable.
> > 
> > As it stands today, we can't support the Raspberry Pi (at any
> > version)
> > with an official Debian installer because of the method of booting
> > and
> > the need for non-free firmware. There's a good port for UEFI - and
> > that's what Fedora is also using, for example - but the need for
> > non-free firmware persists.
> > 
> > > LinAdmin
> > > 
> > > On 24.01.22 02:23, gene heskett wrote:
> > > > I thought I had some cornered earlier today, but when written to
> > > > u-sd
> > > > and booted, were arm64.
> > > > 
> > > > For low latency reasons when a realtime kernel is installed it
> > > > must
> > > > be
> > > > for armhf.
> > > > 
> > > > Cheers, Gene Heskett.
> > 
> > ?? Why must it be armhf - a Pi 4 is massively faster/more capable
> > than
> > a Pi 1 ?? Could you explain what difference 32 bitness makes?
> 
> Simple Andy, and has been explained many times. The bigger stack frame
> of arm64 negatively impacts the IRQ latency, making the response to an
> IRQ take several microseconds longer. Running a fully preempt-rt
> kernel on an i5 can get that time down to 4 u-secs unless you're
> running something that needs the nvidia proprietary video driver,
> which can tie things up with the irq's locked out for 3+ milliseconds.
> That's a full showstopper.
> 
> On armhf, on a 2gig rpi4b, a kernel I built,
> 
> 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
> GNU/Linux,
> 
> almost 2 years ago makes about 12 microseconds which is fast enough to
> run over half a ton of 75 yo sheldon lathe I rebuilt for cnc control.
> The Linuxcnc latency-test won't even run on an arm64 because the
> realtime irq capability isn't there, and when measured by other means
> can be 100 microseconds worse. That's valuable time lost that will
> manifest itself in machine crashes that break expensive tooling. Even
> the half your little fingernail sized carbide chips that tip our
> cutting tools cost $20 or more a copy if we buy the better stuff.
> 
> The guys that inhabit the linux-rt list are putting a lot of what
> they've learned back into the regular linux kernel, with the future
> target being capable of doing this reatime work, but its not all done
> yet. And its a heck of a lot faster now than it was at 2.2 because of
> this, despite the line count being multiplied by 4 or more since then.
> 
> It is Linus's stated target that this happens.
> 
> But there is a lot of work yet to be done too, lots of legacy code that
> needs re-written to take advantage of what has been learned.
> 
> We are the folks who if we want music while we work, will find a radio
> and turn it on.  Its a different environment for sure but in the long
> view it will come together.
> 
> We are the unreasonable people G. B. Shaw wrote about when he said all
> progress is made by unreasonable people, reasonable folks adapt to the
> status quo and get on with it even when things are not optimal.
> 
> > All the very best, as ever,
> 
> To you too Andy, take care and stay well, all of you reading this to
> see what trash talk Gene is spewing today.
> 
> > Andy Cater
> 
> Cheers, Gene Heskett.

FWIW, I unpacked a fresh 64G u-sd card, wrote the 20211030 raspian 
bullseye armhf.img install to it. Then mounted it and edited 
/etc/dhcpdcp.conf to fill in the fallback data at the bottom of that file 
and wrote my hosts file over what was there, and edited hostname to name 
it.

Placed the card in my pi and powered it up,

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Tuesday, January 25, 2022 1:26:39 PM EST Andrew M.A. Cater wrote:
> On Tue, Jan 25, 2022 at 06:17:16PM +0100, LinAdmin wrote:
> > When on 16 Mar 2021 I gave the solution in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
> > 
> > I was told from the omnipotent gurus of Debian that nobody needs 32
> > Bit and the bug was closed.
> > 
> > After that, everybody requiring 32 Bit went with Ubuntu 20.4 LTS
> > which is not as stubborn as Debian.
> 
> No - not quite. That's not what the bug history says. You will find
> that Ubuntu isn't supported on all Pi models, for example, but only on
> later models that are ARMv7. In general, people are opting for 64 bit
> for Pi 3 and Pi 4 - see also Fedora.
> 
> If you actually talk to the people doing the work, you often find the
> reasons why - they're not all "omnipotent gurus" and they're generally
> approachable.
> 
> As it stands today, we can't support the Raspberry Pi (at any version)
> with an official Debian installer because of the method of booting and
> the need for non-free firmware. There's a good port for UEFI - and
> that's what Fedora is also using, for example - but the need for
> non-free firmware persists.
> 
> > LinAdmin
> > 
> > On 24.01.22 02:23, gene heskett wrote:
> > > I thought I had some cornered earlier today, but when written to
> > > u-sd
> > > and booted, were arm64.
> > > 
> > > For low latency reasons when a realtime kernel is installed it must
> > > be
> > > for armhf.
> > > 
> > > Cheers, Gene Heskett.
> 
> ?? Why must it be armhf - a Pi 4 is massively faster/more capable than
> a Pi 1 ?? Could you explain what difference 32 bitness makes?
> 
Simple Andy, and has been explained many times. The bigger stack frame of 
arm64 negatively impacts the IRQ latency, making the response to an IRQ 
take several microseconds longer. Running a fully preempt-rt kernel on an 
i5 can get that time down to 4 u-secs unless you're running something 
that needs the nvidia proprietary video driver, which can tie things up 
with the irq's locked out for 3+ milliseconds. That's a full showstopper.

On armhf, on a 2gig rpi4b, a kernel I built, 

4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l 
GNU/Linux,

almost 2 years ago makes about 12 microseconds which is fast enough to 
run over half a ton of 75 yo sheldon lathe I rebuilt for cnc control. The 
Linuxcnc latency-test won't even run on an arm64 because the realtime irq 
capability isn't there, and when measured by other means can be 100 
microseconds worse. That's valuable time lost that will manifest itself 
in machine crashes that break expensive tooling. Even the half your 
little fingernail sized carbide chips that tip our cutting tools cost $20 
or more a copy if we buy the better stuff.

The guys that inhabit the linux-rt list are putting a lot of what they've 
learned back into the regular linux kernel, with the future target being 
capable of doing this reatime work, but its not all done yet. And its a 
heck of a lot faster now than it was at 2.2 because of this, despite the 
line count being multiplied by 4 or more since then.

It is Linus's stated target that this happens.

But there is a lot of work yet to be done too, lots of legacy code that 
needs re-written to take advantage of what has been learned.

We are the folks who if we want music while we work, will find a radio 
and turn it on.  Its a different environment for sure but in the long 
view it will come together.

We are the unreasonable people G. B. Shaw wrote about when he said all 
progress is made by unreasonable people, reasonable folks adapt to the 
status quo and get on with it even when things are not optimal.

> All the very best, as ever,

To you too Andy, take care and stay well, all of you reading this to see 
what trash talk Gene is spewing today.
> 
> Andy Cater

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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Monday, January 24, 2022 1:50:55 PM EST Andrei POPESCU wrote:
> On Du, 23 ian 22, 20:23:18, gene heskett wrote:
> > I thought I had some cornered earlier today, but when written to u-sd
> > and booted, were arm64.
> > 
> > For low latency reasons when a realtime kernel is installed it must
> > be
> > for armhf.
> 
> Disclaimer: I don't know much about the RPi4b, take below with a big
> grain of salt.
> 
> 
> This wiki https://wiki.debian.org/RaspberryPi4#Booting_from_USB indeed
> mentions only ARM64 images, but it also suggests recent devices can
> boot from USB, in which case you might want to try images from here:
> 
> https://www.debian.org/devel/debian-installer/
I found at a link from the above page, a testing iso in armhf flavor.
If it boots, i'll test install the kernel being built. This I think is 
progress, or at least educational.
> 
> Another alternative might be to take the YAML spec files for vmdb from
> here and tweak to use armhf instead of arm64:
> 
> https://raspi.debian.net/daily-images/
> 
> (could be as easy as replacing 'arch: arm64' with 'arch: armhf' in the
> qemu-debootstrap step)
> 
> Hope this helps,

It may be, thanks Andrei.

> Andrei


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
Genes Web page <http://geneslinuxbox.net:6309/gene>

where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

I thought I had some cornered earlier today, but when written to u-sd  
and booted, were arm64.

For low latency reasons when a realtime kernel is installed it must be 
for armhf.

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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: cubox-i does not boot after upgrade to bullseye

[gene heskett]

On Wednesday, December 29, 2021 1:39:18 PM EST Vagrant Cascadian wrote:
> On 2021-12-29, Rainer Dorsch wrote:
> > Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:
> >> If you can  insert the microSD into another Debian  machine, you can
> >> get
> >> the UUID  by looking in  /dev/disk/by-uuid/ to find the  matching
> >> device
> >> 
> >> or:
> >>   lsblk --fs /dev/DEVICE
> >> 
> >> It might be possible to discover from u-boot as well, but I forget off
> >> the top of my head.
> > 
> > There is
> > 
> > => part uuid mmc 1:2
> > 8ad3fb70-02
> > => part uuid mmc 1:3
> > 8ad3fb70-03
> > =>
> > 
> > but  "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.
> > 
> > In the bullseye installation, there is also a variable defined finduuid
> > 
> > finduuid=part uuid mmc 0:1 uuid
> > 
> > which is even called by bootcmd, but I am not sure if that is doing
> > anything useful.
> 
> That *may* be a partition UUID, rather than a filesystem
> UUID... initramfs-tools 0.121 and newer supports using
> root=PARTUUID=...
> 
> You can see the available partition uuids on linux in
> /dev/disk/by-partuuid/
> 
Thank you very very much, vagrant. I've been wondering how those were 
married, but a much more informative answer is from ls -l + the above path.

>From my 2 gig rpi4, serving as a buildbot, and heavily modified to move much 
of the buildbot traffic off the u-sd:

pi@rpi4:~/linuxcnc/configs/sheldon-lathe $ ls -l /dev/disk/by-partuuid/
total 0
lrwxrwxrwx 1 root root 15 Oct 18 06:55 5e3da3da-01 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Oct 18 06:55 5e3da3da-02 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-01 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-02 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-03 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-04 -> ../../sda4
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c61252a1-01 -> ../../sdb1

sda/sdb are SSD's on usb3-sata adapters
> 
> live well,

You too,

>   vagrant


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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: odd result for sudo dpkg -V

[Gene Heskett]

On Monday 08 November 2021 11:19:12 Daniel Serpell wrote:

> Hi,
>
> El Sun, Nov 07, 2021 at 03:54:50PM -0500, Gene Heskett escribio:
> > On Sunday 07 November 2021 03:19:09 deloptes wrote:
> > > > Note that I as the OP was using dpkg -V, not --verify. Might
> > > > their be a difference?
> > > >
> > > > Cheers, Gene Heskett.
> > >
> > > Gene always check the -h vs --help or man page
> > >
> > > dpkg --help
> > >   -V|--verify [...]   Verify the integrity of
> > > package(s).
> > >
> > > package is optional and if not provided would check all packages
> > > installed but it seems this is broken
> > >
> > > BR
> >
> > well, I'm getting an almost sensible listing from the wintel boxes,
> > although the attributes reported are garbage in all cases of an
> > error. an ls -l shows the attributes correctly.
>
> Please, read the manual.

I have, but it rambles. So I did not note that. This is a much better 
explanation in that it actualy explains the results. Thanks a bunch.

> The reported codes are not the file attributes, those are the status
> of the performed checks. DPKG only has support for verifying the MD5,
> so the result is always "??.??" for a passed check and "??5??"
> for a failed check.
>
> And the reported failed checks on Armbian are because the
> "armbian-config" package modifies configuration files of other
> packages.
>
Should that not result in a more consistent number? I got nearly 90 the 
first time.
I got 74 the last time I ran it on the pi, since nothing was been changed 
since, I am running it again. This pi has lots more stuff installed as 
its a full development system for LinuxCNC. Humm, after almost an hour, 
I got 74 again. There is always the possibility I didn't use a sudo the 
first time.

Thanks Daniel.

> Here, in a minimal Armbian install, I got:
>
> ??5?? c /etc/skel/.bashrc
> ??5?? c /etc/logrotate.d/apt
> ??5?? c /etc/systemd/journald.conf
> ??5?? c /etc/NetworkManager/NetworkManager.conf
> ??5?? c /etc/default/rng-tools-debian
> ??5?? c /etc/logrotate.d/alternatives
> ??5?? c /etc/logrotate.d/dpkg
> ??5?? c /etc/logrotate.d/aptitude
> ??5?? c /etc/sysctl.conf
> ??5?? c /etc/logcheck/violations.ignore.d/rng-tools
> ??5?? c /etc/logcheck/ignore.d.server/rng-tools
> ??5?? c /etc/default/rng-tools
> ??5??   /etc/armbian-release
> ??5??   /etc/default/armbian-ramlog.dpkg-dist
> ??5??   /etc/default/armbian-zram-config.dpkg-dist
> ??5?? c /etc/issue
> ??5?? c /etc/issue.net
> ??5?? c /etc/update-motd.d/10-uname
> ??5?? c /etc/initramfs-tools/initramfs.conf
> ??5?? c /etc/lightdm/lightdm-gtk-greeter.conf
>
> As you see, all are configuration files modified by Armbian.
>
> In the same hardware, a SID install reports all checks OK.
>
> Have Fun!


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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: odd result for sudo dpkg -V

[Gene Heskett]

On Sunday 07 November 2021 03:19:09 deloptes wrote:

> > Note that I as the OP was using dpkg -V, not --verify. Might their
> > be a difference?
> >
> > Cheers, Gene Heskett.
>
> Gene always check the -h vs --help or man page
>
> dpkg --help
>   -V|--verify [...]   Verify the integrity of package(s).
>
> package is optional and if not provided would check all packages
> installed but it seems this is broken
>
> BR

well, I'm getting an almost sensible listing from the wintel boxes, 
although the attributes reported are garbage in all cases of an error. 
an ls -l shows the attributes correctly.  And it may be timing or buffer 
related as it goes down if the "|wc -l" is added, the errors are less.  
And still somewhat randomized, 80 something on the pi yesterday and 74 
today and only 4 pkgs have been updated in the meantime. All instances 
were as sudo of coarse. 

So I believe the --verify or -V, option needs some tlc in all 6 cases 
here. 5 wintel boxes and a rpi4b, all heavily customized, with old but 
realtime kernels. but not the same kernels as the pi is totally home 
brewed including the install method which on a u-boot system is totally 
undocumented so I had to invent my own method. I put it up on my web 
page so I might not be the only one using it. Certainly less than 5 
users on this whole ball of rock and water.  And totaly against armbian 
policy, I am blacklisted from their forum because of it. The NIH 
syndrome's finest example.

It seems to really get an upset tummy if the file perms are 0600 like 
some of amanda's stuff that can only be read by amanda, so even root 
can't see them. Which is correct but the error msg isn't exactly 
accurate, and in every case on 6 machines here, the attributes reported 
are all wrong and identical, pulled out of of very thin air.

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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: odd result for sudo dpkg -V

[Gene Heskett]

On Saturday 06 November 2021 08:45:36 Phil Endecott wrote:

> David Pottage wrote:
> > I got similar results on my RockPro64, It is running
> > Armbain rather than pure Debian, but as far as I am
> > aware only the kernel comes from Armbain, and the rest
> > of userspace is from Debian. In other words it is probably
> > a Debian bug, and I don't think we can blame RaspberryPi OS
> > for it.
>
> No, Armbian has changes to assorted things in /etc which will
> be reported by dpkg --verify. I have previously asked how to
> reduce Armbian to just a custom kernel with vanilla Debian
> everywhere else but didn't make much progress; the Armbian
> people think their changes are improvements or bug fixes. (I
> would be surprised if you see hundreds of files though.)
>
> Here are my results for assorted ARM systems running variants
> of Debian bullseye:
>
> AWS cloud instance: 4 files in /etc, all modified by me.
>
> QEMU vm: 1 file in /etc, modified by me.
>
> 32-bit ODROID NAS running Armbian: 19 files in /etc, about
> 5 modified by me, the others modified by Armbian.
>
> ODROID C2 originally installed with "odrobian" but modified
> by me to approach vanilla Debian with the odrobian kernel:
> 10 files in /etc, nearly all modified by me.
>
> Nvidia Jetson Xavier NX with "Jetpack" installed over Debian:
> 20 files, about 3 modified by me.
>
>
> I don't see any evidence that there is a problem with dpkg in
> Debian; all of these derivatives make changes to configuration
> files and similar which dpkg --verify correctly reports.
>
>
> Cheers, Phil.

Note that I as the OP was using dpkg -V, not --verify. Might their be a 
difference?

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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: odd result for sudo dpkg -V

[Gene Heskett]

On Friday 05 November 2021 10:22:11 Markus Weyermann wrote:

> I ran it on RPi4B RaspberryPi  OS aarch64 Buster and got
>
> :~ $ sudo dpkg -V
>
> ??5?? c /etc/skel/.bashrc
> ??5?? c /etc/elasticsearch/elasticsearch.yml
> ??5??   /usr/lib/systemd/system/elasticsearch.service
> ??5?? c /etc/init.d/elasticsearch
> ??5?? c /etc/php/7.4/mods-available/apcu.ini
> ??5?? c /etc/php/7.4/fpm/pool.d/www.conf
> ??5?? c /etc/fail2ban/jail.d/defaults-debian.conf
> ??5?? c /etc/apache2/apache2.conf
> ??5?? c /etc/rsyslog.conf
> ??5?? c /etc/sudoers.d/010_pi-nopasswd
> ??5?? c /etc/redis/redis.conf
> ??5?? c /etc/mail.rc
> ??5?? c /etc/cron.d/certbot
> ??5?? c /etc/default/useradd
> ??5?? c /etc/email-addresses
> ??5?? c /etc/exim4/passwd.client
> ??5?? c /etc/dphys-swapfile
> ??5?? c /etc/default/rpi-eeprom-update
> ??5?? c /etc/login.defs
>
Thats exactly what I got, around 200 of them.  And its quasi-random, I 
ran it again on my raspian pi4b with a |wc -l and only got 87 next time.

I think the armhf and arm64 versions have a bug. The machine is otherwise 
fine and could be carveing steel 2 or 3 minutes after I got to it.  
Takes that long to properly chuck up a workpiece.

That is not a commonly used option, but I used it because dpkg reported 
an incomplete quite a few packages update this morning and I was looking 
for the cause. But a sudo -E synaptic said its all fine, no errors, no 
fix-brokens etc.

So that -V option, and the dh dependency checker both need a wee bit of 
TLC.

The dependency checker missed some python stuff needed to build linuxcnc 
from github, but I found all that 3 or 4 months back.  That particular 
rpi4 is a full blown armhf development system with a realtime kernel in 
addition to running a 70 yo sheldon lathe with linuxcnc.

> cheers
> markus

Thanks Markus.

Take care & stay well now.

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
Genes Web page <http://geneslinuxbox.net:6309/gene>

odd result for sudo dpkg -V

[Gene Heskett]

Greetings all;

Does it work on debian arm?

Thanks!

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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Raspberry pi 3b+ i2c

[Gene Heskett]

On Friday 22 October 2021 13:50:20 Christian Happ wrote:

> Hello,
>
>
>
> I have installed debian 11 (Bullseye) 64 on my RPI 3b + and want to
> use the i2c bus on the GPIO pins.
>
I2C can probably be done, but its not I2C thats the star on gpio pins, 
its SPI, which can talk to a peripheral at 41 something megabaud using a 
32bit packet format, and reading the 32 bit packet response at 25 
megabaud. On either a pi3b or a pi4b.

It does use transmission line critical terminations but in 4 years of 
running a 1500 lb industrial lathe with it, I have yet to log a mistaken 
packet. 
>
> Is there a tutorial that covers installing the necessary files?

Get a modified buster install for arm64 dvd iso from linuxcnc.org is one 
possibility, but you'll need a preempt-rt kernal, but I am useing a pi 
built realtime preempt kernal on a raspian buster install.

I have spare blood, so I'm also running the master version of LinuxCNC, 
updated at least daily, either self built from github, or from the 
linuxcnc buildbot. Its pretty easy, the surprise to most is that I'm 87 
yo.

Here is the sign--on showing the com rates when talking to a mesa 7i90HD 
interface card over that SPI bus:
pi@rpi4:/media/pi/workspace $ linuxcnc -l
LINUXCNC - 2.9.0-pre0-4830-gfaab5f10e
Machine configuration directory 
is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
hm2_rpspi: Platform: Raspberry Pi 4 Model B Rev 1.1
hm2_rpspi: Base address 0xfe00 size 0x0180
hm2_rpspi: Mapped peripherals from 0xfe00 (size 0x0180) to 
gpio:0x0xb420, spi:0x0xb4204000, aux:0x0xb4215000
hm2_rpspi: SPI0/CE0 clock rate: 41666000/2500 Hz, VPU clock rate: 
5 Hz
hm2_rpspi: SPI0/CE0 write clock rate calculated: 4166 Hz (clkdiv=12)
hm2_rpspi: SPI0/CE0 read clock rate calculated: 2500 Hz (clkdiv=20)
hm2_rpspi: SPI0/CE0 Valid cookie matched
hm2_rpspi: SPI0/CE0 Base: hm2_7i90.0
hm2/hm2_7i90.0: Low Level init 0.15
hm2/hm2_7i90.0: MD 2: 3x IOPort v0: accepted, using 3
hm2/hm2_7i90.0: MD 0: 1x Hostmot2 DPLL v0: accepted, using 1
hm2/hm2_7i90.0: MD 1: 1x Watchdog v0: accepted, using 1
hm2/hm2_7i90.0: MD 3: 4x Encoder v2: accepted, using 4
hm2/hm2_7i90.0: MD 4: 2x PWMGen v0: accepted, using 1
hm2/hm2_7i90.0: MD 5: 4x StepGen v2: accepted, using 4
hm2/hm2_7i90.0: MD 6: 1x LED v0: accepted, using 1
hm2/hm2_7i90.0: 72 I/O Pins used:

That card goes on to define what those 72 i/0 pins are used for, but that 
would be another 80 lines to decipher when not familiar with the 
language...

>
>
>
> Greetings,
>
> Christian


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
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Trouble installing bullseye on Rock Pi 4 A

[Gene Heskett]

On Friday 24 September 2021 04:54:08 Christian Kastner wrote:

> Hi,
>
> For some reason, I'm not getting a signal via HDMI when running the
> bullseye installer from the prepared SD card images. I thought this
> might be a monitor issue, but booting a microSD card with the
> manufacturer's image shows that this is not the case.
>
> Any ideas what could be going on? There's an eMMC attached, but
> knowing that it might affect the boot process, I have zeroed it out.
>
> I'm doubtful that it's the installer. Yesterday, I finished an
> installation on a RockPro64, a similar platform, without issues.
>
> I'd attach a serial cable but the Rock Pi 4 requires on capable of
> 1.5Mbps and none of my cables are. I thought I'd ask here before
> purchasing one.
>
> Best,
> Christian

On  the R-pi4B, its a bit bitchy, and you have to edit something to up 
the signal swing before it works on the pi's. Since this too uses mali 
video, I would not be surprised if it didn't need a boost too.

But I can't tell you where to edit, everybody has to be different, and 
nobody has any for sale. My own experience with the earlier hardkernel 
(korean) version was nice running armbian but the spi didn't work and 
questions about it were ignored. Armbian also did not have a realtime 
preemptable kernel, a must for my application. I do have one for the 
pi3-4's, but I had to build it, no support from the foundation and then 
figure out how to install it. But it works well, with uptimes in months.
This does look like an upward step in capabilities so I might be 
interested in testing one.
-- 
"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
Genes Web page 

Re: Debian on Pine64 H64B?

[Gene Heskett]

On Wednesday 22 September 2021 17:56:18 Lennart Sorensen wrote:

> On Tue, Sep 21, 2021 at 04:52:15PM -0400, Gene Heskett wrote:
> > bookmarked, that will take some study to grok how that works.  Is
> > there a minimum kernel version?
>
> It appears it has been around for many years.  Of course features have
> been added over time.

I found the man page, which may be the most uptodate writings, but the 
setup still seems very complex.

And the machine it would apply to here, is running a nearly 2 yo kernel I 
built, but I have no clue if that stuff is enabled in that build.

Thank you Lennart.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Tuesday 21 September 2021 14:43:57 Lennart Sorensen wrote:

> On Tue, Sep 21, 2021 at 11:36:51AM -0400, Gene Heskett wrote:
> > Humph, idea borrowed from the Z-80 of the very late 70's, or
> > possibly from the TI 9900's, which had no registers, all in memory
> > and it changed context by resetting the index counter to a different
> > address for a new set of registers. Same idea, different execution
> > but it worked well.
>
> Well those required the software to ask to change the pointer to
> memory for the registers.  The hyperthreading just has two sets of
> registers and switches between them whenever the other thread stalls
> (so no delay for any code to run to do the switch).  But since to the
> OS it looks like 2 CPUs, the fact that the amount of clock cycles each
> thread gets to execute varies, makes to a mess if you are trying to do
> predicable realtime. I certainly can't imagine a real time system
> working right with hyperthreading enabled.
>
> > But it in 3 examples of the Z-80 in about 1981 while I was coding up
> > an ATS that looked like a transmitter remote control (different FCC
> > rules) only 1 would reliably swap registers when it read an E6
> > command. I paid for two more as the warranty had expired by the time
> > I discovered it, so in 5 examples, I actually got two that worked.
> > They were about $35/copy at the time. I mistakenly thought it might
> > have been a step up from the first micro-controller I used to make a
> > commercial production tool at a tv station, an RCA 1802.
> >
> > That was in 1979-80, and turned out to be so handy they were still
> > using it in 1995. Thats a couple eons in tv station control room
> > gear life. The RCA Just Worked, the Zilog not so much. I've done
> > several other tv production related projects since, never touched a
> > Zilog product again. Very bad aftertaste.
> >
> > Motorola's 6809, now the smarter Hitachi 6309, a cmos workalike
> > until we discovered it had more registers than the moto version. A
> > fact that hitachi is still contractually enjoined from ever
> > confirming the existance of, they had permission to clone it, but
> > never saw the moto masks, so they microcoded it, filling up the
> > empty spaces in the 6809 mapping. So that was my fav small cpu for
> > 30 years.
> >
> > In any event, it sure screws things up in terms of IRQ latency. The
> > other thing we turn off if we can is the SMS stuff, it can throw a
> > several millisecond monkey wrench into the gears if software
> > stepping. Not very often, but will leave its mark (litteraly) on the
> > part being carved at the time. A gear tooth out of position, which
> > since cutting a gear tooth is a repetitive operation, means that
> > tooth may be narrower by .001".
> >
> > Another item that impinges on the arm speed is that the arm doesn't
> > have the concept, so we've been told, of "isolcpus", where a cpu
> > core is removed from the schedulers execution pool, and later given
> > the job of handling the irq's. This works well on the wintels, but
> > not as effectively on the AMD stuff.
> >
> > My understanding is that you can isolate an arm core but cannot
> > later assign it a task until a powerdown reset is done.  So code
> > that can service an irq on x86-64 in 4 microseconds, can only do it
> > in about 12 microseconds on arm because a core to do it on has to be
> > selected and the context switch performed. Fireing up firefox might
> > extend that lag to 200 microseconds, but otherwise the worst case on
> > the rpi4 is around 50 microseconds but it might take several minutes
> > to record that big a lag with the kernel I'm using. That has not
> > been a problem with the work I've done with it.
> >
> > Is that understanding correct ?
>
> Well I can find people reporting that 'isolcpus' worked on RPi4, but
> that core 0 was an exception and could not be isulated (since it is
> the boot CPU and the isolation was done before the other cores were
> booted it seemed).  But it also said 'isolcpus' is deprecated and
> replaced by 'cpusets'
>
> https://www.kernel.org/doc/html/v5.9/admin-guide/cgroup-v1/cpusets.htm
>l

bookmarked, that will take some study to grok how that works.  Is there a 
minimum kernel version?

Thank you Lennart.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Tuesday 21 September 2021 07:59:42 Lennart Sorensen wrote:

I'm subbed, no need to CC: me.

> On Tue, Sep 21, 2021 at 05:00:12AM -0400, Gene Heskett wrote:
> > No, in fact disabling that is a bios setting done before even
> > installing LinuxCNC. It may make winderz seem to be better, but that
> > context switch, done by the relatively slow bios memory is a
> > performance killer even if the code is stashed in L1 cache. I've 5
> > i5's of various builds here, and none of them have that enabled even
> > if its not running machinery. This cheap 6 core i5 certainly doesn't
> > need it and its actually running at 800 MHz, but capable of 3.7 GHz.
> > Close to zero heat, all 6 cores are below 32C right now.
>
> The BIOS has nothing to do with context switching.  Hyperthreading
> doesn't even do context switching, it has two sets of registers so it
> can do free context switching while the other thread is waiting for
> something.

Humph, idea borrowed from the Z-80 of the very late 70's, or possibly 
from the TI 9900's, which had no registers, all in memory and it changed 
context by resetting the index counter to a different address for a new 
set of registers. Same idea, different execution but it worked well.

But it in 3 examples of the Z-80 in about 1981 while I was coding up an 
ATS that looked like a transmitter remote control (different FCC rules) 
only 1 would reliably swap registers when it read an E6 command. I paid 
for two more as the warranty had expired by the time I discovered it, so 
in 5 examples, I actually got two that worked. They were about $35/copy 
at the time. I mistakenly thought it might have been a step up from the 
first micro-controller I used to make a commercial production tool at a 
tv station, an RCA 1802.

That was in 1979-80, and turned out to be so handy they were still using 
it in 1995. Thats a couple eons in tv station control room gear life. 
The RCA Just Worked, the Zilog not so much. I've done several other tv 
production related projects since, never touched a Zilog product again. 
Very bad aftertaste.

Motorola's 6809, now the smarter Hitachi 6309, a cmos workalike until we 
discovered it had more registers than the moto version. A fact that 
hitachi is still contractually enjoined from ever confirming the 
existance of, they had permission to clone it, but never saw the moto 
masks, so they microcoded it, filling up the empty spaces in the 6809 
mapping. So that was my fav small cpu for 30 years.

In any event, it sure screws things up in terms of IRQ latency. The other 
thing we turn off if we can is the SMS stuff, it can throw a several 
millisecond monkey wrench into the gears if software stepping. Not very 
often, but will leave its mark (litteraly) on the part being carved at 
the time. A gear tooth out of position, which since cutting a gear tooth 
is a repetitive operation, means that tooth may be narrower by .001".

> Hyperthreading's only big problems are that it makes execution speed
> of each thread unpredictable and since two threads are sharing a core,
> it reduces the performance of single threaded code on that core.

Another item that impinges on the arm speed is that the arm doesn't have 
the concept, so we've been told, of "isolcpus", where a cpu core is 
removed from the schedulers execution pool, and later given the job of 
handling the irq's. This works well on the wintels, but not as 
effectively on the AMD stuff.

My understanding is that you can isolate an arm core but cannot later 
assign it a task until a powerdown reset is done.  So code that can 
service an irq on x86-64 in 4 microseconds, can only do it in about 12 
microseconds on arm because a core to do it on has to be selected and 
the context switch performed. Fireing up firefox might extend that lag 
to 200 microseconds, but otherwise the worst case on the rpi4 is around 
50 microseconds but it might take several minutes to record that big a 
lag with the kernel I'm using. That has not been a problem with the work 
I've done with it.

Is that understanding correct ?

Thanks Lennart. An interesting discussion indeed.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Tuesday 21 September 2021 01:07:20 lkcl wrote:

> On September 21, 2021 12:06:35 AM UTC, Paul Wise  
wrote:
> >It sounds like you are talking about userland and Debian still
> > supports a 32-bit userland under a 64-bit Linux kernel on 64-bit
> > devices,
>
> which... and i apologise, i cannot remember your name, our
> person-running-CNC-lathes pointed out that the latency on
> context-switches, presumably because of conversions on system calls
> between 64 and 32 bit and back, is awful, and making microsecond
> response time barely achievable.
>
> microsecond response... 1e6 clock speeds 2e9... bordering on 2,000
> instructions for a contextswitch and syscall, any typeconversion is
> apparently too much.
>
> > do
> >these concerns also apply to the Linux kernel itself?
>
Absolutely. And we often run kernels you consider obsolete by a decade 
just because on older hardware, they run at a better performance level 
than more recent versions. We generally build those kernels 
independently from the distro.

Checking one of my buster based LinuxCNC iso installs,
4.19.0-17-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.194-3 (2021-07-18) 
x86_64

4.19 seems to be a good one for realtime. My rpi4 is running
4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
I built that one myself. And since questions about realtime are not given 
the grace of an answer from arm folks other than goto hell, we are 
definitely on our own where arms are concerned. I had to invent my own 
installer but the src tarball is under 30 megs.

> to a lesser extent given the relative size of the linux kernel, we may
> surmise only the most extreme resource constrained scenarios would be
> concerned about that, and they're likely to be using yocto, buildroot,
> Zephyr or other RTOS etc. custom from-source builds.
>
> i had forgotten about the latency issue though, and was fascinated to
> hear that running CNCs is so borderline.
>
> i wonder if x86 does so much better there due to hyperthreading.
>
No, in fact disabling that is a bios setting done before even installing 
LinuxCNC. It may make winderz seem to be better, but that context 
switch, done by the relatively slow bios memory is a performance killer 
even if the code is stashed in L1 cache. I've 5 i5's of various builds 
here, and none of them have that enabled even if its not running 
machinery. This cheap 6 core i5 certainly doesn't need it and its 
actually running at 800 MHz, but capable of 3.7 GHz. Close to zero heat, 
all 6 cores are below 32C right now.
 
Take care 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 <http://geneslinuxbox.net:6309/gene>

Re: Debian on Pine64 H64B?

[Gene Heskett]

On Monday 20 September 2021 09:39:00 lkcl wrote:

> On September 20, 2021 1:03:39 PM UTC, Paul Wise  
wrote:
> >On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote:
> >> What I would like to see is that the official arm kernels
> >
> >automagically built by Debian could run unchanged on RaPi 32 & 64
> > bit.
> >
> >The RPi 4 is 64-bit, is there a reason for running a 32-bit Linux
> >kernel?
>
> yes: significantly reduced executable size, significantly reduced
> memory footprint, resulting in better L1/L2 cache usage with
> consequent power reduction.
>
> the power consumption of the Cortex A53 compared to the Cortex A7
> jumped TEN PERCENT and that is down to 64 bit executables.  to
> compensate, ARM now recommends 50% larger L1 caches, which
> automatically come with an irrediemable power consumption penalty even
> when running 32 bit binaries.
>
> whilst everyone is rushing headlong into 64 bit in desktop and server
> land, the abandonment is extremely alarming for the embedded world
> where power and resources really matter, and can make the difference
> between a failed and a successful product.
>
> l.

+10 or more.  For those of us who need the armhf variant its a basic 
requirement.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Monday 20 September 2021 09:03:39 Paul Wise wrote:

> On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote:
> > What I would like to see is that the official arm kernels
> > automagically built by Debian could run unchanged on RaPi 32 & 64
> > bit.
>
> The RPi 4 is 64-bit, is there a reason for running a 32-bit Linux
> kernel? (The 64-bit Linux kernel can run 32-bit userspace too).

Yes it can, but slower and at higher latency's.  Some apps are on the 
ragged edge.  CNC machinery for instance needs response to an error 
condition in a few microseconds. The rpi4 can and does do ok, but its 
10x slower than my i5's running 3 other machines here.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Monday 13 September 2021 10:09:05 Lennart Sorensen wrote:

> On Fri, Sep 10, 2021 at 01:17:02PM -0400, Gene Heskett wrote:
> > I am not aware that it ever existed. So I install the needed meat to
> > make it work, via a card reader and the non-compressed tarball is
> > just under 30 megs. apt sees it, leaves it alone. So its pinned 6
> > other packages for about 20 months now.
> >
> > Link to how to docs? I ought to check out something newer than
> > 4.19.xx
> >
> > Thanks Lennart. Take care & stay well.
>
> Well I found stuff here:
>
> https://wiki.debian.org/BuildADebianKernelPackage
>
And that link has a link to what I wanted to do, but its about 1.5 major 
versions of the kernel out of date. It is for the basic 4.3, and I'm 
already on an rt-preempt 4.19. Nothing earlier supports the pi's native 
video, so the video you see with a 4.3 is hundreds of milliseconds 
behind the machine.

5.14-rc1-rt1 was just announced on the rt list

> That mentions the bindeb-pkg and deb-pkg arguments.  I am not sure
> what the difference is.

And I have neither man page. What package contains those?


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: Debian on Raspberry Pi and Pine* and probably ARM support in general (was Re: Debian on Pine64 H64B?)

[Gene Heskett]

On Saturday 11 September 2021 04:11:26 Keith Bainbridge wrote:

> On Tue, 7 Sep 2021 10:01:49 +0300
>
> Andrei POPESCU  wrote:
> >>Kind regards,
> >>Andrei -- happy Debian user of a PINE A64+ and (still) considering
> >>the Pinebook Pro for my next laptop
>
> There's an interesting review of the Pro here:
>
> https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/
>
> Sounds interesting. Pity they are out of stock

It night "sound interesting" if it had sound, but thats the quietest 
movie I've watched in months. No audio buttons to be found.

Thanks Keith.

> All the best
>
> Keith Bainbridge
> keith.bainbridge.3...@gmail.com
>
> 0447 667 468


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: Debian on Pine64 H64B?

[Gene Heskett]

On Friday 10 September 2021 12:46:54 Reco wrote:

> On Fri, Sep 10, 2021 at 12:04:56PM -0400, Gene Heskett wrote:
> > So why do we not have a .deb builder for kernels.?
>
> wiki.debian.org is your friend, consider learning how to search it.
> In this particular case, you probably want [1].
>
> Reco
>
> [1]
> https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage

Thank you Reco, bookmarked and printed.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Friday 10 September 2021 12:32:49 Lennart Sorensen wrote:

> On Fri, Sep 10, 2021 at 12:04:56PM -0400, Gene Heskett wrote:
> > I knew that Reco, but the howto install after building it is the
> > best kept secret on this ball of rock and water, so I invented my
> > own installer. The revelant files total under 30 megs as a tarball.
> >
> > So why do we not have a .deb builder for kernels.? Such secrecy,
> > since it doesn't involve the blacklisted firmware, and which my
> > install doesn't touch, certainly seems politically non-productive to
> > me.
>
> Did make-kpkg stop existing?  It's been a while since I had a reason
> to build my own kernel on any of my debian systems.  I must admit
> searching for it, it does appear to no longer exist.  Hmm.
>
> Some searching on google seems to indicate that these days one is
> expected to use make deb-pkg in the kernel tree instead.  I must admit
> I have never tried that.

I am not aware that it ever existed. So I install the needed meat to make 
it work, via a card reader and the non-compressed tarball is just under 
30 megs. apt sees it, leaves it alone. So its pinned 6 other packages 
for about 20 months now.

Link to how to docs? I ought to check out something newer than 4.19.xx

Thanks Lennart. Take care & stay well.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Friday 10 September 2021 10:35:09 Gunnar Wolf wrote:

> Gene Heskett dijo [Fri, Sep 10, 2021 at 08:07:56AM -0400]:
> > > On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > > > I have some doubts that debian.net has the same ownership
> > > > than official debian.org?
> > >
> > > RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's
> > > key (who is Debian Developer), that's good enough for me.
> > >
> > > Reco
> >
> > But will they run my lathe? If they cannot do it safely, with IRQ
> > latency response well under 50 microseconds they are of sub-zero
> > interest to me.
>
> They are not designed to suit you. I guess you want to build your own
> kernels with the RT_PREEMPT enabled,

yes

> and that's not something you will 
> get with any of the mainstream Linux distributions.

Then you need to update your testing of currant wintel versions. I would 
estimate that IRQ latency today, thanks to the impetus of the Linus rant 
a decade back about its poor performance is having an effect on stock 
kernels, compared to a decade ago when latencys often ran north  of a 
millisecnd, the cureent shipping kernels with buster are now doing under 
100 microseconds as the output of the linux-rt list get adopted into 
shipping kernels. That is its target, to become the default kernel.

> Also, the 
> Raspberry is not the right platform for using RT (I'd suggest you look
> at the Beaglebone, as its hardware with separate microcontrollers is
> better suited at real-time tasks - it has less computing power, but is
> better suited for RT tasks -- you will find
> https://beagleboard.org/static/presentations/MakerFaireNY20140920_Usin
>gBeagleBoneRealTimeMicrocontrollers.pdf interesting).

Depends  on your point of view I think.

The beaglebone is for little bitty machines with barely enough hardware 
to qualify as a cnc driver, a raspi4b can run circles around it while 
browsing the web with firefox, I have done it on that pi4b. 

Based on what I have learned, I could run any of the other 3 of my now 
wintel powered machines on an rpi4 with a mesa 7i90 & friends interface. 
But the rpi4, its 5 amp psu, and the full interface with a box to hold 
it all would cost almost $400 per machine to convert. If I was starting 
from scratch on a new machine the diff in the  power bill would pay the 
cost diff per machine in 2 years with the diff in power used. The wintel 
stuff is hungry, 200+ watts/machine, the pi uses 10 watts to do the same 
job, 21 watts leaving the monitor live too.

> Our images' goal is to provide something as close as possible to a
> base, just-installed Debian image, following the RPi culture of having
> installed images. You can build from there.

And I have, using raspbian buster now. I tried a debian net-install at 
about 10.4, ran great till I rebooted and the net disappeared. I asked 
how to fix it on this list and got told to shuffle off to the main list, 
which doesn't support arm stuff, don't bother us.

I'm sorry if the truth hurts the present managements feelings, but there 
it is.

With a bit longer view than most, I am hoping that this "new broom" you 
represent will fix some of that, and I do think that by this 
conversation even happening at all, that it is improving rapidly. 
Someday, I'm hoping, as I hope to see equality in my remaining time, 
which I'm borrowing with hardware help now, I'll be 87 in about 3 weeks.

 
> Of course, if you want to do a shipping in the hundreds, thousands or
> further numbers of units, you won't want to use the images we generate
> -- but you might find the vmdb2 scripts we have as a worthy starting
> point for you to customize and build your own images. FWIW, I have a
> script set for the ~10 Raspberries we use at work for driving displays
> with our activities; I only use our "raw" images for testing them.

Thanks Gunnar. I tried to send you a PM 2-3 days back, but it bounced.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Friday 10 September 2021 10:30:28 Reco wrote:

>   Hi.
>
> On Fri, Sep 10, 2021 at 08:07:56AM -0400, Gene Heskett wrote:
> > On Friday 10 September 2021 06:59:17 Reco wrote:
> > > On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > > > I have some doubts that debian.net has the same ownership
> > > > than official debian.org?
> > >
> > > RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's
> > > key (who is Debian Developer), that's good enough for me.
> >
> > But will they run my lathe? If they cannot do it safely, with IRQ
> > latency response well under 50 microseconds they are of sub-zero
> > interest to me.
>
> Images provided by raspi.debian.net are shipped with ordinary, non-RT
> kernel. Feel free to install RT-enabled kernel from the usual sources.
>
> Reco

I knew that Reco, but the howto install after building it is the best 
kept secret on this ball of rock and water, so I invented my own 
installer. The revelant files total under 30 megs as a tarball.

So why do we not have a .deb builder for kernels.? Such secrecy, since it 
doesn't involve the blacklisted firmware, and which my install doesn't 
touch, certainly seems politically non-productive to me.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Friday 10 September 2021 06:59:17 Reco wrote:

>   Hi.
>
> On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > I have some doubts that debian.net has the same ownership
> > than official debian.org?
>
> RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's key
> (who is Debian Developer), that's good enough for me.
>
> Reco

But will they run my lathe? If they cannot do it safely, with IRQ latency 
response well under 50 microseconds they are of sub-zero interest to me.

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: Debian on Pine64 H64B?

[Gene Heskett]

On Monday 06 September 2021 13:59:12 Gunnar Wolf wrote:

> Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
> > (...)
> > So I found my own solutions. So, debian-arm, please make up your
> > mind, do you support the pi's or do you NOT support the pi's?
>
> Debian has a very clear line set: We do _NOT_ ship non-free software,
> no exceptions. Given the Raspberries need a non-free firmware blob for
> the GPU to hand over execution to the ARM CPU at bootup... Yes, that
> clearly means no official Debian images exist for Raspberry Pi
> hardware. So, yes, we made up our mind, and the situation has been the
> same since the original RPi was released in 2013.
>
> Some people, me included (but by far, it's not only me) have prepared
> prebuilt Debian images¹ that allow booting a standard Debian system
> with *only* the raspi-firmware non-free package installed.
>
> ¹ https://raspi.debian.net
> ² https://tracker.debian.net/raspi-firmware
>
> > When I did try a net install of buster, but had no network after the
> > reboot, I went back to a raspbian seed image and haven't looked
> > back, it Just Works.
>
> Try running one of our tested images³. I strongly suggest you to use
> the Bullseye images, as they are newer and more recently tested, and
> are our primary target nowadays.
>
> ³ https://raspi.debian.net/tested-images/
>
> > > Whatever floats your boat.
> >
> > That attitude is Indicating to me that debian-arm still has zero
> > interest in arm. A sad truth IMO.
>
> We have zero interest to get engaged with divisive, aggressive users
> that feel entitled to a full support tier when downloading free
> software built by a bunch of volunteers. Do you want us to spend more
> time fixing the many quirks in the RPi? Consider hiring a couple of us
> to do so. No, not me -- I have my time fully booked and am happily
> employed. But if you are interested, I can point you to many people
> who might be interested.

1. That was an early buster net-install image, and my questions at the 
time were bounced. Firmly.

2. I now have about 4 years invested in equiping raspbian 8, 9, & 10 with 
a realtime kernel, and with a $40 ups, it runs until _I_ reboot it. My 
target was to run a cnc converted machine I converted, with a pi, first 
a 3b, now a 4b. And I have succeeded beyond my dreams from years ago. I 
now know how to install a realtime kernel on a pi and once I understood 
it, its as simple as putting the u-sd in a card reader and unpacking a 
29 megabyte tarball to it. So my problems are solved.

I'm not upset with you for following debians lead in rejecting the pi, 
but I am upset that the most popular arm product on the planet is 
specifically disabled as far as debian is concerned.  Thats not your 
decision. But its also never been disclosed anyplace I have read, that 
even a phone call to the foundation asking for permission has ever been 
made.

IMO, debians rejection of pi support out of hand, without sharing the 
results info with the users, is leaving an important fact out of the 
story. One that in view of its market share, really needs to be shared 
with us.

FWIW, I did use your kernel kit, until you stopped supporting it.  And I 
thank you for that.

I also have a couple rock64's, but I don't believe they use a compatble 
gpio module. I talk to the interface card, a Mesa 7i90HD at 40 megabits, 
and receive its answers at 25 megabits over an SPI interface.  Can a 
rock64 do that?

Take care, and stay well, Gunnar.

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: Debian on Raspberry Pi and Pine* and probably ARM support in general (was Re: Debian on Pine64 H64B?)

[Gene Heskett]

On Saturday 04 September 2021 13:08:42 Andrew M.A. Cater wrote:

> On Sat, Sep 04, 2021 at 08:31:11AM -0700, Vagrant Cascadian wrote:
> > On 2021-09-04, LinAdmin wrote:
> > > The unnamed decision makers of Debian some unknown time ago
> > > decided that Pi and Pine stuff won't be supported by Debian.
> >
> > I personally have added support in Debian for:
> >
> >   Raspberry Pi 1
> >   Raspberry Pi 2b
> >   Raspberry Pi 3b+
> >   Pine64+
> >   Pinebook
> >   Pinebook Pro
> >   RockPro64
> >   Rock64
> >
> > And other platforms... others have added support for other Raspberry
> > PI and Pine64 platforms, as well as numerous other platforms...
> >
> > I used the Pinebook as my primary computer for over a year, using
> > absolutely zero software from outside of Debian...
>
> I was going to point out that Vagrant was probably the person very
> likely to be able to contribute most. I note from
> https://wiki.debian.org/InstallingDebianOn/Allwinner that the H64 from
> Pine is supported in Bullseye.
>
> Sometimes it comes down to the fact that we haven't got the hardware -
> most of the people who run ARM have at some point bought dead end
> ARM projects that never actually went anywhere in an attempt to get
> them supported.
>
> Sometimes it comes down to problems beyond Debian's control: most
> often a vendor kernel with no source / with other issues / tied in to
> hardware in obscure ways, a U-Boot similarly ... Often, if you contact
> the vendor they have no real understanding of why a Debian person
> would be asking.
>
> > Debian isn't a consumer product, it is a community project. It is
> > largely a volunteer effort, suppored by the community, so... if you
> > want something supported, please help to add the support.
> >
> > It pretty much comes down to submitting patches, bug reports, merge
> > requests, etc. to enabled the appropriate kernel options, bootloader
> > support, and debian-installer support.
> >
> > Debian doesn't generally support patches that wouldn't be acceptible
> > in upstream projects, or support non-free binary blobs out of the
> > box, so maybe the support isn't as good on a per-platform basis as
> > some other targeted distros willing to use vendor forks or patches
> > for various components.
>
> Armbian / DietPi / Raspberry Pi OS have different viewpoints, include
> different amounts of vendor code / have different attitudes to
> firmware. Things "based on" Debian do things differently and sometimes
> it's hard to see what they've done. As a consumer: if there's
> difficulty getting Debian to work on the board you bought, help us by
> going back to the manufacturer/vendor and politely pointing this out
> as a problem for you.
>
> Help the maintainers of the ARM64 and armhf installers by using them -
> and using reportbug to tell people what went wrong where.
>
First, they have to be interested in your failure reports.  Until now, 
such has not been the case. No interest...

> > The support isn't always perfect; maybe all features don't always
> > work; I don't and can't personally test all combinations of features
> > on all platforms, nor have the time to enable all features on all
> > combinations of platforms. Thankfully, there are others in the
> > community who test and improve what they can.
> >
> > Debian could always use more people helping with testing and perhaps
> > more importantly, upstreaming of support to make sure it works for
> > their use-cases...
> >
> > I know not everybody can dive in and fix all kinds of issues, but
> > there is a pretty broad spectrum of ways to help out... sometimes
> > things are even supported but undocumented. Documenting workarounds
> > and filing bug reports appropriately is one angle that could
> > potentially help.
> >
> > > I switched to Ubuntu LTS which made me (and many others) happy.
> >
> > Curious what exactly is different with Ubuntu that makes it work for
> > you...
>
> Real Ubuntu LTS from Canonical or, to take the H64 from Pine example,
> the Armbian based on Ubuntu Focal? https://www.armbian.com/pine64/ [or
> any other third party rebuild similarly].
>
> If you're on the Raspberry Pi4 - yes, you have Ubuntu LTS - but you
> also have Debian https://raspi.debian.net.
>
> Strictly, discussion of other distributions is off topic here unless
> you've documented issues of where XYZ distribution works and Debian
> doesn't on the same hardware. I await these direct comparisons from
> you with interest.
>
> All the very best, as ever,
>
> Andy Cater
>
> > live well,
> >   vagrant


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: Debian on Raspberry Pi and Pine* and probably ARM support in general (was Re: Debian on Pine64 H64B?)

[Gene Heskett]

On Saturday 04 September 2021 11:31:11 Vagrant Cascadian wrote:

> On 2021-09-04, LinAdmin wrote:
> > The unnamed decision makers of Debian some unknown time ago
> > decided that Pi and Pine stuff won't be supported by Debian.
>
> I personally have added support in Debian for:
>
>   Raspberry Pi 1
>   Raspberry Pi 2b
>   Raspberry Pi 3b+
>   Pine64+
>   Pinebook
>   Pinebook Pro
>   RockPro64
>   Rock64
I wish I had known that 2 years ago, I bought a couple rock64's but all I 
could find was armbian, whose kernel had milliseconds of IRQ latency 
times.  Totally unsuitable for running real hardware that may need 
guidance in a 5 microsecond time frame.

> And other platforms... others have added support for other Raspberry
> PI and Pine64 platforms, as well as numerous other platforms...
>
> I used the Pinebook as my primary computer for over a year, using
> absolutely zero software from outside of Debian...
>
My how to questions were asked in order that the answers might get more 
publicity. Unforch instead of answers which would have facilitated that 
progress, but I was told instead to take it to the main list, 
repeatedly.

And no one on the main list is even aware there are arm cpus fully 
capable of doing these jobs. And with 2 exceptions, no one has had any 
interest in how I did it. And only one was able to follow my directions 
to a running system.

> Debian isn't a consumer product, it is a community project.

I am well awsre of that.

> It is 
> largely a volunteer effort, suppored by the community, so... if you
> want something supported, please help to add the support.

I have made the offer, and I wrote it up where anyone with a browser can 
read the blow by blow. According to the logs, I guess this was not the 
list to tell, that readme has been looked at 3 times now in about 2 
years.

Yes, I block the bots who must think I have I have a 50 gigabyte pipe, 
but its ADSL at 10 megaBITs down. So I understandably block the bots so 
that normal folks can get a byte out edgewise. However there are bots 
that think robots.txt does not apply to them, so they get blocked with 
a /8. If you are a customer of such a company to deserve the /8, my 
sympathies, but you are still blocked.  Change your ISP. It really is 
that simple, refuse to support those that ignore the rules.

> It pretty much comes down to submitting patches, bug reports, merge
> requests, etc. to enabled the appropriate kernel options, bootloader
> support, and debian-installer support.
>
Such howto questions have been ignored and/or rejected in the past. That 
was the response at the time. If you now have a new broom, I'd be glad 
to help, but what I've done and which still works well, is also out of 
date. Meaning I should probably try and build a 5.something kernel.
But its running well on a 

4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7la

kernel for me. Absolute IRQ latency, worst case while running FF to 
browse the web, 50 microseconds, 4 to 12 doing other things, the rp4b 
multitasks well.

> Debian doesn't generally support patches that wouldn't be acceptible
> in upstream projects,

I have yet to find anything this kernel above cannot do.

> or support non-free binary blobs out of the box, 
> so maybe the support isn't as good on a per-platform basis as some
> other targeted distros willing to use vendor forks or patches for
> various components.
>
>
> The support isn't always perfect; maybe all features don't always
> work; I don't and can't personally test all combinations of features
> on all platforms, nor have the time to enable all features on all
> combinations of platforms. Thankfully, there are others in the
> community who test and improve what they can.
>
> Debian could always use more people helping with testing and perhaps
> more importantly, upstreaming of support to make sure it works for
> their use-cases...
>
> I know not everybody can dive in and fix all kinds of issues, but
> there is a pretty broad spectrum of ways to help out... sometimes
> things are even supported but undocumented. Documenting workarounds
> and filing bug reports appropriately is one angle that could
> potentially help.
>
> > I switched to Ubuntu LTS which made me (and many others) happy.
>
> Curious what exactly is different with Ubuntu that makes it work for
> you...
>
>
> live well,
>   vagrant


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: Debian on Pine64 H64B?

[Gene Heskett]

On Saturday 04 September 2021 04:48:48 Reco wrote:

>   Hi.
>
> On Sat, Sep 04, 2021 at 09:51:30AM +0200, LinAdmin wrote:
> > The unnamed decision makers of Debian some unknown time ago
> > decided that Pi and Pine stuff won't be supported by Debian.
>
> Except that Raspberry Pis are supported by Debian.
> There are even pre-built images at https://raspi.debian.net
>
> > I switched to Ubuntu LTS which made me (and many others) happy.
>
There are enough diffs that that path was not one I'd take. My target 
install these days is debian, because LinuxCNC runs on a nearly default 
debian install, and has since wheezy.
raspbian follows debian well, but throws anybody not running their kernel 
under the buss and grinds them up leaving. Zero support for a realtime 
kernel which LinuxCNC demands if its to run real hardware.  So I was 
forced to build my own. Questions involving it are ignored on their 
forum. On the pi3, with its glacial swap, its a nearly 24 hour job.

So I was also forced to invent my own installer, which has now been 
running happily since the pi3b shipped. But the pi3b, while doing the 
job of running 1500 lbs of a cnc converted Sheldon Lathe, did so with 
its tongue hanging out. When the pi4b shipped, the pi3b was replaced, 
initially with a raspbian image, mofified by doing my own install of a 
realtime kernel. That part is remarkably easy, just put the u-sd in a 
card adapter, and unpack my 4.19 tarball to it. plug it back into the 
pi4 and its done. And the pi4b does that job without breathing hard.
With startech usb3 adapters to a couple SSD's, I am even running my own 
buildbot on it to keep LinuxCNC within a few hours of the github master.
By skipping the pi's earlier years, debian did not do its users any great 
favors. The ultimate insult was when I asked a debian-arm related 
question here on this list, and I was invited to use the main list, 
where arm is a vulgar word.

So I found my own solutions. So, debian-arm, please make up your mind, do 
you support the pi's or do you NOT support the pi's?

When I did try a net install of buster, but had no network after the 
reboot, I went back to a raspbian seed image and haven't looked back, it 
Just Works.

> Whatever floats your boat.

That attitude is Indicating to me that debian-arm still has zero interest 
in arm. A sad truth IMO.

> Reco


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: OT: Right to Repair Executive Order in US

[Gene Heskett]

On Sunday 11 July 2021 00:21:00 Jeffrey Walton wrote:

> Hi Everyone,
>
> This just came down the pipe for folks in the US:
> https://www.theverge.com/2021/7/9/22569869/biden-executive-order-right
>-to-repair-isps-net-neutrality. The Executive Order squarely targets
> tech.
>
But its up to our congress critters to fund the enforcement. We'll have 
to do some serious housekeeping at the next general election or that 
will never happen.

> Also see Steve Lehto's analysis
> https://www.youtube.com/watch?v=6qyYEvcS5-8. Lehto is a Michigan
> attorney who specializes in consumer protection. He is very easy to
> understand.
>
> Jeff


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: Feedback from the community -> ARM

[Gene Heskett]

On Friday 11 June 2021 05:34:53 Arnd Bergmann wrote:

> On Thu, Jun 10, 2021 at 4:43 PM Uwe Kleine-König 
 wrote:
> > Is there anything on your mind that is missing above and that you'd
> > like to be shared with ARM? Feel free to reply here or discuss in
> > #debian-arm. (I'm ukleinek there.)
>
> I'll be at the meeting as well, and one point I would want to bring up
> is support for 32-bit binaries on 64-bit kernels. This has come up a
> few times on #debian-arm, and the problem is a mismatch between which
> obsolete instructions are emulated depending on the kernel: 64-bit
> kernels emulate all the instructions that were removed in v8 (setend,
> cp15 barriers, swp), while 32-bit kernels emulate instructions that
> were already needed in v7 (swp, mrc tlsreg, unaligned
> ldm/stm/ldrd/strd). This means that some binaries that ran fine on an
> ARMv7 processor may break when running on an ARMv8 processor with a
> 32-bit kernel, while other binaries may break on the same hardware on
> a 64-bit kernel.
>
> This situation is bad for Debian as there are mixed messages regarding
> what users should actually run on ARMv8 hardware and what should
> be tested. My hope is that we can find an agreement regarding which
> of the emulation code we actually want on v8 processors and then make
> sure that every binary that can run on a 32-bit kernel can also run on
> a 64-bit kernel (but not necessarily the other way round). This could
> mean adding features to arch/arm64/ that have previously been
> rejected, or artificially crippling the emulation code in arch/arm/
> when running on v8 to force user space applications to get fixed.
>
> Side note: yes, 32-bit user space code is still important to run for
> a lot of users, especially in low-memory configurations, but support
> for 32-bit kernels is unavailable on most newer CPU cores and
> somewhat lacking even on older cores (missing errata workarounds
> and certain features of 64-bit kernels).
>
And while discussing that, emphasize that some of us are running 32 bit 
armhf because the stack frame is smaller when switching context, giving 
better, measurable latency responses which are extremely important if 
driving a stepper motor by software generated steps. It is not uncommon 
to see an 80% speed loss when driving steppers by software steppers 
compared to driving them with programmable fpga hardware. A 10 
microsecond wobble in the step timing can cost us 50% of the motors 
torque. 100 microseconds brings the motor to a complete stop but 
bouncing back and forth in the magnetic grip, and if the next step 
arrives when the motor is backing up, it can't accellerate to get back 
in position, the part being made is ruined, and the motor is stalled, 
losing track of its home position so the whole machine has to be 
rehomed.  That costs money in time wasted recovering, in raw materiel 
ruined, and potentially broken and expensive tooling.

Going to pure 64 bit systems effectively means you are locking a large 
percentage of the cnc manufacturing on this planet out in the parking 
lot because we can't tolerate the loss of performance in real time that 
bigger stack frame causes unless we spend an additional $200+ on 
hardware interfaces to get that performance back. We may as well use a 
bigger, uses 20x the power but its cheaper pc. I'm doing it both ways, 
but my shop isn't commercial, its hobbiest. I don't have to make xx 
dollars per hour for a living.

One old farts $0.02.

> Arnd


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: Feedback from the community -> ARM

[Gene Heskett]

On Thursday 10 June 2021 15:03:22 Marcin Juszkiewicz wrote:

> W dniu 10.06.2021 o 20:36, Gene Heskett pisze:
> > On Thursday 10 June 2021 12:44:23 Marcin Juszkiewicz wrote:
> >> My questions (probably get ignored):
> >>
> >> 1. When CBSA spec gets released? It is mentioned in BSA spec but
> >>  not public.
> >
> > New acronym, please define.
>
> I can not as CBSA is all you have in public docs.
>
> It is "C* Base System Architecture" probably where "C*" can be any
> word. If you have NDAs signed with Arm then reach there and ask.
>
> >> 2. Are there plans to enforce BSA compliance for new designs?
> >>
> >> 3. How many years we need to wait for Arm systems to work out-of-
> >>  the-box? I mean unpack, connect input/video/power, boot
> >> generic distro installer, install, reboot and use. So far there are
> >> nearly no such ones outside of server space.
> >
> > This is also true, and a bit of a sore spot with me. Why? Because
> > the pi folks
>
> To be honest: I do not care how bad Arm SBCs are. I just skip them and
> do not plan to spend any money on buying those. Most are really far
> from being usable as generic Arm system.

Same for rockchip.  Armbian runs great on it, but what can it really do? 
Docs suck at lest as bad as the pi's.

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: Feedback from the community -> ARM

[Gene Heskett]

On Thursday 10 June 2021 12:44:23 Marcin Juszkiewicz wrote:

> W dniu 10.06.2021 o 16:43, Uwe Kleine-König pisze:
> > next week there is a (virtual) meeting at ARM who invited some
> > people involved in Linux on ARM CPUs. One of the topics there is to
> > tell them Debian's needs and pain points.
> >
> > My current list (based on own experience and asking for feedback in
> > #debian-arm) currently has:
> >
> >   - Fragmentation
> >     - Vendor kernels vs. mainline
> >   This got better in the past is my subjective impression, but
> > it still hurts. Device tree made this a tad simpler, but it's not
> > unusual to have vendor specific bindings.
> >     - early boot code
> >   U-Boot (or general: bootloader) is device specific and more
> > often than not there is only a Vendor variant available.
> >   Also today there are more relevant components: ATF, UEFI/EDK2
> >     Vendors care at different intensities (and profit from external
> >     developers) Would Arm Base System Architecture (BSA) help? (This
> > is only for AArch64 though, arm32 still relevant for us.)
> >   - relevant SoC/SBC vendors:
> >     - Allwinner
> >     - Broadcom / RaspberryPi Foundation
> >     - Marvell
> >     - NXP
> >     - Odroid
> >     - Rockchip
> >     - some more for sure (which?)
> >   - Graphics
> >     Similar problematic, vendor blobs vs. OSS
> >
> > Is there anything on your mind that is missing above and that you'd
> > like to be shared with ARM?
>
> Sorry if it offends someone but I see Debian Arm team to be more
> Debian Arm SBC team. Sure, it is most of available hardware as it
> includes Windows-on-Arm laptops and Apple M1 systems too but Arm world
> has also something outside of SBC.
>
> My questions (probably get ignored):
>
> 1. When CBSA spec gets released? It is mentioned in BSA spec but
> not public.

New acronym, please define.

> 2. Are there plans to enforce BSA compliance for new designs?

> 3. How many years we need to wait for Arm systems to work out-of-
> the-box? I mean unpack, connect input/video/power, boot generic
> distro installer, install, reboot and use. So far there are
> nearly no such ones outside of server space.

This is also true, and a bit of a sore spot with me. Why? Because the pi 
folks furnish only the bare 4.19-something realtime kernel, only in 
source form direct from kernel.org if you want a real-time system, 
needed to run something like LinuxCNC, which is capable of running 99% 
of the CNC machines that make your fawncy toys on this planet. And with 
only a few exceptions, makeing product faster than the the machines 
original desgner had in mind.

They are snotty as hell, on their forum and will not offer any help in 
configureing, building, or installing that kernel. Questions are 
ignored, and if you ping the forum again, you will get invited to take a 
long walk off a short pier.

Because the pi's u-boot is configured differently from anybody else's, I 
spent a couple months studying how to install that kernel once it was 
built, and finally invented my own installer which has worked well now 
for over a year, on several more machines now, a very simple installer 
that unpacks a less than 30 meg tarball preconfigured to copy whats 
needed to the proper locations on the pi's u-sd boot card while its 
mounted in a card reader. And it Just Works. But it has been far from 
painless.

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: OT: Huge Right to Repair Win for Consumers

[Gene Heskett]

On Thursday 10 June 2021 00:53:57 John Paul Adrian Glaubitz wrote:

> On 6/10/21 2:08 AM, Paul Wise wrote:
> >> The report and its recommendations may provide a means
> >> to pierce the veil of closed platforms, like closed-sourced
> >> firmware.
> >
> > It seems unlikely to me that we will ever see a "Right to Repair"
> > for software, firmware or gateware.
>
> So, why should laws protect the intellectual property of software
> companies but not the IP of hardware companies?
>
> What supporters euphemistically call a "right to repair" is in reality
> an initiative against the right of companies to protect their
> intellectual property.
>
> Why should any company take the risk of investment for new hardware
> developments when they have to fear that every other company in the
> world will get free access to their blue prints?
>
> The claim that hardware companies intentionally make it hard to repair
> consumer products is a conspiracy theory. In reality, a consumer
> product is primarily optimized for production costs which implies
> cheap capacitors or cases that are glued together.
>
> Lots of consumers seem to forget that a product sold into the market
> not only must cover the material costs but also the costs of
> engineering, marketing, customer support, customs, compliance tests
> and so on. And in the end, you still want there to be a small profit
> left which is what makes the whole business model viable in the first
> place.
>
> If law initiatives also now want to take away the exclusive rights of
> hardware designers over their blueprints and hence the market
> advantage over competitors that they took an investment risk for,
> companies will lose the incentive to design and develop new products.
>
> Companies aren't charities so in the end they must protect their
> investments and have to make profits to survive.
>
> Adrian

In short, if you are in fact a debian developer as you imply in your sig, 
something I rather doubt given the thrust of this message, and I was on 
the controlliing end of debian, the first thing I would do is remove 
your account. Debian is being poisoned from within if people of your 
beliefs are allowed to contribute a single byte of code.

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: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Gene Heskett]

On Wednesday 03 March 2021 06:02:31 Alan Corey wrote:

> 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.
>
My first computer had 256 bytes, Alan. An RCA Cosmac Super Elf, with an 
1802 brain. I added another 4k of static ram, $400 for the kit I built 
that plugged into an s100 bus I also had to build, then programmed it to 
do a rather labor intensive and picture quality reducing job of 
preparing a u-matic tape with a commercial on it, to work with an 
automatic station break sequencer they had at KRCR, and getting rid of 
the pix blurring extra copy step. To me it was a learning experience in 
1979. In 1995 I took my then new wife of 6 years back to the left coast 
to meet one of my last surviving aunts and to see some of the country 
I'd lived in which took me within long distance range of calling that 
station.  Much to my surprise, it was so handy that 16 years later they 
were still using it many times a day. As a retired Chief Engineer of 
another medium market tv station, equipment in a tv station control room 
has an average lifetime of 2 to 5 years. To have something I designed 
and built still in daily use 16 years later was quite a surprise.

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: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Gene Heskett]

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 <http://ix.io/1MFf> and 64 Bit Kernel 5.4.
> <http://ix.io/2paq> 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 <http://geneslinuxbox.net:6309/gene>

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

[Gene Heskett]

On Sunday 21 February 2021 09:20:07 Jeffrey Walton wrote:

> On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
> > Hi.
> >
> > 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.
>
> > And last, but not least, having working RTC leads to meaningful
> > timestamps in log files that describe "early boot" (i.e. before NTP
> > time sync kicks in), and that's valuable to me by itself.
>
> Jeff

And I try to make it easy on the level2 servers (most distro 
naintained "pool.ntp.org" site that supply the net since I have 5 or 6 
machines running mostly 24/7, I've configured my router to rebroadcast 
on my local, not accessable home network. So that makes this router a 
level 17 server and all the rest of my boxes get time well wihin 5 
milliseconds of ntp. But to the level2 servers in the typical pool, I am 
just one client.

Since its a free service but they still have to pay for the bandwidth, 
and electricity to run them, it makes sense to cut the bytes used if you 
can.

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: Issues installing libc6:arm64 on amd64

[Gene Heskett]

On Friday 20 November 2020 09:44:04 Witold Baryluk wrote:

> Hi,
>
> I am not sure if this is the best mailing list, but couldn't find
> anything fitting better.
>
>
> I am using Debian testing on amd64.
>
> I am interested in testing qemu-user-aarch64 on my amd64 machine, so
> instead of setting up chroots, I decided to just try to use multi-arch
> and install some libraries and linkers, and then see from there.
>
> Unfortunately, it didn't work well for arm64.

Whatever gave you the idea that arm (aarch64) software, any version, 
compiled for arm would run on amd64 hardware? Different cpu's and 
architectures at the machine code level and they don't speak a 
compatible dialect of native language. Compilers are generally smart 
emough to make the src code work on either platform, but the binaries 
output will be incompatible. At best it will crash.

> $ dpkg --add-architecture arm64
> $ apt update
> $ apt install libc6:arm64 libgcc-s1:arm64 gcc-10-base:arm64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  adduser : Depends: passwd
>Depends: debconf (>= 0.5) but it is not going to be
> installed or debconf-2.0
>  emacs-nox : Depends: emacs-bin-common (= 1:27.1+1-3) but it is not
> going to be installed
>  Depends: emacs-common (= 1:27.1+1-3) but it is not going
> to be installed
>  Depends: libacl1 (>= 2.2.23) but it is not going to be
> installed Depends: libasound2 (>= 1.0.16)
>  Depends: libdbus-1-3 (>= 1.9.14) but it is not going to
> be installed
>  Depends: libgmp10 (>= 2:6.0.0) but it is not going to be
> installed Depends: libgnutls30 (>= 3.6.14) but it is not going to be
> installed
>  Depends: libgpm2 (>= 1.20.7) but it is not going to be
> installed Depends: libjansson4 (>= 2.7) but it is not going to be
> installed Depends: liblcms2-2 (>= 2.2+git20110628) but it is not going
> to be installed
>  Depends: libselinux1 (>= 3.1~) but it is not going to be
> installed Depends: libxml2 (>= 2.7.4) but it is not going to be
> installed erlang-crypto : Depends: libssl1.1 (>= 1.1.1) but it is not
> going to be installed
>  hunspell-fr : Depends: hunspell-fr-classical but it is not going to
> be installed or
> hunspell-fr-modern but it is not going to be
> installed or
> hunspell-fr-revised but it is not going to be
> installed or
> hunspell-fr-comprehensive but it is not going
> to be installed
>  libc6 : Depends: libgcc-s1 but it is not installable
>  Depends: libcrypt1 but it is not going to be installed
>  Depends: libnss-nis but it is not going to be installed
>  Depends: libnss-nisplus but it is not going to be installed
>  Recommends: libidn2-0 (>= 2.0.5~) but it is not going to be
> installed libssl1.1:arm64 : Depends: debconf:arm64 (>= 0.5) or
> debconf-2.0:arm64
>  libsystemd0 : PreDepends: libgcrypt20 (>= 1.8.0) but it is not going
> to be installed
>PreDepends: liblz4-1 (>= 0.0~r122) but it is not going
> to be installed
>PreDepends: liblzma5 (>= 5.1.1alpha+20120614) but it is
> not going to be installed
>PreDepends: libzstd1 (>= 1.4.0) but it is not going to
> be installed
>  procps : Depends: libncurses6 (>= 6) but it is not going to be
> installed Depends: libncursesw6 (>= 6) but it is not going to be
> installed Depends: libprocps8 (>= 2:3.3.16-1) but it is not going to
> be installed
>   Depends: init-system-helpers (>= 1.29~) but it is not going
> to be installed
>   Recommends: psmisc
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be
> caused by held packages.
> $
>
> I tried the same with `armhf`, and apt install libc6:armhf
> libgcc-s1:armhf gcc-10-base:armhf , installed without issues.
>
>
> Any help? Is this some transient issue with the repository?
>
>
> Cheers,
> Witold


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

[Gene Heskett]

ed 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.
>
Which may not be usable as noted below here but recall from your high 
school physics classes that any motor is also a generator.  And an 
earphone is itself also a microphone, but it may not and probably isn't 
hooked up with any back path gain that would make it actually usable as 
such. The only real exception the the rule that a motor is a generator 
is the universally used squirrel cage armature AC motor. They, not 
having a magnetically hard iron core, lose around 99.9% of their 
generating ability unless a dc current is passed thru the coils, which 
will induce a current in its short circuited armature, making an 
excellent brake to slow the motor by dumping all that rotational energy 
as heat in the relatively massive but short circuited armature. You can 
bring a 24,000 rpm motor to essentially a dead stop in much less than a 
second by that means.  Or a 40 lb lathe chuck from 100 rpm to 100 rpm in 
the other direction with only .25 turn of overshoot. I am doing it. But 
thats another subject often glossed over by the teacher, who may be 
reading a teleprompter script and doesn't understand the physics of it 
all.  And likely never will, sadly.  He makes a very poor teacher 
because of that. Should have been re-assigned to teach home-ec or 
something less technically well defined like physics.  Such a teacher 
was part of the reason I quite school in my freshman year and went to 
work fixing these new-fangled things called televisions for a living. 
That smartass, more interested in George Carlin stand up than actually 
teaching didn't understand Newtons third law. That statement of course 
dates itself to the later 40's of the last century. Now an old fart? 
guilty. :)  I'll start a new thread about the 17th of next month if the 
gismo I ordered doesn't work. So lets put a ~30~ on this one.

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


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

[Gene Heskett]

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

[Gene Heskett]

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>

Re: bt question

[Gene Heskett]

On Saturday 26 September 2020 04:22:31 deloptes wrote:

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

But wouldn't that be only if the phones were going to be used on the pi? 
I made no attempt to pair them since that is not where the phones will 
be used when they arrive at the rest home 40 some one way miles away 
from that pi.

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

[Gene Heskett]

On Saturday 26 September 2020 04:15:10 deloptes wrote:

> Gene Heskett wrote:
> > Can anyone else contribute here?
>
> What specification of BT hardware does your keyboard implement?

It doesn't say in the booklet accompanying the keyboard. And I don't 
recall seeing an FCC statement about it, which I assume is a legal 
requirement.

> The current linux version bluez5 seem to be working well with BT HW
> version 4, but not always with BT HW v2.
> Perhaps post make and model.

Thats debatable, I am confused by the markings on the shipping box, and 
on the keyboard as they do not match. The keyboard says SONART, with the 
circled R superscript and is not imprinted with a model number anyplace 
on it. There is a label on the right end, but its recycle instructions 
since its battery is a lithium-ion. Its a genuine no-name AFAIAC. My 
wife is down to around 65 lbs, and it was the lightest full sized 88 key 
keyboard I could find at 15 lbs, sells for $169 at www.walmart.com. I 
first bought a Yamaha P45B, which is a $520 keyboard, thinking it ought 
to have BT, but while its a great keyboard, it doesn't have BT, just 
general midi. And is also 36 lbs. No way in hell she could pick that up 
and put it on the tray-table to play it at a Good Sam's home. Speakers 
are 2" junk and very low powered.

The rooms at Good Sam's are double so we're assuming the headphones are 
needed so as not to disturb the roomy when she plays it. She plays well, 
often from memory, a retired music teacher. We also have a small upright 
but its not been tuned in 25 years. No line cord on that obviously.
>
> Also do you have BT HID installed/configured? Because keyboards are
> HID devises (If I am not mistaken)
> https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles

The keyboard and mouse on the pi are HID wireless so I'd assume yes.

Which seems to be for mainly for mobile phone headsets, and the huge 
market for those 2 way devices. Everything else reads like placeholders 
in a first draft.

> It is strange that the device is not discovered. This is why I ask the
> first question. If it were discovered but can not connect, it could be
> the second, but who knows.

A good question, the total lack of discovery makes me want to warranty 
it, but that is a prolonged process I'd druther not waste time I maybe 
don't have doing it. Her major problem is COPD, end stage.  So I 
ordered, last night, a bt kit to put a remote phones broadcaster kit on 
a tv, but estimated arrival is 3 weeks, Oct 16th. Almost 2 months now 
already, and she is understandably upset with me for all the delays.

> regards


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

[Gene Heskett]

On Friday 25 September 2020 21:24:53 Alan Corey wrote:

> dscoverable on.
syntax error, miss-spelled ;-)
scan on, followed by show, gets this
CHG] Controller DC:A6:32:0D:9E:45 Discoverable: no
[bluetooth]# show
Controller DC:A6:32:0D:9E:45 (public)
Name: rpi4.coyote.den
Alias: rpi4.coyote.den
Class: 0x0048
Powered: yes
Discoverable: no
Pairable: yes
UUID: Headset AG
(1112--1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile 
(1801--1000-8000-00805f9b34fb)
UUID: A/V Remote Control
(110e--1000-8000-00805f9b34fb)
UUID: Generic Access Profile
(1800--1000-8000-00805f9b34fb)
UUID: PnP Information   
(1200--1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target 
(110c--1000-8000-00805f9b34fb)
UUID: Audio Source  
(110a--1000-8000-00805f9b34fb)
UUID: Handsfree Audio Gateway   
(111f--1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0532
Discovering: yes
for the headset, turned on in bt mode, laying on the other side of the 
houses alu siding wall. Looks promising to me, so I'd say the headset is 
working and its the musical keyboard that is not. But now let me go turn 
on that keyboard and see if it is discovered. Ok, it is powered up, and 
the headphones are now on my ears and several rooms farther away from 
the pi, which is on the back of the Sheldon lathe in the garage. But a 
repeat of show only lists the headset again.  So this keyboard is 
apparently not discoverable.  I wonder if this is a valid warranty claim 
against the keyboard?  Its an 88 key piano keyboard, with shitty 
speakers but sounds good in these phones if a cable is plugged in 
connecting them together, something I would rather the piano playing 
wife, now in a nursing home, would rather not have to deal with.  
Bedfast, she wanted something to play to help the arthritis pain in her 
hands, so thats what this is all about. 
I just turned the phones off. But the pi has apparently buffered the data 
as it still show's as above.

Thank you for the tutorial Alan, I appreciate it.  What do you make of 
the above data and the non-discovery of the keyboard? 

The keyboard has no menu entry for bt control, but there are instructions 
in its teeny booklet for 3 different brands of smart phones to download 
an app to talk to it, command and control for its canned features from 
reading between the lines, but we have no smart phones. So it appears I 
need to find and buy some sort of a gismo that plugs into the 1/8" 
headphone jack, and connects the headphones, yet a 3rd item to have to 
recharge the batteries in. I've a usb2 hub she can plug them all in to 
recharge them.

Can anyone else contribute here?

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>

bt question

[Gene Heskett]

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 <http://geneslinuxbox.net:6309/gene>

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

[Gene Heskett]

On Tuesday 31 March 2020 12:08:35 Pete Batard wrote:

> Hi Ralph,
>
> On 2020.03.31 15:24, Ralph Aichinger wrote:
[...]
> If you want to help, maybe report that the bug I pointed out above
> affects you too, since, if you can live without SD support, it's
> pretty much the one thing that stands in the way of being able to use
> the vanilla netinst ISOs on the Pi 4.
>
> > I hope the tone of this message does not come across as demanding,
> > pushy  or unfriendly, I really do appreciate all your work in
> > the arm port, I have been using arm devices as my servers at
> > home for years now, and I am very grateful that these devices
> > can run with a sane Debian based OS. But I think using
> > vanilla Debian on the Pi should be a lot easier than it is
> > now.
>
> Amen!
>
> We're doing what we can to make that happen on the UEFI side, and I
> believe we are already there in terms of providing a usable means of
> installing and running vanilla Debian on the Pi 4, at least from USB.
>
> The only thing that's missing, really, is for Debian folks to
> integrate the retrofitted Genet network driver, which we submitted 2
> months ago, in the vanilla aarch64 installation images...
>
Tweaks my curiosity. That driver doesn't exist in the raspi armhf build 
from raspbian, yet the networking is flawless. I run a host file based 
net config, and it Just works.

> Regards,
>
> /Pete


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: Resize a disk image from 32G to 4G or copy u-boot?

[Gene Heskett]

On Wednesday 25 March 2020 09:51:03 gru...@mailfence.com wrote:

> On Wed, 25 Mar 2020, Gene Heskett wrote:
> > On Wednesday 25 March 2020 08:51:17 gru...@mailfence.com wrote:
> >> On Wed, 25 Mar 2020, Gene Heskett wrote:
> >>> On Wednesday 25 March 2020 04:18:20 Andrei POPESCU wrote:
> >>>> On Ma, 24 mar 20, 19:12:46, Gene Heskett wrote:
> >>>>> 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.
> >>>>
> >>>> You could do this with the 'sparse' option of dd (you might need
> >>>> to fill the partition with a file containing only zeroes first).
> >>>>
> >>>> The resulting file must be handled with care as many tools (cp,
> >>>> rsync) will un-sparse it by default, as will writing it to a
> >>>> filesystem without support for sparse files (tar it first).
> >>>>
> >>>> To see the actual size with ls you will have to use -s/--size.
> >>>>
> >>>>> 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.
> >>>>
> >>>> Just create the partitions slightly smaller than the size of the
> >>>> SD card.
> >>>
> >>> I've also considered that, but then you risk losing the gpt tables
> >>> and it all disappears in the cloud of blue smoke being emmited
> >>> from ones ears.
> >>>
> >>> BTDT at least twice on arm systems. The distro folks have it and
> >>> use it to make an install image of 5 gigs, unpacks to 7 or 8G and
> >>> which can then be auto expanded on the first reboot to fill the
> >>> card, so they know how to do it, why can't the user make backups
> >>> from a deployed well running system that could be put on a fresh
> >>> u-sd card and treated exactly the same for recovery purposes?
> >>
> >> could you not just dd to a file and then manipulate that file to
> >> suit you but i would never dd a running system
> >
> > Amanda has very occassional problems with that as all its backups
> > are from a live system.
>
> doing backups of files and creating an image are apples and oranges
> it sounded like you wanted an image that could be redeployed
> if you create an image and save a copy on your backup server
> exclude it from your amanda backup since it will never change

Not true as I update about weekly. Both raspbian and LinuxCNC which I 
build from a fresh git pull of Master about weekly, there by keeping my 
debs up to date. And my config also gets updated when more gingerbread 
gets added to the GUI. It has several extras such as a readout of both 
chuck overtravel at the bottom of the hole and If I export the tpi or 
tpmm via an m68 command I get a overshoot depth display which I intend 
to ship back to the gcode and use to automatically trim the depth of the 
g33.1 command. the idea being to stop it from hitting the bottom of a 
blind hole and breaking the tap. One can EDM the broken tap out and save 
the part but it takes a good piece of a day to do as my EDM supply is a 
bit puny. This is something that LinuxCNC doesn't normally do. Neither 
does anybody else's control software that I've come in contact with.

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: Resize a disk image from 32G to 4G or copy u-boot?

[Gene Heskett]

On Wednesday 25 March 2020 08:51:17 gru...@mailfence.com wrote:

> On Wed, 25 Mar 2020, Gene Heskett wrote:
> > On Wednesday 25 March 2020 04:18:20 Andrei POPESCU wrote:
> >> On Ma, 24 mar 20, 19:12:46, Gene Heskett wrote:
> >>> 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.
> >>
> >> You could do this with the 'sparse' option of dd (you might need to
> >> fill the partition with a file containing only zeroes first).
> >>
> >> The resulting file must be handled with care as many tools (cp,
> >> rsync) will un-sparse it by default, as will writing it to a
> >> filesystem without support for sparse files (tar it first).
> >>
> >> To see the actual size with ls you will have to use -s/--size.
> >>
> >>> 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.
> >>
> >> Just create the partitions slightly smaller than the size of the SD
> >> card.
> >
> > I've also considered that, but then you risk losing the gpt tables
> > and it all disappears in the cloud of blue smoke being emmited from
> > ones ears.
> >
> > BTDT at least twice on arm systems. The distro folks have it and use
> > it to make an install image of 5 gigs, unpacks to 7 or 8G and which
> > can then be auto expanded on the first reboot to fill the card, so
> > they know how to do it, why can't the user make backups from a
> > deployed well running system that could be put on a fresh u-sd card
> > and treated exactly the same for recovery purposes?
>
> could you not just dd to a file and then manipulate that file to suit
> you but i would never dd a running system

Amanda has very occassional problems with that as all its backups are 
from a live system.

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: Resize a disk image from 32G to 4G or copy u-boot?

[Gene Heskett]

On Wednesday 25 March 2020 07:26:12 Nate Bargmann wrote:

> * On 2020 25 Mar 00:11 -0500, Alan Corey wrote:
> > Try your kernel config string.  On this Pi /boot/cmdline.txt has
> > root=PARTUUID=d9b3f436-02
>
> Except I'm not working with a Pi.  Yes, I've done the exact same thing
> in the past on a Pi.  Pi's are easy peasy.  This is a different animal
> that has p1/boot.scr that is a binary/ascii file that u-boot, which is
> written to the area of the first 1 MB of the mmc, reads as a bootup
> script.  The UUID is not hard coded into this file as far as I can
> see.
>
> The board I am working with is an Olimex A20-OLinuXino-LIME2.
>
> I just need to figure out why I'm still getting a kernel panic stating
> the rootfs is not found even though I've updated the UUID on the 4 GB
> card in every location I could find it and I set the label for p2 to
> "root" as it is on the 32 GB card.
>
> - Nate

Has it occured to you that "root" is often used to mean the root of the 
filesystem?  Aka "/".

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: Resize a disk image from 32G to 4G or copy u-boot?

[Gene Heskett]

On Wednesday 25 March 2020 04:18:20 Andrei POPESCU wrote:

> On Ma, 24 mar 20, 19:12:46, Gene Heskett wrote:
> > 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.
>
> You could do this with the 'sparse' option of dd (you might need to
> fill the partition with a file containing only zeroes first).
>
> The resulting file must be handled with care as many tools (cp, rsync)
> will un-sparse it by default, as will writing it to a filesystem
> without support for sparse files (tar it first).
>
> To see the actual size with ls you will have to use -s/--size.
>
> > 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.
>
> Just create the partitions slightly smaller than the size of the SD
> card.

I've also considered that, but then you risk losing the gpt tables and it 
all disappears in the cloud of blue smoke being emmited from ones ears. 

BTDT at least twice on arm systems. The distro folks have it and use it 
to make an install image of 5 gigs, unpacks to 7 or 8G and which can 
then be auto expanded on the first reboot to fill the card, so they know 
how to do it, why can't the user make backups from a deployed well 
running system that could be put on a fresh u-sd card and treated 
exactly the same for recovery purposes?

> Kind regards,
> Andrei


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: Resize a disk image from 32G to 4G or copy u-boot?

[Gene Heskett]

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


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: Raspberry Pi

[Gene Heskett]

On Monday 02 March 2020 11:25:32 Reco wrote:

>   Hi.
>
> On Mon, Mar 02, 2020 at 09:01:48AM -0500, Alan Corey wrote:
> > Yes, the Pinebook Pro has a T860 Mali which supposedly
> > is compatible with Vulkan. https://www.pine64.org/pinebook-pro/
>
> If we're talking about Mesa's implementation, you'll need recently
> released Mesa 20.0, and it's not quite there yet.
> I see little point in discussing non-free blobs of questionable
> quality.
>
> > I've been trying to find something to learn Vulkan on, I can't quite
> > do it on an RPI 3B,
>
> Consider using vc4 instead of Broadcom blob, for starters.
> And no, it's not Mali, it's VideoCore.
> A hint - it involves removing that /opt/vc for good.
>
> > Rock64,
>
> Fresh mesa required.
>
> > or Odroid N2
>
> Has very basic DRI support as of Mesa 20.0 and no free OpenGL/GLES
> implementation at all.
>
> > I would consider a limit a defect if there's no way to disable it
> > for benchmarking purposes,
>
> Glxgears is an old and somewhat obsolete benchmark.
> Try using glmark instead.
>
> Reco
Unforch here, glmark can't be found by apt on a raspi buster 10.3 on an 
rpi4b.


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: Raspberry Pi

[Gene Heskett]

On Sunday 01 March 2020 13:31:21 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

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.  Then we who do carve 
steel are back to haunting the used boards market for the few surviving 
Intel D-525-MW motherboards left in the wild, hoping everything on the 
one we're buying blind on fleabay, still works.  And paying $30 more 
than it sold for new for the privilege of taking that chance.

Debian has a nice 64 bit net install, works well and had power bump to 
power bump uptime in both an rpi3b and an rpi4b. So I built a couple 64 
bit realtime kernels.  Realtime-preempt for these so called kernels was 
so poor and latency so long that 3/4 ton of moving machinery ran out of 
buffer to keep it moving and stopped for lack of data in the buffer, 
latency's were well over an millisec at times. running out of data in 
excess of a  millisecond several times a foot. An armhf kernel has 10% 
of the peak latency of an arm64 kernel and runs that same machine from 
an rpi4b with zero such stutters, while running the cpu's in an rpi4b at 
only 800 Mhz.

There are 2 huge advantages to the debian arm64 builds, 1; it boots from 
grub, and that seems to get rid of the /boot/overlay directory that only 
raspbian (that I know of) uses, and which ATM means you have to use the 
raspbian supplied src to build an preempt-rt kernel that will actually 
boot on a pi. That, and only the raspi supplied srcs know about the mali 
video, giving us full screen glxgears at 60 fps since buster 10.2. 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.  Bottom line

Re: Raspberry Pi

[Gene Heskett]

On Sunday 01 March 2020 05:31:04 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.

Yes, I've done it, works fine, with one glaring exception all the 64 bit 
fans refuse to recognize.

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.
>
> Please see either:
> https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.h
>tml or
> https://www.raspberrypi.org/forums/viewtopic.php?f=50=249449=84f
>ebcd504e6159355215ff8b8fa6d67
>
> Regards,
>
> /Pete


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: arm64-net-install buster 10.2

[Gene Heskett]

On Monday 03 February 2020 14:53:09 Lennart Sorensen wrote:

> On Mon, Feb 03, 2020 at 01:50:25PM -0500, Gene Heskett wrote:
> > I have no "leveerage" with raspbian. They officially have zero
> > support for a realtime kernel. 4 posts to their forum in threads
> > related, over4 days have not elicited a reply from anyone.
> >
> > I have no problems building kernels on the rpi4b as I two SSD'd
> > mounted on sata-usb3 cables, so a full kernel bulld is under an hour
> > in wall time.  I also, because its only a 2G pi, have a 10G swap
> > partition mounted, and the swapfile turned off to reduce pressure on
> > the u-sd card.
> >
> > The pi-4b is a whole new critter worth looking at.
> >
> > It is supported upstream by any linux-rt kernel newer than 4.14
> > although 4.14's support for the mali gfx isn't quite fully baked
> > until 4.19.y.
>
> Ehm, I was pretty sure all Raspberry Pi models have broadcom videocore
> graphics, and certainly not mali.
>
> > I am actually running a
> >
> > Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Oct 10
> > 15:22:22 EDT 2019 armv7l GNU/Linux
> >
> > right now, but a /boot/dts/overlays directory has apparently been
> > removed from newer ones, and I'm trying to find a workaround, or
> > make an arm64 boot work and rebuild LinuxCNC to run on a 64 bit
> > build. I'd settle for either scenario.
> >
> > So it would appear Len. And I'll repeat, the original 10.0
> > netinstall Just Worked, and felt dead stable, but now a 10.2 of this
> > buster doesn't even try to boot.  The main diff is that there is now
> > a pair of ssd's on sata adaptors plugged into the usb-3 ports with a
> > total of 360G available as scratchpad workspaces.
>
> I don't see how adding USB disks should change anything.
>
> Did you upgrade the working 10.0 system, or did you do a new image?
> Because the only think that makes sense to me is that the 10.0 image
> wasn't a pure Debian image, but rather one modified enough for RPi4
> operation.
>
It Just ran, updated to 10.2 by apt upgreade. Nothing heroic at all.

> > Thanks Len, for any enlightement.
>
> I don't have a 4 (only a 2 and 3 so far).  What I have read made me
> think that it simply should not work so far with Debian.  There
> appears to be some unofficial modified images out that that should
> work.


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: arm64-net-install buster 10.2

[Gene Heskett]

On Monday 03 February 2020 14:21:37 Pete Batard wrote:

> Hi,
>
> On 2020.02.03 15:53, Lennart Sorensen wrote:
> > On Mon, Feb 03, 2020 at 10:41:17AM -0500, Gene Heskett wrote:
> >> Written to a 64GB card with dd, makes zero attempt to boot on rp4b.
> >>
> >> Put presently running raspbian buster 10.2 card back in, boots up
> >> normal.
> >>
> >> Suggestions?
> >
> > According to https://wiki.debian.org/RaspberryPi there is no support
> > for the Pi4 in Debian's kernel yet (after all it has to be supported
> > upstream before Debian will support it).  Raspbian has no issues
> > with using a patched kernel with stuff that isn't supported upstream
> > yet as long as it makes Pi models work with it.
>
> Well, if you can live without SD support and with ACPI rather than
> Device Tree, then please be aware that I have just sent a patch that
> should enable netinst of *vanilla* Debian ARM64 on a Raspberry Pi 4 in
> ACPI mode, when using the EDK2 UEFI firmware from mainline
> edk2-platforms (See [1]).
>
> The patch can be found at [2] and I am really hoping this can be
> fast-tracked for inclusion into 10.3, so that native netinst on the Pi
> 4 becomes about as easy as an x86 PC install.
>
> Obviously, there are a few caveats:
> - Because the RPi4's weird DMA and other matters, DT boot from UEFI is
> currently NO_GO, so only ACPI will work. Which means that, until we
> also sort an ACPI driver support for SDHC (which looks like this will
> require some work, as it's not as easy as adding a few ACPI binding to
> sdhc-iproc as we did for bcmgenet), you can forget about SD card
> support. Then again, USB 3.0 mass storage support seems to work
> brilliantly, and is much faster than SD anyway, so you're better off
> running Debian from USB anyway...
> - Also because of DMA, you will be limited to 3 GB RAM if you use the
> 4 GB model. Of course, we're working on removing that limit.
> - The relevant ACPI patches for networking are currently being
> integrated into EDK2, so the firmware binaries I pointed to in [1]
> don't have them yet (which means that, even if you apply the patch
> from [2] and rebuild your own kernel, networking won't work until you
> get a UEFI firmware with the relevant patches applied. But this should
> become a moot point soon hopefully).
> - Of course, since this is new development, the network stack may not
> be entirely stable at this stage. Personally, I've been observing some
> packet losses, that other people don't seem to observe, though those
> losses don't seem to prevent the system from downloading updates and
> stuff.
>
> Still, if you plan to install vanilla Debian on the Pi 4 through
> net-install, and provided that the proposed patch gets applied, the
> next ARM64 vanilla ISOs should allow you do just that...
>
> Regards,
>
> /Pete

At 10.0 no UEFI in site, network worked fine once I convinced it it was a 
hostname and hosts based lookup, although i do seem to recall blowing 
away dchpdc5 or something, what ever it was that insisted my route came 
from agahi.  Once that was done it did everything I asked it to  do for 
about a month, with zero hiccups until I had to get my heart rebuilt (
new aortic valve and a bunch of stents, and the lathe running as I had to 
make something that was bigger than my 7x12 could handle well.


> [1] https://github.com/pftf/RPi4
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950578


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: arm64-net-install buster 10.2

[Gene Heskett]

On Monday 03 February 2020 11:34:41 Nigel Sollars wrote:

> Perhaps you could leverage this from raspian,

I have no "leveerage" with raspbian. They officially have zero support 
for a realtime kernel. 4 posts to their forum in threads related, over4 
days have not elicited a reply from anyone.

I have no problems building kernels on the rpi4b as I two SSD'd mounted 
on sata-usb3 cables, so a full kernel bulld is under an hour in wall 
time.  I also, because its only a 2G pi, have a 10G swap partition 
mounted, and the swapfile turned off to reduce pressure on the u-sd 
card.

> https://lb.raspberrypi.org/forums/viewtopic.php?t=245908
>
> I dont have any experience with this one nor have hardware ( not a pi
> fan ).  More Pi4 SoC info came in with 5.4/5 anyhow so you would want
> something recent to get it done.

The pi-4b is a whole new critter worth looking at.
> Nige
>
> On Mon, Feb 3, 2020 at 11:00 AM Lennart Sorensen
>
>  wrote:
> > On Mon, Feb 03, 2020 at 10:41:17AM -0500, Gene Heskett wrote:
> > > Written to a 64GB card with dd, makes zero attempt to boot on
> > > rp4b.
> > >
> > > Put presently running raspbian buster 10.2 card back in, boots up
> > > normal.
> > >
> > > Suggestions?
> >
> > According to https://wiki.debian.org/RaspberryPi there is no support
> > for the Pi4 in Debian's kernel yet (after all it has to be supported
> > upstream before Debian will support it).
It is supported upstream by any linux-rt kernel newer than 4.14 although 
4.14's support for the mali gfx isn't quite fully baked until 4.19.y.

I am actually running a 

Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Oct 10 
15:22:22 EDT 2019 armv7l GNU/Linux

right now, but a /boot/dts/overlays directory has apparently been removed 
from newer ones, and I'm trying to find a workaround, or make an arm64 
boot work and rebuild LinuxCNC to run on a 64 bit build. I'd settle for 
either scenario.

> > Raspbian has no issues  
> > with using a patched kernel with stuff that isn't supported upstream
> > yet as long as it makes Pi models work with it.
> >
> > Also the boot process for the 4 is completely different than the
> > older models as far as I know.

So it would appear Len. And I'll repeat, the original 10.0 netinstall 
Just Worked, and felt dead stable, but now a 10.2 of this buster doesn't 
even try to boot.  The main diff is that there is now a pair of ssd's on 
sata adaptors plugged into the usb-3 ports with a total of 360G 
available as scratchpad workspaces.
> >
> > --
> > Len Sorensen

Thanks Len, for any enlightement.

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: arm64-net-install buster 10.2

[Gene Heskett]

On Monday 03 February 2020 10:53:31 Lennart Sorensen wrote:

> On Mon, Feb 03, 2020 at 10:41:17AM -0500, Gene Heskett wrote:
> > Written to a 64GB card with dd, makes zero attempt to boot on rp4b.
> >
> > Put presently running raspbian buster 10.2 card back in, boots up
> > normal.
> >
> > Suggestions?
>
> According to https://wiki.debian.org/RaspberryPi there is no support
> for the Pi4 in Debian's kernel yet (after all it has to be supported
> upstream before Debian will support it).  Raspbian has no issues with
> using a patched kernel with stuff that isn't supported upstream yet as
> long as it makes Pi models work with it.
>
> Also the boot process for the 4 is completely different than the older
> models as far as I know.

Thanks Lennart S. I also tried your (debian) arm64-net-install image from 
this mornings download, does not cause any green led activity that I've 
been able to *catch* when a card with it is inserted and power applied.

* my pi is mounted upside down because of cabling to interface boards, 
and I can't reach the pwr switch on its ups and see it at the exact same 
time, so there's perhaps 1.5 seconds before I can get around the cabinet 
door to see it. I do know it worked for 10.0 in early Oct of 2019, now 
the 10.2 version does not.

Thanks.

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>

arm64-net-install buster 10.2

[Gene Heskett]

Written to a 64GB card with dd, makes zero attempt to boot on rp4b.

Put presently running raspbian buster 10.2 card back in, boots up normal.

Suggestions?

Thanks.

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: Build Kernel 5.5 RC3 for Raspberry4

[Gene Heskett]

t;>>> which file is used there?
> >>>>>
> >>>>> On 01.01.20 05:23, Nigel Sollars wrote:
> >>>>>> Just took a look at the bootlog there,  those GPIO failures
> >>>>>> arnt clever,  missing firmware I would take a wild guess that
> >>>>>> things in the latest kernel tree has changed I did also see an
> >>>>>> article about newer support for the Pi 4 in the latest kernel (
> >>>>>> cant remember if its 5.4 or 5.5 ).  Do you use 'make
> >>>>>> menuconfig'?.  the size difference you mention with those
> >>>>>> errors do point to you not enabling the needful
> >>>>>>
> >>>>>> Looks like 4.19 has been the latest for along time,  I would
> >>>>>> diff your 5.5 config with the 4.19 and see what you have
> >>>>>> missing / what has moved / changed.  A quick google does not
> >>>>>> yield much so you could be very much on your own / pioneering
> >>>>>> this one.
> >>>>>>
> >>>>>> Hopefully helpful links
> >>>>>>
> >>>>>> Someone to perhaps reach out to for info,
> >>>>>> https://forum.manjaro.org/t/raspberry-pi-4-5-4-1-kernel/114273
> >>>>>>
> >>>>>> 5.5 Graphics / better support by all accounts,
> >>>>>>
> >>>>>> https://www.phoronix.com/scan.php?page=article=linux-55-fe
> >>>>>>atures=1
> >>>>>> https://www.linux-arm.info/index.php/1537-linux-5-5-lands-broad
> >>>>>>com-bcm2711-raspberry-pi-4-bits
> >>>>>>
> >>>>>> again hope this helps
> >>>>>>
> >>>>>> Nige
> >>>>>>
> >>>>>> On Tue, Dec 31, 2019 at 5:18 AM basti 
 wrote:
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I have try to build kernel for raspi4 from upstream (5.5-rc3).
> >>>>>>> Kernel boot but can't find the SD Card, so there is no
> >>>>>>> partition, no root-fs and end up in initramfs/busybox.
> >>>>>>>
> >>>>>>> Log of serial console is attached. I have used U-boot and dtb
> >>>>>>> from ubuntu image. My dtb build during kernel build is a half
> >>>>>>> size of the ubuntu one and doesn't work.
> >>>>>>>
> >>>>>>> the custom build kernel works on rpi3 out of the box.
> >>>>>>>
> >>>>>>> best regards
> >>>>>>>
> >>>>>>> p.s. i build it as deb package


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: MP30-AR0 arm64 sdcard slot not detected

[Gene Heskett]

On Sunday 20 October 2019 09:19:00 Alan Corey wrote:

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

I've some pi's here, they they always id the sd they boot from 
as /dev/mmcblk+ an identifier, on both a pi3 and a pi4.  
The card readers always sign in ack a dmesg report as /dev/sda|b|c|d etc 
plus the partition number. And thats the same for this stretch on amd64 
as it is on the pi's. No clue of course how your gigabyte bios might 
handle that. I just rebooted this amd64 stretch, I was up to /dev/sdi# 
for the card readers. Lots of traffic there as I build boot cards for 
the pi's, on the pi's but move the image to this machine about half the 
time to write the card. The lack of spare ports on the pi's is the main 
reason as I've a pair of ssd's I use as scratchpads when building new 
images or debs of linuxcnc.  The pi's are actually running machine shop 
stuff like metal lathes and multi-axis mills. They run the machines 
nicely, but the video on the pi3 is rather glacial. So once its had 
another 2 hours to warm up I'll open the garage door for working room 
and swap the pi3 running a medium sized (11x54) Sheldon lathe, out for a 
pi4 with about 20x faster video.

I may have grown old at 85, but I've never grown up. :)

The reason I stuck my hand up is that the sd cards are generally accessed 
via an spi path, whereas the mmc's have a more parallel interface for 
higher bandwidth. So to clarify, read the helps for the spi stuff in 
your config as something missing there might preclude the proper 
detection of the sd hardware.

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