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

Fri Jul 24 18:24:42 UTC 2015

OK, I think the discussion was worthwhile to make sure we all have a
similar understanding. -Gedare

On Fri, Jul 24, 2015 at 2:04 PM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> 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
>
>
> _______________________________________________
> umon-devel mailing list
>
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel