I'm trying to use elftosb (V4.0.0) to generate an updated version of the flashloader sb file, and having some troubles.
I created a bd file with the following contents;
flags = 0x00;
startAddress = 0x20208000;
ivtOffset = 0x400;
initialLoadSize = 0x2000;
elfFile = extern(0);
...and then created the ivt-including file with;
amd64/elftosb -f imx -V -c c.bd -o flashloader.bin evkmimxrt1020_flashloader.axf
(I had to use my own built version of the flashloader because the one in the distribution is V2.1 and the one in the bootloader example is V2.7).
I can then upload that to the board, and run it, with;
./sdphost -u 0x1FC9,0x0130 -V -- write-file 0x20208000 flashloader.bin
./sdphost -u 0x1FC9,0x0130 -- jump-address 0x20208400
...trouble is, it doesn't start :-( The flashloader works perfectly when run from mcuexpresso.
On investigation I find that the version of the file uploaded by mcuexpresso and the version uploaded by sdphost are identical, until the very end of the load. To the left is the working version uploaded from mcuexpresso, to the right the version uploaded by sdphost (Star means the line is repeated...this is output from od);
...what is confusing is that the end of the program image is at an offset of 0x15f48, and everything looks good until there!
If I take the memory image on the left and re-upload it using sdphost then flashloader all works correctly. My conclusion is therefore that sdphost is curtailing the write of the output file too soon but, frankly, it shouldn't matter because the differences are all after the end of the program, according to the map file.
I have no idea what is going on here. Can anyone suggest what these extra data are, and why they are needed? I guess they could be thunks or something, but then I would expect them to be in the output file. For completeness the map file and the axf are attached.
I have a workaround for now - just image back off the board and use that for sdphost, but it doesn't explain why elftosb isn't working correctly for me.