All Activity

Ahah cool! Congrats!

Following my lack of knowledge of the subject I found out another GPIO implementation that seems to have mappings for the NanoPi M4 called OPi.GPIO. Rewired the LCD, I was unsure about the GPIO pin I picked for the DC pin: MOSI > GPIO1_A7 > SPI1_RXD > M4 Pin 21 > LCD DIN Pin (blue) SCK > GPIO1_B1 > SPI1_CLK > M4 Pin 23 > LCD CLK Pin (yellow) CS > GPIO1_B2 > SPI1_CSn0 > M4 Pin 24 > LCD CS Pin (orange) RST > GPIO1_A1(3V) > M4 Pin 11 > LCD RST Pin (white) DC > GPIO1_A3(3V) > M4 Pin 13 > LCD DC Pin (green) Installed and run the thing without much success: pip3 install --upgrade OPi.GPIO ls /dev/spi* /dev/spidev1.0 python3 luma.examples/examples/3d_box.py \ --display=ssd1351 \ --interface=spi \ --width=128 --height=128 \ --spi-bus-speed=16000000 \ --bgr \ --spi-device=1 --spi-port=0 \ --gpio-reset=35 \ --gpio-data-command=33 \ --gpio OPi.GPIO \ --gpio-mode nanopi.m4.BOARD Traceback (most recent call last): File "luma.examples/examples/3d_box.py", line 129, in <module> device = get_device() File "/root/luma.examples/examples/demo_opts.py", line 61, in get_device device = cmdline.create_device(args) File "/usr/local/lib/python3.7/dist-packages/luma/core/cmdline.py", line 246, in create_device device = Device(serial_interface=interface(), **params) File "/usr/local/lib/python3.7/dist-packages/luma/core/cmdline.py", line 161, in spi gpio=self.gpio or GPIO) File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 299, in __init__ bitbang.__init__(self, gpio, transfer_size, reset_hold_time, reset_release_time, DC=gpio_DC, RST=gpio_RST) File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 187, in __init__ self._DC = self._configure(kwargs.get("DC")) File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 200, in _configure self._gpio.setup(pin, self._gpio.OUT) File "/usr/local/lib/python3.7/dist-packages/OPi/GPIO.py", line 470, in setup pin = get_gpio_pin(_mode, channel) File "/usr/local/lib/python3.7/dist-packages/OPi/pin_mappings.py", line 80, in get_gpio_pin return _pin_map[mode][channel] KeyError: 33 From what I understand of https://github.com/rm-hull/OPi.GPIO/blob/master/nanopi/m4.py my physical pin 11 maps to GPIO 33 and physical pin 13 to GPIO 35. Is this even correct? Either way it still fails.

I found this on lore.kernel.org: https://lore.kernel.org/linux-rockchip/YS0v9UbzoHkiU9om@sashalap/T/#t Apparently they're looking into a proper fix, but nothing has come of it yet.

Nope, not yet, I'm a bit busy with rk3288 at the moment, but here you go: ddrbin_v1.16.bin

Maybe a stupid question but why would the regular serial (the one I connect to using USB) of the helios64 not work?

@jock - do you have this extracted ddrbin somewhere in your repos already? i was not able to find it yet ...

Now unfortunately luma-oled seems to be yet another problem. I wired up my LCD as: MOSI > GPIO1_A7 > SPI1_RXD > M4 Pin 21 > LCD DIN Pin (blue) SCK > GPIO1_B1 > SPI1_CLK > M4 Pin 23 > LCD CLK Pin (yellow) CS > GPIO1_B2 > SPI1_CSn0 > M4 Pin 24 > LCD CS Pin (orange) DC > GPIO1_A0(3V) > M4 Pin 7 > LCD DC Pin (green) RST > GPIO1_A1(3V) > M4 Pin 11 > LCD RST Pin (white) Display: https://www.ebay.com/itm/203101646517 Datasheet: https://www.waveshare.com/w/upload/5/5b/1.5inch_RGB_OLED_Module_User_Manual_EN.pdf From my understanding I had to get GPIO1_A0 and GPIO1_A1 in the system so the lib could use them. According to this https://hev.cc/2927.html GPIO mapping I tried: ls -la /dev/spi* crw------- 1 root root 153, 0 Sep 16 18:51 /dev/spidev1.0 echo 32 > /sys/class/gpio/export echo 33 > /sys/class/gpio/export ls -la /sys/class/gpio/ total 0 drwxr-xr-x 2 root root 0 Jan 18 2013 . drwxr-xr-x 76 root root 0 Jan 18 2013 .. --w--w---- 1 root dialout 4096 Sep 16 20:51 export lrwxrwxrwx 1 root root 0 Sep 16 20:50 gpio32 -> ../../devices/platform/pinctrl/gpiochip1/gpio/gpio32 lrwxrwxrwx 1 root root 0 Sep 16 20:50 gpio33 -> ../../devices/platform/pinctrl/gpiochip1/gpio/gpio33 lrwxrwxrwx 1 root root 0 Jan 18 2013 gpiochip0 -> ../../devices/platform/pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 18 2013 gpiochip128 -> ../../devices/platform/pinctrl/gpio/gpiochip128 lrwxrwxrwx 1 root root 0 Jan 18 2013 gpiochip32 -> ../../devices/platform/pinctrl/gpio/gpiochip32 lrwxrwxrwx 1 root root 0 Jan 18 2013 gpiochip64 -> ../../devices/platform/pinctrl/gpio/gpiochip64 lrwxrwxrwx 1 root root 0 Jan 18 2013 gpiochip96 -> ../../devices/platform/pinctrl/gpio/gpiochip96 --w--w---- 1 root dialout 4096 Sep 16 19:19 unexport Now I tried the luma-oled examples (running as root): python3 3d_box.py --display ssd1351 --interface spi --spi-port 0 --spi-device 1 --gpio-reset 33 --gpio-data-command 32 --width 128 --height 128 usage: 3d_box.py >(....) 3d_box.py: error: GPIO access not available I'm not even sure if this part "--gpio-reset 33 --gpio-data-command 32" is correct. I've tried both the virtual pin number and the hardware number without luck. Also tried to install https://github.com/friendlyarm/RPi.GPIO_NP without much luck: apt-get update apt-get install python-dev git clone https://github.com/friendlyarm/RPi.GPIO_NP cd RPi.GPIO_NP python3 setup.py install python3 setup.py install python3 luma.examples/examples/3d_box.py --display=ssd1351 --interface=spi --width=128 --height=128 --spi-bus-speed=16000000 --bgr --spi-device=1 --spi-port=0 --gpio-reset=33 --gpio-data-command=32 --gpio RPi.GPIO Traceback (most recent call last): (...) RuntimeError: It is not NanoPi based board.

@piter75, Your comment was crucial to fix my "issue". I enabled the overlay and then as described on the file edited `/boot/armbianEnv.txt` in order to include: param_spidev_spi_bus=1 param_spidev_max_freq=100000000 Now the SPI shows up: ~# ls -la /dev/spi* crw------- 1 root root 153, 0 Sep 16 18:51 /dev/spidev1.0 Also passes the spidev_test (https://raw.githubusercontent.com/torvalds/linux/master/tools/spi/spidev_test.c) ~# ./spidev_test spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 kHz) (Had to adjust the path) Thank you for the tip!

Yeah that one should do. Any other will do too as long as it supports a baud rate of at least 1,5Mbaud.

Something like that ? --> https://www.amazon.fr/AZDelivery-Adaptateur-UART-TTL-conversion-dinterface/dp/B08T24NML9/ref=sr_1_5?__mk_fr_FR=ÅMÅŽÕÑ&dchild=1&keywords=USB+UART+adapter&qid=1631903713&qsid=262-4238766-5218215&sr=8-5&sres=B08T24NML9%2CB07TFSZ3ZP%2CB07BBPX8B8%2CB01CYBHM26%2CB07N2YLH26%2CB07LH6NJSZ%2CB08VRQFNSN%2CB075XK737D%2CB07TXVRQ7V%2CB07WF7BJJH%2CB0773G2K92%2CB01LY97ZM5%2CB08Y8CJRZT%2CB082R9MYV9%2CB07VDSJPKX%2CB01N9RZK6I%2CB00VBOCUIO%2CB07LH54QHM%2CB072K3Z3TL%2CB004ZMYTYC&srpt=ELECTRONIC_ADAPTER OK, thank you, Werner, I will do that !

Hard to tell without digging deeper which is only possible with serial connection. (that is true for all ARM single board computers btw.) Pickup an USB UART adapter. They are dirt cheap and extremely helpful in debugging boot failures. While waiting on that thing to arrive you can check the Kobol wiki and disable the eMMC via jumper and write a fresh image to an sd card and boot from that to make sure the unit itself is fine.

Hello everyone, I’m starting this message by apologizing for my poor English (I am French) and also by informing you that I am a newbie with Linux. I have a big problem with my NAS Helios64. At first, I thought this problem was caused by OMV. So I went to the OMV forum to explain my situation. I created the following topic: https://forum.openmediavault.org/index.php?thread/40252-many-problems-after-an-update/&pageNo=1 . There, a kind moderator (macom) asked me to enter some instructions to try to pinpoint the root of the problem. After giving him some outputs, he told me: "For me it looks like your SD card is dead." My installation is not on an SD card but on the eMMC chip of the Helios64. (I followed the Kobol wiki instructions exactly from here : https://wiki.kobol.io/helios64/install/emmc/ ) After that, my NAS has become unreachable. I can no longer log into the OMV Dashboard. I cannot reach the NAS by SSH either. I can just tell you that all the LED lights on the NAS are solid blue. No red diode on. Is the eMMC chip of my NAS dead? Is there a solution that would prevent me from losing all the data stored on the hard drives? (They are in RAID1 and they are encrypted with the OMV LUKS encryption plugin) (I have not made a data backup elsewhere ... I know, big mistake!) I thank in advance all those who will take the time to help me.

More news, I think this could be a u-boot issue. I have seen some u-boot related changes in the Armbian changelog at https://docs.armbian.com/Release_Changelog/ Thank you for moving to Jira and keeping such good track of completed tasks -- this gives me much more insight into what has changed and when. Here's how I believe it's a u-boot issue: 1. I started with an older Armbian image I have: Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.img 2. I copied several Linux kernels onto this SD card and updated the /boot/Image and /boot/uInitrd and /boot/dtb symlinks to load different kernels. All kernels I tried did not produce any black bars on the HDMI output. The kernels tested were - 4.4.184 from Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.img - 4.4.213 from Armbian_21.08.1_Rock64_buster_legacy_4.4.213_xfce_desktop.img - 5.10.60 from Armbian_21.08.1_Rock64_bullseye_current_5.10.60.img - 5.13.12 from Armbian_21.08.1_Rock64_hirsute_edge_5.13.12.img Next I will load the Armbian 21.08.1 images without any changes to SD card to verify that they are all affected before inspecting u-boot.

https://github.com/armbian/build/pull/3149 Checkout PR, build image and test. Let me know if this does the trick.

I haven't noticed any eth related problems on 5.13.y and RK3399, but when moving to 5.14.y I also found that eth no longer worked. I corrected the issue by reverting the following commit: https://github.com/torvalds/linux/commit/2d26f6e39afb88d32b8f39e76a51b542c3c51674 I understand its not a true fix. This was tested on the NanoPC-T4. --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 2021-09-12 03:01:00.000000000 -0400 +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 2021-09-14 07:19:24.402736613 -0400 @@ -21,6 +21,7 @@ #include <linux/delay.h> #include <linux/mfd/syscon.h> #include <linux/regmap.h> +#include <linux/pm_runtime.h> #include "stmmac_platform.h" @@ -1528,6 +1529,9 @@ return ret; } + pm_runtime_enable(dev); + pm_runtime_get_sync(dev); + if (bsp_priv->integrated_phy) rk_gmac_integrated_phy_powerup(bsp_priv); @@ -1536,9 +1540,14 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac) { + struct device *dev = &gmac->pdev->dev; + if (gmac->integrated_phy) rk_gmac_integrated_phy_powerdown(gmac); + pm_runtime_put_sync(dev); + pm_runtime_disable(dev); + phy_power_on(gmac, false); gmac_clk_enable(gmac, false); }

Hi, I was making my own battery for the kobol64. To do this, you can use a ready-made balancing board, like this https://aliexpress.ru/item/32884781878.html?item_id=32884781878&sku_id=12000024864748835 any 10k thermistor, for example such https://aliexpress.ru/item/32819250168.html 6 pin connector https://aliexpress.ru/item/1005001490801246.html?item_id=1005001490801246&sku_id=12000016325255609

moved to tvboxes

Thanks for this. Confirmed the same bug can also be found on Bulleseye image for Allwinner H6 TX box: [ Armbian_21.11.0-trunk_Aw-h6-tv_bullseye_current_5.10.62.img.xz ] by balbes150 ZRAM log was getting full again after device reboot & also due to Bulleseye image "ignore the setting SystemMaxUse=20M in /etc/systemd/journald.conf" For now I'll fallback to Buster image previously downloaded for the device.

Hi, forums main language is English only. Use translator tool if necessary.

There is Tronsmart Vega S95 Telos, installed armbian on it, everything works fine, except for one moment, it is not entirely clear how to enable the sata port. Who installed armbian and knows how to enable the sata port on this TV box?

https://dosya.co/irtohgogh4hh/Screenshot_20210917-153104.png.html Hep kırmızı ışıkta beklemek. Hiçbir şey hareket etmiyor. Cihaz açılmıyor. cihazı nasıl geri yükleyebilirim Lütfen yardımcı olur musunuz :(((

I tried but "Install/Update the bootloader on SD/eMMC" this option is showing

Both sharing the same very same kernel package so firmware is identical. I would go for bullseye since this is the most recent stable Debian release.

Use search next time

I think I will have to completely rebuild my server :/ All because of a simple update via armbian-config ... First of all, I must be able to recover all my data from my RAID10, I hope to be able to succeed ... Then, if I start from scratch, can I take the last armbian image for Helios64? (i.e) Armbian_21.05.9_Helios64_bullseye_current_5.10.63.img.xz or is it recommended to stay on the image: Armbian_21.05.9_Helios64_buster_current_5.10.63.img.xz sources: https://mirrors.netix.net/armbian/dl/helios64/archive/ Thank you