SD controller now initialized; still need to read SD ID and perform data block transfer. Some questions on TFS and booting an application image

[Ed Sutter]

>> Jarielle,
>> Your observation is correct.  The documentation is based on a generic,
>> programmable (via TFS scripts), configure-at-runtime type of bootup.
>> It assumes the user will use the facilities provided  by the monitor command
>> line.
>>
>> The approach Gedare is recommending (Gedare, correct me if I'm misstating)
>> simply takes some defined boot sequence and shifts it from a uMon/TFS script
>> to a
>> snippet of code in the port directory.  This certainly reduces boottime
>> flexibility but
>> does keep things much less complicated.
>> I suppose sometimes too many options are not a good thing.
>>
> Yeah. This is important in safety- and security-oriented systems. I'm
> all for features that aid software productivity and make for a
> flexible environment, but only if it can be turned off and even
> stripped-out of the code completely with minimal pain.
I totally understand where you're coming from, and don't disagree. Any 
level of user
programmability reduces security.   The tough part was to try to provide 
the flexibility but
also allow folks to disable that in runtime when necessary.  I *think* I 
did that to some
degree; although I don't know how hard that was put to the test.

At the end of the day though, when you put any flexibility in a system 
and then
provide a means to lock it out, the user wants some kind of back door so 
they don't shoot
themselves in the foot (i.e. forget a password).  That's where the 
problems creep in.  All
files and commands in uMon have user levels so different passwords would 
provide
different levels of access to the monitor and underlying hardware). How 
well did all that
work?  I doubt many folks ever even used it, so I don't know.
Bottom line... assuming there is a threat, simplicity is safer and more 
secure; no argument there.

> Also, I just stumbled across this code which might be worth visiting:
> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/umon
>
That's ancient, but probably still works if the latest files are put in 
place.  I did some
work with RTEMS on a Cogent PowerPC board.  Umon was the boot, and RTEMS 
the OS.
I opted to use TFS as the file system because the board had NOR flash.  
Optionally,
I had attempted to hook TFS into the RTEMS IMFS stuff...  Don't know if 
it was ever used.