September 13, 2018

Nanopi Fire3 and the bl1 loader - fix a bug

I have adopted the bl1 bootloader and forked my own copy. A ran into a bug that kept me busy for a couple of days, and like all things of this sort, it all seems fairly simple now.

The symptoms were that when I loaded an image via USB, it would trigger an exception. A confusing aspect was that I remembered using the bl1 loader with success a few days before. My work had been interrupted by a couple of days of intensive work on another project, so my memories were far from clear.

The problem was that when loading an image via USB (and only in this case) the loader would not copy the 512 byte header into memory. So the first 512 bytes of memory were uninitialized. So if my code specified an address in the first 512 bytes (and it did), anything was possible.

My confusing memory of things working was because the code in bl1 that boots from SD card does not have this bug. It first reads the 512 byte header into static ram so it can pull fields out of it to guide the boot process. Then it also copies the header into target ram. Apparently my memory of things working was when I was placing images onto SD card (both bl1 and the image I wanted to run and test), which would indeed work.

Also note that if the launch address was beyond the first 512 bytes of the image (i.e. if the header was nothing more than a header), the USB boot code would work, but almost all code I have seen expects to branch to code contained in the header.

Lessons Learned

It is always hard debugging code written by someone else, especially if you for some reason have confidence that it is for some reason beyond criticism. Interruptions are always dangerous, and without careful records past results cannot be trusted, and perhaps not even then. There is probably no shortcut except to work patiently, trust nothing, and perform tests to find the problem.

Have any comments? Questions? Drop me a line!

Tom's electronics pages / [email protected]