jeanrhum

Testers needed. More especially, people with samsung, nexell or even marvell are expected.
The main issue for now is the way the dtb is named and located in the boot folder. I tried to infer it using the comptible property of the device tree, but I don't own all supported hardware .
I already tested sucessfully on several kernels (aml 4.20, rk and aw on 5.8, 5.9).

https://www.stationpc.com/thread-126-1-1.html

First pull request for me: https://github.com/armbian/config/pull/123
It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.

First pull request for me: https://github.com/armbian/config/pull/123
It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.

First pull request for me: https://github.com/armbian/config/pull/123
It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.

First pull request for me: https://github.com/armbian/config/pull/123
It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.

:
 
Issue is finally fixed in (at least) nightly builds !
 
There is now a "pine64-7inch-lcd" overlay in /boot/dtb//allwinner/overlay
 
Just add
 
 "overlays=pine64-7inch-lcd"
 
to armbianEnv.txt and screen magically works.
 
A BIG thank you to the team for fixing this! Pine64 is now ready for mainline kernel goodness!
 

I see your point. You are used to deal with some profile of TV-box user, with high expectations and little technical knowledge. I personally would not call "dangerous" the standard approach of erasing eMMC in order to replace it for Armbian, it is what we do in many other boards. I have personally done it, the method is documented in official Khadas documentation, as well as the method for flashing the original Android again. But, again, I see your point, that it can be somehow "dangerous" for someone who has no clue of what he is doing.
 
So I think a sane approach is to keep the kvim2.csc the same way as we have been doing all along with kvim1.csc, which has not produced many complaints so far. The option in the build script is there, but we don't publish images among the supported boards, nor specify the method to install them. That way, only users with enough knowledge to use the build script will have those images. At least, for the time being, this may change in the future of course.
 
Besides that, I have developed a new function for the bash script, that grabs the meson-gxm boot blobs from the amlogic-boot-fip repo, as well as some patch to fix CPU scheduling in AML S912. These things can be useful if/when we start to support the Tartiflette.
I'm making a PR with all these changes.

I think this could be an interesting soc, but in how many months (or years)?
This soc is not referenced in sunxi status matrix and nothing is planned in kernel 5.11, so I fear that support is not even started from their side. Maybe it's close enough to h6, but I didn't see any information about somebody able to start linux with it and it has a different gpu.
 

I gave some bucks for this powerful server. Paypal was perfect for me. Long live to armbian!
I hope the target will be attained soon.

The  transcoding is handled by the jellyfin-ffmpeg package, which is basically a fork of ffmpeg. You can specify your own path to ffmpeg binary in settings, as the supplied binary is linked with raspberry libs (which is the only rpi specific code of jellyfin).
Raspberry pi is ok for VPU.
 
@Wernertry jellyfin on your NEO3 and compile ffmpeg with --enable-version3 --enable-rkmpp --enable-drm
 
Personally I don't use transcoding but leave it all to the RPI3 (LibreElec) which happily plays all formats from SMB except for 10bit x265.

I updated the system with the new dtb package and edited the tree again, this time without the feiyang panel.  Here are the the .dts snippets for dsi and d-phy:
             
  dsi@1ca0000 {                         compatible = "allwinner,sun50i-a64-mipi-dsi";                         reg = <0x1ca0000 0x1000>;                         interrupts = <0x00 0x59 0x04>;                         clocks = <0x02 0x1c>;                         resets = <0x02 0x05>;                         phys = <0x44>;                         phy-names = "dphy";                         status = "okay";                         #address-cells = <0x01>;                         #size-cells = <0x00>;                         phandle = <0x8d>;                         vcc-dsi-supply = <0x04>;                         port {                                 endpoint {                                         remote-endpoint = <0x45>;                                         phandle = <0x20>;                                 };                         };                 };                 d-phy@1ca1000 {                         compatible = "allwinner,sun50i-a64-mipi-dphy\0allwinner,sun6i-a31-mipi-dphy";                         reg = <0x1ca1000 0x1000>;                         clocks = <0x02 0x1c 0x02 0x71>;                         clock-names = "bus\0mod";                         resets = <0x02 0x05>;                         status = "okay";                         #phy-cells = <0x00>;                         phandle = <0x44>;                 };  
This time, dmesg is at least not displaying any mipi or dsi-related errors:
 
# dmesg | grep dsi
[    2.318045] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360)
~# dmesg | grep mipi
[    2.275838] vcc-mipi: Bringing 2900000uV into 3300000-3300000uV
 
so definitely closer.
 
Now I'm going to re-visit the thread and armbian documentation to see what needs to be done to enable.
 
 

Funny thing is, I haven't seen any outrage about HK using startup protection on "foreign" hardware in its u-boot, which causes the firmware in the device to be destroyed if it's not HK hardware. Where are you defenders of freedom ? I have long seen that most of all squeal about the violation of rights of those who themselves are engaged in theft and piracy, that would hide behind the freedom of their personal dirty deeds to get their personal benefits at someone else's expense. Yes, I warn all fans of freebies in advance that they would not try to hack and try to run my future versions, which will be designed for specific supported models, on their unsupported hardware and for all the consequences of disrupting the operation of their devices, they will be to blame themselves.

Technically Balbes never supported the s905x3. But it is true that he is now ending support of all amlogic cpus.  I already make my own kernel builds, and since I own a few different amlogic based boxes, I have an interest in seeing support continue in some form.  I have asked balbes in another thread if he would tag his public github repositories with a tag that corresponds to his last build supporting amlogic, which then can be a starting point for continued support by the community if there is enough interest.

Now you can download the latest versions of images and DEB packages from the official Armbian resource via the link. 
 
https://users.armbian.com/balbes150/

Good news. Now you can download the latest versions of images and DEB packages from the official Armbian resource via the link. 
 
https://users.armbian.com/balbes150/

You have an error in your extlinux.conf: you should comment the rk3399 lines and uncomment 1 line of amlogic starting with fdt and the last one starting with append.
Here is the one I use for s912 boxes (you may change the dtb if the generic q200 is not relevant):
And you may also change the extlinux.conf-menu file:
 

For less than 100$ you can go with Odroid N2/N2+ which is plenty powerful, but as already suggested float around properly supported SBCs and find one that best suits your need.
 
Expensive tvboxes from known vendors usually are good quality, but I would not suggest to buy them to do server jobs.
IMHO SBCs are a couple of notches superior for build quality, support and warranty, tv boxes are for toying around mostly

This information is already outdated and does not correspond to the current market situation.
 
Make a mistake, rk3399 now has one of the best support in the main kernel (not to be confused with specific models of SbS or TV boxes, chip support and ready-made device support are not the same).
 
 

v20.08.1
Due to several - mainly small - problems in last build we are considering pushing out a smaller bug fix release.
 
- fixes that are merged in next 7 days (due = September 4th)
- all images will be rebuild
- an update will go out

H3 is very well supported in armbian and linux mainline, but I don't know if there is a NAND driver actually.
The choice of the box vastly depends on what you need to do and how much horsepower you need with that one.
If you want to be sure you get what you actually want, buy a proper SBC with eMMC and a case.
Hardware of tv boxes, expecially cheap ones, is always a lottery, as you already experienced by yourself.

I tested your newest debian server on my x96 mini with s905w dtb and it works well!
 
I was also able to install a desktop environment with armbian-config.
As expected wifi and bluetooth are not detected. It should require some specific firmware (armbian-firmware installed) but I had not open my box to see the chip.
I also saw a problem with zram service not working.

Ethernet works: http://ix.io/2pla
 

The new version 20200609. In it, I switched to using the u-boot version 2020.04 (source shared with universal images for aarch64). This version has long implemented the function of starting the system from USB media. Now rk3288 also has the option to start the system from USB media. Minimal Bionic and Buster images have also been added to the site.
 
Starting from USB is available on both systems (Libreelec and Armbian). For example. You can write to an Armbian SD card, and write to a Libreelec USB flash drive. When you connect both media, LE will work, and when you disable the USB flash drive, Armbian starts.
 
 
p.s. The correct installation of these systems in eMMC is currently being tested.

Hello anyone!
I'm proud to announce the Multitool RK3288 edition!
 
It's a small but powerful tool to easy operate on internal eMMC flash of RK3288 devices.
 
Features:
Backup the content of internal eMMC Restore a previously backed-up image to eMMC Erase the eMMC (via fast blkdiscard or zero-fill as fallback) Burn an Armbian (or LibreELEC) image directly on the eMMC Provide a recovery shell for manual maintenance Windows-friendly: everything is placed in a FAT partition Image compression format autodetection: they are decompressed on-the-fly during burn process Instructions are simple:
Download the image from here Burn it on an sdcard Open the FAT partition with your preferred file manager Place the images you want to burn on the device in images directory (backups will be stored in backups directory) Plug the sd card in the RK3288 device Power the device and wait few seconds, the Multitool menu will appear on screen and can be navigated with the keyboard At the moment it has been tested only on my xt-q8l-v10 device, but any test, feedback and suggestion is welcome!