Creating pre-baked FAT16 flash image with LevelX

[AaronGee1]

In our current workflow using FileX, we are able to successfully generate pre-baked FAT16 flash images on our Linux development host using standard system tools (such as dd). We then write these pre-populated filesystem images directly to our storage media during production flashing.

We are now incorporating LevelX into our architecture and want to achieve a similar workflow where we can pre-populate a FAT16 filesystem within a LevelX-managed framework on our host development machine before production flashing.

Questions for the Development Team:

1. Is there an official, standalone host-side utility (Linux or Windows command-line) provided by the ThreadX/LevelX ecosystem that can format and inject files into a LevelX NOR image structure?

2. If no native tool exists, is the recommended best practice to compile a host-side (PC) simulation using lx_nor_simulator.c and use FileX APIs to write the initial asset files to a backing file?

3. Are there any hidden pitfalls we should be aware of regarding sector sizes, page alignment, or block overhead when relying on a host-simulated LevelX backing file for direct production flashing?

Thank you,
Aaron

[fdesbiens]

Hi @AaronGee1.

Thank you for your questions. I need some time to think about them. I will get back to you soon.

[fdesbiens]

Hi @AaronGee1,

Here are answers to your questions.

1. There is no official standalone LevelX host-side image creation utility in the Eclipse ThreadX/LevelX repo today. The project provides LevelX, FileX integration drivers, simulators, and samples, but not a supported command-line tool equivalent to mkfs/mcopy for creating a production-ready LevelX NOR image.

2. A host-side program using FileX + LevelX is the right general approach, but I would not rely blindly on the stock lx_nor_flash_simulator.c memory layout for production images. It is useful as a reference and for tests, but a production image generator should use a NOR driver/backing-store implementation that matches your target driver's geometry and address model.

A typical flow would be:

  - create or truncate a backing file to the exact flash size,
  - initialise it to the erased NOR value, usually `0xFF`,
  - expose that file through a host NOR driver with the same block size, sector layout, and LevelX parameters as the target,
  - call `lx_nor_flash_format()` / `lx_nor_flash_open()` as appropriate,
  - call `fx_media_format()` with the same FileX parameters expected on target,
  - use normal FileX APIs to create directories and write files,
  - flush/close FileX and LevelX,
  - flash the resulting backing file byte-for-byte to the device.

3. The main pitfalls are geometry and binary-layout mismatches. The host image is only safe for production flashing if the host driver produces the same physical LevelX layout that the target driver expects.

Things to check carefully:

• The LevelX NOR logical sector size must match FileX sector size. The supplied FileX NOR simulator driver checks for LX_NOR_SECTOR_SIZE * sizeof(ULONG), normally 512 bytes.
• The target and host must agree on ULONG size and endianness. This matters because LevelX metadata is stored as ULONG values. A 64-bit Linux host build using an 8-byte unsigned long would not be compatible with a typical 32-bit embedded target. Build the host tool with the same data model as the target, or otherwise make the image driver explicitly target-compatible.
• The NOR block geometry must match exactly: erase block size, words per block, physical sectors per block, metadata overhead, and total usable logical sectors.
• The backing file must start in the erased state (0xFF), not zero-filled.
• Do not treat a normal FAT16 image as directly flashable under LevelX. LevelX adds its own physical metadata, mapping tables, erase counts, obsolete-sector tracking, and wear-levelling layout underneath FileX.
• Make sure FileX free-sector notifications are enabled in the media driver, as the supplied FileX NOR simulator driver does with fx_media_driver_free_sector_update = FX_TRUE.
• Use the same compile-time LevelX options for the image generator and the target when they affect physical layout or behaviour.
• After populating files, close/flush FileX and LevelX cleanly before extracting the backing image.

So the short answer is: there is no official image-builder utility that I know of, but a purpose-built host image generator using FileX + LevelX is a reasonable approach. The important part is that the host backing driver must model the production NOR driver, not just the demo simulator, unless the demo simulator’s geometry and data model exactly match your target.

This would actually be a useful contribution to the project. If your team ends up building a generic host-side LevelX/FileX image creation utility, I would encourage you to consider contributing it upstream. A tool that can take NOR geometry, FileX formatting parameters, an input directory, and an output image path would likely help other users with the same production-flashing workflow. I don't have the time to build this myself right now, but I could maintain it if we receive the contribution.