Libre Computer Raspbian Portability Feedback

Software
42

I can’t seem to be able to install the dahdi module…

Loading new asl-dahdi-3.0.1.20200801-0.1 DKMS files…
Building for 6.0.8-00789-g99a6460d70b3
Building initial module for 6.0.8-00789-g99a6460d70b3
Error! Bad return status for module build on kernel: 6.0.8-00789-g99a6460d70b3 (aarch64)
Consult /var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/make.log for more information.
dpkg: error processing package asl-dahdi-dkms (–configure):
installed asl-dahdi-dkms package post-installation script subprocess returned error exit status 10
Processing triggers for man-db (2.8.5-2) …
Processing triggers for systemd (241-7~deb10u8+rpi1) …
Errors were encountered while processing:
asl-dahdi-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)

DKMS make.log for asl-dahdi-3.0.1.20200801-0.1 for kernel 6.0.8-00789-g99a6460d70b3 (aarch64)
Tue 15 Nov 2022 07:24:04 PM EST
make -C drivers/dahdi/firmware firmware-loaders
make[1]: Entering directory ‘/var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi/firmware’
make[1]: Leaving directory ‘/var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi/firmware’
make -C /lib/modules/6.0.8-00789-g99a6460d70b3/build M=/var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi DAHDI_INCLUDE=/var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[1]: Entering directory ‘/usr/src/linux-headers-6.0.8-00789-g99a6460d70b3’
warning: the compiler differs from the one used to build the kernel
The kernel was built by: gcc (Debian 8.3.0-6) 8.3.0
You are using: gcc (Raspbian 8.3.0-6+rpi1) 8.3.0
/var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi/Kbuild:61: CPU Architecture ‘arm64’ does not support VPMADT032 or HPEC. Skipping.
CC [M] /var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi/dahdi-base.o
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
gcc: error: unrecognized command line option ‘-msign-return-address=all’
make[2]: *** [scripts/Makefile.build:249: /var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi/dahdi-base.o] Error 1
make[1]: *** [Makefile:1852: /var/lib/dkms/asl-dahdi/3.0.1.20200801-0.1/build/drivers/dahdi] Error 2
make[1]: Leaving directory ‘/usr/src/linux-headers-6.0.8-00789-g99a6460d70b3’
make: *** [Makefile:74: modules] Error 2

Another hat, besides the MMDVM dual channel I would like to use is the SHARI PiHat.

https://kitsforhams.com/shari-pihat

Is there going to be any support for these? Or is there a way to interface with these?
These Libre Computers have the same pin header connections? How can I interface with these hats?

43

We already have guides on how to enable UART. It is up to the device implementers to handle drivers. Please contact the authors of the projects and point them here. All of our stuff is based on standard upstream Linux. If their code is written properly, it should work. If not, then they need to be the ones who fix it.

We cannot be engineering support for xyz device manufacturer’s products. We can only build our stuff to standards and hope that others follow standards and maintain their code base.

44

How can I fix this issue? Is there a Debian image available for this board yet?

45

What you are doing is not productive. You are trying a lot of hacks that are not appropriate and will not fix the problem. Switching to obsolete images is not going to solve your problems with device drivers and/or poorly written userspace. It’s best to find the source code to the various components of the project so we can provide you with the feedback on their state and what to change and who should fix what.

First, open a new thread instead of replying to existing threads with non-relevant replies. Then, try to aggregate documentation on the hardware and software. We can provide you feedback on each piece.

46

I am looking for Debian 10 (not Debian 9, I gave up on stretch) Debian 9 is on loverpi but I want buster.

Here is what I am trying next: - beta - runs on buster - maybe you can shed some light

https://wiki.allstarlink.org/wiki/ASL_FAQ

–Created a new topic, even though this is a patched Raspbian 10 using LRP.

47
48

Pi-Star Downloads - pistar.uk
The Pi-Star is another program. And it didn’t work. I booted with GParted and moved the ext4 (not resized yet) partition to give 64MB more to /boot and gave it 128MB before booting with PI and it all worked fine. Did the L-C-R-P patch but it did not boot. The hat doesn’t even work, so no sense in trying… I’m about to give up on these Libre Computers…

@librecomputer any news on this?

49

Is there even source code for that project? Also, it’s not related to the portability tool so best to open a new thread.

50

Are you using Win23DiskImager to write the images to the SD cards? If so, I’m encountering exact the same issue (and yes, the sector is always 8192).

I always solve this by writing again the image to the SD card for the second time. So far, for all the images I’ve flashed (and there’s quite a few!) the verification has always been successful the second time.

Don’t ask me why Win32DiskImager behaves like that, but that’s a “quirk” I’m willing to take since otherwise it’s an excellent program.

51

Windows or other software like antivirus sometimes will mount the drive. This will cause the contents on the disk to change. 8192 is the offset of the first FAT partition which Windows can read and automatically tries to mount. That is why automount should be disabled just in case.

52

So, I have run the portability script and all went fine. I can use the SD card in a Le Potato board and it starts up without problems.

The main reason why I’ve run the portability script is the following:
On my current Raspberry Pi boards 2B/3B+ I’ve added the following line in the /boot/config.txt file:

dtoverlay=i2c-mux,pca9548,addr=0x70

Linux has built-in support for a few I2c mux/switches, one of them being the PCA9548 (or a variant of it). By default, this support is not activated unless you activate the above mentioned device tree overlay.

If activated, the Linux kernel will automatically “sense” at boot up if there’s an I2c multiplexer 9548 connected to the I2c bus on address 0x70. If so, then the Linux kernel driver will create 8 additional I2c devices (/dev/i2c-11 until /dev/i2c-18).

If you command your software to send something to, say, /dev/i2c-13 then the Linux kernel will automatically change the position of the I2c switch to the correct I2c output prior to sending the I2c command on the bus so that your command will arrive on the correct I2c bus where an I2c device can pick it up and handle accordingly.
You don’t have to tinker yourself in your software to change the I2c switch position before you send out your I2c command for a device on that bus.
Extremely handy and it gives you another 8 extra I2c buses.

Now my question:
After running the portability switch and adding the above dt overlay command in the /boot/config.txt file, will Le Potato do the same as the Raspberry Pi does? In other words, will it also activate that internal Linux module for the I2c mux that senses if there’s a PCA9548 connected to the I2c bus at startup? Will it then also automatically set the I2c switch in the correct position for certain I2c devices on certain I2c buses?
Or do I still have to make a device tree overlay file myself (such as the i2c-ao.dts and the likes) and add/merge it to the overall overlay file?

53

config.txt is Raspberry Pi specific. Per the Raspbian release notes, config.txt do not do anything on our images. We have the wiring tool. You need to write a device tree overlay or copy the device tree overlay from Raspberry Pi and modify it.

54

I have good news. I was able to create a DTS file for the PCA9548 and when I compiled, installed and enabled the module, I got the following message in the dmesg feedback:

[ 3711.951406] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/bus@c8100000/i2c@500/status
[ 3711.960088] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /__symbols__/pca9548
[ 3711.971380] i2c i2c-0: Added multiplexed i2c bus 1
[ 3711.973785] i2c i2c-0: Added multiplexed i2c bus 2
[ 3711.984706] i2c i2c-0: Added multiplexed i2c bus 3
[ 3711.991326] i2c i2c-0: Added multiplexed i2c bus 4
[ 3712.002107] i2c i2c-0: Added multiplexed i2c bus 5
[ 3712.012163] i2c i2c-0: Added multiplexed i2c bus 6
[ 3712.019968] i2c i2c-0: Added multiplexed i2c bus 7
[ 3712.027143] i2c i2c-0: Added multiplexed i2c bus 8
[ 3712.028492] pca954x 0-0070: registered 8 multiplexed busses for I2C switch pca9548

Don’t know exactly where the memory leak message is coming from, but it’s definitely not related to my DTS only since I see this a lot of times when enabling a DTO.

When I run the command ls -als /dev/i2c* I have the following feedback:

pi@librecomputer:~ $ ls -als /dev/i2c*
0 crw-rw---- 1 root i2c 89, 0 Dec  1 16:03 /dev/i2c-0
0 crw-rw---- 1 root i2c 89, 1 Dec  1 17:02 /dev/i2c-1
0 crw-rw---- 1 root i2c 89, 2 Dec  1 17:02 /dev/i2c-2
0 crw-rw---- 1 root i2c 89, 3 Dec  1 17:02 /dev/i2c-3
0 crw-rw---- 1 root i2c 89, 4 Dec  1 17:02 /dev/i2c-4
0 crw-rw---- 1 root i2c 89, 5 Dec  1 17:02 /dev/i2c-5
0 crw-rw---- 1 root i2c 89, 6 Dec  1 17:02 /dev/i2c-6
0 crw-rw---- 1 root i2c 89, 7 Dec  1 17:02 /dev/i2c-7
0 crw-rw---- 1 root i2c 89, 8 Dec  1 17:02 /dev/i2c-8

which is perfect!

Next, I connected an MCP23017 IO expander to the second output of the PCA9548 (so, connected to the virtual bus /dev/i2c-2) and saw the following feedback when running the command i2cdetect -y x, where x in the below output is 0, 1 and 2:

pi@librecomputer:~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
pi@librecomputer:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
pi@librecomputer:~ $ i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- 21 -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --

As you can see, bus 0 only detects the PCA9548 (defaulted to address 0x70) and indicates it as UU, meaning it’s not really directly accessible but used as a “proxy” I2C device to forward incoming I2C commands to the correct output.

Bus 1 (that is the first virtual bus created by the PCA9548 DTO) has the same output as bus 0 since nothing is connected to that I2c output of the PCA9548.

However, bus 2 detects, next to the “proxy” I2C device, also my MCP23017 IO expander, which is perfect!

I can now access my I2C IO expander through the I2C mux, which was my first goal to achieve. Mission accomplished!

And for those interested in the PCA9548 DT source file, here it is:

/*
 * Author: Geert Vancompernolle
 *
 */

/*
 * Overlay to add the PCA9548 I2C mux (or equivalent) to the system giving the user an extra
 * 8 I2C buses /dev/i2c-1 .. /dev/i2c-8.
 * Default address of the I2C mux = 0x70 (all 3 address pins grounded).
 */

/dts-v1/;
/plugin/;

/{
	compatible = "libretech,cc", "amlogic,s905x", "amlogic,meson-gxl";

	fragment@1 {
		target = <&i2c_AO>;

		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";

			pca9548: mux@70 {
				compatible = "nxp,pca9548";
				reg = <0x70>;
				#address-cells = <1>;
				#size-cells = <0>;

				i2c@0 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <0>;
				};
				i2c@1 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <1>;
				};
				i2c@2 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <2>;
				};
				i2c@3 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <3>;
				};
				i2c@4 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <4>;
				};
				i2c@5 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <5>;
				};
				i2c@6 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <6>;
				};
				i2c@7 {
					#address-cells = <1>;
					#size-cells = <0>;
					reg = <7>;
				};
			};
		};
	};

	__overrides__ {
		addr = <&pca9548>,"reg:0";
                bus = <&i2c_AO>,"reg:0";
	};
};

If someone from LibreComputer (or anyone else) has any remarks, then I’m happy to hear some feedback.

1 Like
55

Raspbian portability tool did not create /dev/vchiq. I am unable to run omxplayer.

How can I add vchiq?

56

This is a good guide, I would recommend making a new How-To post to help others instead of burying it in this thread. Device trees are very powerful and not very complex.

57

omxplayer is Raspberry Pi specific and uses Raspberry Pi specific hardware. vchiq is probably some non-standard Raspberry Pi specific kernel device driver. Whatever you are trying to do probably won’t work with the route you’re taking so best to post what exactly you are trying to do instead on a new thread.

58

Yeah, as I understand it /dev/vchiq is the direct interface to the Broadcom VideoCore. Since Le Potato uses Mali, without a translation layer (and the potential headaches those include) omxplayer probably won’t work.

59

i tried the porting tool

after typing “continue” i got an error…
it says
“sfdisk: Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently”

any way around this?

60

There is no extended partitions on the Raspbian images so this might be a NOOBS error. Per the readme, this script does not support NOOBS because the disk layout is too complex.

1 Like
61

Do you have anything that will convert this Arch image.
http://www.gmrslive.com/index.php/downloads/