Is there even source code for that project? Also, it’s not related to the portability tool so best to open a new thread.
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.
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.
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?
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.
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
Raspbian portability tool did not create /dev/vchiq. I am unable to run omxplayer.
How can I add vchiq?
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.
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.
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.
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?
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
Do you have anything that will convert this Arch image.
http://www.gmrslive.com/index.php/downloads/
No, we will not support anything other than normal Raspbian. The compatibility matrix will become huge if we try to add support for other images and we do not have the engineering bandwidth to test. We recommend that you ask the image makers to just have their software in a standard deb package.
Is anyone saying that they have got either ASL / Allstar Shari OR a PiStar type MMDVM to work on the Libre le Potato? If so, please, please explain how you have done it, I have run out of ideas entirely.
I have compiled MMDVMHost and DMRGateway and used a MMDVM hotspot with an AURSINC GPIO <—> USB board, and that works fine, but I cannot for the life of me get the hat to operate directly on the Libre board.
If someone has done this with ASL, all the better, I will order more boards today. But it seemed impossible to get ASL running, given the ancient software versions they rely on. I am pretty sure the current version of Asterisk for Allstar was written on a combination of cave walls, and an abacus…
ASL uses an out of tree module that does not compile properly on Linux 5.17+. The ASL owners need to update their code for the latest Linux.
Fully understood and agreed that this particular issue is not Libre, it is ASL. ASL is conceptually brilliant, IMHO, but you pretty much have to start the package by standing out in front of the radiator and manually turning a crank until Debian 9 kicks in.
I am in no position to complain, the folks behind the project are gurus compared to me, and the project itself is conceptually pretty awesome. But ASL still lends the feeling of working with an abacus.
I have been unable to get it to work. It would have to be built from scratch. I tried building allstar to from the online scripts but could not get it to run. I have not tried every option yet but it looks like one driver only works with Arch Linux. Open Repeater should work as its running on Raspbian and the conversion script will work with that. If we can find a Arch Linux image that will boot then we can likely build it onto that.
Hello @librecomputer I have a Raspbian image that I have ran the porting program on and the image is not booting on a Libre Le Potato board. If I were to send an image to you is there any way you can run the porting program and troubleshoot the issue?
Hey @GeertVc to get the Libre to detect the MCP23017, did you need an additional overlay?
I am having troubles getting the MCP23017 to be recognized with the i2c_AO overlay and have not had any luck on the custom overlays.
Thank you!