Most of the systems integrations teams doing this stuff know too little about Linux and Android to do it
"properly". This has been so ever since wireless routers started using Linux, and I see no significant change in quality, except possibly when they simply fork OpenWRT and add their own look-and-feel. (Do note that OpenWRT, while good, isn't any kind of a pinnacle either; it's very generic and modular, is all.)
For the SD card Dave dumped, it really looks to me like a bog-standard Android system image.
One that has not been optimized, and is, uh, quite "vanilla", indicating that with some systems integration work, the boot-up time could be shortened significantly, for example. I wonder how receptive Rigol would be towards such suggestions?
(It really depends on whether they used some external team to cobble something together for them, or whether they set up their own team that is still getting up to speed on how to optimize Android for appliance use. I'm really hoping for the latter, because that means future updates could be really nice for users, also showing how to leverage their chosen hacker-friendly stance for actually creating a better end product. Time will tell.)
How realistic do you think it would be for an external team to cobble together a low-power standby mode? Put the RK3399 into a low power mode, turn off the screen and a low power state for the Xilinx FPGA? Obviously keeping the RAM state. Then "instant on" if any button is pressed?
Sleep modes for the RK3399 are supported by the kernel already, so it's really only a matter of the FPGA. The FPGA is a black box; I don't know if they even implemented software power control for it. Anything else is doable. Even hibernation (suspend to disk), although I wouldn't want to do that with an SD-card based storage.
Thus, the answer is: it depends on how they control the power to the FPGA. If the control is sane-ish, very realistic. If there is no software power control, and the FPGA circuits are designed to be powered whenever the power is on, then it won't work.
I myself have much more experience with Linux-based integration than Android, the difference being in the userspace, but I really don't see why the bootup should take 45 seconds. Something like 15 seconds would sound more reasonable for this hardware, although the SD card could be a bottleneck here. Not necessarily the
bandwidth, but the
IOPs, i.e. scattered small-file read speed. On SD cards, it is often under 1 MB/s. The maximum bandwidth for the SD card on the RK3399 is 104 MB/s per SD3.0.
Note that using the eMMC 5.1 HS400 interface that the same subsystem on RK3399 supports as an alternative (but would use more pins than SD card) would top at 400 MB/s. This alone would not make a big difference to the boot time, I believe, but it would allow options with better scattered small-file read speed.
Presumably Android has a lot of [power state and sleep stuff] built-in as every tablet & smartphone needs to preserve battery life?
Absolutely. There are even tools designed to help linearize the file access patterns on bootup, to speed up booting for devices that tend to have slow scattered small file I/O access. The vendors don't
do their own tools for this, they use the standard Android tools to finesse their systems integration. Which, I must admit, on phones (and most TVs and TV boxes) is pretty impressive, overall. If I recall correctly, I saw some of these in the system image Dave grabbed –– but I only did a quick look-see to get an overview, not any kind of examination.
Hibernation, also known as suspend-to-disk, would also be a viable option if the mass storage medium was more reliable. I don't think phones use that (because the radios need to be on or wake up regularly), so it is rare on Android; but the kernel does have the necessary doodads for this, and it is widely used in Linux.
here is a Linux ARM suspend to disk summary from 2014, for example.