Search the Community

Can I run a YOLOv8 model in RKNN format, developed for Rockchip 3588, on a Rockchip 3588S without any issues?

Hi I've made a new kernel Auxiliary Display Driver for TM16XX and compatible LED controllers. This driver supports various LED controller chips, including TM16XX family, FD6XX family, PT6964, and HBS658. It provides support for both I2C and SPI interfaces. I wanted it to manage the hardware on the kernel space while having an easy sysfs user space interface. It also aims to reduce the code to maintain by relaying on existing kernel features instead of recoding them. Plus, you can switch to hardware i2c/spi (instead of software gpio) depending on the pins used. You can use "vfdconf-convert" to convert your existing vfd.conf to its device-tree version. Or you can use the already converted vfd.conf of https://github.com/arthur-liberman/vfd-configurations that are listed in the device table. You don't need to manually edit your device tree, the "make" command will apply the device tree source overlay to your dtb. It comes with a service written as a simple bash script. So it's easily customizable without having to write custom C code. Instructions and source code at https://github.com/jefflessard/tm16xx-display/ Could you please give it a try and report your feedback?

I have FriendlyElect CM3588 (RK3588 based) Nas kit which is lagging behind in terms of incorporating the latest NPU driver (the current is 0.9.3) in their firmwares. Thier repository contains Ubuntu / Debian with Kernels 6.1.x As far as I know the latest RKNPU version is 0.9.6. and as I understand there is no OS on Armian tailored for CM3588. What is best way to get the lastest driver?

Hello, thank you for your new image work. However, although I wrote to write your image to emmc or sd card, the device does not respond at all. The previous version Armbian_23.11.1_Panther-x2_bookworm_current_6.1.63.img.xz works normally on my panther device. The new version and minimal iot version do not boot at all. I kindly request your information about Armbian_community_24.11.0-trunk.25_Panther-x2_bookworm_current_6.6.47_minimal .img.xz.

Hi, could we add tag and section for Orange Pi 5 Max? I looked at the forum and couldnt find it here.

While a friend of mine was developing my Rockchip rv 1126 device, we lost access as a result of a wrong operation. The device is powered on. the red light on the back is on, but we cannot access the device we have previously identified from the ip's. When I try the usb port on the device, I get a device not recognized warning in ubuntu 22.04 and windows10. Can anyone help me to reinstall the operating system or access the device? Thank you.

I found what a likely duplicate out-of-tree driver after investigating a warning from the kernel build: CC [M] drivers/gpu/drm/panel/panel-simple-dsi.o drivers/gpu/drm/panel/panel-simple-dsi.c: In function 'panel_simple_get_modes': drivers/gpu/drm/panel/panel-simple-dsi.c:310:73: warning: passing argument 3 of 'of_get_drm_display_mode' makes pointer from integer without a cast [-Wint-conversion] 310 | ret = of_get_drm_display_mode(panel->dev->of_node, mode, p->desc->bus_format, | ~~~~~~~^~~~~~~~of_get_drm_display_mode~~~~ | | | u32 {aka unsigned int} In file included from ./include/drm/drm_crtc.h:32, from drivers/gpu/drm/panel/panel-simple-dsi.c:13: ./include/drm/drm_modes.h:509:66: note: expected 'u32 *' {aka 'unsigned int *'} but argument is of type 'u32' {aka 'unsigned int'} 509 | struct drm_display_mode *dmode, u32 *bus_flags, | ~~~~~^~~~~~~~~ This code cannot work as is and a fix would be to add the missing ampersand before the p->desc->bus_format. Still other warning surface when this is fixed. This driver calls of_get_drm_display_mode against bus_format while panel-simple does against bus_flags (it also has bus_format but it passes it as an argument to drm_display_info_set_bus_formats). So it might well be that the driver would pass the wrong arguments. It has no documentation for its DTS parameters so it is hard to tell if bus_format should be set as bus_flags from the panel-simple documentation or if its user will end up sending bus_format as a bus_flags. There is already a dsi driver in upstream drivers/gpu/drm/panel/panel-simple.c (panel-dsi-simple while this one is panel-simple-dsi). So I wonder if there is a use in shipping two drivers for the same purpose. And there are no dts users of this out-of-tree driver panel-simple-dsi. The discussion about its introduction is in: https://github.com/armbian/build/pull/3140 It is told in the commit log to be a port of a rockchip kernel 4.4 driver, but panel-simple has dsi probe since v3.14. I am puzzled rockchip forked panel-simple instead of expanding it. Rockchip.DRM.Panel.Porting.Guide.pdf has no mention of the bus_format dts parameter so maybe this code path was never used and the buggy code affects no users. (a few dts parameters in the rockchip code are also not documented in this PDF). @iamdrq you are the author of this driver. Was there code missing in the dis support of panel-simple.c for dsi support, ie is panel-simple-dsi necessary? Was the aim to have a version of the panel dsi code that is bit-to-bit compatible with the rockchip kernel, so no porting was necessary? If features were missing could we bake them into the panel-simple.c driver (so they could be tested and one day be upstreamed)?

Is there any generic build of Armbian compatible with that processor?

SMART AM40 iQ Appliance P/N: 1031572 Model: UGK-AM40-EDU | EWY1-AM40-EDU | EWY2-AM40-EDU Processor RK3399, Dual-core A72+Quad-core A53, 64 bits, 2GHz Memory 4 GB DDR3L SDRAM Storage 32 GB eMMC 5.1 Wireless technology Bluetooth 4.1 802.11A/B/G/N/Ac Capture options Establish a Bluetooth wireless connection with a supported mobile device Connectors HDMI 1.4 (1920 × 1080) output for external monitor USB 3.0 Type-A (×2) RJ45 Gigabit Ethernet --Update-- For device tear-down and technical sheets included in package - SEE SECOND POST Reference links posted at bottom are sourced as I dig up more details that may be useful . It looks like the power will have to be supplied via gpio as far as I can tell.. The official documentation and fccid technical orders refer to the Headless SBC / Module what have you; as an "IQ Appliance". Tagged 'grep' for control/command function searching through fccid or other official documentation) Otherwise found simply as AM40 rk3399 or AM40 iq on google/other engines --AM40 iQ - Anyone seen or attempted armbian on something similar?-- Figured this forum may be one of the few places that might appreciate and see what I first saw. So if anyone might have an idea where to proceed with a possible hidden gem like this.. I picked it up for reasonable price a quite a bit LESS than current nanopi m4 cost the other night. Can't say quite yet if it will be a useless paperweight, or a diamond in the rockchip. heh. As soon as it arrives I intend on seeing what kind of hac.. err educational research can be done to place Armbian on it eventually over its intended OS. There seems to be a service switch that is used on other models to allow intel modules and windows OS. The form factor seems to be carrier board size, so here's hoping for that switch to be more open to source than intended for this particular model. It's just something about the specs on it raised an eyebrow, yea? And the case it comes with is pretty solid compared to the shit, err, other case and fan combos you normally see.. That alone.. I didn't see any tear-down from the ffcid schematics available to the public, possibly because it sold as an education exclusive device to school system. If anyone here shows interest, I'd be glad to do a tear-down (bubba do like destroy) and share it with the RK3399 community. -Follow up- Regarding cost. I paid somewhere under $50. If anyone else considers it, I suggest you be firm with the seller, and make an offer that is well under what they're going to be asking. Reason to be a cheapskate on these things? Well.. 1. Likely these were paid for by government tax funds for schools. Or written off as a privately owned business cost anyhow, which means someone like us already helped pay for them.. In the form of tax or tax return budget allotted to business owners. 2. Considering I'm not even sure if its possible to power on so simply without gpio testing or a breakout wizard beard 3. Cause we can build this things ourselves already for under $100 easily. So yea don't pay something more than that, even brand new for sure! Open Power Specification and 2 pins in the back is all I see so far. Ebay: https://www.ebay.com/itm/SMART-Model-AM40-Part-Number-1029788-Rev-07-No-Antennae-Very-Good-Condition/174156468137?hash=item288c88cfa9:g:DvwAAOSwCRVdcQyW https://www.ebay.com/itm/NEW-SMART-iQ-Appliance-AM40-Education-Digital-Signage-Player-Rockchip-RK3399/173853101572?hash=item287a73ce04:g:AccAAOSwaAlccc2l Manufacturer Reference: https://support.smarttech.com/docs/software/iq/en/about/specifications/am40.cshtml https://support.smarttech.com/docs/software/iq/en/about/iq-appliance-connectors.cshtml FCCID Technical Orders: doesn't seem to have its own nomenclature listing however, it is referenced in great detail its carrier device (an over priced touch screen) sourced for IMPORTANT notes before any reversing or mod attempt at introducing hardware compatible touch screen, PSU, OPS (serial) etc user manual control/command function search 'grep AM40' FCC ID QCIIDS665P1 QCI-IDS665P1, QCI IDS665P1, QCIIDS665P1, QCIIDS665PI, QCI1DS665P1, QCIID5665P1, QCIIDS66SP1, QC11DS665P1, OCIIDS665P1, 0CIIDS665P1 SMART Technologies Inc. SMART Board 6000S and 6000S Pro Series Interactive Displays IDS665P1 SMART LCD Monitor SBID-6065S, IDS665-1 Smartboard Interactive Display 6000S / Pro SBID-6265S, SBID-6275S, SBID-6265S-PW, SBID-6275S-PW https://fccid.io/QCIIDS675P1 https://fccid.io/QCIIDS675P1/Users-Manual/User-Manual-4554712 FCC ID QCI7086 QCI-7086, QCI 7086, QCI7086, QCI7O86, QC17086, OCI7086, 0CI7086 SMART Technologies Inc. Interactive Display 7086 https://fccid.io/QCI7086 https://fccid.io/QCI7086/User-Manual/Users-Manual-3626573 https://fccid.io/QCI7086/Internal-Photos/Internal-Photos-3626563 user manual control/command function search 'grep iQ appliance' FCC ID QCI7000 QCI-7000, QCI 7000, QCI7000, QCI7OOO, QC17000, OCI7000, 0CI7000 SMART Technologies Inc. Interactive Display 7000 https://fccid.io/QCI7000 https://fccid.io/QCI7000/Users-Manual/user-manual-3417295 https://fccid.io/QCI7086/Internal-Photos/Internal-Photos-3417295 OPS: Open Plug-gable Specification Serial (40 pin) Seria(40 pin) = OPS (80 pin *note, not sure exactly if this is the way to go, but closest I could find for now to adapt the OPS interface manufacturers "support" forum search regarding ops https://community.smarttech.com/s/global-search/OPS?language=en_US A Challenger Appears https://hackaday.io/project/20193-open-pluggable-specification-breakout-board https://www.digikey.com.au/products/en/connectors-interconnects/rectangular-board-to-board-connectors-arrays-edge-type-mezzanine/308?k=tx24&k=&pkeyword=tx24&s=54162&pv1989=0&FV=ffe00134&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25 OPS: Open Plug-gable Specification potentially an inconvenient convenience. (hdmi,usb,rj45 and etc..) to make the platform a module. imagine your favorite usb to serial, or whatever favorite debugging i/o. Now, chop off the USB part, and replace it with this. heres hoping those 2 pins are simple logic level voltage and ground Service Switch: Possibly switches between EMMC and SD Boot? May be interesting TLDR; possibly epic fail or epic win used condition: metal case / fan / rk3399 / 4GBDDR3 / 32GB EMMC vs NanoPi M4 Metal Case w/ Cooling Fan $30 to $45 Metal Case with Cooling Fan and RK3399/4GBDDR3/32GB eMMC $35 to $100

Hi, I'm trying to use desktop community build for Windows dev kit 2023 but it is not working. Current image: Armbian_community_24.8.0-trunk.554_Wdk2023_noble_wdk2023_6.7.0-rc6_gnome_desktop.img.xz When using etcher to flash to usb, it will flash but fail at validation step say "Cannot validate, the image could be corrupt" or something like that. If still use that usb in WDK, it won't boot. The lite version Armbian_community_24.8.0-trunk.554_Wdk2023_bookworm_wdk2023_6.7.0-rc6_minimal.img.xz is still working fine.

Is there any description how to setup the boot logo? I tried what I found: in build/packages/blobs/splash change logo.png and run command line with "BOOT_LOGO=yes", it doesn't work. After I found "What we use now is plymouth". OK. Does it work in compile time? I don't have plymouth after installing armbian in a docker container. How should I use plymouth (if it is the only way) to make a boot logo in compile time?

Hello! Just wondered if an armbian image was planned for the Odroid M1S? Thank you in advance!

I install armbian on the sd card, then insert it into firefly ROC-RK3328-CC. At the start, it flashes quickly 2 times, makes a small pause and flashes quickly 2 more times. Before that, it worked correctly, but I decided to reinstall the system and got this problem. I tried to install the system from firefly, as a result, only debian 9 worked, but it also worked with problems (at the first launch it reached the desktop, after rebooting and connecting the keyboard and mouse, it did not go beyond tty).

Hello Everyone I have added Armbian for the Heltec HT-M2808 Helium Miner https://github.com/armbian/build/pull/6989#event-13647037453 https://heltec.org/project/ht-m2808/ To Compile ./compile.sh build BOARD=rk3328-heltec BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=no KERNEL_CONFIGURE=yes KERNEL_GIT=shallow RELEASE=bookworm You can obviously decide to go with a desktop environment (board has no HDMI) or use a different release. How to Flash 1) Install Rockchip Flash Tools 2) Download bootloader (rk3328_loader_ddr333_v1.16.250.bin) attached here. 3) Boot device into LOADER mode. Plug USB Cable in to back of the unit, powered off. On the back of the device. Use a small pin and hold the reset button (unit powered off) THEN insert the power cable while the reset button is pressed 4) Follow the flash procedure found here. Maskrom Pin If you get stuck and need to reflash, there's a good chance holding the reset button will not work to get back into LOADER mode. To boot directly to MASKROM, you can short this pin Needed 1) Wifi/BT does not work currently 2) SPI not recognized 3) LEDs not working 4) Likely other things, but the OS is 90% functional. rk3328_loader_ddr333_v1.16.250.bin

I am looking to purchase an SBC ideally under $100 to install armbian and develop some hardware projects. I had previously gone for a BpiM5 which also has EMMC but when I came to install software I found there is little support from the makers, installing software is fiddly and the most recent Armbian images for this board were not working. I eventually got this going using Ubuntu Mate. For my next project I would like to change from Amlogic CPU's , use Armbian as the software base and choose a platform which has reasonable up to date support whilst avoiding going for an RPI. Regards

The build instructions `README` suggest it's possible to build an image using Github actions. So, I created a new repository and created the following file under `.github/workflows/orangepizero3_build.yml` name: Build Orange Pi Zero 3 server image on: workflow_dispatch: jobs: build-armbian: runs-on: ubuntu-latest steps: - uses: armbian/build@main with: armbian_token: "${{ secrets.GITHUB_TOKEN }}" # GitHub token armbian_release: "bookworm" # userspace armbian_target: "build" # build=image, kernel=kernel armbian_board: "orangepizero3" # build target armbian_ui: "server" But when I tried to run this action, I received this error: Error: Could not find file '/home/runner/work/_actions/_temp_52217267-7314-4a20-996d-95b7097793e8/_staging/armbian-build-de030c7/patch/kernel/rockchip-rk3588-collabora/dt/rk3588-nanopc-cm3588-nas.dts'. Am I doing something wrong? Is there some aspect to building an image using Github Actions I'm missing?

Hi there, I wanted to share with everyone here the final product - a gaming handheld we've designed from scratch in Solidworks. I've been working on this with a fellow Armbian contributor @GinKage for quite some time (probably over a year now... time really does fly) who has helped me learn a lot on the software side, which I wasn't really familiar with before I reached out to him. Despite it's shortcomings, I'm really happy with the v1 build. I hope you guys like it! Open source files can be found here, including CAD files, Armbian build files and more. https://github.com/StonedEdge/Retro-Lite-CM5 Retro Lite CM5: Radxa CM5 Gaming Handheld Specifications Hardware specifications 3D printable housing in PLA. Comfort grips for added ergonomics Radxa CM5 Compute Module (8GB RAM/64GB eMMC) SoC – Rockchip RK3588S octa-core processor with 4x Cortex‑A76 cores @ up to 2.4GHz, 4x Cortex‑A55 core @ 1.8GHz Arm Mali-G610 MP4 “Odin” GPU Video decoder – 8Kp60 H.265, VP9, AVS2, 8Kp30 H.264 AVC/MVC, 4Kp60 AV1, 1080p60 MPEG-2/-1, VC-1, VP8 Video encoder – 8Kp30 H.265/H.264 video encoder WiFi 6/Bluetooth 5.2 via PCIe E-key slot (Intel AX210) - https://www.intel.com/content/www/us/en/products/sku/204836/intel-wifi-6e-ax210-gig/specifications.html 6 layer carrier board with 3 B2B mezzanine connectors to interface with any Radxa CM5 module 5v boost rated at 3.5A continuous current RP2040 gamepad HID controller - complete with SDL mappings and evdev gyro support/mouse control via MPU6050 1280 x 720 (5.5" DSI IPS LCD): DSI video output on internal display Up to 4k HDMI video output via HDMI output Up to 4k DisplayPort Alternate Mode via Type-C USB 2.0/3.1 capable USB-C data transfer USB-C dual role port functionality (sink/source) Brightness and volume HUD adjustment. Brightness is adjusted by holding plus hotkey + down/up. Volume controlled either by volume buttons or plus hotkey + left right DPAD USB-C PD charging support via sink profiles supporting 5V/3A, 9V/3A, 12V/2A & 15V/2.6A (switch charger) via TPS65987D PD controller (see binary in TPS65987D folder). Recommended to use <12V for best charge and play performance Stereo Audio Output via i2s. Dual stereo speakers with ported chambers Headphone jack, with automatic switching 5000mAh lipo, providing around 1.5-5 hours of gameplay depending on load (to be upgraded to a larger size) Dual stacked shoulder buttons (L, R, LZ, RZ) with dual tact buttons for GameCube functionality (LR analog/LR digital) 2x hall effect analog sticks running at 3v3 Resin casted ABXY, DPAD, start+select, shoulder buttons Silicone membranes for nice button feel Software specifications Armbian GNOME desktop (Kernel 6.1.57 as of this post) Full upstream Rocknix support Hardware graphics support via Panfrost/OpenGLES (no Vulkan support… for now) Safe software/hardware shutdown (either from software or via button) Low power sleep mode Internal Components/Hardware/Random Pictures All of the components laid out - ready for assembly time! Internal PCBs - 6 layer boards designed myself, fitted with the compute module (v2.2 pictured) Handmaking all of the buttons with silicone and resin from a machined polished mould. 3D printed buttons really dont feel good so I wanted to make these special Final internal pictures before closing it up Front shot of Armbian desktop 😁 Flashed to the internal eMMC (non-socketable) with an SD card for added storage for running games via RetroPie Docking. DisplayPort functionality works over Type-C with my TPS65987D/TUSB546 PD extcon config. I have set it up to work with 2 lanes of DisplayPort and 2 lanes of USB 3.0 over Type-C Grips for added comfort. Because why not? Purple build! (GinKage)

How does compile.sh display the nice little icons like 🔨 when building an image

A few weeks ago I installed the minimal Armbian Bookworm image on a Odroid M1. The installed kernel was 6.6.31 The current minimal version for this board is 24.5.3 with kernel 6.6.36 After running apt update and apt dist-upgrade the kernel updated to version 6.6.32 which was build more then one month ago. I also used armbian-config to update the firmware in hopes that this covers the kernel as well but I am still stuck with the old kernel. What am I doing wrong? And how can I actually update the entire software, including the kernel to the most recent release without manually reinstallig the entire system?

The mainline 5.11 patch "phy: rockchip: set pulldown for strobe line in dts" https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e (not backported to 5.10.y) seems to have broken most if not all rockchip board EMMC HS400 enhanced strobe support. This probably affects supported rockchip boards (at least rk3399 ones, but probably most). That is boards exhibit: [ 18.985162] mmc1: running CQE recovery [ 18.988056] ------------[ cut here ]------------ [ 18.988500] mmc1: cqhci: spurious TCN for tag 12 and the filesystem ends up corrupted on write attempt. Note that another bug about regulator core DEFERRED support (which might have produced the same issue hardware wise) was introduced in 5.10.43 (I had bisected it to https://github.com/torvalds/linux/commit/98e48cd9283dbac0e1445ee780889f10b3d1db6a "regulator: core: resolve supply for boot-on/always-on regulators"). But I was confident that it to be fixed in at least 6.1 by https://github.com/torvalds/linux/commit/8a866d527ac0441c0eb14a991fa11358b476b11d "regulator: core: Resolve supply name earlier to prevent double-init" (introduced in 6.1), still EMMC was still failing on me. Thanks to @RussianNeuroMancer telling me that not all rk339 boards had EMMC HS400es broken, I found that nanopc-t4 had https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4 So the current way, from this nanopc-t4 commit, to fix EMMC HS400 on most rockchip is to add "rockchip,enable-strobe-pulldown;" to the "emmc_phy" node (at least this node alias for rk3399). &emmc_phy { + rockchip,enable-strobe-pulldown; status = "okay"; }; With this patch I can renable hs400es for rk3399 emmc on helios64 (it is already set for nanopc-t4 in mainline). Details in: I believe the https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e mainline commit was wrong in that it probably should have done the opposite (that is enable the pulldown) as most boards were hardwired so. As was done for rk3588 boards: "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 " JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees. Maybe one can confirm this is the case not only for rk5588 but for other rockchip boards? (about the default for hardware reset and rockchip BSP with regards to active that eMMC-DS pin's builtin pulldown if any, and board designers for other boards than rk5588 also not bothering to add a dedicated RDS resistor, instead relying on the rockchip internal bias, also if any on non rk5588) At least two other boards disabled hs400es in mainline probbaly due to this patch disabling the internal pulldown by default "phy: rockchip: set pulldown for strobe line in dts" https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e in 2023 in vanilla Linux: Rock 4C+ https://github.com/torvalds/linux/commit/2bd1d2dd808c60532283e9cf05110bf1bf2f9079 Rock Pi 4 https://github.com/torvalds/linux/commit/cee572756aa2cb46e959e9797ad4b730b78a050b

Simple to reproduce: Install armbian from Armbian_23.05.0-trunk_Bananapip2zero_bookworm_current_6.1.24.img after setup make apt-get update apt-get upgrade System will do nothing after reboot, LED stays off copying back kernel 6.1.24 brings it back to life again, with the rest upgraded. thanks Michael

Hi guys, I still have two 21.5-inch tablets here, on which I would like to install Armbian. The mainboard is a Sunchip AD-Z33 V1.1 with an RK3288 on board. The board has 2GB RAM and 8 GB flash memory. However, it also has an LVDS slot to which the touchdisplay is connected. Here you can see the equipment in detail: https://www.embeddedsystemboard.com/sale-11364924-rk3288-industrial-arm-board-multi-function-linux-os-i2c-interface-touch-screen.html Do you think that Armbian runs on it and that the functions are still available? Or maybe an RK3288 ArmbianTV box version could run on this as an alternative?

Bigtreetech CB2 and Pi 2 released somewhat recently (April 20th). They use RK3566 and have a lot of nice features. The board and module are intended for 3d printer use but can be used just like any other pi. There is an official linux image on bigtreetech github, and it seems it's a slightly customized armbian. I propose copying that configuration and adding it as a supported board. This is a bit of a personal tangent, but I was also thinking of how I can submit the device tree files to the mainline linux kernel, would that be a good idea? I'm planning to use or at least try Alpine on the board and it would be nice to have the needed files in the linux package already.

Hello, https://doc.embedfire.com/products/link/en/latest/linux/ebf_lubancat.html I tried to port the kernel device tree in the SDK provided to the mainline kernel, but it ultimately failed to start I'm not sure what the difference is between the device tree in the mainline kernel and the rk custom kernel Please help me.

Hi! Currently try to figure out how to run my freshly builded Armbian using QEMU arm64. According to this tutorial: https://docs.armbian.com/Developer-Guide_Build-Preparation/ I prepare clean Jammy VM. Build using this CMD: ./compile.sh BOARD=qemu-uboot-arm64 BRANCH=current RELEASE=bookworm Build process was going smoothly i pick up two files from output folder: 1) Armbian-unofficial_24.5.0-trunk_Qemu-uboot-arm64_bookworm_current_6.6.29_minimal.img.qcow2 2) Armbian-unofficial_24.5.0-trunk_Qemu-uboot-arm64_bookworm_current_6.6.29_minimal.u-boot.bin Currently boot up process stucked, i can run U-boot and mount qcow2 image using this CMD: qemu-system-aarch64 \ -machine virt -cpu cortex-a57 \ -netdev user,id=net0 -device e1000,netdev=net0 \ -serial stdio \ -bios Armbian-unofficial_24.5.0-trunk_Qemu-uboot-arm64_bookworm_current_6.6.29_minimal.u-boot.bin \ -drive if=none,file=Armbian-unofficial_24.5.0-trunk_Qemu-uboot-arm64_bookworm_current_6.6.29_minimal.img.qcow2,id=mydisk \ -device ich9-ahci,id=ahci \ -device ide-hd,drive=mydisk,bus=ahci.0 U-boot see the drive with rootfs, but during boot process i had this error: Failed to load '/boot/uInitrd' Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid Boot failed (err=-14) Full boot process log: U-Boot 2023.10-armbian (Mar 14 2024 - 01:18:23 +0000) DRAM: 128 MiB Core: 51 devices, 14 uclasses, devicetree: board Flash: 64 MiB Loading Environment from Flash... *** Warning - bad CRC, using default environment In: pl011@9000000 Out: pl011@9000000 Err: pl011@9000000 Net: e1000: 52:54:00:12:34:56 eth0: e1000#0 Hit any key to stop autoboot: 0 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': Scanning bootdev 'fw-cfg@9020000.bootdev': fatal: no kernel available No working controllers found scanning bus for devices... Target spinup took 0 ms. SATA link 1 timeout. SATA link 2 timeout. SATA link 3 timeout. SATA link 4 timeout. SATA link 5 timeout. AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode flags: 64bit ncq only Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 54564.0 MB = 53.2 GB (111747072 x 512) Scanning bootdev 'ahci_scsi.id0lun0.bootdev': 0 script ready scsi 1 ahci_scsi.id0lun0.bootdev /boot/boot.scr ** Booting bootflow 'ahci_scsi.id0lun0.bootdev.part_1' with script scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 54564.0 MB = 53.2 GB (111747072 x 512) Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 54564.0 MB = 53.2 GB (111747072 x 512) <DIR> 4096 . <DIR> 4096 .. <SYM> 28 Image <SYM> 24 dtb <DIR> 4096 dtb-6.6.29-current-arm64 38518 boot.bmp 0 .next <SYM> 28 uInitrd 906 boot.cmd 6040046 System.map-6.6.29-current-arm64 978 boot.scr 49178863 uInitrd-6.6.29-current-arm64 318778 config-6.6.29-current-arm64 38134272 vmlinuz-6.6.29-current-arm64 49178799 initrd.img-6.6.29-current-arm64 KERNEL LOAD ADDRESS: kernel_addr_r : 0x40400000 INITRD LOAD ADDRESS: ramdisk_addr_r: 0x44000000 FDT LOAD ADDRESS : fdt_addr : 0x40000000 38134272 bytes read in 853 ms (42.6 MiB/s) ** Reading file would overwrite reserved memory ** Failed to load '/boot/uInitrd' Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid Boot failed (err=-14) --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid) Any ideas what i'm doing wrong?