All Activity

I just wanted to thank @Jojo for the hints and guidance - it works, my Armbian was directly installed onto my eMMC and booted right away, all seems to be working fine, I can move forward with my project. Really appreciated!

When I first flashed your latest image, the USB2 port did not work, only the blue port works. I then applied this overlay and after rebooting it now works. USB3 speed is still not functional. rk3528-x88pro13-usb2ndhost.dts rk3528-x88pro13-usb2ndhost.dtbo

@Sergey Lepeshkin from the messages, i bought it online and the seller i know him since i bought wires from the shop. I couldnt contact the seller to provide the rom and i think they dont know since they most resell them. Also is it safe to install that file on my box?? Im scared that is going thr brick the box

@Sergey Lepeshkin HOLYthat was the same color, same board layout i think mine is the same as you Btw im busy from school and my phone broke, it was a long time since… Also im not really into soldering can i use a electrical tape instead?? Edit : i have checked the modified version of the file, and the os, all the malwares are on my box i think we have the same box. I have a good specs laptop from 2018, it runs well and i can compile the image, the problem is the memory settings since i think we dont have the same ra, chips accord to the 2 years difference of the ram chip on my board

I got interested after reading this thread and ordered an X96Q from AliExpress. The board is marked as V5.1, so I thought it would be straightforward, but after two days of trying, no matter which image I use, it always boots into Android. I tried UART communication, but nothing appeared. I even applied the secure boot patch and built it, just in case, but it still wouldn’t boot. How can I get this machine to boot from an SD card? I’m attaching photos of my board and the extracted DTS for reference. dtb.0.dts

I found a TX box X96 Mini with rk3228 chip and I try to boot with multitool but it is stuck with a red ligh. I try multitool and multitool2, with no success, can someone tell me what I am doing wrong ? Thank you The multitool i used are from here i used balena etcher to burn the image I also try to short pins on eMMc (around 45 times...) but nothing works from me. Now i order a male-male cable on amazon. edit: added front/left photos

@Jojo Would you be so kind and lend me a hand here? What I did: clone the repo locally manually changed the files in your PR (csc, dts and modified the .config) run ./compile.sh The problem is - it does not offer the M1S board in the list of targets. I must be missing a step or two. Would you mind checking my steps and advise, please? Never mind - all I needed to do is to click the middle option in the compile menu (Show CSC/WIP/EOS/TVB)

It sounds very promising for Espressobin usage and further kernels upgrades. It is yet to discover how could your u-boot port be built and which changes to code should be made for espressobin v5 and v7. I believe, they use the same chip. As you have a working build environment already, it would be worth sharing your pre-built binaries for testing in the 1st run. It could be a big step forward. Probably Armbian could offer them for downloads as well as alternatives in parallel with their own builds.

Debian would be even better, it just was not in your list. I'll then go and try to replicate your how-to, let's see if I can succeed

Different soc and even different soc family. This most likely will not work on h618.

Currently Noble Server is not planned. I have the impression, that generally speaking Debian is the way to go for server stuff while Ubuntu is more targeting Desktop systems (at least Armbian). Of course there might be cases where both are provided. All my small servers here at home run Debian-based systems. Never had any issues or disadvantages compared to Ubuntu... If you read through this thread, you'll see what is needed to build it on your own: - clone the Armbian repo - get the correct dts file and place it in the correct folder - get the correct csc file and place it in the correct folder - run the compile script and choose M1S from the list The files and where to place them can be found in the corresponding PR on github. If you don't get it running on your own just wait/hope a little bit for the board to be officially (community-)supported by Armbian. Or I share the pre-compiled image with you (on your own risk). Greetings

Step-by-step Guide to Install ILI9486 Display on Orange Pi Lite: 1.Create the overlay source file: cd /boot sudo nano spi-display-overlay.dts Paste your custom overlay configuration for SPI, DC, and reset GPIOs. 2.Compile the overlay to a binary (.dtbo) sudo dtc -@ -I dts -O dtb -o spi-display-overlay.dtbo spi-display-overlay.dts 3.Move the compiled overlay to the system overlays directory sudo cp spi-display-overlay.dtbo /boot/overlay-user/ 4.Enable the overlay in Armbian environment sudo nano /boot/armbianEnv.txt Add the line: overlays=spi-display-overlay 5. Reboot the system 6. Verify the framebuffer device is created: ls /dev/fb* Output should include /dev/fb0 7.Redirect framebuffer output to the SPI display sudo cat /dev/fb0 > /dev/fb0 It's just a test, it's a static image 8.Modify /boot/armbianEnv.txt Edit the armbianEnv file and add the following lines to ensure the framebuffer continuously updates on your display: extraargs=console=tty1 fbcon=map:0 fbcon=font:VGA8x8 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u ( 9.Troubleshoot reset GPIO if needed ) If display stays white, try another GPIO pin for reset in the overlay and recompile. Step 10: Post it on the Armbian forum and Reddit. I haven’t worked with the touch sensor yet, but it’s already 5 AM 0.o I hope this helps, and good luck!

Hi everyone! I thought I’d share my experience. I successfully got a display working on my Orange Pi Lite using this: https://github.com/jonathan-gatard/ili9486-xpt2046/tree/main I followed the instructions from the link above. At first, I connected the screen to the Pi and configured the pins in the device overlay. However, the reset pin, which was PD25, kept giving errors. Later, I rewired the display to a different pin, but it still didn’t work. Finally, when I moved it to a third pin, PC08, it worked! Until then, the screen just showed white, but after that, it started working perfectly. spi-display-overlay.txt

This is truly incredible. I had no idea Mali and Linux has come this far. Though it's a shame things aren't mainlined.

Start with this DTS and change the GPIO for your OPIZ3 https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts Or start with your DTS and change the "compatible" line to "compatible=waveshare,rpi-lcd-35" and copy the other parameters of piscreen-overlay.dts if needed Let us know if it works

TV Box Status Information Template Version 1.0 TV Box Name (example: TX3 mini): T9 CPU (example: amlogic s905w): RK3328 Armbian build file name: Armbian_community_25.11.0-trunk.367_Rk3318-box_trixie_current_6.12.54_minimal.img DTB file used: rockchip/rk3318-box.dtb Kernel Version: 6.12.56-current-rockchip64 Distribution Installed (focal, buster, etc): trixie Working Ethernet (Yes/No):Yes Max Ethernet Speed that works (100/1000): 100 Max Does wifi work (Yes/No): Yes 2/5 Does bluetooth work (Yes/No): Yes Does HDMI audio work (Yes/No): some noise Additional Comments (provide any additional information you feel is important): IR Receiver yes 5 Digit display working: yes MASKROM PINS for recovery flashing available on the back side. SOC RK3328 RAM 4Gx4 D9PQL VFD DRIVER FD6551 WLAN CHIP SP6330 32 GB EMMc KLMBG2JENB VT RT9045 vfd.conf rk3318-t9.dtso Log android gpio T9.txt

Update I have opened the box. Indeed the driver is an FD6551 and the SOC is RK3328. I was using the FD655 just because that was the one used in a working vfd-openvfd conf file. So I have just changed the dtso file directive compatible = "fdhisi,fd6551"; The advantage is that 8 levels of intensity are now available using 1..8 in "echo 1 > /sys/class/leds/display/brightness". I did not chage the filename but as a matter of fact it should be as well the working rk3328-t9.dtso. rk3318-t9.dtso

DVFS has been working well for me on two devices for over a year now. Linux accepted my patch to re-enable 1.2Ghz in 6.15. I build my own Arch packages, but I started with ALARM. I didn't like the way they packaged the kernel and it wasn't being maintained. There are a few of us working on bringing Arch to aarch64. You'll find us on IRC. Libera.chat #archlinux-ports The ALARM project is a completely independent project of Arch Linux (despite the confusing name). I have no issues with random number generation. It was actually fixed by this project: https://gitlab.nic.cz/turris/mox-boot-builder which builds one component of the bootloader. So I use that project (instead of Marvell) for that part of the bootloader.

Both senteces are correct , I have reviewed the DT and now display-service is working properly and consequently there is no more sysfs "value" attribute. "Message" attribute is working as expected (scrolling, etc). Notes: It seems to me that the automatically generated dtso file for rk3328-t9 in the git repository is not valid. There are a lot of "T9" TVBOXES all around, mine is labelled T9-RK3328-8x4-V1.8 , (although I have always used it as an rk3318-t9 due to the main dtb file), so I will reopen it one of these day and be back. Anyway the latest driver is working as well with another box, another chip (FD650), please see:

Any Ubuntu Noble release?

the two tv box are quite different.The rk3318-H50 of this post is quite cheap, so are the component inside. By the way for the rk3318-H50: the PMIC is a DF1517, not an usual one. The Board has three leds (one red is power on always on the other two are both blu but I have never seen them on) and a 4 digit display plus (colon) usb, lan and wlan icons. Wifi works with the base configuration 2 and 5 ghz (although some warnings in the log). Bluetooth is recognized as well. I do not see any message related to the IR receiver. By the way it seems to be quite stable. This is the gpio list: android_tv_box_32:/ $ cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0: gpio-2 ( |vcc_otg_vbus ) out hi gpio-30 ( |vcc_sd ) out hi gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1: gpio-42 ( |bt_default_rts ) out lo gpio-50 ( |reset ) out hi gpio-53 ( |bt_default_poweron ) out hi gpio-56 ( |fd650_scl ) out hi gpio-57 ( |fd650_sda ) out hi gpio-58 ( |bt_default_wake_host) in hi gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2: gpio-81 ( |vcc_host_vbus ) out hi gpio-82 ( |power-led-ir ) out lo gpio-90 ( |power-led-normal ) out lo gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3: The T9 is an old and quite different TVBOX (cames in two flavours rk3318 and rk3328 from Sunwell) and everything is working "out of the box" - wifi, bluetooh, lan, hdmi, ir receiver. It has no leds but a 5 digit display + 6 icons but if you think it would be useful I can open it and peraphs describe it in a different post to avoid confusion. It seems to me that is more widespread as there are configuration files all around. Let me know if it is of ant interest.

I've recently encountered when generating rsa keys low entropy available to OS on espressobin. You mention that "The hardware random number generator contained in the Cortex-M3 coprocessor was not available to the OS." It may explain the reason. Which entropy numbers do you reach now with the fixed u-boot ?

Hi all, I just installed Armbian with OpenMediaVault on a Odroid HC4 (v25.8.2 for Odroid HC4 running Armbian Linux 6.12.48-current-meson64), when I tried to disable automatic updates in armbian-config it purged a lot of packages including openmediavault. Guess this is a bug, in case where should I report it?

IS THERE ANYTHING COMPATIBLE FOR S905Y4 VERSION

@CyberHaZard Thanks for the feedback. Yes, the internal eMMC is untouched. You can mount these Android partitions in your file system if you want to access them. Thank you for the offer. I already have access to the Android OS, but tests are apriciated Usb3 is not fully implemented yet . It might just be a Linux configuration issue. I still need to investigate. Maybe it's also acting as a device. there could be a switch via GPIO. The front LED display uses the HT1628 chip. There's a driver available at https://github.com/venkatesh4009/TM1628_LED_Driver It's worth a try.