LPC55S6x ROM bootloader documentation and SPI flash recovery mode

[scottm]

I'm working on porting a project to the LPC55S69 and the ROM bootloader documentation in the user's manual had my head spinning. Is there other documentation about the bootloader functions I should start with? There's a whole lot to cover and most of it is irrelevant to my needs, and the user's manual doesn't spend much time on introductions and definitions.

At the moment I'm most concerned with SPI flash recovery as mentioned in 6.4.3. Here's where I'm coming from:

The exiting project runs on a Kinetis MK22FN1M0. It uses my own custom bootloader that resides at the top of flash. The device has USB MSD support and to update the firmware the user copies an encrypted firmware file to the device. The application code checks the header, finds the appropriate image within the file (it could be packaged with other firmware images), authenticates it, and then sets a command block in reserved flash with the decryption keys and other information the bootloader needs to find and load the image and invokes the bootloader. If the update is interrupted, the bootloader will see that the loaded image is invalid and will start the process over again using the information from the command block.

I'm trying to determine how much of this I can replicate with the ROM bootloader. 6.4.3 says that a SB2.1 image file can be stored in external SPI flash. It says to see 8.6.11.2 for details on SPI flash use. From what I can tell, that seems to cover pass-through programming of the SPI flash via the bootloader, not programming from SPI flash. It refers to packet-based commands, not ROM API calls.

7.3.6.5 describes updating from external SPI flash to be the recommended method. 7.3.6.6 just says "See LPC55S6x/LPC55S2x/LPC552x User Manual for complete list of ROM API functions" - that's the document I'm reading. It describes skboot_authenticate() but it doesn't say anything about how to use it with SPI - it just takes a start address and an "isSignVerified" option.

Does it use the Flash Configuration Option Block as described in 8.6.11.2? Is there some way to set that in-application? It looks like it's only set via packetized commands. How do I authenticate and load a file from SPI flash? Even for writing to flash like 8.6.11.2 describes, I don't see how to configure it to use a specific FLEXCOMM module and PCS.

Thanks,

Scott

[Alice_Yang]

Hello @scottm 

1)About  SPI Flash Recovery, you can also have a look at :

https://community.nxp.com/t5/LPC-Microcontrollers/LPC55S69-SPI-flash-recovery/m-p/1164130   

https://community.nxp.com/t5/LPC-Microcontrollers/LPC55S69-SPI-Flash-Recovery-Boot-Configuration/m-p...  

2) About the ROM bootloader, if you think it some messy, you can also porting the secondary bootloader from K22 to LPC55s59.

BR

Alice

[scottm]

Hi Alice,

Still hoping for an answer on this.

[scottm]

Hi Alice,

It looks like Paul didn't really get his question answered in that thread. Or if it was answered, I'm not understanding the answer. Jun Zhang says:

The LPC55S69 flash recovery feature is for 1bit SPI flash, it doesn't have mirror address in MCU memory map.
SPIFI flash address is mirrored to MCU memory map but not for spi flash.
For SPI flash, its address is included in SPI command. normally it starts from 0. 

What is meant here by "its address is included in SPI command"? Does this mean that the user provides the SPI block read command parameters to the bootloader? This says "normally it starts from 0" - what is "it" here? The starting address the bootloader is requesting from the SPI flash? How does one change this?

And am I understanding correctly that there's no way to trigger the SPI recovery mode manually short of corrupting the firmware image and triggering a reboot?

The ROM bootloader clearly has a lot of code devoted to authenticating, decrypting, and loading images. I'm trying to avoid duplicating that functionality. It's not really clear from the documentation how it's all expected to be used, though.

How does one configure the bootloader to tell it how to access the SPI flash? I don't see anything that specifies what FLEXCOMM port it uses, or which peripheral CS line. Is that fixed to one port+PCS? If not, how do you configure it?

Thanks,

Scott

[Alice_Yang]

Hello @scottm 

1) SPI Flash Recovery mode uses below pins:

2)There is a description about NOR flash, and there is a example about programming 1-bit SPI NOR FLASH via boot ROM of UM11126:

8.6.11.2 1-bit SPI NOR FLASH support (for version 1B only)

3) About Secure Boot, refer to below AN:

https://www.nxp.com.cn/docs/en/application-note/AN12283.pdf 

BR

Alice

[scottm]

Hi again Alice,

After pondering this some more I think I have an idea what our fundamental misunderstanding might be. I've been assuming all along that the purpose of the bootloader was to simplify the process of implementing secure updates for the average developer in a system where the LPC55S69 is the main MCU.

I think instead maybe the purpose is to position the LPC55S69 as the root of trust in a larger system where it serves only or at least primarily in a security role - like Microsoft designing a new XBox and using it for key management. In-the-field / OTA updates would be provided to the application processor, with its own storage and the ability to easily validate update packages, and would be loaded via the ROM bootloader and one of its communication interfaces. The SPI NOR flash would only be used to brick-proof the LPC part in case of a failed update. The SPI flash is not expected to be used for any other purpose or to be accessed by the regular firmware on the LPC device.

Does that sound correct? If so, I think I just need to forget about the bootloader entirely. It's a shame, because it seems to be 90% of the way to doing what I'd need it to to replace my own secure bootloader. I know all of the validation code and the ability to access external SPI NOR flash is there. All it would need is a few extra configuration options to set the FlexComm port and the source address.

Scott

[Alice_Yang]

Hello @scottm 

1) "The SPI NOR flash would only be used to brick-proof the LPC part in case of a failed update. The SPI flash is not expected to be used for any other purpose or to be accessed by the regular firmware on the LPC device."

->> Yes.

2) "Does that sound correct? If so, I think I just need to forget about the bootloader entirely. It's a shame, because it seems to be 90% of the way to doing what I'd need it to to replace my own secure bootloader. I know all of the validation code and the ability to access external SPI NOR flash is there. All it would need is a few extra configuration options to set the FlexComm port and the source address."

->> If you want to use external flash, yes, you need use your own bootloader.

BR

Alice

[scottm]

Can you confirm my guess that the ROM bootloader is only intended to be used for in-application updates when it's part of a larger system, with an outside processor to perform the update?

[Alice_Yang]

Hello @scottm 

Sorry I'm not very understand your this question.

The ROM bootloader is mainly used to update application in internal flash. 

BR

Alice

[scottm]

What I'm saying is that there's no way to load an SB2.1 image from within the application using the ROM bootloader, right? You can use ROM-resident routines to program flash, but you can't use the decryption and certificate validation functions unless the LPC55S69 is connected to an external host.

Scott

[Alice_Yang]

Hello @scottm 

Yes, you are right, need  external host to program SB2.1 image, for example  MCUXpresso Secure Provisioning Tool, download from:

https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-s...  

Or using blhost, refer to  https://www.nxp.com.cn/docs/en/application-note/AN12283.pdf   

BR

Alice

[scottm]

Well, that's disappointing. All of that ROM code for security and no way to use it for standalone OTA updates - I still have to replicate all of the functionality in my own bootloader. It's almost usable - if not for the limitation on the SPI port I could potentially force the recovery mechanism into action to do the job.

Maybe a feature request could be passed along for future versions to allow selection of an SPI port and starting address, and provide a couple of API hooks to validate and install images?

Thanks,

Scott

[Alice_Yang]

Hello @scottm 

Thanks for your suggestion, I will take ticket forward it to BOOT ROM team.

BR

Alice

[scottm]

Hi Alice,

Just to make sure we're on the same page, can you give an example of what is meant by "1-bit SPI NOR Flash"? I'm assuming it means something like a Winbond W25Q128 - a flash chip with a standard 1-bit wide SPI interface. "1-bit SPI NOR Flash" is not a term I normally hear applied to it, and if you google that exact phrase the whole first page of results are just LPC documentation.

It just expects a standard NOR flash organized x8 bits internally, right? I want to make sure we're not starting with false assumptions since there seem to be a whole lot of assumptions in the documentation.

Can you explain what the intended use of the SPI flash recovery mode is? In 6.4.3 it says it can be used to recover a factory image when the internal image is corrupted and says it "...can be implemented during OTA...". Is it intended that this should be a fallback in case some other update method fails? What is imagined to be the OTA process here? Is the OTA bootloader assumed to be provided by the customer?

NXP provides tools to create and sign secure boot images, and the blhost tool for (presumably) factory programming, which I think includes pass-through programming of a SPI NOR flash. (It's not clear to me whether that's for factory programming automation in general, or if it's strictly for the SPI flash recovery mode.) The ROM bootloader provides extensive facilities for validating signed images, but I can't see how to access any of those capabilities in-application for an OTA use case.

So in what situation would the image corruption happen and need recovery by a backup image? Is it intended that the backup image SPI NOR flash be solely devoted to the recovery image? Like the customer designs in an 8-pin flash chip ONLY on the FC3 pins and uses that only for storing the one image?

Table 249 mentions a field for "Start address of external memory" but as far as I can tell gives no further explanation. It's only a 4-bit field. Is this the start address in external memory? External SPI memory isn't mapped into the local memory space so I don't know what other address it could be referring to. Which 4 bits of the address is this? In what documentation is this field explained?

My board (at least the one I'm working on at the moment) can't use FC3 and doesn't have space for a second SPI NOR flash. It has one 256 Mbit flash on the HSSPI port, which I think is the one that would make the most sense for anyone's first choice to connect a SPI flash memory since it's the SPI peripheral most likely to need high bandwidth.

So if I can't use the ROM bootloader's SPI recovery mode, is there some way to feed it an SB2.1 image in-application? Or any way to access the validation functions to avoid having to replicate all of that functionality in my own in-application bootloader?

Thanks,

Scott