Jump to content

Rock PI 4


mboehmer

Recommended Posts

Hi- Would it be possible to upgrade dev image to KERNELBRANCH='tag:5.4.0-rc1-1120-ayufan' please in config/sources/rockchip64.conf

 

Yet tested particular tag and it does not result in a bootable image ( for rockpi 4a ) though, 

building with these : "  BRANCH=dev RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no EXPERT=yes " result in:

  LD [M]  drivers/net/wireless/rtl88x2bu/88x2bu.o
  AR      drivers/net/wireless/built-in.a
  AR      drivers/net/built-in.a
  AR      drivers/built-in.a
[ error ] ERROR in function compile_kernel [ compilation.sh:382 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated

Just wondering if there is any focus on this or is the plan to wait for e.g. a new tag with rc3 from ayufan ? 

cheers

Link to comment
Share on other sites

Hi,
i am still a beginner at armbian-system for rock pi4.  -->

Debian Buster with Armbian Linux 4.4.192-rockchip64
I have the following system:
rock pi4 4GB with nvme and a Z-Wave plus card ZMEERAZ2 on the Gpio.
The system runs and boots on the nvme. But I can not continue with Z-Wave installation.
Z-Wave uses the / dev / ttyAMA0 on a Raspberry (RXD / TXD pin 8,10).
If I enter ls / dev / ttyS *  then comes / dev / ttyS0 / dev / ttyS2 / dev / ttyS4.
During the software installation comes:
sudo wget -q -O - https://storage.z-wave.me/RaspbianInstall | sudo bash
the following error:

".....

Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.z-wave.me/z-way/raspbian b                   uster InRelease' doesn't support architecture '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:
 z-way-full : Depends: z-way-server but it is not installable
              Depends: webif but it is not installable
              Depends: zbw but it is not going to be installed
E: Unable to correct problems, you have held broken packages. "

 

who can help me here?

Link to comment
Share on other sites

2 hours ago, TE999 said:

who can help me here?


The one which made this "z-way-server" software ... 
 

But before that, try this:

 

But you will need to sort this out first - enable proper UART to get this device UP.

 

2 hours ago, TE999 said:

Z-Wave uses the / dev / ttyAMA0 on a Raspberry (RXD / TXD pin 8,10).
If I enter ls / dev / ttyS *  then comes / dev / ttyS0 / dev / ttyS2 / dev / ttyS4.

 

From there on you can install any software, perhaps OpenHab (this one I use for my ZWave network) or Home assistant, ...

Link to comment
Share on other sites

Hi
Thanks to Igor. Sometimes you need a small push to get ahead.
I use the Z-Way Board ZMEERAZ2 with IP-Symcon. I am aware that you do not need the original software from Z-Way. I only used these to realize a backup and restore of the Z-Way data during hardware changes. Since this part is currently not running with AMR64 I will realize this on the Raspberry.
Thank you again for the quick response.

To use the Z-Way Board ZMEERAZ2 on the GIOP 8/10, the line "console = display" must be added to "/boot/armbianEnv.txt" to free up the UART.

Thomas

Link to comment
Share on other sites

O dear, "something" happened the other day ( 1 November ) as it seems it is currently impossible to build a fresh image ( both 5.3 and 5.4 images ):

just checked out fresh "compile" environment from github, tried both ayufan 1118 ( default 5.3-rc4 ), 1119 ( 5.3 ) and 1120 ( 5.4.-rc1 ) but NOK

Displaying message: Cleaning arm-trusted-firmware-rockchip64/rockchip info
Displaying message: Compiling ATF  info
Displaying message: Compiler version aarch64-linux-gnu-gcc 6.4.1 info
Displaying message: Started patching process for atf rockchip64-rockpi-4a-dev info
Displaying message: Looking for user patches in userpatches/atf/atf-rockchip64 info
Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] add-trust-ini.patch  info
Displaying message: ERROR in function compile_atf compilation.sh:87 err
Displaying message: ATF file not found trust.bin err
Displaying message: Process terminated  info

Also noticed " Armbian_5.99.191031_Rockpi-4b_Debian_buster_dev_5.3.0-rc4_minimal.7z " is latest available to download ( which should work/boot on 4a I suppose )

Link to comment
Share on other sites

2 hours ago, dolphs said:

tried both ayufan 1118 ( default 5.3-rc4 ), 1119 ( 5.3 ) and 1120 ( 5.4.-rc1 ) but NOK


Expected to not be o.k. without adjustment. Since you had to adjust build parameters for that ... are you sure you are doing right things? And we never supported DEV builds (its as is, wait that is fixed, fix on your own).

Link to comment
Share on other sites

9 hours ago, Igor said:

Expected to not be o.k. without adjustment. Since you had to adjust build parameters for that ... are you sure you are doing right things? And we never supported DEV builds (its as is, wait that is fixed, fix on your own).

agreed with that , but 16 October I was still able to build ( using AUFS=no ), apparentely things changed that way dev build is currently broken. 

 

Link to comment
Share on other sites

2 hours ago, dolphs said:

... but 16 October I was still able to build ( using AUFS=no ), apparentely things changed that way dev build is currently broken. 

 

You were probably building rockpi-4b target then as rockpi-4a could never work until moments ago ;-)

rockpi-4a is also not part of automatic build process now/yet and is no different than -4b anyway.

 

Pull latest master and it should build without issues for both Rock Pi 4 targets:

[ o.k. ] Writing U-boot bootloader [ /dev/loop0 ]
[ .... ] Fingerprinting
[ o.k. ] Done building [ /home/vagrant/armbian/output/images/Armbian_5.99_Rockpi-4a_Debian_buster_dev_5.3.0-rc4_minimal.img ]
[ o.k. ] Runtime [ 10 min ]
[ o.k. ] Repeat Build Options [ ./compile.sh  BOARD=rockpi-4a BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no  ]

 

Link to comment
Share on other sites

Hi - You might be right I accidentally hit 4a instead of 4b... <sigh> ...

Anyway 4b OK, but BOARD=rockpi-4a still NOK, just built fine with ayufan-1120 ( 5.4.-rc1 )  :

./compile.sh BOARD=rockpi-4b BRANCH=dev RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no EXPERT=yes BUILD_MINIMAL=yes AUFS=no

thanks !

 

UPDATE: both cooked just fine ( did not flash and test ):

-rw-rw-r-- 1 root root 708837376 Nov  6 23:24 Armbian_5.99_Rockpi-4a_Debian_buster_dev_5.4.0-rc1_minimal.img
-rw-rw-r-- 1 root root 708837376 Nov  6 23:15 Armbian_5.99_Rockpi-4b_Debian_buster_dev_5.4.0-rc1_minimal.img

 

Link to comment
Share on other sites

latest modifications of rk3399-rock-pi-4.dtb  broke libmraa, the model name is set to "Radxa ROCK Pi 4" however libmraa looks in /proc/device-tree/model for "ROCK PI 4A" and "ROCK PI 4B" respectively.

 

I verified that this is the reason which breaks mraa by changing the the model in the dtb to ROCK PI 4A and mraa is working fine, wheres before you get "No Pins" issuing the command mraa-gpio list.

You can have a look in the sources of libmraa there you'll see that it is looking for that name in src/arm/rockpi4.c

 

Link to comment
Share on other sites

IMHO It could never work with mainline kernel.

At first it was named "RockPi-4B" in Armbian's custom device tree and then it was renamed to "Radxa ROCK Pi 4" following Rock Pi 4's device tree upstreaming somewhere around July.

 

At this point you could:

  1. use "default" image which should work fine with "libmraa"
  2. make yourself and overlay with a model change to survive kernel updates
  3. try adjusting "libmraa" to make it work with mainline kernel (and upstreaming the change) - probably by the means of verifying that "compatible" contains "radxa,rockpi4"

3rd option would be best in the long run IMO.

Link to comment
Share on other sites

Hi,

 

Has anyone successfully connected a ds18b20 sensor to Nanopi M4?

I've successfully connected to a raspberry pi B+. There is a lot of guides for the RPi it but none for the M4.

I'm using armbian stretch on the m4.

 

 

Thanks,

Link to comment
Share on other sites

On 1/7/2020 at 8:21 AM, n_b said:

Hi,

 

Has anyone successfully connected a ds18b20 sensor to Nanopi M4?

I've successfully connected to a raspberry pi B+. There is a lot of guides for the RPi it but none for the M4.

I'm using armbian stretch on the m4.

 

 

Thanks,

 

I was trying to accomplish the same... however after enabling the w1-gpio overlay I get this:

 

:~# dmesg | grep wire
[    6.696830] Driver for 1-wire Dallas network protocol.
[    6.702902] gpio-36 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[    6.703002] OF: /onewire@0: could not get #gpio-cells for /vop@ff8f0000/port/endpoint@2
[    6.703013] w1-gpio onewire@0: gpio_request_one (ext_pullup_enable_pin) failed
[    6.703069] w1-gpio: probe of onewire@0 failed with error -22

 

I also tried to add "param_w1_pin=GPIO1_C7" in order to have it working at physical pin 18 / gpio 55 without luck. Strangely enough I still get the same error about gpio-36 (GPIO1_A4) after adding that line...

 

~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
 gpio-1   (                    |vcc3v0-sd           ) out hi
 gpio-4   (                    |host-wakeup         ) in  lo
 gpio-5   (                    |GPIO Key Power      ) in  hi ACTIVE LOW
 gpio-7   (                    |cd                  ) in  hi ACTIVE LOW
 gpio-9   (                    |shutdown            ) out hi
 gpio-10  (                    |reset               ) out hi ACTIVE LOW
 gpio-13  (                    |status_led          ) out lo

gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:

gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
 gpio-68  (                    |ep                  ) out hi
 gpio-90  (                    |device-wakeup       ) out lo

gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
 gpio-111 (                    |PHY reset           ) out hi ACTIVE LOW

gpiochip4: GPIOs 128-159, parent: platform/pinctrl, gpio4:

 

I'm currently wiring the sensor to my NanoPi M4v2 with a 4.7k resistor, similar to this:

 

Raspberry-Pi-DS18B20-768x337.png.e0d85ddb2d317f5368c3c25241800035.png

 

System: 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux

 

Anyone has tips? Thank you.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines