after reading the very entertaining thread regarding the BPI-W2 and the following opening of the bsp-kernel on github, I became curious and when prices dropped for the Lake-1-TV-Box, I decided to play around with it.

Without very much documentation there was a bunch of trial and error and still many things are not absolutely clear to me, but finally I could boot an armbian build today:

 _          _          _ 
| |    __ _| | _____  / |
| |   / _` | |/ / _ \ | |
| |__| (_| |   <  __/ | |
|_____\__,_|_|\_\___| |_|
                         

Welcome to ARMBIAN 5.68 user-built Ubuntu 18.04.1 LTS 4.9.119-rtd1295   
System load:   1.49 0.74 0.31   Up time:       3 min
Memory usage:  4 % of 1631MB    IP:            
CPU temp:      46°C             
Usage of /:    11% of 7.2G      

[ General system configuration (beta): armbian-config ]

New to Armbian? Check the documentation first: https://docs.armbian.com


Thank you for choosing Armbian! Support: www.armbian.com

This is still connected over the serial port and completely untested. I had to use the strange chained double-u-boot and load kernel and dtb manually (from raw sd card sectors), so it is not even close to alpha. But it seems, that this can be improved. 

I plan to make a repeatable build config, but do not expect some really usable stuff anytime soon.  The situation with the lack of mainline support was already discussed in the other thread and the future does not look very bright here.

This is more or less a personal playground at the moment. But if anyone is interested, you can leave comments or questions here.

Sticky part (updated 03-03-2019):

RTD1295-Devices:

      Tested: Lake 1 Home Cloud TV Box

      Untested: Beelink SEA 1, Zidoo X9s, Zidoo X8, Zidoo X10,  Probox2 AVA, WD My Cloud Home, ...

All development and tests thus far have been done on the Lake-1-TV-Box. It can not be ruled out, that the other boxes have other u-boot-versions/-configurations.

Prerequisites:

Mandatory:

Serial connection soldered to the PCB (to reach the u-boot-shell) and a suitable terminal software. Further information here: https://en.opensuse.org/HCL:Lake1 (I can not confirm that „SD rescan“ does not work. Only „fatls“ and „fatload“ never worked for me, that’s why raw sector reads are used.)

Recommended:

Access to a Windows-PC, a USB-male-to-male-cable and the knowledge to re-flash the device by yourself.

If you are not comfortable in doing this, DON’T DO IT!!! YOU CAN BRICK YOUR DEVICE FOREVER !!

Current installation process (booting from SD-Card):

1. Build a full-OS-image with armbian selecting „lake1“ from this fork: https://github.com/Staars/build. This will create an image with kernel image and dtb written to sectors before the root partition. The u-boot-build of armbian is not used.
2. Write the image (using etcher) to an SD-card. For the moment we will not touch the eMMC of the target device and therefore will work as non-destructive as possible. This might change in the future and it should be no problem to implement a eMMC-only solution, but at the moment there is no solution in sight, that would let you dual-boot Android and Linux.
3. Create a terminal connection to the serial pins of your target device and intercept the boot process immediately after power up to reach the first u-boot-shell. Now we have to edit the BOOTCMD the following way:

• env edit bootcmd
• sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr
• env save

           This is a relatively harmless operation and can be reversed with the insertion of 'bootr' in step 2.

           The Android-installation on the eMMC stays untouched.

   4. Now at every boot the device will initialize the SD (which can fail!!), load the image and dtb, change the bootargs and call the second u-boot, which then will (hopefully) boot the kernel. 

U-boot:

At the moment u-boot will be build, but not used. Because of bootloader encryption this will likely stay that way. We can build the fsbl-parts, but without the proper encryption the boot stops, when the first part (hw_setting) is loaded. 

A separated u-boot-fork at https://github.com/Staars/u-boot-rtd is used for the armbian build, but that does not really matter. We must use the vendor-u-boot and we can not do real scripting (no RUN-command) but only chaining of commands.

Kernel:

The starting point from Sinovoip was labeled 4.9.119, but this is very likely not the whole story. Some parts are even newer and some are probably older, given the fact that git-cherry-picking showed possible updates when used with the stable linux-4.9-branch below tag:4.9.119.

The additional phoenix drivers were partly integrated in the kernel-fork on https://github.com/Staars/linux-kernel-rtd/tree/latest_patched as an extra folder to keep them in one place.

If there should be really an adoption of this platform in the future, it might be a good idea to go the other way around and merge the soc-specific parts into a generic linux-4.9.-fork. This is a bit of work, but it should be possible.

The fork is currently patched to 4.9.174

New kernel fork started at https://github.com/Staars/linux-stable/tree/linux-4.19.y (not 4.20 because of LTS) and armbian build config updated.

DTS/DTB:

This is a minimal changed version for the banana-pi w2. 

Bluecore.audio:

I do not really know if this (audio firmware?) is useful outside of Android. It is written to the SD-Image (directly behind the DTB), but not loaded.

What works:

-SATA-port (incl. booting with /root on SSD with bootarg 'root=/dev/sataa1')

-WLAN (onboard 8821AU), but there are very short freezes every few seconds

-simple software install (i.e. OMV)

-reboot/restart works, but can take some time

-bluetooth

What does NOT work:

-bluetooth

-halt/restart

Things to do:

-waiting for someone, who confirms, that this is repeatable on other setups

-working on the DTS/DTB

-test Ethernet, USB

-HDMI-in/-out or graphics in general (very low priority for me)

-eMMC-only-install (must check first, where it is safe to write data)

-test 4.19 (functional regression expected)

Board_Pics:

I try to install Armbian on my Arduino UNO Q (2 GB), but it fails with all three images

• Armbian_community_26.2.0-trunk.703_Arduino-uno-q_trixie_edge_6.19.0_minimal.tar.xz
• Armbian_community_26.2.0-trunk.703_Arduino-uno-q_noble_edge_6.19.0_gnome_desktop.tar.xz
• Armbian_community_26.2.0-trunk.703_Arduino-uno-q_noble_edge_6.19.0_kde-neon_desktop.tar.xz

The error message:

.\arduino-flasher-cli.exe flash .\Armbian_community_26.2.0-trunk.703_Arduino-uno-q_trixie_edge_6.19.0_minimal.tar.xz

WARNING: flashing a new Linux image will erase any existing data that you have on the board.

Do you want to proceed and flash .\Armbian_community_26.2.0-trunk.703_Arduino-uno-q_trixie_edge_6.19.0_minimal.tar.xz on the board? (yes/no)
yes
Unzipping Debian image
arduino-images/
arduino-images/disk-sdcard.img.esp
arduino-images/disk-sdcard.img.root
arduino-images/flash/
arduino-images/flash/imagefv.elf
arduino-images/flash/zeros_1sector.bin
arduino-images/flash/multi_image.mbn
arduino-images/flash/gpt_main0.bin
arduino-images/flash/gpt_backup2.bin
arduino-images/flash/featenabler.mbn
arduino-images/flash/boot.img
arduino-images/flash/prog_firehose_ddr.elf
arduino-images/flash/tz.mbn
arduino-images/flash/xbl.elf
arduino-images/flash/rawprogram0.xml
arduino-images/flash/gpt_both0.bin
arduino-images/flash/gpt_empty0.bin
arduino-images/flash/gpt_backup1.bin
arduino-images/flash/xbl_feature_config.elf
arduino-images/flash/rawprogram0.nouser.xml
arduino-images/flash/gpt_main2.bin
arduino-images/flash/km4.mbn
arduino-images/flash/gpt_backup0.bin
arduino-images/flash/zeros_33sectors.bin
arduino-images/flash/gpt_main1.bin
arduino-images/flash/abl.elf
arduino-images/flash/rpm.mbn
arduino-images/flash/storsec.mbn
arduino-images/flash/devcfg.mbn
arduino-images/flash/cdt.bin
arduino-images/flash/hyp.mbn
arduino-images/flash/qupv3fw.elf
arduino-images/flash/patch0.xml
arduino-images/flash/uefi_sec.mbn
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
github.com/arduino/arduino-flasher-cli/internal/updater.Flash({0x7ff7f72e8c08, 0xc0000e9e50}, 0xc000288130, {0xc0000a8060, 0x54}, 0x1?, 0x0, {0x0, 0x0}, 0x0)
        D:/a/arduino-flasher-cli/arduino-flasher-cli/internal/updater/flasher.go:95 +0x757
github.com/arduino/arduino-flasher-cli/cmd/arduino-flasher-cli/flash.runFlashCommand({0x7ff7f72e8c08, 0xc0000e9e50}, {0xc000288110, 0x1?, 0x1?}, 0x0, 0x0, {0x0, 0x0})
        D:/a/arduino-flasher-cli/arduino-flasher-cli/cmd/arduino-flasher-cli/flash/flash.go:117 +0x349
github.com/arduino/arduino-flasher-cli/cmd/arduino-flasher-cli/flash.NewFlashCmd.func1(0xc00002c908, {0xc000288110, 0x1, 0x1})
        D:/a/arduino-flasher-cli/arduino-flasher-cli/cmd/arduino-flasher-cli/flash/flash.go:74 +0x94
github.com/spf13/cobra.(*Command).execute(0xc00002c908, {0xc0002880e0, 0x1, 0x1})
        C:/Users/runneradmin/go/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1019 +0xae7
github.com/spf13/cobra.(*Command).ExecuteC(0xc00002c608)
        C:/Users/runneradmin/go/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1148 +0x465
github.com/spf13/cobra.(*Command).Execute(...)
        C:/Users/runneradmin/go/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1071
github.com/spf13/cobra.(*Command).ExecuteContext(...)
        C:/Users/runneradmin/go/pkg/mod/github.com/spf13/cobra@v1.9.1/command.go:1064
main.main()
        D:/a/arduino-flasher-cli/arduino-flasher-cli/cmd/arduino-flasher-cli/main.go:71 +0x3f0

.\arduino-flasher-cli.exe flash latest works as expected, so it seems to be an issue with these images. Or do I use the wrong installation method?

The problem is reproducible under Windows 11 and Linux.

Installation over Armbian Imager also fails

• https://paste.armbian.com/fowidugipo
• https://paste.armbian.com/ogekaqalaq

I'm creating a board configuration for NanoPi Zero2 (RK3528A) and wanted to coordinate with the community before submitting.

Great News: Mainline Support Exists!

I discovered that Jonas Karlman has already merged NanoPi Zero2 device tree support into mainline Linux kernel:

• Device tree: rk3528-nanopi-zero2.dts (merged for v6.15-6.18)
• U-Boot support: Also merged
• Source: https://github.com/ziyao233/rk3528-mainline

Since the hinlink-h28k.csc config already provides RK3528 support, creating a NanoPi Zero2 config should be straightforward.

Quick Questions

1. Is anyone already working on this? (Don't want to duplicate!)
2. Kernel branch: Should I target current (6.12) or edge (6.15+) for the DTB?
3. Bootconfig: Can I reuse hinlink_rk3528_defconfig or does Zero2 need its own?

My Plan
  # Copy existing RK3528 config
  cp hinlink-h28k.csc nanopi-zero2.csc

  # Update:
  BOARD_NAME="NanoPi Zero2"
  BOOT_FDT_FILE="rockchip/rk3528-nanopi-zero2.dtb"
  KERNEL_TARGET="current,edge"

Testing Commitment

• Hardware: NanoPi Zero2 arriving next week
• Use case: Production IoT device (headless, Docker, eMMC boot)
• Will test: Full manufacturing flow, LED control, eMMC boot, network, Docker
• Will contribute: Tested config + documentation

Why This Board?

Tiny form factor: 40×40mm
Production-ready: Good margins, reliable supply
Sufficient specs: 2GB RAM, eMMC, single GbE
Mainline support: Thanks to Jonas Karlman's work!

Any advice before I proceed? Happy to collaborate or take guidance from maintainers. Thanks! 🙏
 

It looks like Olimex have forked Armbian-build and done the board bringup: https://github.com/OLIMEX/imx8mp-build/commit/a3cb5ad2710cd3edf6a4c6c067b049af48b03fa5#diff-1b53368896f4902ddbb5db1fa206835ccbb04445cd8bcaa5fef353655794665a

How could I bring that code back into the main https://github.com/armbian/build/tree/main

I think I need to rebase the Olimex fork back to the main Armbian Repo?

Or should I fork the Armbian repo and then re-apply the Olimex changes to the fork?

Does the C4 image work on the C5?

Is there any Armbian .img available for this SBC ? 

I wanted to ask if it would be possible to add support for installing Armbian on the UniFi CloudKey Gen1. It uses an MT7623, very similar to the BPI R2, which appears to already be supported.

Below is information about the UC-CK hardware:

FCC ID, Datasheet

MT7623AI
2GB DDR
16GB internal storage
Micro SD slot

(1) 10/100/1000 Ethernet Port

I am a crappy user not helping armbian to survive. My apologies. However, because I'm studying more linux, arm technologies. I would like to give any help to armbian. I am poor, not rich. But if there is another way to donate thousand dollars I'm ready to help.

So my question is How to help Armbian about the new Orange pi sbc, orange pi 6 plus?

Modos can delete this post if it breaks rules. No any problem for me. 

My apologies, my english is bad.

Noticed the NanoPi Zero2 the other day and it might help me setting up a wifibridge WiFi (WiFi6) to LAN.

Since it has the  RK3528A SoC there is an image avaiable based on that SoC , though for the Rock 2F

Therefore wondering about its status and if it will be (not) adapted?

Thanks

I'm building a custom board for the AM69 processor, which is similar to AM68.

My question is if there is any Arabian support for AM69 with web browsing e.g Chromium with streaming ability such as Youtube/Netflix etc?

Any pre-compiled builds?

I read that at least the RK3528 SOC is just getting Mainline Support for the Clock as in Kernel 6.15. No USB, Ethernet, PCIe or GPU support at all right now.

I don't know how similar the RK3528 and RK3528A are, I couldn't find much Information on the Internet.

At the very lead I would need MicroSD, Ethernet and USB (including USB OTG) working.

I saw there is a Repository with some Notes for the RK3528 SOC on Github, outlining the Status of getting Mainline Support:

https://github.com/ziyao233/rk3528-mainline

@Igor mentioned a few Months ago on Github that he planned on getting the Radxa Rock 2F Board soon, but no Timeline available yet:

https://github.com/armbian/build/issues/7836#issuecomment-2662772344

@Igor: did you have a Chance to play a bit around on the Radxa Rock 2F ? Is anything working right now ?

Thanks for the Help !

I would like to add support for Milk-V Mars in the Armbian build system. Right now I am building for visionfive2(build boots fine with u-boot in spi) and intend to see if I can reuse the DTBs produced by the Milk-V Mars official SDK build(https://github.com/milkv-mars/mars-buildroot-sdk/releases/). I am looking for guidance on how to proceed. The board has the same SoC as the Visionfive2 but different peripherals (USB, m.2).

L.E. I realized that the bootloader from the image cannot boot the image, the “official “ u-boot from SPI flash is used instead. Possibly due to some incompatible config.

You can find info on luckfox web. 

Thanks

A question about Quartz64. Can I create a PR for CSC or do we not support it in any form ?

Today run wince 6.0 but i can replace for rdp client OS .

Thanks by any way .

Heber

https://www.crowdsupply.com/ov-tech-gmbh/pi-mx8-module

- SOC: NXP i.MX 8M Plus

- NXP guarantees production of the chip for 10 years.

- 4x A53 cores at up to 1.8 GHz / 1x M7 core at up to 700 MHz

- 1 GB/2 GB/4 GB/8 GB LPDDR4 system memory

- Vivante GC7000UL GPU

- Gigabit Ethernet PHY supporting IEEE 1588v2 and SyncE

- PCIe Gen3 1x1 Interface

- Optional eMMC with 8 GB/16 GB/32 GB

- Optional 2.4 GHz & 5 GHz Wi-Fi + Bluetooth 5.2 (Murata LBEE5PK2BC)

- Optional Coral Edge TPU connected via PCIe

- Two CSI-2 interfaces, one with 4-lane and one 2-lane width

Some open hardware carrier boards exist such as

Twisted fields CanBUS/ Robotics

Piunora Camera, Qwiic, Arduino pinout

Jkiv Gigabit, uSD

Will cluster

RobertLukan dual camera, 40 pin header

Wiretrustee SATA/ NAS

Mirko PC 2x HDMI, 2x Camera, M.2, uSD, 40pin

tkircher camera, Qwiic, M.2, HDMI, uSD

Others

I plan to use this thread to document the hardware and other related efforts to support IMX8 hardware, intending to add Armbian support for this board.

So far I have found:

- https://github.com/Joshua-Riek/ubuntu-apalis-imx8

- https://github.com/TechNexion-customization/ubuntu-tn-imx/tree/master?tab=readme-ov-file#technexion-ubuntu-lts-image-builder

One issue is the HDMI output which seems to be quite unusual. I can only get one of my monitors to display an image (a 4K philips) .

The usual 1920x1080 screens such as Acer 22" don't work.

It also seems the Debian version can only run an overlay driver rather than native

I already run a NanoPi M4V2 and a NanoPi R2S under Armbian and am very happy with them and armbian

I'm happy to be a guinea pig for anyone wanting to get an armbian version running on the T6. I have some respectable machines that can do cross-compiles quite fast. 

I want to get the device to run fully native drivers and specifically have full control over the NPU cores for hard-core image applications.

https://disk.yandex.ru/d/3Xta87KhFem-Bw

But he can't detect NAND.

root@dispatch:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0  14.9G  0 disk
└─mmcblk0p1 179:1    0  14.7G  0 part /
zram0       254:0    0    50M  0 disk /var/log
zram1       254:1    0 246.3M  0 disk [SWAP]

Onboard flash: 8G eMMC (Reference: http://wiki.banana-pi.org/Banana_Pi_BPI-P2_Zero)

Your distro would become a bestseller quickly.

Please share your opinion on that directly on Github.

I'm wondering if there is any armbian resources for this chip? I got thousands of Hi3798mv300 / Hi3798mv310 chips from my uncle who is recycling hardware devices from some factories.

If I can activate all of them. I will be able to build a real cluster in my farm for many upcoming MPP test.

Thanks,
Gary Willmes

https://wiki.seeedstudio.com/ODYSSEY-STM32MP157C/

With ST Microelectronics move into the MPU space, there is a lot of potential growth for a mature and trusted US brand with the integrity to provide proper documentation

Free hardware can be provided if required. Free stuff. Just sayin'

Who is interesting to develop Armbian for the Quartz64?

I will spend two brand new boards (8GB) to developers.

Send me a mail, if you are intresting:    markus@humberg.de

(found one on http://www.banana-pi.org/r2.html - hidden in the 'gallery photos' which looks like the revision I have)

Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description ):

• MT7623n (ARM Cortex-A7 quad core)
• GbE over MTK7530 (1x "wan" 4x "lan")
• 2x USB 3.0 and 1 USB 2.0 otg port
• 2x SATA over asm1061
• (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested)
• Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript)
• wifi/bluetooth combo-chip (b/g/n / 4.1)
• HDMI
• Powering over 12V barrel jack

Pros:

• relatively cheap (~90$ Aliexpress)
• Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment)
• 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it)
• MT7623 gets relatively good upstream support by Mediatek in mainline
• There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  See https://forum.armbian.com/topic/7296-bananapi-r2-csc/?do=findComment&comment=55245 
• the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing ).
• It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board, still a lot of stuff linked to sources not provided by them self e.g. description of 'how network is implemented), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds. 
• U-Boot patches for this SoC are under review for upstream 

Cons:

• u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working).
• There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker ) http://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&media=bpi-r2:boot-structure.png  the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time)
• During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot)
• There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work ), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  I think, I pickt more or less all of the SoC relevant drivers after 'a few attempts'... 
• Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't...   The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know.
• From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'.
• I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images. 
• No LTS-Kernel due to 4.14 has a lot of back-ports inside which might mess up things in case a other member of the same SoC will join the boardfamily. 4.19 will be the first LTS which we might use for this board
• Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.

So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):

• Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) Will not longer be supported by my builds.
• U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking)
• SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run).
• Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list'). Will most likely never be supported due to 'mainline only' and I will not implement an android wifi driver into the mainline kernel.
• dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse).
• Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot). 4.17.0-rc7 based on multi_v7_defconfig slightly adjusted to bring up the device but still a lot of 'clean up' needed.

Disclaimer: 

If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 

It's not armbian, it's just a Image created with armbians buildscript at the moment:  

 ____                                  ____  _   ____  ____
| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  _ \|___ \
|  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |_) | __) |
| |_) | (_| | | | | (_| | | | | (_| | |  __/| | |  _ < / __/
|____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| |_| \_\_____|


Welcome to ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.14.42-mt7623n 
System load:   0.30 0.09 0.03   Up time:       0 min
Memory usage:  2 % of 2013MB    IP:
Usage of /:    28% of 3.5G

This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen`  open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).

So happy discussion (with valid arguments)... 

Specs look decent - 1GB, 16MB SPI-NOR, 8GB eMMC - runs OpenWRT, but they promise ubuntu support - shipping mid-October 2019

https://www.gl-inet.com/products/gl-mv1000/

I've done work with other devices in their product lineup - and GL-Inet does a pretty good job on the HW side, and good SW support.

Nice that they have USB gadget support on the USB-C port (which is also power)

Initial vendor docs here -- https://docs.gl-inet.com/en/3/setup/brume/first-time_setup/

I need to run Armbian Distro linux on imx8 NXP platform.

Can you please provide the following information 

1.Is Armbian Distro supported on imx8 Platform

2.How to download the source code for Armbain distro which runs on imx8 platform.

Please help on above topics 

we are looking for a low-power SBC with (deep sleep) / poweroff features for IoT applications.

Arduino or any other MCU board are not suitable for doing our use cases, so we are investigating the use of an low-power SBC.

i.MX6ULL (https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industrial-Grade-Linux-SBC-eMMC-Version-p-4221.html)

has an integrated PMU with a lot of different low-power modes.

Like SNVS mode, where only the power for the SNVS domain remain on. In this mode, only the RTC and tamper detection logic is still active

This board is quietly new is there any possibility that this board can be supported by the Armbian community.

Thankyou in advance.

IMX6ULLIEC.pdf

I need help to build a new ARMBIAN - Image based on DEBIAN fort this board: https://www.tq-group.com/de/produkte/tq-embedded/arm-architektur/stka8mx/

Can anyone help me with building, etc. for this board?

Best regards

Matthias

Maaxboard 2GB RAM boot from sd-card, NXP i.MX 8M - Cortex-A53 Quad-Core  1.300MHZ ( it can run 1.5Ghz) 

I have added solid fan.

The recent official images are already based on debian, but the kernel is NOT the mainlined opensource version: https://beagleboard.org/latest-images

Thats why it would be great to see armbian supported with mainline image. I prefer the clean mainline kernel armbian images for everything.

I have searched in this forum to make sure that i dont double post about this. There is no thread about armbian support for BeagleBone Black.

The hardware itself can run on fully free software already. The only not supported thing is the GPU for OpenGL-ES acceleration but that is not important and also the usage of it is not that high this days. Video output is already mainlined and working.

Great things about the beaglebone black:

Its PCB-design is OpenHardware! So anyone can start building this device: https://github.com/beagleboard/beaglebone-black/tree/master/ALLEGRO

System reference manual: https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual

Its supported by mainline kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.20-rc3&qt=grep&q=beaglebone+black

Also the BeagleBone Black wireless version is supported upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.20-rc3&id=fbb5850bd3c13a7a804c2f47dbd9eeb05e4e4b4a

(but it require closed source wifi blob - personally i am not interested in the wireless version because of that and dont own it because of that reason)

The BeagleBone Black is a really stable device:

I am willing to test images for the BeagleBone black. Developers can send me images for the BeagleBone black and i would test them and send logfiles. This and the case that everything is already mainlined make it possible to add BeagleBone black to armbian also for people who dont have the hardware at home.

Sadly i am terrible at coding after trying it out many times.

BeagleBone Black is avialable to order and would be probably available for much longer time thanks to OpenHardware + OpenSource software supported. I think its worth it to be supported by armbian.

Thanks!

New threads should be created here by people who have the intention to add official Armbian support for a new board.

Clarification: this is not a subforum for requesting support for a new device or asking when/if a new device will get the support.

Clarification: official support is possible only if one or more members of the core team have this device, in other cases it is still possible to add a community supported configuration (CSC).

• The device in question should be available for buying by anybody (except shipping/export limitations), even if in small quantities or in a BTO queue. Please do not ask for "official support" for a private/custom designed board.
• Requests for new devices without the intention to contribute to the Armbian build framework should not be posted here.

Clarification: if you are posting a new thread here we can assume that you already tried to integrate support for this device into the Armbian build script and you already got a bootable image based on Armbian.

• Please check the build script sources for a list of supported, community supported and discontinued devices first.
• Raspberry Pi family will not be supported.
• TV boxes in general will not be supported by the core Armbian team.

Currently there is no "Board Bring Up" template or checklist, please check the recent topics.