@luz
I'd be genuinely interested in understanding the background of wanting to prevent reading out firmware in the first place.
I now realise that the Omega family of chips is not positioned as being secure, but I do need to demonstrate that I can do all that is reasonable to make hacking difficult. We've gone to great lengths to ensure that our software services are secure. At the end of the day though, while we can't do a great deal to protect against physical access, there is information that we need to protect reasonably. Having uboot provide an easy way to gain access to the file system via the console seems avoidable, so we should attend to that. Again, having Onion support this style of bootloader would be great as I imagine most commercial deployments involving the Omega family would/should want it. However, building one's own flavour of the bootloader is arduous unless you're familiar with the process.
If an attacker gains physical access via hardware and is determined by taking the cover off the Omega chip and connecting to its flash over SPI, I'm not sure there's much that can be done to prevent that given the MT7688 architecture. That is, other than potting a board hosting the Omega in resin or similar (including its console pins).