elftosb crash on Linux

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

elftosb crash on Linux

1,424 Views
lorenzomarcanto
Contributor II

OK, just unboxed the iMX1050-EVK and the bubble demo works. Now trying to get thru the bootloader.

Downloaded the Flashloader_i.MXRT1050_GA 1.1 package. If I got the documentation correctly the plan would be to:

1) Fix the BOOT_MODE switches to enter serial boot, USB attached on the OTG port of the board; reset -> success it enumerates

2) use sdphost to pull the flashloader inside.

sdphost -u .... write-file 0x20000000 ivt_flashloader.bin
sdphost -u jump-address 0x20000400
success, it reenumerates as a freescale composite device

3) check the flashloader responds
blhost -u -- get-property 1
success, it says version K2.1.0

4) Now the plan would be to create the SB file. The board is still with hyperflash so I adapted the only hyperflash example in the package:

options {
flags = 0x00;
startAddress = 0x60000000;
ivtOffset = 0x1000;
initialLoadSize = 0x2000;
//DCDFilePath = "dcd.bin";
# Note: This is required if the default entrypoint is not the Reset_Handler
# Please set the entryPointAddress to Reset_Handler address
// entryPointAddress = 0x60002411;
}

sources {
elfFile = extern(0);
}

constants {
kAbsAddr_Start= 0x60000000;
kAbsAddr_Ivt = 0x60001000;
kAbsAddr_App = 0x60002000;
}

section (0) {
#1. Prepare Flash option

# In this example, the 0xc0233007 represents:
# HyperFLASH 1V8, Query pads: 8 pads, Cmd pads: 8 pads, Frequency: 133MHz
load 0xc0233007 > 0x2000;
# Configure HyperFLASH using option a address 0x2000
enable flexspinor 0x2000;

#2 Erase flash as needed.(Here only 1MBytes are erased)
erase 0x60000000..0x60100000;

#3. Program config block
# 0xf000000f is the tag to notify Flashloader to program FlexSPI NOR config block to the start of device
load 0xf000000f > 0x3000;
# Notify Flashloader to response the option at address 0x3000
enable flexspinor 0x3000;
#5. Program image
load elfFile > kAbsAddr_Ivt;
}
I called this imx-flexspinor-normal-unsigned.bd. I couldn't find more documentation on the file contents (like the magic f00000f number? where it comes from?)

Now for example I tried with the supplied test file

./elftosb -f imx -V -c ./flexspinor-normal-unsigned.bd -o out.bin led_demo_evk_ram_0xa000.elf

THIS DOESN'T WORK. It says

elftosb: /home/nxa07476/d/Repo/mcu-boot/apps/elftosb/common/SourceFile.cpp:93: virtual void elftosb::SourceFile::open(): Assertion `!isOpen()' failed.

This is extremely not-fun… what is happening here???

The next step would be to feed the out.bin file (the SB file, right) to the flashloader. Since mfg-tool is windows-only I was thinking about something like
./blhost -u -- receive-sb-file out.bin
Would that be correct?

However I'm stuck on the elftosb step.
Please advise
Thanks in advance

Labels (1)
0 Kudos
Reply
5 Replies

1,416 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you to refer to the post:https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Generating-a-Bootable-Image-for-the-RT1050/ta-p/...

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

1,404 Views
lorenzomarcanto
Contributor II

That's quite different than the application notes says… I got slightly further but still no luck.

First of all the "Generating a Bootable Image for the RT1050" article suggests to disable the XIP_BOOT_ENABLE macros and supply a separate dcd.bin file. Fine for me. However these macro not only inhibit generation of the .boot_hdr section in the elf file but also change some detail in the board initialization code (i.e. the SDRAM initialization and maybe some other thing). Could this be an issue? No idea if 'double initializing' memories could give problems

So, this round had this results:

1) succesfully compiled without the macros. Now the elf file has an empty .boot_hdr section

2) made the s-rec file (which is nothing more than an objcopy). The range 0x60000000-0x60002000 is now correctly empty.

3) elftosb -f imx as in the page; I uncommented the DCDFilePath directive and supplied the DCD image in a separate file (1088 bytes of stuff). This gave a bin file with an IVT at 0x1000 and following the DCD and the program code; so far so good, it seems

I noticed that elftosb crashes when it finds something at the addresses before 0x2000 since it want to fill them itself (an error message could be better than a segfault). The area before 0x1000 is zero filled. This will contain the FCFB block created by the flashloader, right?

4) ./elftosb -f kinetis -V -c ../../../bd_file/imx10xx/program_flexspinor_image_hyperflash.bd -o boot_image.sb ivt_blinky_nopadding.bin

STILL SEGFAULTS. This should make the file to be fed to the flashloader right?

Any ideas on how to troubleshoot/fix it?

 

0 Kudos
Reply

1,395 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thanks for your reply.
1) Could this be an issue?
-- No.
2) This will contain the FCFB block created by the flashloader, right?
-- Yes.
I was wondering if you can demonstrate the complete steps of generating the boot image, as it can help me to figure the issue out.
In further, I'd like to suggest you do the same testing on the Windows PC to check whether to encounter the same issue.
NXP provides a GUI tool to generate the boot image, maybe you can give a try and its download like is below.
https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-s...
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

1,389 Views
lorenzomarcanto
Contributor II

Made more tries. The issue is in the *Linux* version of elftosb. In the kinetix mode of operation it segfaults.
Running on Windows instead it completes and it generates a boot_image.sb file.

Shouldn't be the same program? maybe it's because the Linux one is 64 bit so the int is bigger…no idea but I've got similar issues to porting programs in the past.

I'll try the provisioning tool but I'd prefer something to be run from makefiles. If possible please fix the tool.

Also the MCU Manufacturing Guide has a big misleading error… figure 19 captioned "Example command to generate SB file for flexspi nor programming" has instead the command for generating the IVT bin file!

Thanks for the assistance

0 Kudos
Reply

1,382 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thanks for your reply.
1) Shouldn't be the same program? maybe it's because the Linux one is 64 bit so the int is bigger…no idea but I've got similar issues to porting programs in the past.
-- Yes, and I'll try to do the same testing on Ubuntu later to check whether can replicate the phenomenon or not.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply