Here's the imxrt1062-fcb-gen from the teensy4-rs project. It's more advanced than the original crate, and it's gone through a rename. I'm looking for some early feedback before we start considering it.

How's the name? I went with boot-gen because it generates data structures required for booting. I changed it from fcb-gen, which had meant "firmware configuration block" (FCB). I was abusing that term. The FCB is a specific data structure in the serial NAND boot process. I confused the abbreviation with FlexSPI configuration block (FCB), which is general to all serial FLASH boot data structures. But, if we stick with fcb-gen, we can't extend the crate to include SEMC (parallel FLASH) booting! boot-gen is all I could think of. (I also want to play with IVT and DCD hooks in this crate, and the generic name leaves us open to that possibility.)

How's the feature-flag utilization? We require a feature flag, just as we require a feature flag in the RAL crate. The feature flags don't do much, since we only support the most common feature: an FCB for serial NOR FLASH over FlexSPI.

Will it actually work with the iMXRT1011 EVK board? I studied the 1010 reference manual, and compared it to the 1060 reference manual and implementation. I found a few discrepancies, and I accounted for them behind feature flags. From my understanding, this crate should be ready to generate a 1011's FCB for serial NOR flash boot.

Finally, and maybe most importantly, is this all too much? Seems like a lot of overhead to generate a byte array. I justify it by saying the approach is self-documenting, and it could help defend against silly programming errors. It's the opposite of the Teensy approach, which hard-codes the array. Let me know if this all seems too complex for what it's actually doing.

In the organization's HAL project, we've decided to name HAL crates after i.MX RT product lines. The same applies to feature flags. This simplifies our naming convention, and it lets us implement features that align with a chip's datasheet and reference manual.

The imxrt-boot-gen crate uses our previous feature naming convention. We should update it to follow our org's new convention.

• 1011 support should be generalized as 1010
• 1051 and 1052 support should be covered by '1050' support
• 1061 and 1062 support should be covered by '1060' support

The issue tracks supported and unsupported i.MX RT chip families. If you'd like to add support for another family, leave those thoughts below. Checked means that there's support in the crate; unchecked means it's known to be missing.

Support includes

• serial NOR flash over FlexSPI.

Chip support

• 500
• 600
• 1010
• 1015
• 1020¹
• 1040
• 1050
• 1060
• 1064¹
• 1160
• 1170

¹ Implemented by evaluating the reference manuals; or no known usage.

Tips

• Read the "System Boot" section of your chip's reference manual, specifically the "Boot Devices" subsection
• Make sure that the data structures for your boot device matches the existing memory layouts
  • If the layout varies, control it with a chip-specific feature flag
• Make sure that field enums match in both name and value
  • If the names or values differ, control it with a chip-specific feature flag
• Find a known, good configuration block for your system, and drop it into a test (objdump an NXP binary, copy bytes from a reference library, etc). Then, define the data structure using the crate's API. Compare byte-by-byte, and make sure the memory matches.
  • If the FCB is for a publicly-available development board, we would be happy to help you maintain it in this repository.

I'm trying to get Rust booting on iMXRT106x chips and I'm finding it difficult to get it to boot properly.

My current setup includes imxrt-rt, imxrt-ral, and imxrt-hal.

I have some code running on the iMXRT1062, but I dont think the QSPI flash configuration is setup up. Usually I expect to see the QSPI flash configs at 0x60000000, and the IVT at 0x60001000. I do have the IVT visible, but the configs are not.

I've been trying to get these for a few days, and I would really appreciate any help. I was wondering if someone could share a project with minimal stuff thats needed to properly boot and setup the flash.

[dependencies.imxrt-boot-gen]
version = "0.2.0"
features = ["imxrt1060"]

Hi everybody!

I'm currently looking into the i.MX RT1064, trying to boot a MIMXRT1064-EVK using the imxrt-rs ecosystem. It works - at least to the extend that I am able to reproduce the basic example from the book on said evk (the adapted example is available here). Now that it works, I'm trying to understand how it works/what I actually did (I should have done it the other way round 😅 ).

Maybe you can shed some light on below questions on the generation of FlexSPI config blocks, please? I should start with a "disclaimer", though: I'm kind of new to both Rust and the embedded software development, so if you feel like my questions are out of place here, then that's fine, too.

Quick wrap-up of what I did: to the best of my knowledge, there is no "plug-and-play" fcb package targeting the 1064 like the ones shipped e.g. for the 1010, 1060 and 1170. To my understanding, the 1062 and the 1064 are quite similar, which is why I tried porting the fcb contained in the teensy4-rs repository. Please find the result here. Basically, there is only a single code change: specify 4MB flash size instead of 2MB. Ah, and please correct me, if my understanding of this is wrong!

While reading through the code, I encountered several questions:

1. The opcodes, operands, pads and sequences have been taken from the mcus' reference manuals, right? I noticed a corresponding comment in the sources Where does this docstring show up in the docs? I searched the docs for it, but I could not find it.
2. How did you choose which sequences to include in the code? In the reference manuals there are multiple sequences described (IMXRT1060RM, rev. 3 and IMXRT1064RM, rev. 2; section 27.6.2 in both manuals), but not all of them are represented in code. Probably there just has to be one sequence per flexspi::Command, but then I guess the question simply becomes: how did you choose which commands to include in the code?
3. How did you decide in which order to place the sequences in a lookup table? I feel like I'm missing some part of documentation here.
4. Where did you take all the values required to setup the common configuration block from? Also, if you're aware of some material explaining the meaning of the individual values, please let me know 😃

Thank you so much for your help! 🙏