Booting a Windows Embedded Compact image is a three step sequence.. A raw binary of binary file or a record based binary file is used for each phase of the OS boot. Includes use of CELoader to image a target.
Context: This discussion is with respect to the Texas Instruments AM335X MPU as used with BeagleBone Black (BBB) and the Variscite VAR-SOM-AM33. This material was developed mainly with the latter but the BBB was also used in parts.
When booting an OS, a Bootloader is used to initialize the system sufficiently to load and start the OS. The OS generally is loaded from external storage such as a disk drive or flash memory. The MPU will initially boot run from internal ROM and use internal memory. With Windows Embedded Compact the main vehicle for booting the OS is eboot but this won’t typically won’t fit into the MPU’s ROM. The Bootloading is therefore done in two phases. One to enable loading of eboot from flash or external storage such as an SD card, and then eboot once it is loaded. The Windows Embedded Compact OS boot sequence therefore is:
When a Windows Embedded Compact/CE OS is installed, three images are written to the device:
xldr is the initial software loaded from boot and resides in the on- board flash of the AM335X CPU. It is like the EPROM/ROM that we used to use with microcontroller systems. It gets loaded into the MPU internal RAM to run and loads the external RAM, flash GPIO and clocks. Its job is to simply load the eboot into RAM and start it. The eboot may come from external flash or storage media such as an SD card, which is optioned with the AM335X SOM boot mode button.
eboot is stored in flash external to the MPU (or SD card) and its job is to load sufficient drivers so as to be able to get the OS image into external RAM and start it, including enabling the external RAM There is often a boot menu supplied at the eboot phase where the user can optionally select the source of the OS image. This can be in the external flash, on a storage card such SD or downloaded.
nk is the operating system is encapsulated as a single file. This contains the OS configuration, registry settings ad well as all files (whether modules or resources) in the OS. At system start, this is copied into RAM from the source and started. If a hive registry is used (where changes to the registry are saved and survive a reboot) then this is loaded into RAM from its storage location in flash.
When the OS is built, all three have different versions of their built code:
The first two are what are used when loading an OS or flashing a target device. A bin file is a series of binary records that contain a sequence of binary (compiled) bytes as well as a memory location for that sequence of bytes. The data may be compressed.. There is also overall header information (a TOC: Table of contents) for the file, usually positioned towards the end of the file. Viewbin (run in the VS/PB Build command line Release directory context) will display key information about the bin file:
Image Start = 0xC0002000, length = 0x012FFE5C
Start address = 0xC000B2C0
Checking record #18 for potential TOC (ROMOFFSET = 0x3F011B54)
Checking record #132 for potential TOC (ROMOFFSET = 0x40000000)
Found pTOC = 0x81300440
ROMOFFSET = 0x40000000
RelDir >viewbin ebootnd.bin
Image Start = 0x8FE00000, length = 0x00026278
Start address = 0x8FE01000
Checking record #5 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC = 0x8fe24bf8
ROMOFFSET = 0x00000000
RelDir >viewbin xldrnand.bin
Image Start = 0x402F1000, length = 0x000083F0
Start address = 0x402F2000
Checking record #4 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC = 0x402f8c5c
ROMOFFSET = 0x00000000
These mean that nk is flashed at 0xC0002000, eboot is flashed at 0x8FE00000 and xldr is stored in internal ROM at 0x402F1000. If we open nk.bin in a hex editor we find its ROM address as 4 bytes close to the start of the file, as the 8th to 10th bytes of the file (in little endian format),. Its start address is the second last 4 bytes of nk.bin. Similarly the ROM address is located at the 8th to 10th bytes in ebootnd.bin and xldrnand.bin. The eboot start address is the also the 2nd last sequence of 4 bytes, whereas the start address of xlrdnand.bin is located one byte closer to the end of its file..
When OS Image files are downloaded, a BIN file is what is used. Ebootsd.bin is the eboot image and nk.bin is the OS image. Note that when the image is built, there is an option to specify whether that bin image is to be flashed or copied directly to RAM. When launching the OS via download or SD card, if the image is built as a flash image it is written to flash first before being copied to RAM and launched.
An nb0 (nb zero) image is a complete raw uncompressed binary image of what is to be placed in ROM. To that end, it will often be larger than a bin file as it has to “fill in all of the gaps”. The image file xldr for the TI AM335X as used by SD boot, is called MLO, which is xldr.nb0 with some header information prepended. The format of a MLO file is:
<length><load address><nb0 image>
In building the OS there are two important environment variables with the Variscite BSP.:
If the former is set, then the images are built for flashing (but can be downloaded). If the latter is set, then then the image is built for direct copy to RAM and can be downloaded from Platform Builder or copied from SD card.
In building the OS, various versions of eboot are built for different boot mechanisms. There is the NAND flash eboot (ebootnd), the SD eboot (ebootsd) and the UART boot (ebootUART). They are built both as BIN and NB0 files, the NB0 version used for direct flashing (or SD setup). xldr isn’t built by default but can be built by right clicking on it under the LIB SRCs. When built the two main outcomes of its building is xldrnand.nbo and a file called NBO. The first is used for flashing xldr and the second for configuring a bootable SD card.
The main outcome of the OS build is the nk.bin file. This can be used for download and remote flashing. For direct flashing (vua SD or application, see later) then an NB0 version of nk is required. This isn’t built by default. It can be built manually in a twostep process, which can be semi-automated, the two step processs as a Post Build action, or by building as part of the OS build through configuration of BSP file, config.bib. Generation of nk.nb0 is the subject of a separate document.
The OS can be downloaded at runtime from Platform Builder (as part of the Visual Studio IDE), run from external storage such as an SD card, or run from flash. A system under development would typically use one of the first two methods. A shipped product would use flash. To download an OS image, the system is booted into eboot where the download option is selected. If ebooting from flash, then xldr comes from onboard the MPU, whereas if eboot is loaded from SD then xldr exists on the SD as the MLO file. The SD card is specially prepared such that MLO is the first file written to it after formatting as it lays down some boot tracks. If the OS to run from flash then the files need to be flashed to the the target MPU.
The OS image files can be downloaded at runtime, or placed in flash or SD storage to be referenced at runtime. Note that the primary launch vehicle, xldr, can’t be downloaded at runtime. It needs to reside permanently and uncorrupted onboard the MPU. For a system under development, eboot may reside in SD or flash storage. The OS would be downloaded from Platform Builder in the Visual Studio IDE or from SD card (where it can be simply changed as a file copy). Once the OS is completed, its eboot and OS would be flashed. The OS images can be flashed in a number of ways:
This works directly with the MPU via some dedicated MOU ports. It is able to intercede the MPU functionality from the first instruction after reset and so can be used to debug the boot process. It is a much lower level of debugging than that provided by Platform Builder which depends upon many layer of software to function. Besides debugging, as it has direct access to the MPU modules, it can also be used to directly flash the xldr image. JTAG is though quite complex to set up and get working. Whilst there are cheaper versions of JTAG, one needs support by a vendor to use this in a professional manner.
At the eboot menu, when booted from SD Card, there is an option to specify the file to be loaded and as to where flashing is enabled. The file needs to have been previously copied to the SD card. If the file is built for flashing, then it gets flashed (this may require enabling of Flash writes in the eboot menu first). The file can be a MLO, eboot or nk file. Note that this does depend upon xldr, onboard, being intact and the SD card eboot being functional. The following files are used in this method:
File to be flashed
There is tool for the AM335X called OSUpdate, provided with the Variscite BSP source code. This takes an NB0 file and writes it to flash. It is used for updating eboot and the OS (nk). It can also update the logo image used at boot time. The code as supplied doesn’t support flashing xldr. In all cases OSUpdate uses the raw NB0 version of the images. You would typically place the image/s to be flashed in the OS’s flash file location and flash from there.
As previously discussed, f the built image in Platform Builder is configured for flashing then when it is downloaded, the OS will be flashed in the external NAND flash before being copied to RAM and launch. An nk.bin file is downloaded in this case. This can facilitate the flashing of nk only.
There is a tool available on Codeplex, CELoader, authored by a colleague Thierry Joubert, that downloads the OS bin file (nk.bin) image using TFTP in the same manner that Platform Builder does from the Visual Studio IDE. If the image is built for flashing, then it will be flashed before loading into RAM. Also, and this is the big positive, if the flashable BIN file targeted for download using CELoader (a command line option) is ebootnd or xldrnand then that gets updated on the target! All three downloads are BIN files. A note of caution though from Thierry is that if xldr gets corrupted then JTAG will be needed to restore it, although the SD process flashing process should be able to restore xldr.
 Nk.bin is by default downloaded. But documentation says that any bin file (such as eboot.bin) loaded into Platform Builder can be similarly downloaded to a target.
 In the source code for this app, as supplied from the OEM I found a significant bug which precluded it from working. This has been resolved and the built app works reliably.
One note, while still being used, native NAND usage as described here is on its way out and is quickly being replaced by managed NAND. Native NAND has had a hard time keeping up with all the changes in density technology and matching error correction algorithms etc. eMMC parts are built to an industry interface standard which removes much of the manufacturing variability not to mention the timing and wear leveling issues. eMMC parts, like used on the BeagleBone Black, are “managed NAND” and interface much like a standard SD card. Using these parts you can eliminate many of the headaches associated with native NANDs and its possible to build one universal image that can run from a SD card or from eMMC with no build or loading modification. As a nice side benefit all the error correction, wear leveling and flash management is now resident on the part itself relieving the OS from handling all these tasks.