Hyperstart Load Project
Description
This project is to enable target loading of hyperstart images from within OpenArbor. This capability is intended for the Deos_Louie_D345_Release on 2016/03/28.
This is in support of the Louie_Program, but the capability is desired to be generally useful.
Design
The proposed design is to have:
- A DeosBoot which can switch between two hyperstart images,
- A "Loader" hyperstart image capable of programming a "Custom" hyperstart image via FTP, and
- OpenArbor able to request an OpenArbor constructed "Custom" hyperstart image to be written.
Note that a symmetric "ping pong" pair of hyperstart images would also work where "Loader" and "Custom" are one and the same.
BootDeos
If the "Custom" hyperstart image CRC is good, BootDeos will start it, otherwise BootDeos will start the "Loader" image. The "Custom" image can request the activation of the "Loader" image via setKernelAttributesEx().
Loader
The Loader hyperstart will contain a registry with a platform resource describing the FLASH for the "Custom" hyperstart image. The resource will be writable by FTPServer. FTPServer will be modified to use a dynamically loaded "resource writer" library from the kernel file system to save files incrementally as the file is downloaded. The library will implement the FTP protocol agnostic device file operation interface currently used by LwIP.
FTPServer will be told to use the library to save a file by specifying a "magic" pathname:
/proc/ldev/libraryName/ResourceName
The resource writer library will erase the FLASH block on a file open, write flash lines as FTP provides the data, and process partial lines on a file close.
In addition to the above, we'll make LwIP compatible with the same file naming convention by extracting the interface used by LwIP into a separate svn extern'd component, and change both LwIP and FTP to use the new file name syntax. LwIP would drop the "driver library name" parameter to the lwip.config file "pppos" option and get the library via the /proc/ldev pathname. How to handle device initstring is TBD.
OpenArbor
OpenArbor will be modified so that a button, i.e., "Update Target Load" will:
- Request the target to switch to the "Loader" hyperstart image.
- Write its most recently constructed hyperstart image.
- Switch back to the "Custom" image.
How OpenArbor knows which style, incremental vs hyperstart load should be performed is TBD, but could initially be hard coded
Image/File Loading Proposal 1
.options proposal for hyperstart and individual file loading.
First some data modeling:
A hyperstart image contains a kernel file system containing 1 or more registries. The hyperstart file is contained in a region of linearly mapped physical memory. Another way to think of this is that the SRT, boot interface object, PVAS, and other related data structures in a hyperstart file are just part of the Deos "kfs" file system, and thus that a hyperstart file is just a Deos kfs.
In the future more than one file system could be visible when booting a Deos kfs, and some of those file systems might not be "kernel file systems".
When viewed this way it makes sense to think of a platform as containing one or more partitions, each partition housing a file system of some type. Some of the file systems are "bootable", some are writeable and the means to write a given partition varies depending on which partition is booted. Some configurations have limits on what files can be written, for example a max file size. For now only the boot partition can be programmed via kfs operations (saveKernelFile, etc.), and non-boot partitions can only be loaded via some other means, e.g., cffs or via hyperstart image loading.
The proposal is to model the above declaratively. The following uses a language based description, but XML will be used in OA runtime. How to translate the language to XML can be sorted out if/when there is concurrence.
In the following, lower case are literals, upper case are BNF like variables with the following meaning:
INDEX The partition index, an int, aka boot index. FILTER A limit on which files can be written. METHOD A way that files can be written on the target. NAME A user defined name. REGISTRY Registry file name, e.g., platreg.bin, etc.
A "partition" entry describes a partition, it's boot index, and which registries it contains. Each "registry" entry defines a way to boot that partition and when so booted the partitions that can be modified and how:
partition INDEX
alias NAME # e.g., bootDeos, basecon, flight, etc.
registry REGISTRY
# The things writeable when booted in this registry
can-write INDEX [FILTER] METHOD
Filter
A way to limit the set of files available. Linguistically we represent the options braces "{}". The kind of things expected to be filters are pathname globs or regular expressions of some sort, and file size restrictions. For example:
{ PATTERN="/cff/*", SIZE<200KB }
Methods
The legal set of methods is still being worked out, but these are what we know of now. A method may have parameters called METHOD_PARAMS. METHOD_PARAMS are method specific.
kfs
Summary:
kfs # no parameters
Can update a partition containing a Deos kernel file system, e.g., via saveKernelFile(). Currently Deos only supports writing to the partition that has been booted, so INDEX must match the partition index. Currently there are no kfs METHOD_PARAMS, but in the future writing to non-boot partitions might be possible at which point parameters might be added to denote how to write to other partitions, e.g., the "mount point".
hyperstart
Summary:
hyperstart RESOURCE
An entire hyperstart file can be loaded using the given RESOURCE. RESOURCE is a file name in the booted partition, e.g., /proc/flash/flight
cffs
"cffs" is a placeholder at this time. The arguments are TBD.
pool-padded
"pool-padded" is a placeholder at this time. The arguments are TBD.
Semantics
OA would use the partition specifications to determine the commands necessary to write files and hyperstart images. For example, when OA is asked to program a file into partition 0 (traditionally the only hyperstart image), OA searches for some boot configuration that can program hyp index 0, i.e., a partition with a matching name and a registry specifying it can program hyp index 0 (either via hyp or file loading). If there was more than one method available, then some sort of dialog would have to be presented, or that condition could be an error. Something like this:
POSSIBLE_METHODS = {}
for each FILE that needs to be updated
for each PARTITION
for each REGISTRY
for each can-write METHOD
if the can-write INDEX matches the FILE's PARTITION and
the FILTER matches the FILE
then
POSSIBLE_METHODS += METHOD
if POSSIBLE_METHODS == {} error "No way to write the files"
if length(POSSIBLE_METHODS) == 1, use the method
else use environment defaults or ask user which method to use.
Examples
The configuration for existing BSPs would be:
partition 0
alias "basecon"
registry "platreg"
# when platreg is booted, no file mods permitted
registry "platregd"
can-write 0 kfs
The Louie config, where the "basecon" can be hyperstart loaded when the "bootDeos" partition is booted, and basecon can do individual file loading would be:
partition 0
alias "bootDeos"
registry "platreg"
can-write 1 hyperstart "/proc/flash-c-90/UserHyperstartFlash"
partition 1
alias "UserHyperstart"
registry "platreg"
# when platreg is booted, no file mods permitted
registry "platregd"
can-write 1 { SIZE<200KB } kfs
Note that there is currently no equivalent of the "alias" above. It is included above on the expectation that OA would use the name in dialogs and that in the future we'd permit the alias to be used instead of an "INDEX" to make the configuration easier to understand and maintain.
OA would need some built in logic to know how to write each file system type, and would use the above for the "variables" for each method, e.g., the FTP command arguments.
Aaron grumbles: it really annoys me that we gave several files (registries, hyperstart images, etc.) an extension of ".bin". We should have used semantic file extensions, e.g., platreg.bin should have been something like platreg.regbin, or normal.regbin or download.regbin. Sigh.
Proposed XML
This is what is agreed to so far for the XML specification of the language from above:
<partitions> <-- TBD partition information goes here --> </partitions>
Issues
- The Louie_Program will also need to provide incremental file loads to support automated tests, although using MRAM is probably acceptable for that configuration. A suitable PAL and basecon.hyp will be required.
- The customer will be required to load the "Loader" hyperstart image via some other means, e.g., emulator or flash programmer.
