KY69 reacted to skyfly555 in Armbian for Amlogic S9xxx kernel 5.x
I totally agree with @balbes150.
In my opinion, what he's doing is absolutely great.
Maybe it's easy to forget @balbes150 is doing this for free, and maybe we don't know how many hours he's spending on doing this (I bet some of them, everyday).
Thank you, Mr. @balbes150: I think you should be paid by ATVs manufacturers, because, thanks to your work, and only in my case, they have sold 3 Amlogic ATVs (to me); and I had never bought them because of Android: It's your Armbian, the reason
To be sincere, I'm happier with my ATV boxes, running @balbes150 Armbian, than I am with my Raspberrys, covered by tons of dust in this very moment.
KY69 reacted to mb16 in Armbian for TV box rk3328
Glad to read I seem to have created something useful.
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection.
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.
KY69 got a reaction from manuti in Armbian for TV box rk3328
It probably already works for the box you linked, but if I may suggest, this one already works for sure, it costs just a few dollars more (4/16 model), and has twice the amount of RAM. I wouldn't think twice:
KY69 reacted to ab1jx in Terrible Synaptic performance
That problem was cured by not keeping the package info in compressed form as far as I'm concerned. You have to change something in a config file then delete the lists and apt-get update again. It's 10-20 times as fast now.
If you have to live without Synaptic try apt search.
KY69 got a reaction from Xiaofan in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)
I remember I had similar problems a few months ago when I tried installing Armbian on my TX3 mini for the first time. I did some tests back then and if I recall correctly mounting any Linux partition (extX) on Android seemed to be changing the file system to use SElinux permissions, which prevented Armbian from even reaching the first login prompt. I had the same problem even after having everything running and simply mounting the SD card or HDD on Android, it simply messed everything up, and changing all permissions back was time consuming, so I simply do NOT mount any linux filesystem when running Android on the box. Actually I never even boot Android, I bought the box specifically to run Armbian, sadly I haven't had time to play with it for over a month now.
But the symptom was as you described, I prepared the SD card, updated the box to multiboot (via Android, so it mounted the linux filesystem on the SD card and messed it up right there), and no matter what dtb file I used it would halt somewhere like what you showed. After rewriting the SD card and not mounting it on Android (I already had multiboot), Armbian booted out of the box, but it took me some time to figure that out. After I had the system working I booted Android and inserted the SD card, and I was again not able to fully boot Armbian due to SElinux permissions on certain system files (actually all over the filesystem, but fixing the permissions to a few system files made the system bootable again. Afterwards I still had to fix the whole filesystem nonetheless). I tried a few things after I had the system running from an HDD, and simply mounting this HDD on Android was enough to "update" the file permissions and make Armbian unbootable again. In summary, at least with my TX3 mini, I cannot mount any media with Armbian partitions on Android. I believe my box has Android 7.1 from March/2018.
In fewer words, your problem is probably not with the Android Update app, but with Android itself whenever it mounts the extX partition(s). Hope this helps somehow.