Search the Community

Thanks for your reply! Upgrade from kernel 6.1.50 to 6.6.16 is a major thing, I would have thought? It could be related to GPIO pins I have plugged in (and not using). Orange Pi board is connected to an ASIC board, by company Futurebit.io, it's called Apollo and it's a Bitcoin miner. I only get power from it, but I don't use any pins connected by serial connector, because I use this device through USB instead. If I disconnect Orange from it, I will have to figure out an extra cable to power the Orange board, which I didn't need to do in my years of using this device. This device is creating some error and debug entries in dmesg (that's my interpretation of what I see in dmesg), but never caused any instability. But now, something does.

Hi Nick, thanks for adding the patches. I updated from git, recompiled the image and wrote it to SD. All is as expected. Here is my bluetooth output from dmesg: I thick communication with the BT module is not coming up on your board because otherwise there should be a message line BCM: chip id xx. My suspicion would be that some of the BT control signals are connected to different GPIO or UART on your hardware. I have used the gpio utilities to identify the ports (without bluetooth being in the device tree).

Hello, I'm using a BPI M2 Zero (with H3 Chip) to control two relays on CON2-P05 / PA11 and CON2-P03 / PA12. During the boot process there is a high level present at the pins, which is driving the relays. Is there a way to create a DTB overlay to drive the pins to a low level during boot. My userspace application uses libgpiod to control the pins. I'm familiar with compiling and activating overlays, i would just need help to write the correct .dts file. Thank you very much in advance

@werner it is possible to express the wish ... to integrate GPIO & the overlays ... please

Hello, about a month ago I got MangoPi QM-Quad - quite nice board, but with small support. Hardware specification: https://mangopi.org/mqquad Review: https://bret.dk/initial-mangopi-mq-quad-comparison/ I needed a raspberry pi zero board with usb-c with both host and otg ports and external wifi antenna - so after some consideration I want with Mango-Pi QM-Quad. Sadly after some work with available distributions I finally give up with trying to compile / build everything I needed and moved to getting Armbian to run on the board. Thankfully board is almost identical with orangepi-zero2 - so modification with edge kernel only required modifying dts & u-boot configuration. So here I am with repository containing patches for mangopi: https://github.com/rymut/armbian-build_mangopi-mq-quad_longan-pi-3h Some work needs to be done: gpio and media connector comes to mind, any body interested in supporting this board?

I was able to solve this by using systemd-tmpfiles to modify these values on boot. Specifically I created a file `/etc/tmpfiles.d/enable-audio-jack.conf` with the following contents. w /sys/class/gpio/export - - - - 15 w /sys/class/gpio/gpio15/direction - - - - out w /sys/class/gpio/gpio15/value - - - - 1

it actually did not require recompiling the bootloader at all actually heres what i did and it works! I worked on connecting a TV box running Armbian with an Arduino using a UART connection, allowing them to communicate. The aim was to control the Arduino using commands sent from the TV box. Firstly, I programmed the Arduino to react to simple text commands that would turn an LED on or off. This step was crucial to test whether commands from the TV box were being correctly received by the Arduino. Next, I focused on setting up the TV box for UART communication. Through the terminal, I found the UART device (/dev/ttyS2) and temporarily disabled its console service using the command sudo systemctl start serial-getty@ttyS2.service or sudo systemctl stop serial-getty@ttyS2.service This was necessary to use the port for sending commands to the Arduino without interference from the TV box’s system. To ensure the setup worked, I connected the TV box to a Windows computer using a USB-to-Serial adapter ( using my Arduino uno for this shorting the reset and GND together to by pass the chips mcu ) and monitored the communication with PuTTY. By sending a test message from the TV box and seeing it in PuTTY, I confirmed the UART port was functioning correctly. This allowed for successful data transmission between the two devices. A key part of this was a external port i made. i went in and solder on pin cables and routed it as neat as i could permanently so i can access the UART easily . This setup made it easy to connect and disconnect the Arduino without opening the TV box each time. It effectively allowed the Arduino to act like a USB-to-Serial device and vice versa, simplifying the communication process. I adjusted permissions to access the UART port without needing administrative rights and ensured the baud rates on both devices matched. this has thus far enabled general commutations through the UART and when i want to log back in through uart if ever i can simply start the serial -getty and log in this then allows me to run NANpy, making the arduino act like a slave to the tv box much like how people take rasberry pis and do the same thing to expand the gpio ports through serial communication using nanpy on the pi! this basically turns our silly ole tv box with the rk3318 into a raspberry pi with out the features lacking! that was the one thing about the pi that made it better for most tasks. well this helps level that disadvantage! @jock

Hi all, LONG POST WARNING!!! I have been trying to get an SPI TFT screen to work with the OPI Zero 3. To that end, the first goal was to get SPI output confirmed working on physical pins 19, 21, 23 and 24. I have compiled 6.7.10-edge-sunxi64 from the build environment. The actual board is gold screen printed as a "Waveshare Spotpear 3.2" which may well be a clone, as the chipset is marked HR2046, i.e. an XPT2046 -ish which is, possibly a clone of the TI ADS7846, some or all of this sentence may be incorrect. To get the overlays to display in armbian-config it is required to name the overlays with the chipset prefix - i.e. for Opi Zero 3, this would be sun50i-h616-myoverlay.dtbo - bearing in mind the chipset for the zero 3 is actually h618, but I am aware discussions are ongoing as is the work, for which many thanks. 6.x Kernel SPI on H618: https://docs.armbian.com/Developer-Guide_Build-Preparation/ This allows compilation for the Zero 3: ./compile EXPERT=”yes” Remember to select the drivers for TFT displays in the config, I say this (not remembering exactly where they are buried) because it may be the case that they cannot be easily added after the fact - don't shoot me - I read it somewhere in my travels plus it was easier for me. Alter and compile the chosen DTS files to DTBO Set up the ENV and copy the DTBO files to the device. If activated overlays have parameters marked as “Required”, those parameters have to be set to proper values U-boot does not support overlay parameters, so changing values is implemented via executing a "fixup" script after all overlays were applied. This script uses environment variables loaded from /boot/armbianEnv.txt to change the live tree using fdt command. How to work out the numbers: // Select pins: 1st number = pos. of letter in the alphabet - 1 // 2nd number = pin number // 3rd number = DON'T CHANGE! (1 = ACTIVE_LOW, 0 = ACTIVE_HIGH) // Example: PA2 = <&pio 0 2 1> // PC7 = <&pio 2 7 0> The dtc is used to decompile/recomple the DTS to DTBO and vice versa, the exception being user created overlays, it is fully documented so not repeated here, this can be added via the "sudo armbian-add-overlay" command - which compiles and places .dts files into /boot/overlay-user/ Documentation is here: https://docs.armbian.com/User-Guide_Allwinner_overlays/ https://docs.armbian.com/Hardware_Allwinner/ https://github.com/armbian/sunxi-DT-overlays https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt https://github.com/rm-hull/spidev-test is invaluable for testing. The following commands have also proved useful: sudo /bin/bash -c "cat /sys/kernel/debug/pinctrl/*/pinmux-pins" sudo cat /sys/kernel/debug/gpio I also downloaded and installed the Orangepi wiringOP: Download the code of wiringOP orangepi@orangepi:~$ sudo apt update orangepi@orangepi:~$ sudo apt install -y git orangepi@orangepi:~$ git clone https://github.com/orangepi-xunlong/wiringOP.git -b next Note that the source code needs to download the code of the wiringOP next branch, please don't miss the -b next parameter. According to initial loopback testing before adding my own overlays (apply a jumper between MISO and MOSI) , via "sudo ./spidev_test -v -D /dev/spidev1.0" - this interface is functioning as expected. The Opi Zero 3 seems to have two SPI busses, and the devices on said bus need to be targeted correctly (0 or 1) hence what I think is correct, which is to add a CS (chipselect) overlay. Results of gpio readall (screenshot as copy paste mucks up the formatting): Next step was to add the dtbo files and activate via armbianEnv.txt verbosity=1 bootlogo=true console=both disp_mode=1920x1080p60 overlay_prefix=sun50i-h616 overlays=spi-ads7846 spi-double-spidev-cs spi-spidev param_spidev_spi_bus=1 param_spidev_cs=0 rootdev=UUID=22c98ce5-14a8-483f-b440-35690209c856 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I have added my own dtbo files modified from the ones in https://github.com/armbian/sunxi-DT-overlays - which are attached. The error I am getting appears to be interrupt related, so my question is - how are the interrupts assigned, or more directly what do I put in place of PA7 which appears to be the issue the first three errors notwithstanding as I believe from reading about other OrangePi devices, the board .dtb may need looking at? dmesg | grep spi [ 1.840708] sun6i-spi 5010000.spi: Error applying setting, reverse things back [ 1.840994] sun6i-spi 5011000.spi: Error applying setting, reverse things back [ 1.849460] sun6i-spi 5010000.spi: Error applying setting, reverse things back [ 1.857263] spi-nor spi0.0: supply vdd not found, using dummy regulator [ 1.872754] spi-nor spi0.0: spi-nor-generic (16384 Kbytes) [ 7.127377] SPI driver ads7846 has no spi_device_id for ti,tsc2046 [ 7.127404] SPI driver ads7846 has no spi_device_id for ti,ads7843 [ 7.127409] SPI driver ads7846 has no spi_device_id for ti,ads7845 [ 7.127413] SPI driver ads7846 has no spi_device_id for ti,ads7873 [ 7.132367] sun50i-h616-pinctrl 300b000.pinctrl: pin PA7 already requested by spi1.0; cannot claim for 300b000.pinctrl:7 [ 7.132399] ads7846 spi1.0: failed to request pendown GPIO [ 7.132405] ads7846: probe of spi1.0 failed with error -22 There also seems to be a bit of a debate about the <compatible> tag and what should or should not be in it. I am fast approaching the end of my knowledge on this, as this is a first post, please be gentle! This is an attempt to document the fact that due diligence has been applied as much as possible, it might help others, and if nothing else, it has imbued me with admiration for those who have got this board to the state of functionality that we can enjoy today. If anything is hideously wrong, please guide (gently) as I know there are people here who have far greater detailed knowledge than I. Main takeaway - SPI works - needs tweaking, help and guidance appreciated. sun50i-h616-spi-double-spidev-cs.dts sun50i-h616-spi-ads7846.dts

Actually these boards have UART correct? Can the UART send communication signals? If so I'm pretty sure I can use the UART parts to create a link to Arduino and then! Have gpio ! I can't believe I didn't think of this before. But I'm certain this is feasible. Uart is a very legacy communication protocol and I'm sure it's fast enough for general purposes scripts and such! The goal is to use it like a MCU and to send commands to the Arduino with out taking up my precious USB ports!

@jock is there a way to revert said changes? can you at least pin point me in the general direction i might look and maybe fix it myself? it makes sense that its something to do with hdmi. iv been going through this entire thread as much as i can and i saw you made some kind of patch for the 6 series kernal and then i saw someone mention they found the source of hdmi issues with some kind of hex editor fix? im not sure what could be the case but i do have this running just fine on this older build and im scared to try to upgrade anything. i forze the kernal updates in the config does that mean i can apt upgrade all and kernal wont be touched? if so then im fine for now but im scared to touch apt upgrade in fear it might upgrade the kernal by force. is there a way to freeze it so it wont upgrade it no matter what? im using this as a pi hole and a klipper setup and it works but i wanna update my packages if i can. also yes a sbc would be easier but i wanna try to hack this together just for the fun of it. im wondering if i could wire up a powered hub inside a 3d printer encloser along with the board and make it have one internal port and then 4 external by wiring directly to the usb pads to make it intigrated then use a arduino as a slave board for GPIO to make this a hacked together rasberry pi they have githubs made to make the arduinos dedicated GPIO for linux based machines which allow the computer to controll the gpio instead of the MCU on the arduino which makes this idea seem feesable the goal is to make this basically as close to a rasberry pi as possible with a little extra steps but it will end up faster than the pi too which is even better. once i found out about tv boxes being reposed into linux machines i was hooked iv been addicted to this for awhile now just trying to iron out the issues i have atm,

I need to mention as an update. If I stay in the minimal old 5.15 kernal I get HDMI out but if I run apt upgrade or upgradable if I then reboot once I'm done. HDMI out no longer works. However if I don't update anything. I can reboot all day. This is flashed directly on the internal storage because sd card booting does not work for me. I can only boot this stuff after flashing it directly from multi tool. This makes it harder to quickly test different kernals such. if i even attempt to use the desktop ready imgs on the same kernal hdmi out also does not seem to work. i have no way of knowing if its actually booting at all or not either. is there a way to log into the system even if its the first time boot and there is no account setup? maybe then i can go in the shell somehow and enable things? it would be great to have a working desktop. i opened up the tv box and the motherboard is blue. idk if that matters. this was made in 2019 apparently . ok update i was able to log in with ssh both blue and red led is flashing after using the latest mainline installs. but ssh works not sure what i can do to proceed i setup the configs too, got the proper led working wifi not working but im using ethernet my ultimate goal is to wire up a gpio board to the system with its usb ports being spared and making this a sudo sbc computer but a little extra steps i already have a Arduino so making it a slave would be cool this is offtopic but if i can get the hdmi out working ill be closer to my goal, ( i was thinking of directly wiring the usb port to the usb port that way it works as device but spare the other usb port too maybe a wired hub inside the case so i wont be missing ports but still have the board hardwired in? it seems possible.... ok ok final edit i installed a very older build with a desktop env it works! but the kernel is in the 5 series.....i really wish i could have a more up to date kernel. for now i enabled blocking of kernel updates.

Description Add support to OrangePi Zero 2W (allwinner H618), changes: Patch for u-boot v2024.04-rc5, includes: allwinner-h616-THS-workaround.patch allwinner-h616-GPU-enable-hack.patch allwinner-pwrled-config-option.patch allwinner-enable-autoboot-keyed.patch allwinner-boot-splash.patch Kernel patch for adding zero2w dts, some part are taken from the orange pi official repo. Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. Jira reference number [AR-9999] Documentation summary for feature / change Please delete this section if entry to main documentation is not needed. If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation". You are welcome to open a PR to documentation or you can leave following information for technical writer: [ ] short description (copy / paste of PR title) [ ] summary (description relevant for end users) [ ] example of usage (how to see this in function) How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] Build and install the current image to SD, and then test on zero2w [x] Build and install the edge image to SD, and then test on zero2w [x] HDMI: test if HDMI output correctly [x] Network: test if wifi connect to access point correctly [x] Uart: test uart0 to get the kernel output [x] USB: test onboard type-c (host) [x] USB: test onboard type-c (otg) [x] USB: test usb port on the 24pin connector [x] GPIO: test GPIO voltage level - pull down and pull up by gpioset, both ok Checklist: Please delete options that are not relevant. [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

@thuvasooriya wrote hi if you review this thread, the earlier comments, you would notice that there are quite varous discussions about DTS overlays for the gpio headers. noticably discussions from / between @Gunjan Gupta @pixdrift @Stephen Graf. Unfortunately, it seemed for now not all the changes have made it into the trunk. there are also various discussions about libgpiod and gpiod, hope those may help with access to the pins.

Playing with the latest community build armbian for opi zero 3 on my opi zero2w, didn't test ethernet yet Few observations: there are some broken menus in armbian-config desktop default menu seems to be not working and working sometimes apt update results in ``` Hit:5 http://fi.mirror.armbian.de/beta bookworm InRelease Err:5 http://fi.mirror.armbian.de/beta bookworm InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 ``` not sure if these are supposed to happen. and yes i switched to unstable 6.7.10 kernel like a madman only to notice all the gpio harware configurations from armbian-config disappear. my priorities were to setup gpio and run a docker with a python webserver first. I'm looking for a good library for gpio interface on noticed @Gunjan Gupta mention mraa library in another post, I have some trouble installing it in above setup, where can I look for good references. Sorry for the ramblings any suggestions are welcome.

Hi, I have a board Orange Pi Zero with modified PAs for power of WiFi module from PA20 to PA02, by soldering a connection on board. This is done to allow connection of I2C DAC. I see that board definition in 'u-boot/configs/orangepi_zero_defconfig' It uses dts definition of: 'arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts' I need to modify one section of this dts file from: reg_vcc_wifi: reg_vcc_wifi { compatible = "regulator-fixed"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc-wifi"; enable-active-high; gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>; to: reg_vcc_wifi: reg_vcc_wifi { compatible = "regulator-fixed"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc-wifi"; enable-active-high; gpio = <&pio 0 2 GPIO_ACTIVE_HIGH>; How can I do this and use armbian build script: compile.sh Thanks, Michal

If I connected the serial port with my device through GPIO pin 8 and 10 (UART_AO_A_TXD, UART_AO_A_RXD), the Radxa Zero with " Armbian 23.02.2 Jammy" failed to boot. If I removed my device from the serial port, zero can boot. After booting, I connected my device to the UART port, it worked well through /dev/ttyAML0. Any suggestions? Many thanks!

Hello, I tried ` echo 463 > /sys/class/gpio/export ` and it build gpio464 folder under /sys/class/gpio , and I cat `value` file to check gpio status. It seems not work. The same gpio was working on Bananapi official debian and Ubuntu mate image. How can I solve this problem? Thanks

Hello, I'm trying to connect a serial device on my nanopi neo plus2, but the gpio uart seems to be disable, please can you help me step by step? I found some things on forums but I understand nothing .... Thank you in advance

Hello, I tried to install the RTL8821CE card on Orange Pi 5 Plus, but only the Bluetooth is on, the wifi not working. Which driver i should use? I am using Armbian 24.2.1 Jammy with Linux 5.10.160-legacy-rk35xx here is the dmesg of admin@orangepi5-plus:~$ nmtui admin@orangepi5-plus:~$ dmesg | grep 8821 [ 5.588211] pci_bus 0003:30: root bus resource [mem 0x9c0000000-0x9ffffffff pref] [ 8.482106] rtw_8821ce 0002:21:00.0: enabling device (0000 -> 0003) [ 8.493940] rtw_8821ce 0002:21:00.0: Firmware version 24.11.0, H2C version 12 [ 8.534600] rtw_8821ce 0002:21:00.0: rfe 6 isn't supported [ 8.534719] rtw_8821ce 0002:21:00.0: failed to setup chip efuse info [ 8.534723] rtw_8821ce 0002:21:00.0: failed to setup chip information [ 83.795823] Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821 [ 83.796843] Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin [ 83.799263] Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin admin@orangepi5-plus:~$ lspci 0002:20:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3588 (rev 01) 0002:21:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3588 (rev 01) 0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) admin@orangepi5-plus:~$ dmesg | grep iwlwifi admin@orangepi5-plus:~$ dmesg | grep wifi [ 4.419741] wifi_disable: no parameters, enabled [ 4.419802] reg-fixed-voltage wifi-diable-gpio-regulator: wifi_disable supplying 0uV [ 6.159542] [WLAN_RFKILL]: wlan_platdata_parse_dt: wifi_chip_type = ap6275p [ 6.159548] [WLAN_RFKILL]: wlan_platdata_parse_dt: enable wifi power control. [ 6.159554] [WLAN_RFKILL]: wlan_platdata_parse_dt: wifi power controled by gpio. [ 6.159620] [WLAN_RFKILL]: wlan_platdata_parse_dt: The ref_wifi_clk not found ! [ 6.159633] [WLAN_RFKILL]: rfkill_set_wifi_bt_power: 1 admin@orangepi5-plus:~$

I'm using image Armbian_23.8.3_Orangepizero2_bookworm_current_6.1.53 I'm building a DTS overlay for a SPI Touchscreen and every pin I try to use is showing this error: [ 1.441808] sun50i-h616-pinctrl 300b000.pinctrl: pin PC11 already requested by 5011000.spi; cannot claim for 300b000.pinctrl:75 [ 1.441817] sun50i-h616-pinctrl 300b000.pinctrl: pin-75 (300b000.pinctrl:75) status -22 [ 1.441829] sun6i-spi 5011000.spi: cannot register SPI master I'm trying to configure my touchscreen dts to use the SPI1.0 & SPI1.1. However, the pins exposed on the headers are all allocated for device use under 300b000.pinctrl. How do you allocate header pins for another use? I need 5 pins + SPI1 for the touchscreen to work. My dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { spi1_cs1: spi1_cs1 { pins = "PC11"; function = "gpio_out"; output-high; }; opiz_display_pins: opiz_display_pins { pins = "PC9", "PC6", "PC5"; function = "gpio_out"; }; ads7846_pins: ads7846_pins { pins = "PH6"; function = "irq"; }; }; }; fragment@1 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-1 = <&spi1_cs1>; pinctrl-names = "default", "default"; cs-gpios= <0>, <&pio 2 11 0>; /* PH9 PC11 */ opizdisplay: opiz-display@0 { reg = <0>; /* Chip Select 0 */ compatible = "ilitek,ili9341"; spi-max-frequency = <16000000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&opiz_display_pins>; rotate = <90>; bgr = <0>; fps = <10>; buswidth = <8>; dc-gpios = <&pio 2 6 0>; /* PC6 */ reset-gpios = <&pio 2 9 1 >; /* PC9 */ led-gpios=<&pio 2 5 0>; /* PC5 */ debug=<0>; }; ads7846: ads7846@1 { reg = <1>; /* Chip Select 1 */ compatible = "ti,ads7846"; spi-max-frequency = <500000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&ads7846_pins>; interrupt-parent = <&pio>; interrupts = <7 6 2>; /* PH6 IRQ_TYPE_EDGE_FALLING */ pendown-gpio = <&pio 7 6 0>; /* PH6 */ /* driver defaults, optional */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0x0FFF>; ti,y-max = /bits/ 16 <0x0FFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; }; }; };

I found more information on 32kHz clock. Starting at page 275. https://www.scs.stanford.edu/~zyedidia/docs/allwinner/h616.pdf 3.13.3.4.6. RC Calibration The basic circuit of RC calibration is shown in Figure 3-39. Whether to output the calibrated RC clock can be selected by the RC_Cali_SEL control bit, the calibration principle is as follows. http://nskhuman.ru/allwinner/h616reglist.php?nreg=153 3.13.3.5.3. Fanout Set the bit0 of 32K_FANOUT_GATING_REG to 1, and ensure that external pull-up resistor and voltage are normal, then 32.768 kHz fanout square wave can be output. Fanout: The clock source of fanout can select RTC_32K, or 32K divided by PLL_PERI(2X), or 32K divided by HOSC. http://nskhuman.ru/allwinner/h616reglist.php?nreg=161 /* * There are other differences between models, including: * * - number of GPIO pins that can be configured to hold a certain level * - crypto-key related registers (H5, H6) * - boot process related (super standby, secondary processor entry address) * registers (R40, H6) * - SYS power domain controls (R40) * - DCXO controls (H6) * - RC oscillator calibration (H6) * * These functions are not covered by this driver. */ I guess there's no function to calibrate the internal RC oscillator yet. https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c This is the 32K_FANOUT_GATING_REG. #define SUN6I_LOSC_OUT_GATING 0x0060 rtc->ext_losc = clk_register_gate(NULL, clkout_name, init.name, 0, rtc->base + SUN6I_LOSC_OUT_GATING, SUN6I_LOSC_OUT_GATING_EN_OFFSET, 0, &rtc->lock); If we can find out which clock source we are using and change it to something more accurate? All though, Calibrating the RTC is the ideal solution. On these cheap boxes there is no external 32KHz oscillator.

I try to boot for first time an espresso bin v5, I followed the advice in (Espressobin / Ultra – Armbian](https://www.armbian.com/espressobin/) and updated my uboot, and reset the environment. env default -a ## Resetting to default environment I added the image and fdt address with: setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv image_name boot/Image setenv scriptaddr 0x6d00000 The last line is after seeing in the forum that this setting has been erased when resetting the default environment my environment is now: When I try to boot, it seems to load the initrd but never complete the boot I get: Marvell>> boot *** ERROR: `serverip' not set *** ERROR: `serverip' not set ... booting from SD 1631 bytes read in 9 ms (176.8 KiB/s) ## Executing script at 00800000 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. ## Info: input data size = 2100 = 0x834 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. To boot that kernel without an initrd image, use a '-' for the second argument. If you do not pass a third a bd_info struct will be passed instead Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image ramdisk - relocate initrd, set env initrd_start/initrd_end fdt - relocate flat device tree cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep - OS specific prep before relocation or go go - start OS 21764608 bytes read in 2021 ms (10.3 MiB/s) ext4load - load binary file from a Ext4 filesystem Usage: ext4load <interface> [<dev[:part]> [addr [filename [bytes [pos]]]]] - load binary file 'filename' from 'dev' on 'interface' to address 'addr' from ext4 filesystem 11618 bytes read in 12 ms (945.3 KiB/s) ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Using Device Tree in place at 0000000006f00000, end 0000000006f05d61 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.15.48-mvebu64 (root@8b3d501f9218) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.05.3 SMP PREEMPT Wed Jun 22 07:22:16 UTC 2022 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') ..... Omitted a long boot log .... [ 2.376178] Key type fscrypt-provisioning registered [ 2.383950] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no [ 2.394740] d0012000.serial: ttyMV0 at MMIO 0xd0012000 (irq = 0, base_baud = 1562500) is a mvebu-uart [ 2.404251] printk: console [ttyMV0] enabled [ 2.404251] printk: console [ttyMV0] enabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.425972] xenon-sdhci d00d0000.sdhci: Got CD GPIO [ 2.464648] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA [ 2.473851] Waiting for root device ... [ 2.512635] mmc0: new high speed SDHC card at address d6d7 [ 2.520455] mmcblk0: mmc0:d6d7 SU08G 7.40 GiB [ 2.531514] mmcblk0: p1 It seems that my boot env is incomplete. I tried with the last bullseyes and bookworm image, with the same result. I also tried the instructions in Armbian Documentation - Esspresso bin even if it seems obsolete by now, as it uses old uboot variable names, and contain a booiti command after sourcing the boot.scr script which itself contain the booti command; but I got the same result, even if the inird addr was distinct. Please what is wrong, and what I'm missing in this uboot environment.

Hello there. I'm trying to set up GPIO pins PD15 and PD16 on my OrangePi 3 LTS to work as input pins using device tree overlays. The overlay I have created is the following (for PD15 only): /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h6"; fragment@0 { target = <&pio>; __overlay__ { my_pins:my_pins { pins = "PD15"; function = "gpio_in"; default-state = "on"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { my@0 { compatible = "my-gpio"; pinctrl-names = "default"; pinctrl-0 = <&my_pins>; gpios = <&pio 3 15 0>; status = "okay"; }; }; }; }; Probably it is incorrect, because when I check the GPIO state using "gpio readall" command, I still get OFF state for the PD15 pin. Of course, I could change the pin mode using the "gpio" command itself (it does work, like "gpio mode 9 in" does set the PD15 pin mode to input), but I would prefer the overlays method.

Hi! I need to make sure that my GPIOs remember the last state when my Tinkerboard reboots. Is it possible to modify the bootloader and avoid GPIO.cleanup? If yes, then how? Thanks!

unable to access gpio using wiringpi python. I have tried steps available on banana pi wiki. but it throws error "/dev/gpiomem" is not available and then "This board is not odroid". did anyone successfully implemented this?