i.MX RT Crossover MCUs中的主题 Re: elftosb issue

elftosb issue

dmarples — Mon, 02 Nov 2020 14:32:11 GMT

Hi,

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;

options {
 flags = 0x00;
 startAddress = 0x20208000;
 ivtOffset = 0x400;
 initialLoadSize = 0x2000;
}

sources {
 elfFile = extern(0);
}

section (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.

Regards

DAVE

Re: elftosb issue

dmarples — Thu, 06 Feb 2020 17:21:23 GMT

The plot thickens...if I convert the axf (==elf) into an srec file and use that as the source for elftosb;

arm-none-eabi-objcopy -O srec evkmimxrt1020_flashloader.axf evk.srec‍

...then everything works properly.

I don't know what elftosb is missing in an elf file, but it's something. My workaround now got easier, but this should probably be investigated.

Regards

DAVE

Re: elftosb issue

dmarples — Thu, 06 Feb 2020 17:38:42 GMT

Sorry for thinking out loud, but I think I've found the issue. The data segment (initialised data) follows the end of text, so that's not being recognised and loaded. It's possible there's a magic incantation to elftosb to include that (please let me know if so) but it might also be a bug...and it's certainly a trap for the unwary, like me.

Regards

DAVE

Re: elftosb issue

EdSutter — Tue, 25 Feb 2020 21:53:44 GMT

Dave, thanks for posting this.

I'm just getting started on the 1020EVK (eventually headed for 1064) and I started with this application but lost faith quickly simply because it didn't build successfully. The error (as you must already know) is a section overflow.

I attempted two different fixes:

Increase m_text size by 0x8000.
Reduce space needed by setting BL_CONFIG_HS_USB_HID to 0 in bootloader_config.h

Neither attempt worked for me. Would you mind sharing what you did to get over this hump?

Re: elftosb issue

dmarples — Wed, 26 Feb 2020 15:49:33 GMT

Hi Ed,

I think you've got to do a Release Build rather than a Debug one....I

seem to remember that was the trick. If you need the app I can probably

send you the binary if you can't get it built.

Regards

DAVE

Re: elftosb issue

EdSutter — Wed, 26 Feb 2020 21:43:06 GMT

Dave,

Well, changing to "Release" did eliminate the section overflow (thanks for the pointer), so it does build without any intervention from me. That's as far as the good news goes.

When I run through the IDE, it appears to be alive . According to the "Flashloader Use Case" document that comes with the flashloader package, I think I should be able to run "blhost -u -- get-property 1" and get a response (I don't). Also, apparently when the flash loader comes up it re-enumerates the USB port to a different PID/VID, but all that I see in "Device Manager" is the device go away.

Anyway, I'm clearly a pain-in-the-***, but if you have any other thoughts, I'd sure appreciate them...

I've even tried ignoring any build and just using the images that come with the flashloader package (see my latest question here). That doesn't even work.

Re: elftosb issue

dmarples — Wed, 26 Feb 2020 22:40:40 GMT

Hi Ed,

It seems to me that the intention is that this stuff can only easily be done with FAE support, which is a shame...anyway, here are the two scripts I use to get the whole thing off the ground;

The first script actually loads the monitor into memory and configures the chip (based on the first 4K of an application file that contains a memory configuration that's suitable);

RUNDIR=$(dirname $0)
$RUNDIR/sdphost -u 0x1FC9,0x0130 -- write-file 0x20208000 $RUNDIR/ivt_flashloader.bin
$RUNDIR/sdphost -u 0x1FC9,0x0130 -- jump-address 0x20208400
sleep 1
$RUNDIR/blhost -u 0x15a2,0x0073 -- get-property 1

# Write memory configuration
$RUNDIR/blhost -u 0x15a2,0x0073 -- write-memory 0x20204000 $RUNDIR/nuttx.bin,4096
$RUNDIR/blhost -u 0x15a2,0x0073 -- configure-memory 1 0x20204000
‍‍‍‍‍‍‍‍‍

The second one burns an application (after running the first one to get the monitor loaded);

RUNDIR=$(dirname $0)
$RUNDIR/blhost -u 0x15a2,0x0073 -- flash-image $1 erase 9
‍‍

...and the third erases it;

RUNDIR=$(dirname $0)
$RUNDIR/blhost -u 0x15a2,0x0073 -- flash-image $1 erase 9
‍‍

Having said all of that, if you're using an 1020_evk you might want to consider tinyUF2...I just committed the patches for that board for it this morning. It makes the application space on the CPU into a 'drive' that you can drag and drop onto, and once it's installed you don't need the OpenSDA stuff. Take a look at TinyUF2. It's rather painless to use.

Regards

DAVE

Re: elftosb issue

EdSutter — Thu, 27 Feb 2020 19:21:00 GMT

Dave,

Ok, that worked for both the provided flashloader.elf (that comes with the 1020 flashloader package) and the evkmimxrt1020_flashloader.axf (built from the SDK with MCUXpresso). That does require your -earlier-mentioned- conversion to S-record because apparently elftosb doesn't like the non-numerically ordered sections.

For either of those files, elftosb can use imx-ocram-unsigned.bd (also comes with the flashloader package) to create the .bin that can be loaded with sdbhost. My error was that I was not compensating for the 0x2000, which I assume is established by the initialLoadSize entry in the bd file. I see now that the IVT in the pre-built ivt_flashloader.bin did have a self entry of 0x20208000. The actual starting point for the executable image is at 0x2020a000, so it is naturally loaded there when the .bin file is written to 0x20208000 (0x2020a000-0x2000).

Regarding TinyUF2, thanks for the pointer. Once I feel secure about what I'm doing here, maybe I'll give that a shot.

Thanks much for your tips on this.