dolphs Posted October 16, 2019 Posted October 16, 2019 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 0 Quote
martinayotte Posted October 16, 2019 Posted October 16, 2019 11 hours ago, dolphs said: KERNELBRANCH='tag:5.4.0-rc1-1120-ayufan' I did some private builds with that branch, the compile error is cause by AUFS patches, so I've disabled it by passing AUFS=no to compile.sh. 1 Quote
dolphs Posted October 16, 2019 Posted October 16, 2019 2 hours ago, martinayotte said: I did some private builds with that branch, the compile error is cause by AUFS patches, so I've disabled it by passing AUFS=no to compile.sh. thank you that indeed works out, also for me! 0 Quote
TE999 Posted October 20, 2019 Posted October 20, 2019 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? 0 Quote
Igor Posted October 20, 2019 Posted October 20, 2019 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, ... 0 Quote
TE999 Posted October 26, 2019 Posted October 26, 2019 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 0 Quote
dolphs Posted November 6, 2019 Posted November 6, 2019 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 ) 0 Quote
Igor Posted November 6, 2019 Posted November 6, 2019 On 10/26/2019 at 7:57 AM, TE999 said: Since this part is currently not running with AMR64 This is all you need. 0 Quote
Igor Posted November 6, 2019 Posted November 6, 2019 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). 0 Quote
dolphs Posted November 6, 2019 Posted November 6, 2019 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. 0 Quote
piter75 Posted November 6, 2019 Posted November 6, 2019 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 ] 0 Quote
dolphs Posted November 6, 2019 Posted November 6, 2019 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 0 Quote
p-i-u.de Posted November 16, 2019 Posted November 16, 2019 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 0 Quote
piter75 Posted November 17, 2019 Posted November 17, 2019 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: use "default" image which should work fine with "libmraa" make yourself and overlay with a model change to survive kernel updates 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. 1 Quote
n_b Posted January 7, 2020 Posted January 7, 2020 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, 0 Quote
TCB13 Posted September 19, 2021 Posted September 19, 2021 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: 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. 0 Quote
Recommended Posts
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.