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 ed.sutter at alcatel-lucent.com
Fri Jul 24 18:04:05 UTC 2015 

Maybe this whole discussion is moot...
A complete, full-featured uMon port can be tuned to be as basic or 
feature-full
as the user wants.  The goal of any uMon port has always been to make 
all the
features work when they are enabled.  Then the user can decide whether 
or not
to enable them.  That's the whole point of config.h and the INCLUDE_XXX 
macros.

To turn TFS on...
#define INCLUDE_TFS     1
to turn TFS off...
#define INCLUDE_TFS  0

Ed

> Also, I could be completely off-base with respect to what is feasible
> for a working bootloader. I'm certainly no expert on the area! I'm
> just coming at this from the perspective of maximizing the flexibility
> of end users in terms of how they might want to use a bootloader. Some
> will want it to be the bare minimum, while others might appreciate a
> rich set of features that may be shared with the RTOS.
>
> I'm thinking in terms of flexibility of how uMon gets used, and not
> how much flexibility the set of features available gives a user. Hope
> that makes sense.
>
> Gedare
>
> On Fri, Jul 24, 2015 at 1:39 PM, Gedare Bloom <gedare at gwu.edu> wrote:
>> 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

More information about the umon-devel mailing list