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

[Gedare Bloom]

On Fri, Jul 24, 2015 at 1:24 PM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> I assume the simple case would still include some kind of non-volatile
> environment (similar to uboot's setenv/getenv) right?
>
So, the question boils down to whether uMon can get the entire
boot-time configuration to be statically determined, either at
compile-time or provided through a configuration "file" that uMon
reads say from non-volatile storage or over net. Relying on a
non-volatile, writable environment is convenient but also prone to
abuse. If we can create a really simple bootloader that can be
configured for more, then we give users the widest flexibility in
determining what they want to leverage.

I'll say it again. For safety- and security-critical applications, the
less code that exists, and the less resources that code can access,
the easier it is to certify the code. That's my motivation here,
anyways.

Gedare

>
>> Ed (and others),
>>
>> My general opinion*, backed by current trends, is that code simplicity
>> trumps everything else when dealing with low-level systems code. My
>> preference is that uMon be as simple as we can make it, so that it
>> hands-off control to RTEMS and then (effectively) disappears. I prefer
>> to see successively more complexity/features added as execution gets
>> closer and closer to the application itself. Thus, uMon hands off
>> control to RTEMS BSP, which boots in asm and hands-off control to
>> RTEMS kernel where it initializes based on application-provided
>> configuration.
>>
>> *The one caveat to this philosophy is that debug code in the boot,
>> while adding complexity, can aid debugging the complexity in the RTOS.
>> This can allow, for example, fatal errors to fall-out into the
>> boot/monitor. I'm not certain how to judge this factor, but it should
>> be an optional feature anyways. Thus, I recommend having an option for
>> a very simple, no-frills bootloader, and leave the more complex,
>> feature-ful one (with TFS, debug support, etc) as a 'switchable'
>> variant. My $0.02.
>>
>> Gedare
>>
>> On Fri, Jul 24, 2015 at 10:33 AM, Ed Sutter
>> <ed.sutter at alcatel-lucent.com> wrote:
>>>
>>> On 7/24/2015 9:07 AM, Gedare Bloom wrote:
>>>>
>>>> On Fri, Jul 24, 2015 at 8:08 AM, Ed Sutter
>>>> <ed.sutter at alcatel-lucent.com>
>>>>
>>>> wrote:
>>>> [...]
>>>>>
>>>>> There are several configurations to consider here...
>>>>>
>>>>> 1. Don't use any FFS in uMon at all:
>>>>>      uMon boots up, establishes connectivity with MMC and Ethernet and
>>>>> based
>>>>> on
>>>>>      the content of some area of raw MMC, it can either boot some
>>>>> already-installed
>>>>>      RTEMS application or it can look to the network for a network
>>>>> boot.
>>>>> Once
>>>>> RTEMS
>>>>>      is running, it will have access to the MMC in whatever format it
>>>>> wants.
>>>>>
>>>> This option #1 is appealing from a simplicity point-of-view.
>>>
>>> With that simplicity comes very little configurability, but maybe that's
>>> ok.
>>> The value of
>>> configurability depends on how much the base system is to be reused
>>> without
>>> rebuild.
>>> If each new system can just rebuild/reconfigure the boot scheme to be
>>> specific to that
>>> system, then there's no need for runtime configurability.
>>>>>
>>>>> 2. Incorporate whatever FFS RTEMS will use into uMon:
>>>>>      Since RTEMS already has some FFS-ish capabilities, just hook that
>>>>> same
>>>>> code
>>>>>      (or fragments of it) into uMon so that both the bootloader and app
>>>>> can
>>>>> access
>>>>>      all files easily.
>>>>>
>>>> What kind of files would be shared through this feature? I don't
>>>> entirely buy the premise that sharing a FS between a bootloader and an
>>>> application is a good idea. Is there a document I can read describing
>>>> the philosophy? Are there some reasons like for debug or modifying the
>>>> boot scripts (from within the application itself) that makes it
>>>> sensible to do this kind of sharing? It seems more likely that a
>>>> remote debug or upload engine would be used that can access the MMC
>>>> directly.
>>>
>>> It just allows the bootloader to come up and do some pre-Application
>>> stuff
>>> prior to
>>> turning control over to it.  This was useful in eval boards (for example,
>>> Cogent) that
>>> were not pre-determined to run a particular application or RTOS. For
>>> example, it would
>>> give the user the option to run a memory test at startup prior to loading
>>> the application.
>>>>>
>>>>> 3. Incorporate TFS in uMon by allocating some block of MMC to it:
>>>>>      At startup, uMon initializes all periphery, and then has a section
>>>>> of
>>>>> MMC
>>>>> that
>>>>>      it sucks into RAM and then TFS is overlayed on that block of RAM.
>>>>>      Then uMon can have its typical script driven bootup, and RTEMS can
>>>>> optionally
>>>>>      have access to that, while still using some other FFS for the MMC.
>>>>>
>>>> I understand the utility of the FS to enable uMon to use scripts,
>>>> etc., but I don't buy that it is good to expose applications or even
>>>> RTEMS to those internal details, or to expose the FFS to possible bugs
>>>> in the application or RTEMS. Also, on reset the RAM FS has to be
>>>> re-built, so if the FS is not shared there is no point in reserving
>>>> that part of memory to preclude use by RTEMS/app, i.e. RTEMS should be
>>>> able to "wipe" the RAM overlay that is built by uMon.
>>>>
>>>> But if good reasons for the sharing are proposed, I wouldn't be
>>>> opposed to seeing the TFS implementation ported to RTEMS (with proper
>>>> licensing). As it stands, however, I find it simpler to just ignore
>>>> that region of the flash device (MMC) from within RTEMS.
>>>
>>> RTEMS having access to TFS is always optional; the real point is that you
>>> give
>>> uMon the flexibility to use TFS for scripts at boottime (still,
>>> optional).
>>> The RTEMS
>>> hook to uMon is either optional (at build time) or not even made
>>> available.
>>> That's
>>> your call.
>>> A lot of the reason for the facility sharing hooks (between uMon &
>>> application) were
>>> due to system limitations that generally speaking don't exist much
>>> anymore
>>> (except for
>>> microcontrollers).
>>>
>>>> IMHO, mode #3 is ideal because that philosophy can be applied to any
>>>> system
>>>> regardless of the memory configuration; however, I'd prefer that we get
>>>> feedback
>>>> It's a fine option, but I don't see how the memory configuration has
>>>> anything to do with making this option better than the other two.
>>>
>>> My point regarding the memory configuration was just to emphasize that
>>> TFS
>>> was really
>>> made to run on NOR flash, but it can still be used with other memory
>>> configurations as long
>>> as its ok to run from RAM (pumped from whatever non-volatile memory is
>>> used).   The
>>> connection of RTEMS to TFS is still optional.
>>>
>>> Seems to me this initial BBB port of uMon should be as versatile as
>>> possible; at least supporting
>>> both a TFS and TFS-less boot strategy.  Having TFS in uMon does not imply
>>> that RTEMS has
>>> to even know about it; its just an option.  That's why I suggest that
>>> Jarielle postpone any TFS
>>> work till everything else is done, and we've had a chance to think
>>> through
>>> what you guys want
>>> to hookup between the two (uMon and RTEMS).
>>>
>>> The good news is there are a lot of options.
>>> The bad news is there are a lot of options.
>>>
>>> The decision you guys have to make is what options you want to make
>>> available to RTEMS
>>> users.  Clearly you can just not provide the hook if that's a concern.
>>>
>>>>> from some other RTEMS core developers to get thoughts on that.
>>>>> Ed
>>>>>
>>>>>> Hi Ed and all:
>>>>>>
>>>>>> Initializing the SD controller on the AM335x took a bit longer than I
>>>>>> expected which was mostly a result of encountering some issues with
>>>>>> the SD controller initialization, specifically the clocks that are
>>>>>> involved.
>>>>>>
>>>>>> Now that I was able to resolve the issues I was facing, I was able to
>>>>>> initiate CMD0 (GO_IDLE_STATE), CMD8 (SEND_IF_COND), and CMD55
>>>>>> (APP_CMD) and was able to receive appropriate responses from any
>>>>>> arbitrary SD card that is connected.
>>>>>>
>>>>>> Right now I have the interface setup using 4-bit SD mode with the SD
>>>>>> clock frequency set to 6MHz and currently operating on 3.0 V.
>>>>>>
>>>>>> Currently, I am looking into reading the ID register and to write and
>>>>>> read to/from the SD card.  I suspect that this would be much easier
>>>>>> now since the SD controller is set up properly already.
>>>>>>
>>>>>> As I am approaching in getting ready to integrate the SD code, i.e.
>>>>>> establishing the necessary code to get the "sd" command working, I am
>>>>>> also simultaneously looking into TFS.
>>>>>>
>>>>>> It looks like a RAM-based TFS would have to be set up as both the
>>>>>> MMC/SD can not be accessed linearly.
>>>>>>
>>>>>> Once TFS is set up, I would say that the next step would be to have
>>>>>> the ability to transfer an application image from the SD card into TFS
>>>>>> for uMon to boot from or, if it's possible, to transfer a raw
>>>>>> application image from SD into DDR3 and then pass control to the entry
>>>>>> point of the application image.
>>>>>>
>>>>>> Am I approaching the idea of TFS and booting an application image
>>>>>> correctly.
>>>>>>
>>>>>> Thanks.
>>>>>> _______________________________________________
>>>>>> umon-devel mailing list
>>>>>> umon-devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> umon-devel mailing list
>>>>> umon-devel at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>
>>>
>>> _______________________________________________
>>> umon-devel mailing list
>>> umon-devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel