[evla-sw-discuss] Some thoughts on booting the TC-11 IB

[Barry Clark]

The boot device for a power-on boot is selected by pin wiring on the 
chip.  For our particular application, we would want it wired to boot
from local flash.  When the power-on reset is released, execution transfers
to the on-chip boot rom, which addresses the boot device and transfers
a short bootstrap, of 247 to 4096 bytes (depending on the device).  
This is a short routine, which I think has to be written in assembler, 
which would then read the system image from the same device, and then 
transfer control to it.  It is not clear to me that a BSP would come
with this bootstrap.  (There are other ways of loading a system image;
I think the one most likely to be used by the BSP developers is to use 
the PCI port, and configure the TC-11's memory to be a slave in the address 
space of the host PC.)

The leading contenders for the RTOS are ones in which the system and 
application code are bound together in a single image.  I would expect
the image to be of order one MByte.  So a flash size of 2 Mbytes is 
required, I think, and we are not very interested in sizes much larger 
than this until we get up to 32 Mbytes, when we might start thinking 
about holding the system images for all possible devices.  My opinion 
is that going to more than 2 Mbytes of flash is not justified.

Parallel flash using the External Bus Unit would load very fast, even for
a 8-bit wide device.  I do not know what speeds are practical for a serial
ram.  The boot routine sets the SPI clock to one MHz.  Not obvious how
much faster it could run.  With a 1 MHz clock, a system image would take
about 10 seconds to load.  Anybody have a feel for whether this is OK?

Another possibility is to not have an on-board flash, but to store the 
system image into the flash that holds the slot identification.  Advantage -
decreases device count by one.  Disadvantages - we couldn't write protect
the slot flash, offering us an opportunity to screw things up royally;
also, we wouldn't dare try increasing the SPI clock beyond 1 MHz to this 
flash, I think.

First thing the system should do after booting is to set the soft reset
parameters to boot from flash also - the watchdog does a soft reset, and
we would want it to, in the general case, get a new copy of the system and
start it up.

Also, after reading the slot flash, the system should send an ethernet 
broadcast packet saying, "Here I am, my address is <xxx.xxx.xxx.xxx>, 
I am a device type <y>, and am running software revision <z>.  On the
array (but not in the lab) a listener in the control building would then
compare the software version with the "official" software version, and, if
they disagree, ask the array operator if he wants to load the official 
version.

I think we need a boot task, rather than going through a shell, even if 
there is such a thing.  The task would sit there waiting for a TCP connect.
If it gets one it would accept a password and a function code.  If the
password is correct it would do one of four things:
  -  Restart the current system image after a soft reset
  -  Execute a soft reset to reboot from flash
  -  Accept a system image over the socket, disable interupts, move the 
     system image into execution space, and start it via a soft reset
  -  Accept a system image over the socket and write it into local flash;
     then execute a soft reset to boot this image from flash

There is an interesting window of vulnerability while the system image is
being transfered to flash.  If the power goes down, or some other catastrophe
occurs, during this window, we may end up without an executable image in
flash.  Then there is no recourse but to go to the antenna and swap out the
flash.