stut

@stut - here i wrote down quite a bit of information about how to build mainline u-boot for amlogic s905x/w devices - see: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxl - you might try the ones i built (see the july 18 2020 releases of that github repo) - gunzip all the files with boot-amlogic_gxl_*.gz and then dd them to an sd card and try to boot them one by one with serial console and a hdmi monitor connected (some have serial console and some hdmi) - if you are lucky one of them maybe gives you a working mainline u-boot you can boot from sd card
 
good luck and best wishes - hexdump

Since this link is down does anyone have an image of the latest published for S812?

If your emmc is not working, I don't think you can.  My understanding is that these amlogic boxes basically are hard coded to look for uboot on emmc.  That is why the aml-s9xx-box builds use the emmc uboot to then chain load the distribution from sd/usb/etc.  It is always using the emmc uboot initially.  If your emmc is working, you should use recovery to reinstall the android uboot and then you could move on from there.  But in your case you have already tried that, and it didn't work (likely indicating that your emmc is not working).  Based on your comments, it sounds like you have previously reinstalled the android firmware, so you know that process used to work (the reason I am stating this, is that sometimes different boards/firmware combinations require specific versions of the amlogic burning tool)

Another factor is that at least as far as the armbian builds go, there is no uboot suitable for your box available.  It isn't feasible/possible to build uboots for the hundreds of different tv box hardware configurations out there (and the tv box manufacturers don't release their source for their android uboots), so the uboot on the armbian build sd card is basically just a place holder (generic uboot that 100% is guaranteed not to work for your box).  The whole armbian amlogic tv box strategy is to use the uboot that comes with the tv box on emmc.  So if you are trying to get something working from sd, it isn't going to be armbian unless you can get your emmc working again.

These instructions are for Amlogic CPUs for TV Boxes. 
 
Note: If you have previously run other distributions on the box such as coreelec the below installation will not work.  You will need to restore the original android firmware before attempting the install.  coreelec changes the boot environment in ways that are incompatible with these Armbian builds.
 
Download links:
    Weekly Community Rolling Builds:  https://www.armbian.com/amlogic-s9xx-tv-box/
    or build your own image using the Armbian build framework
 
Once you download your chosen build, you need to burn the image to an SD card.  Generally balenaEtcher is recommended as it does a verification of the burn.  Also be sure to use high quality SD cards.
 
Once you have the SD card with your chosen build, then you need to edit the boot configuration file on the SD card.  In the BOOT partition of the SD card there will be a file /boot/extlinux/extlinux.conf, that you need to edit.  There will also be a extlinux.conf.template file to use as a reference.  You will need to add a line into the extlinux.conf file for the Device Tree (dtb) file you will be using for your box.  Place this line before the APPEND line as shown in the .template file.
 
Basically you need to have the correct dtb for your box.  You may need to attempt to use different dtb files until you find the one that works the best for your box's hardware (there are a bunch of dtb files in /boot/dtb/amlogic/... to try depending on your cpu architecture and hardware).  It is unlikely that there will be a matching dtb file for your TV box.  The idea is to find the one that works best for your box.  This may mean that you try booting with different dtb files until you fine one that works good enough for your needs.  By searching the forums you will find information about what dtbs other users have found work best for different boxes.  Because you are booting from an SD card, you can easily try different dtb files.  The dtd files are named by cpu family.  So for example dtb files for the s905x2 cpu are named meson-g12a-*.  Below there is a table that shows the identifiers for each familiy (g12a for s905x2 in this case).
 
Next you need to copy the correct uboot for your box.  This is needed for how these builds boot on amlogic boxes.  There are four different u-boot files located in the /boot directory:  u-boot-s905, u-boot-s905x-s912, u-boot-s905x2-s922, u-boot-s905x3
You need to copy (note copy not move) the u-boot file that matches your cpu to a new file named u-boot.ext in the /boot directory
So for example with a TX3 mini box that has an s905w cpu you would copy u-boot-s905x-s912 to u-boot.ext: cp u-boot-s905x-s912 u-boot.ext
(See table below for more details on which u-boot to use for which cpu)
 
Once you have your SD card prepared you need to enable multiboot on the box.  There are different ways documented to do this, but the most common is the "toothpick" method.  The "toothpick" method means to hold the reset button while applying power to the box.  The reset button is often hidden and located at the back of the audio/video jack connector.  By pressing that button with a toothpick or other such pointed device you can enable multiboot.  What you need to do is have the box unplugged, have your prepared sd card inserted, then press and hold the button while inserting the power connector.  Then after a bit of time you can release the button.  (I don't know exactly how long you need to hold the button after power is applied, but if it doesn't work the first time try again holding for longer or shorter times).
 
You should now be booting into armbian/linux.  Note that the first boot takes longer as it is enlarging the root filesystem to utilize the entire SD card.
 
After you are satisfied that your box is working correctly for your needs you can optionally copy the installation from the SD card to internal emmc storage (assuming your box has emmc). (Note: Installing to emmc has some risks of bricking your box.  Don't do this unless you feel you understand how to reinstall your box's android firmware)  You install armbian to emmc by running the shell script in the /root directory: install-aml.sh. Note: It is not possible to install into emmc on boxes with the s905 cpu (s905x, s905w, s905x2, etc however should all be supported).  It is recommended that you make a backup of emmc first.  Also be prepared if anything goes horribly wrong with your emmc install to reinstall the android firmware using the Amlogic USB Burning Tool to unbrick your device.  If you have or can find an original android firmware on the internet and you can generally (but not always) recover a bricked box using the Amlogic tool and the original firmware file.
 
 
Mapping from CPU to uboot and dtb:
 
u-boot-s905
s905 - gxbb
 
u-boot-s905x2-s912
S905X - gxl
S905W - gxl
S905D - gxl
S905L - gxl
S805X - gxl
S912 - gxm
A311D - gxm
 
u-boot-s905x2-s922
S905X2 - g12a
S922 - g12b
 
u-boot-s905x3
S905X3 - sm1
 
Not supported or not tested
S805 -
S905W2 -
S905X4 -
S805X2 - s4
A113D - axg
A113X - axg
 
 
 
Note: Followup posts in this thread should be limited to comments to improve or better understand these instructions.  Other issues should be posted as new questions in the Amlogic CPU Boxes sub-forum.

@balbes150 If I could ask a favor of you.  Would it be possible to add a tag to your public github repositories that corresponds to your last build supporting AML?  With a tagged version of source code that corresponds to your final released build others can pick up where you have left off if they are capable and motivated.  I appreciate your dedication to armbian and respect your decision to end your support of Amlogic cpus.

Most of the boards just got one freshly build test image - check bottom of download pages.
 
- minimal image only
- mainly kernel 5.6.y
- Ubuntu Focal 20.04 based
- u-boot 2020.04
- xz compressed
- no end-user support

Each kernel version needs its own dtb. So I'm afraid you will have to make one from scratch for 5.x kernels. I also have a mxq s805 board and no dtb was working for either 4.x or 5.x kernels. It just runs 3.x kernels and that's about it. We need someone with skills that can make an up to date dtb for s805 mxq boards or stick to kernel 3.x where everything including nand works.

You make a good point! I will contact some of these sellers and offer them a low amount. It will be a nice device to learn and tinker with and it shouldn't be too difficult to hunt down a SDK for this somehow somewhere. Which might make it easier to get Armbian on this. This box could make a nice little router or access point or something. I'm mostly sold on the form factor to be honest. I got a weak spot for these kind of boxes. I hope I can get my hands on one or two at a nice price. 
 
As for your power bill, I charge powerbanks using one of those 'camping' solar panels and use those powerbansk to run sbc's on. During day time the pass trough charging makes sure all the banks are filling up and at night there's enough juice left to last all night. And to be honest my main sbc doesn't take much at all. I have a bunch of NanoPi NEO2 boards and as Pihole or little webserver they're usually under 100ma at 5v. Very very little.
 
You could also get one of those chargers they had for the OLPC laptops. They have this foot pedal or crank to generate power. Charge powerbanks with it that are powering your sbc, or build your own desk 

 

You make a good point! I will contact some of these sellers and offer them a low amount. It will be a nice device to learn and tinker with and it shouldn't be too difficult to hunt down a SDK for this somehow somewhere. Which might make it easier to get Armbian on this. This box could make a nice little router or access point or something. I'm mostly sold on the form factor to be honest. I got a weak spot for these kind of boxes. I hope I can get my hands on one or two at a nice price. 
 
As for your power bill, I charge powerbanks using one of those 'camping' solar panels and use those powerbansk to run sbc's on. During day time the pass trough charging makes sure all the banks are filling up and at night there's enough juice left to last all night. And to be honest my main sbc doesn't take much at all. I have a bunch of NanoPi NEO2 boards and as Pihole or little webserver they're usually under 100ma at 5v. Very very little.
 
You could also get one of those chargers they had for the OLPC laptops. They have this foot pedal or crank to generate power. Charge powerbanks with it that are powering your sbc, or build your own desk 

 

you'd be supprised at how the asking price and market value can find a reasonable middle ground with a reasonablely low offer on technology. because the supported hardware/software revision has expired anyhow (EOL); i believe any open pluggable specification device pre 2017 are about (less) as useful as my virtualboy or sega saturn was at its EOL as far as market value is concerned.  
 
i imagine if they ask more than $50-70 the seller better verify from buyer and seller should confirm its not EOL, is  model 2017+  new or used with all parts in working order.. and boots to an OS... otherwise it needs to be relisted as for parts only and gfl.
 
-phew. my 2-or-more-bits oppionion anyhow
 
 
on topic;
 
thank you, and I will give a legitimate attempt to bub my way through flashing armbian to this board!
 
 
 
 
till then I had better mention a few important things; some of which have may already been said multiple times by myself or others, on forum or otherwise
 
 
# disclaimer and acknowledgement
# I claim no rights to inventing, development, safe practices or translation iterization utilization or any other legal shit that hoes on, on this device, reference, or any other planet.
#this disclaimer is possibly the only thing i take responsiblilty for, so if any system, ANY system breaks down, welcome to the club, bubba destroy  alot of stuff for hobby and educational purposes only.
#if it armbian made, old new borrowed or dissassembled, I will share the knowledge and credit source to those who are due credit as best as possible.
 
#any the unlikely event of any new software or hardware  developed unless otherwise mentioned specifically as my own creation is purely by a miracle circumstance and sheer brute force plug it in till it works or breaks method.
 
# peer sharing is awesome, bright red blood makes the green grass grow, and always remember to spay and tutor your pests.
 
supporting original content creators and future makers is probably a really good thing.  money is a tool for helping many people create something together, so use it intelligently once in a while.
 
Which reminds me, all shit costs electricity.
i gotta go invest in a hamster wheel and hamster army to power this experiment. thats what i would say anyway, if i was the boss of anything.
 
 
 

you can try activating the multi-upload manually. Execute these commands.
 
usb start
fatload usb 0 1020000 aml_autoscript
autoscr 1020000

Most of them are working as long as they are 2.7V and above. Frequency is not really an issue since in DT it is usually set 40MHz and could be lowered manually by editing DTS.
I've used Winbond ones on both my OPiZeros and OPiPC2. So, I suggest Winbond one, but maybe also GigaDevice.

https://yadi.sk/d/QCGU0PIv3G5kEa
 
 

mainline amlogic hwvdec with patches still in review, can be directly used by mpv with `-hwdec=auto`
 
cpu usage drop to 10% from 50%

or just add SUBREVISION=.99999 to your build command line

I have the waveshare 2.8 A tft and touch panel working on the Orange Pi PC2 with one long dtoverlay. 
 
Some of my inspiration came from here: 
 
Like i said one dtoverlay, both fbtft and the touch panel, no other overlays needed. 
 
I admit i am a neophyte and it might be possible to trim this one slightly and use it in combination with the CS1 dtoverlay but it wasn't clear to me how that would work. 
 
I am using a 6 inch hand-made cable to connect my waveshare 2.8 A but it is wired straight through on only the needed wires for touch and tft. 
 
As I've said before it should work just the same with a 3.2 B. 
 
May work on PC Prime as-is, should work on other orange pi boards with minor changes (compatible arch and the assignment of pin 26 varies from board to board).
For orange pi zero, zero plus (H3 and H5), maybe some others, instances of PA21 should be changed to PA10. Check your pinouts to be sure. 
 
The spi speed of 1.6mhz for the tft is a safe example, I have run up to 4mhz without issues and might be able to go higher but i am leaving the safe default in place for this post.
 
one caveat: as i said i don't have a use for the touch panel in my application. I tested it by catting /dev/input/mouse1 and running a fingernail over the touch panel. I got output. yay. More tweaks might be needed, but the driver is fundamentally working and all the overrides are included in the dts
 
waveshare_32b_28a_opipc2.dts

Thanks for the instructions @NicoD!
 
I modified the mesa build options to enable egl:
meson -D egl=true -D gles1=true -D gles2=true -D shared-glapi=true -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/  
With egl one can compile and run git version of supertuxkart.

Panfrost instructions Armbian
 
!!!! I made a script that does all this, check a few posts later for the script !!!!!  
This tutorial explains how to build an Armbian image with panfrost. And what else you need to make it work.
These are early drivers. Many things don't work yet. Only OpenGL 2.1 works now.
 
You need to build an image with kernel 5.2 or later.
For this you need an x86 pc with Ubuntu 18.04 or a virtual Ubuntu 18.04 x86 image.

First install git, then clone the build folder from Armbian, and enter the build directory.
 
apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build Now run the script with EXPERT=yes so you can choose to build a dev image.
sudo ./compile EXPERT=yes Choose "Full OS image for flashing" Then "Show a kernel configuration menu before compilation" Choose your board. If it's not in the regular list, look in "Show SCS/WIP/EOS/TVB". Choose Development version kernel configuration -> device drivers -> graphic drivers -> panfrost  
Let it run until it's finished. The image will be in the /build/output/images
Burn it to an SD-card/eMMC/...
 
Now we need to install all the needed software
sudo apt install flex bison python3-mako libwayland-egl-backend-dev libxcb-dri3-dev libxcb-dri2-0-dev libxcb-glx0-dev libx11-xcb-dev libxcb-present-dev libxcb-sync-dev libxxf86vm-dev libxshmfence-dev libxrandr-dev libwayland-dev libxdamage-dev libxext-dev libxfixes-dev x11proto-dri2-dev x11proto-dri3-dev x11proto-present-dev x11proto-gl-dev x11proto-xf86vidmode-dev libexpat1-dev libudev-dev gettext glmark2 glmark2-es2 mesa-utils xutils-dev libpthread-stubs0-dev ninja-build bc python-pip flex bison cmake git valgrind llvm llvm-8-dev python3-pip pkg-config zlib1g-dev wayland-protocols Download and install meson
wget http://ftp.de.debian.org/debian/pool/main/m/meson/meson_0.55.3-1_all.deb sudo dpkg -i meson_0.55.3-1_all.deb Download and install mesa DRM
git clone git://anongit.freedesktop.org/mesa/drm cd drm meson build --prefix=/usr ninja -C build sudo -E ninja -C build install cd .. Download and install mesa graphics
git clone git://anongit.freedesktop.org/mesa/mesa cd mesa meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/ ninja -C build/ sudo ninja -C build/ install REBOOT
 
Optionally, update sdl (recommended)
git clone https://github.com/SDL-mirror/SDL.git cd SDL mkdir build cd build cmake ../ make -j6 sudo make install REBOOT
 
Only thing that works ok with it is supertuxkart, to install it.
sudo apt install supertuxkart
 
Panfrost - Linux games working from repo
SuperTuxKart - Works well
ExtremeTuxRacer - lots of glitches
AssaultCube - lots of glitches
 
Instructions by Salvador Liébana & NicoD

What may help is adding a custom version string in menuconfig when building the kernel package.

I don't have specific experience with widevine but debian-derived distributions including armbian are capable of hosting multiple ABIs. 

Your s912 is aarm64 but is backward compatible with armhf. Your 32-bit arm binary is armhf. Similar to how an amd64 system is backward compatible with an i386 system. 
 
You start with dpkg --add-architecture armhf
 
then apt-get update
 
Then you install 32-bit versions of everything you need for your 32-bit netflix, etc with "apt-get install foo:armhf" and so on. 
 
I've only done this on a small scale, but if you get lucky and everything you need is in the distribution, it's pretty painless.  the "ldd" command will tell you what libraries a dynamically linked binary needs to have around. 
 
more info here: https://wiki.debian.org/Multiarch/HOWTO

Very nice guide, thanks for this! What I'm missing is an upgrade part. How does one upgrade to a newer release without losing data? I remember a while back we could download separate deb files for the new release and install those one by one. But I don't see those anymore, just an image now. Is the best way to upgrade to do a clean install and then copy back the old files and stuff? Almost seems more feasible to build your own from source so you end up with the deb packages to upgrade an existing system. But Maybe I'm missing something.

I was having issues connecting to certain APs, the password was always wrong even though I knew for sure they were right. In the end it was due to network-manager's random mac address trickery. After disabling it I could connect just fine. Maybe the random mac should be turned off by default as it can interfere with certain APs?
 
A quick fix, create /etc/NetworkManager/conf.d/99-disable-wifi-random-mac.conf and add the following;
[connection] wifi.mac-address-randomization=1 [device] wifi.scan-rand-mac-address=no  

I was having issues connecting to certain APs, the password was always wrong even though I knew for sure they were right. In the end it was due to network-manager's random mac address trickery. After disabling it I could connect just fine. Maybe the random mac should be turned off by default as it can interfere with certain APs?
 
A quick fix, create /etc/NetworkManager/conf.d/99-disable-wifi-random-mac.conf and add the following;
[connection] wifi.mac-address-randomization=1 [device] wifi.scan-rand-mac-address=no  

Important information for Rockchip RK3328\RK3399 and Allwinner H6. If you have written to the SD card any version of the system that uses a GPT table or a non-standard u-boot (for example, an Android image or an Ubuntu image built by the device manufacturer, etc.). Before writing an Armbian or Libreelec image, be sure to zero the entire SD card with the
 
dd if=/dev/zero  of=/dev/<sd_card> bs=64M
 
command. Only then can you write the image to the SD card and it will work correctly. If you do not zero the SD card, there will be problems with u-boot from Armbian and Libreelec (u-boot does not start and stops with a partition table error message). For those who use the new version of u-boot, which supports direct launch from USB media, I recommend using USB media to launch, this guarantees that the system will start, regardless of what was previously on the USB media.