MaxT

Hi,
I'd also like to see armbian running on my M1S.
It arrived today and honestly I ordered it in the hope to see it being supported one day.
Afaik none of the devs currently own an M1S yet, what makes development somewhat more difficult. So I would be happy to contribute by providing my M1S for tests.
So if anyone without an own M1S can provide an Armbian image with modified device tree and so on I will try to perform the desired tests.
 
Cheers and thank you!

This is a tricky shit that hides behind openness, but in fact tightly controls the main part-the loader. I.e., at any time, it can block or completely control any unwanted person's actions.
 
 
It's funny, you described a whole theory about freedom, and as a result it all came down to advertising and pushing aml shit. 
For your information, aml imposes its BSP shit on everyone, which is stuffed with Trojans and bookmarks to gain full control over those who use their shit. They lie to all users about their hardware and actively cooperate with those you are trying to protect yourself from.
 
In general, everything is as usual, if you remove the beautiful words about freedom, it all came down to the fact that "someone" would spend their time and money and provide the rest with free use of aml shit.
 

In /home/hts there are two hidden folders:
/home/hts/.hts and /home/hts/.xmltv

stop tvheadend, tar profile which is in /home/hts like here http:// https://askubuntu.com/questions/834717/recursive-tar-compression
on another system stop tvheadend, untar profile, start tvheadend.

I guess that you will have to manually check that dvb cards are properly mapped

I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.
The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:
the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before) the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000 the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot u-boot finally loads the device tree and boots the kernel when you use prepare the u-boot and trust images with  loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).
Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.
 
The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:
The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory the SoC ROM code reads the u-boot SPL that immediately follows the TPL u-boot SPL executes the OPTEE trustos u-boot SPL executes the main u-boot u-boot loads device tree and boots the kernel For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.
 
My guess is that the rk3318/rk3328 boot process is very much the same
 

Michael was asking me in a PM where the MAC address is persisted during "first boot" ...
@TonyMac32 are you aware of the persisted address file location ?