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]

I assume the simple case would still include some kind of non-volatile
environment (similar to uboot's setenv/getenv) right?


> 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