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:04 PM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> 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.

Also, I just stumbled across this code which might be worth visiting:
https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/umon


> So, here are a few more thoughts...
>
> 1. Continue the MMC work and hook to the 'sd' (or similar) command to
>      support the ability to read data from the MMC to RAM and write data
>      from RAM to the MMC directly from the command line.
> 2. Step over to the Ethernet interface and implement the code that is
> discussed
>     in beagleboneblack/etherdev.c.
>
> These two steps are needed no matter what follows.
>
> We'll start by taking the "TFS-less" approach, so we now have to think about
> how we replace a TFS boot script with a block of code.
> Some of that may be doable by using the "docommand()" function which is
> essentially the same as the "system()" function in linux.  You can issue a
> command
> from code.  The problem is that you really don't have a lot of control of
> the flow
> from one command to the next.  We'll just have to keep thinking about this.
>
Well, I'd like to hear Joel and Chris chime-in on the design and
philosophy questions. I'm just one voice, after all. :)

> Its a different approach than I've taken in the past with uMon, so I
> apologize
> for being a bit flakey here...
>
> Ed
>
>
>> If a TFS and TFS-less configuration were to be supported, what would
>> be the recommended way to configure the build process and what
>> necessary modifications would have to be done to uMon to support this?
>>
>> >From what I have read in Chapter 5 of the uMon user manual, and by
>> walking through the steps in start(), i understood it to be (correct
>> me if I am wrong) that uMon requires TFS to boot an executable or to
>> be able to interpret scripts to ultimately boot an application image.
>>
>> If option #1 is to be taken where uMon for the BBB (and for future
>> ports if applicable) is to access MMC/SD in raw form to access a raw
>> binary application image to transfer into main memory for execution,
>> what would be the recommended way to integrate this functionality. Am
>> I missing anything, is my logic sound?
>>
>> On Fri, Jul 24, 2015 at 7:48 AM, Gedare Bloom <gedare at gwu.edu> wrote:
>>>
>>> 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