Since the application boot sequence is hardcoded (not defined using bootcmd) we need to dive deeper into how this works.

Using Ghidra I have decompiled the U-boot MIPS assembly code to understand more. I simply loaded the DRAM dump performed earlier into Ghidra and disassembled for MIPS32 architecture. The initial output from Ghidra is difficult to interpret, but slowly as you start to give functions and variables more intuitive names the process begins to speed up.

It turns out that the application boot sequence is very complicated with CRC checks and multiple flows for various software upgrades via ethernet and USB. There is also some redundant code that seems to perform no function whatsoever, almost as if this version of M-boot has been further hacked and modified by the author of the final application software. I will provide more detail on this later in the form of a flow chart after I've fully reverse engineered it.

What I have managed to determine is the main application boot sequence. In order to replicate it via the U-boot command line type the following sequence:

spi_rdc 0x81100000 0x300000 0x700000
mscompress7 d 0 0x81100000 0x700000 0x80000180
go 0x80000224

This sequence: 1.) copies the compressed application image from flash to DRAM starting at starting 0x81100000, 2.) decompresses the image to DRAM starting at address 0x80000180, 3.) begin code execution from DRAM address 0x80000224. The main application now boots with display out via HDMI. Note, this sequence bypasses all of the CRC checks in the standard hardcoded sequence.

Interestingly, we can also use the same process to boot the secret software upgrader application:

spi_rdc 0x81100000 0x90000 0x250000
mscompress7 d 0 0x81100000 0x250000 0x80000180
go 0x80000224

Again, this provides a display output via HDMI and goes through a sequence of trying to update software via ethernet, USB and OTA.