U-boot seems to ignore ymodem crc, perform explicit crc checks in memory
While working on end-to-end testing of hi3518ev300 I spent some time analyzing boot failures that came from seemingly nowhere. In search for sanity I programmed a "golden" image that I know boots correctly. To my surprise it failed virtually the same way that my other attempts did, crashing in early startup.
I got a hint of what was going on when I ran the u-boot help command repeatedly. Each time the output would be similar but slightly corrupted. Some bytes apparently got lost or corrupted.
While proper shielding for the serial port is another topic, we can do better inside oh-flash itself. We can use the u-boot crc32 command to compute the checksum of the memory we either just initialized or just transferred from the host. This will let us stop and repeat the transfer before attempting to program anything.
Separately we should inspect if u-boot is really ignoring that CRC we compute or is the checksum weak enough that it can be fooled by the particular corruption I've experienced.