Serial Download Protocol on i.MX25 secure board

[bryangreen]

Hi,

I'm using the iMX_Serial_Download_Protocol.py tool to download and execute a bootloader over SDP.

I've been testing with Engineering Mode boards, and know that my process works, but on a secure Production board, the download succeeds, but there is no evidence of a successful boot.

I'd like to diagnose the reason for the failure to boot, but the get_status SDP command does not appear to be providing valid results.

After downloading the file, the expected '88 88 88 88' response is returned.

After that, the get_status command does not return a valid HAB Status Code as expected.  Instead, each get_status request returns 2 or 3 bytes at a time instead of 4, with values such as:

53 7A 0D

D3 7A CF

D3 6A CF

...

Eventually, the device seems to recover on its own, and get_status returns "F0 F0 F0 F0" again.

What explanation might there be for SDP behaving this way?

Thanks,

Bryan

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[Yuri]

  Please double check UART settings, needed for the SDP ; please refer to Table 7-17 (UART Configuration)  
of the i.MX25 Reference Manual. Also,  according to section 7.3 (Using Serial Download Protocol to Test a
Secure Boot Image) of app note  AN4547 (Secure Boot on i.MX25, i.MX35, and i.MX51 using HABv3) :

"... the modifications of the clock tree are not recommended at this stage, because this could change the

frequency of the clock used by the UART, breaking the serial communication link". Perhaps UART
frequency was changed during initializations via the DCD table. After some time, because of watchdog,
boot ROM restarts and continue working.

Have a great day,
Yuri

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

[bryangreen]

Thanks Yuri for your response.

My UART configuration seems to be correct.  SDP works fine and produces the 88 88 88 88 response as expected after sending down a file.

We also do not modify the clock during SDP.  Once SDP is complete, our binary has a DCD section which configures the clock, i.e.:

DCDGEN(25, 4, 0x53F80008, 0x20034000)

But at this point, SDP has completed.  I have tried removing this DCD entry, but the device does not seem to be able to boot without it.

However, the same process works fine on an unsecured Engineering mode board, but does not work on a Production board.  The only difference is the fuse configuration.  Since SDP download works in both cases, what difference could contribute to the lack of successful boot in the case of the Production board?  We are confident that the image is properly signed.  Interestingly, when I attempt to use a small unsigned bootloader, I get a 47 47 47 47 response, as expected.  But if I use a larger unsigned bootloader, I get garbage.  In fact, I have consistently found that file size has a significant impact on behavior.  The same goes for a bootloader that loads into internal ram.  If the bootloader is loaded starting at 0x78001c00 and is up to 120k in size, it boots (on a non-secure board).  But if loaded at 0x78000000, or if it is 121k or larger, it does not boot.  Can you indicate any documentation that might explain this subtle behavour?

Cheers,

Bryan

[bryangreen]

I've discovered an interesting detail.  As I mentioned, we have an entry in the DCD header of our binary to set the clock to 399MHZ:

DCDGEN(25, 4, 0x53F80008, 0x20034000)

I found that when I remove that entry from an unsigned bootloader, SDP returns a status after loading of 35: "Signature verification failed".  But with that DCD entry, we get the usual garbage from SDP.  So that makes things very clear: when SDP download completes, the MX25 executes the DCD table before performing the HAB check.  When the HAB check fails, we cannot get the HAB status code back because the clock was modified during DCD processing.  My previous assumption had been that the DCD processing would be performed _after_ the HAB check.

I now need to produce a signed bootloader for SDP that does not set the clock in the DCD, but which is still able to boot.  Unfortunately, this unsigned version with the removed DCD entry does not boot successfully on an Engineering board.  Do you have a thought as to why this is, or how we could work around it?

Cheers,

Bryan

[Yuri]

  Please look at the restrictions in section 5.4 (Core PLL Clock

Generation) of the i.MX25 Reference Manual. Also, pay attention on
the recent erratum ERR007917.

http://cache.freescale.com/files/32bit/doc/errata/IMX25CE.pdf

~Yuri.