All Activity

@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??

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

@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.

I believe you have managed to overcome the majour Espressobin culprits, i.e. frequency scaling resulting in instability. It was a deadlock for me in the kernel choice and uboot frequency build version. At some moment I was compelled flashing uboot with frequency downgraded to 1GHz and 800 MHz in order to get stable setup for production. Good catch! Your use of Arch Linux is also interesting. Which flavor have you installed ? Is it from https://archlinuxarm.org/platforms/armv8/marvell/espressobin ? I routinely out of curiosity try alternative builds for testing and comparison when making new setups despite that Armbian remains a preferred one so far with general score of usability.

Hey, I am really happy there is someone else with M1S - just got it today in the mail and after first boot received notification that ubuntu 20.04 server is no longer supported (shocker!). It would be nice to be able to run later kernel (you've mentioned 6.12) on the machine. I was not able to follow your steps to get it working, unfortunately. I don't care for desktop performance at all. Would it be possible to get the image of ubuntu noble server? Or is there some place with idiot-proof step-by-step guide for noobs? Thanks in advance!

@johlnx I have tried your recently built image from here Github Page and it booted fine. Boots fine. Wifi and Ethernet works. USB port only one is working. The blue one and I assume that that is wired for USB3. So I find this strange. I have still not touched the original eMMC. Here is the output from blkid. Note I am using a 16GB micro SD to boot and that is at /dev/mmcblk0 cyberhazard@x88pro:~$ blkid /dev/mmcblk0p1: LABEL="armbi_boot" UUID="d312472c-e5d3-4ef4-9a72-4d38e367fa7c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="bootfs" PARTUUID="c7a9a714-e024-406b-a111-dbf5782bfd06" /dev/mmcblk0p2: LABEL="armbi_root" UUID="ead9d55f-9f5d-4db3-84af-1b4c0807169c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6acc9d55-8827-45f0-bb5f-3b864952abfa" /dev/mmcblk1p11: UUID="da8b6f4f-89cc-4ed5-8bd6-aa0ef3b881e8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="metadata" PARTUUID="b85e0000-0000-4752-8000-0c2400004469" /dev/mmcblk1p10: UUID="790cebf2-3e31-464d-bf22-00bea1cb7eb6" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="cache" PARTUUID="cb490000-0000-4c68-8000-157e000041fe" /dev/zram1: LABEL="log2ram" UUID="d0a97d5c-6f8c-41e3-863b-f7fdf23d9288" BLOCK_SIZE="4096" TYPE="ext4" /dev/zram0: UUID="334781b1-ee36-425e-819a-6796d4f4f36a" TYPE="swap" /dev/mmcblk1p3: PARTLABEL="trust" PARTUUID="71760000-0000-4537-8000-2f8f00000c08" /dev/mmcblk1p13: PARTLABEL="super" PARTUUID="94030000-0000-4f58-8000-234700004169" /dev/mmcblk1p1: PARTLABEL="security" PARTUUID="e9430000-0000-4579-8000-4da800000c18" /dev/mmcblk1p8: PARTLABEL="recovery" PARTUUID="8a190000-0000-457d-8000-74a10000796b" /dev/mmcblk1p6: PARTLABEL="vbmeta" PARTUUID="e02c0000-0000-496d-8000-062400006ffa" /dev/mmcblk1p4: PARTLABEL="misc" PARTUUID="8d390000-0000-472e-8000-3dc60000506d" /dev/mmcblk1p14: PARTLABEL="userdata" PARTUUID="134d0000-0000-4d40-8000-71540000188f" /dev/mmcblk1p2: PARTLABEL="uboot" PARTUUID="523b0000-0000-4275-8000-4a4700000883" /dev/mmcblk1p12: PARTLABEL="baseparameter" PARTUUID="e3430000-0000-4f7b-8000-3af900005bf5" /dev/mmcblk1p9: PARTLABEL="backup" PARTUUID="d31e0000-0000-4930-8000-76c000007aec" /dev/mmcblk1p7: PARTLABEL="boot" PARTUUID="a61c0000-0000-4708-8000-75db00002fb2" /dev/mmcblk1p5: PARTLABEL="dtbo" PARTUUID="f0710000-0000-412e-8000-58350000717b" Can I help you with something? Do you require any files from the original emmc partitions? Maybe this would allow to use all the HW. Also do you think the front LED segment display can be functional?

A service was created to fix the issue, should be this added to official BPI-M7 image? sudo nano /etc/systemd/system/btattach.service sudo systemctl daemon-reload sudo systemctl enable btattach.service sudo systemctl status btattach.service sudo systemctl start btattach.service sudo systemctl status btattach.service cat /etc/systemd/system/btattach.service [Unit] Description=Bluetooth UART Attach Service After=network.target Before=bluetooth.service [Service] Type=simple ExecStartPre=/usr/sbin/modprobe bluetooth ExecStartPre=/usr/sbin/modprobe hci_uart ExecStart=/usr/bin/btattach -B /dev/ttyS6 -P bcm -S 115200 Restart=always [Install] WantedBy=multi-user.target