eCosPro-BootUp is eCosCentric's commercial name for the CYGPKG_BOOTUP package. The package is not included as standard in eCosPro Developer's Kit releases. Review the board specific documentation to determine if support has been included for your target platform.

The CYGPKG_BOOTUP package implements a lightweight bootROM that is intended to be easily portable and customizable to support the requirements of a given platform. It is purposely designed to provide an uncomplicated and straightforward boot mechanism, but does however provide a framework that the target platform code can use to easily extend its basic functionality. This can be used to incorporate more advanced features such as secure boot capabilities and application or system updates.

The BootUp code does NOT support any debug ROM monitor features. It is targeted at deployment of SoC-based designs that have limited memory resources and where hardware debugging (JTAG, SWD, BDM, etc.) will be used. It does not incorporate a debug agent such as GDB stubs, a CLI or any other debug monitor features. If you require these kinds of features then the RedBoot bootloader and debug firmware will be a more appropriate vehicle.

The BootUp package provides the generic, logical, framework for optional updating and execution of application images. Most of the heavy-lifting implementation for this is provided by architecture, variant or platform specific code that is incorporated when CYGPKG_BOOTUP is built. This is primarily because the location and format of the relevant application images is platform specific. This provides the greatest flexibility to developers with regards to how applications are stored and what extra information may be embedded to support updating and any other custom bootROM features.

Note

Normally it is envisaged that the BootUp ROM image will be loaded onto devices once, and then very rarely (if ever) updated. The BootUp world is designed to be very simple to minimise the chances of errors in the implementation that would stop the system from booting, or from allowing a different main application to be loaded into the device. The simpler implementations make no use of specific run-time configuration, and all implementations do not impose any footprint on the target after it has started the main application.

BootUp has been utilised by various example target platform implementations to support different mechanisms for safe application updates. These examples can be used as the basis of an update mechanism for your target platform. For example:

Architectures, variants or platforms that support the BootUp loader will implement CYGINT_BOOTUP_APPSTART. This feature allows BootUp to start the main application and is an essential requirement for the BootUp world to be used.

If BootUp starts when there is no valid on-chip application, and no valid alternative application is available, then if the platform provides the macro CYG_HAL_BOOTUP_BADAPP then that is used to call platform specific code. This provides a hook to allow target specific feedback indicating the lack of an application.

If CYGINT_BOOTUP_UPDATE is not defined then the BootUp loader will simply just execute the “main” application if it is present and valid. If the platform defines CYG_HAL_BOOTUP_COPYAPP then platform supplied code to copy an application to its executation location is called (e.g. for RAM loaded applications). In reality if neither CYGINT_BOOT_UPDATE and CYG_HAL_BOOTUP_COPYAPP are provided by the target then there is no real need for the BootUp to be used, and a normal simple ROM application configuration would suffice.

When CYGINT_BOOTUP_UPDATE is defined by a platform it indicates that the platform provides the mechanism for identifying if a different alternative application image is available, and that the alternative image should replace the current main (normally on-chip) application when different. It is the responsibility of the platform supplied routines to implement how such image validation is performed.

The following configuration options control the main features of the BootUp bootROM world:

CYGBLD_BUILD_BOOTUP controls whether the BootUp image is created, and will normally be defined for all BootUp configurations.

CYGIMP_BOOTUP_UPDATE controls whether the BootUp bootROM supports replacing the main application image with a different image from the alternative storage location. If not defined then BootUp will simply start the main application.

CYG_HAL_BOOTUP_COPYAPP controls whether the platform provides code to copy an application from NVM to RAM for execution.

$ ecosconfig new <target> minimal
[ … ecosconfig output elided … ]
$ ecosconfig import $ECOS_REPOSITORY/hal/TARGETPATH/VERSION/misc/bootup_ROM.ecm
[ … ecosconfig output elided … ]
$ ecosconfig resolve
$ ecosconfig tree
$ make

The following section is only relevant for target platforms that define CYG_HAL_BOOTUP_UPDATE and CYG_HAL_BOOTUP_VALID_ALT where the BootUp world is designed to allow for robust in-field updates of the firmware on a device.

For such systems the application started by BootUp must implement some of the support needed with regard to providing the “pending update” application image. When a new firmware update has been downloaded by the main application it will normally force a system restart, which will cause BootUp to perform the necessary update prior to starting the new main application.

The main application, when loading a pending update application into the alternative memory/device (e.g. off-chip SPI), should ensure that it does not set (write) the "valid signature" until it has validated the correct storage of the rest of the image. This requirement ensures that if a system reset occurs before the signature has been written that the image will NOT be interpreted by BootUp as being valid. This allows the BootUp loader to be simpler since it can treat a valid, complete, signature as an indication that the application was written correctly.

At a minimum (and critically) the main application needs to ensure that it invalidates the alternative image signature prior to starting the process of storing a new application image into the alternative area. This ensures a partial image is not incorrectly identified as a valid, pending, update. If CRC checking is also being used by the platform HAL then this likelihood is minimised.

Note

This requirement that the alternative storage area must have a complete valid image, whenever there is a complete signature present, ensures that in the case where the implementation does not use a CRC (or similar check) for the BootUp code to perform validation of a complete image, that any previous previous valid signature is not incorrectly accessed and treated as “valid”. For example, if the writing of a subsequent pending update is interrupted (CPU reset, etc.) before it “overwrites” the signature of the previously stored image. If a pending update is downloaded to the holding area, validated and marked as such BUT the system is not rebooted (so the pending update is not applied). Subsequently another pending update starts to download a different image to the holding area but the process is interrupted before the previous image “valid” signature is over-written. The BootUp code could then incorrectly interpret the invalid (partially overwritten) image as being valid if no other validity checks are performed. This is why the rule exists that the code performing the pending update storage should first invalidate the signature. It is the responsibility of the main application storing the pending update to ensure that the complete image is valid PRIOR to finalising the platform specific signature. To reiterate, the BootUp package, in combination with the platform HAL support, only requires a simple “signature validity check” for robustness WHEN the code storing the pending update ensures that if there is a valid signature in the alternative area then the rest of the bytes are also valid (i.e. a complete valid image is in place).

Since the BootUp will only perform an update when the valid alternative image is different, there is no strict need to erase the signature/image until the main application needs to provide a new update. However, doing so during its normal startup will avoid BootUp having to spend CPU cycles validating and checking the alternative image prior to checking the signature and deciding not to update.

Notes

To reiterate, the main application (not BootUp) is responsible for invalidating (erasing/removing) the alternative image, or at least the signature. This allows BootUp to be simpler since it only needs to be able to read from the alternative image location. The signature can either be embedded in the application (assuming the caveat of it being the last data written), or it can be a totally separate distinct section maintained in conjunction with the update application image. Such design decisions are left to the specific platform HAL support. The use of other validation mechanisms, e.g. a CRC, will only be required if the medium that is used to store the alternative (pending) image can suffer from data corruption, or transient read errors. Such a situation will be extremely unlikely for the vast majority of implementations.

BootUp is supported by the following platform HALs: