Install Libmraa on Buster

igorp · April 28, 2020, 9:12am

This is your by far best option https://dl.armbian.com/rockpi-4b/Focal_dev_minimal_nightly … or Debian variant if you DIY https://github.com/armbian/build

hwaas · April 28, 2020, 9:34am

Yeah I’ll better build it myself, need to ensure compatibility to OMV as well.

hwaas · April 29, 2020, 6:29pm

Any ideas how can the radxa overlays be used with the mainline kernel?

hwaas · May 1, 2020, 1:17pm

Nvm, got that going.

hwaas · May 2, 2020, 2:11pm

Well I ended up compiling libgpiod with python bindings. Enabled w1-gpio overlay, using it from it python3.7 with my own wrapper. Got all the pins working.
Got stuck however on the using the hardware PWM.
I am on 5.6.7 with the standard rk3399-rock-pi-4.dtb.
Rockpi 4 should have one chip :

ls -l /sys/class/pwm/
pwmchip0 -> …/…/devices/platform/ff420020.pwm/pwm/pwmchip0

✓check

… with two channels:

cat /sys/class/pwm/pwmchip0/npwm
1

So only one channel showing up…

and this one seems to be used up in the device tree so it’s busy ofcourse:

cat /sys/kernel/debug/pwm
platform/ff420020.pwm, 1 PWM device
pwm-0 (vdd-log ): requested enabled period: 25000 ns duty: 3997 ns polarity: inverse

So what’s happening here? Where is the other channel?

First guess is that I need to recompile the rk3399-rock-pi-4.dts with some changes.
Or i need a separate PWM overlay to load at the boot?

hwaas · May 4, 2020, 11:05am

Any bit of help here will be awesomely appreciated.Thanks!

hwaas · May 11, 2020, 11:36pm

Right so… compiled the latest buster trunk with no change. Went back to 5.3 stable, still nothing.
Mmmm dunno from here.

igorp · May 12, 2020, 7:53am

Then you need to dig deeper and port functionality from somewhere else … can’t tell without research.

hwaas · May 12, 2020, 5:15pm

Yes Igor I am trying to dig deeper, i know i’ve got to enable the PWM in the DT overlay. Now it shouldn’t be that hard, for someone proficient with DT lang. However this is all new to me.
A little support from the radxa reps… wouldn’t be that hard now wouldn’t it?

Anyway for the DT bindings I’ve looked up in the RK3399 SoC dtsi and in the rockpi4 dts

arch/arm64/boot/dts/rk3399.dtsi
arch/arm64/boot/dts/rk3399-rock-pi-4.dts .

Now if i want to activate…say the first pwm channel and i patch the rockpi dts with a dummy node with the ‘status’ set to ‘okay’:

&pwm0 {
status = “okay”;
};

or add pinctrl group info:

&pwm0 {
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_pwmo>; /* GPIO4_C2, gpiochip4@line18 */
status = “okay”;
};

i’m getting stuck @ “…Starting the kernel”.
Will see how i’ll go next

marvin · September 7, 2021, 6:15pm

I am having the same issues as this. Specifically:

mount: vfat: mount point does not exist. after apt install rockchip-fstab
Unable to locate package libmraa-rockpi4 after adding radxa apt: wiki.radxa.com/Rockpi4/radxa-apt
No pins after building libmraa from source.

Are there solutions to any of these problems?

marvin · September 7, 2021, 6:16pm

Related to:

marvin · September 7, 2021, 6:19pm

Also related to (I’m a new user and can only put two links in each message):

How to use SPI (easiest way)

Stephen · September 8, 2021, 12:06pm

Hi, the package name of mraa for ROCK Pi 4 is changed to libmraa, which also supports ROCK Pi S/E/N10.

Package rockchip-fstab and libmraa-rockpi4 are not needed any more.

We have just updated the mraa guide. Please check here,https://wiki.radxa.com/Rockpi4/dev/libmraa.

shawaj · September 9, 2021, 4:42pm

hi @Stephen further to comment from @marvin above

Unfortunately, things still aren’t working. Here is the Dockerfile we are using and this is what /boot/hw_intfc.conf looks like:

intfc:pwm0=off
intfc:pwm1=off
intfc:uart2=off
intfc:uart4=off
intfc:spi1=off
intfc:spi2=off
intfc:i2c2=on
intfc:i2c6=on
intfc:i2c7=on

But neither GPIO or I2C returns any results:

# mraa-i2c list
# mraa-gpio list
No Pins

Also, it appears to detect the i2c buses 2, 6 and 7 but does not configure them properly:

# /usr/sbin/i2cdetect -l
i2c-0	unknown   	rk3x-i2c                        	N/A
i2c-1	i2c       	rk3x-i2c                        	I2C adapter
i2c-2	unknown   	rk3x-i2c                        	N/A
i2c-7	unknown   	rk3x-i2c                        	N/A
i2c-9	unknown   	DesignWare HDMI                 	N/A

Also, when we use the same hat with i2c on a Raspberry Pi 4, we see the ECC in the expected address, 0x60:

# /usr/sbin/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: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

But when we do the same thing on the RockPi, it shows up busy and in a different address, 0x11:

# /usr/sbin/i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Clearly this is the wrong I2c bus

Any ideas?

Stephen · September 10, 2021, 2:13am

Would you please use this image for quick test, https://dl.radxa.com/rockpi4/images/debian/rockpi4b_debian_buster_xfce4_arm64_20210608_1321-gpt.img.gz?

marvin · September 14, 2021, 11:54am

Thanks @Stephen this helped narrow down the problems I was facing. Here’s an overview of the main challenges faced:

Radxa APT does not have consistent contents. libmraa specifically seems to be available only in buster-testing but not buster-stable. Furthermore, some docs reference buster alone.
Unable to locate the source code for the packages in Radxa APT. Unclear how the referenced packages work.
Using a RockPi image supplied by Balena.io instead of the official Radxa release. Dockerfiles that use that image must set privileged: true. Attempted to use container flag io.balena.features.sysfs without success.
The end goal is to get gateway-miner-rs working on RockPi. Care needed to be taken to supply the application with the correct arguments. sudo ./gateway_mfr --path /dev/i2c-7 --address 96 test. Note that 0x60 == 96. 96 is the default address.

I am still doing some additional validations, but every thing is working now. Thank you.

Stephen · September 15, 2021, 3:42am

Package libmraa is added to buster-stable.

legogris · September 30, 2021, 1:17am

Any chance we could get a .deb installable on bullseye (esp given that it’s current stable)?

AFAICT it should just be a matter of depending on python3.9 rather than 3.7/3.8 (<3.9 is not available in bullseye main repos)

shawaj · November 27, 2021, 1:52pm

We are still getting the error of package not found in the apt repo

“Unable to locate package”

ken · November 29, 2021, 2:37am

You can modify file /etc/apt/sources.list.d/apt-radxa-com.list like this:

deb http://apt.radxa.com/buster-stable/ buster main
deb http://apt.radxa.com/buster-testing/ buster main

Because the newest package libmraa is added to buster-testing.
And install needed packages.

sudo apt update
sudo apt install libmraa