@vpeter
Kernels built with UAS=Y or even UAS=M with a UAS-capable drive as bootup drive will freeze during init and has no interactive console through UART to debug. After some digging I found even when a driver is built as a split module instead of built-in it will still be included in the initramfs, and then be loaded during init if needed. The module however, can’t be loaded for wierd reason and freezes inits as a result.
Some manual tweaks and I found a workaround: avoiding uas driver entirely before sysroot is mounted. Having kernel+system images on sd and storage partition on uas drive does the trick.
I’m guessing UAS is disabled by default due to this, and Amlogic didn’t test nor wanted to support this since the use cases for a UAS drive on Android TV box is not that demanding. There’s also a lot of fixes made to uas.c after 4.9 was branched from mainline Linux, so I don’t think uas support in Amlogic’s 4.9 kernel is that robust.
Do you have any idea why loading uas driver during init would freeze the system entirely? Or what should I do to at least get more logs from UART?
But from what I read there can be multiple issues with UAS driver and that’s why we decided to not include it. It is safe for wider audience. And if some user really want it self build is possible.
Booting from non-UAS drive is also OK for me, the problem is when a kernel.img with UAS module is loaded from a UAS-drive. As long as uas need to be loaded during init to initialize the bootup drive, the kernel hangs and nothing helpful for debug can be gotten from uart.
Thanks, I thought the module was already included given it would also hang when uas is set to built-in and didn’t check the options here. Would test about it tomorrow.