Quick Update: Re: thoughts for next steps...

Fri Jun 26 08:47:36 UTC 2015

I just wanted to give a quick update on my progress in attempting to
get Umon to boot off of a uSD.

Initially I was approaching the uSD boot by having Umon boot from the
uSD in what is considered in AM335x terminology, raw-mode.  Here,
sectors are read directly at specific locations into the internal
SRAM.  Based on my readings from the AM335x TRM, the processor will
determine how to boot from the uSD.  Despite not getting raw-mode boot
to work before changing my approach towards booting from a
FAT-filesystem, I decided to transition immediately to get Umon
located within the FAT-filesystem and then booted from there.

After recalling from the BBB SRM, the more common approach would be to
boot from a uSD that is formatted with a FAT-filesystem.  Here, the
internal ROM code in the AM335x will locate for a booting file within
this FAT-filesystem, which must have the filename set to "MLO", and
then transfer the boot image into the internal SRAM before passing
control to it.

Once the "MLO" file is located in the root directory of the
FAT-filesystem, unlike booting from XIP (eXecute In Place) sources
like NOR flash or even peripheral booting such as UART, booting from a
uSD requires a non-XIP booting process as elaborated in the AM335x TRM
section 26.  As a result, the actual application image must be
prepended with a header that specifies the size and entry point of the
application image (AM335x SRM Section 26.1.7.3).

After undergoing countless iterations of transferring the Umon image
to the uSD and then booting the BBB with it to test what works and
what doesn't, I am still encountering issues with the uSD boot but I
am confident that I am very close to getting the uSD boot to work.

My initial attempts resulted in the AM335x to determine that the uSD
did not contain anything valid and so it immediately went on to the
next booting device where it will try to boot from there.  If the uSD
card does not contain anything valid for the ROM internal code to
inspect, it will try to boot from UART.  As a result, if I see UART
booting taking place after an attempt to boot from the uSD, I
immediately know that the contents of the uSD is invalid.  With this
in mind, I inspected the contents of the uSD and for some reason I
have found out that the FAT-filesystem structures (i.e. FAT table,
root directory entry) are not updated accordingly when I add the MLO
file to my uSD and as a result I had to modify them.

Since I have not worked extensively with the FAT filesystem before, or
FAT32 to be more exact, as of right now its an ongoing learning
process for me.  Looking at the FAT-filesystem specifications allowed
me to figure out how the FAT-filesystem is laid out and has provided
me with an insight on how to place the Umon image at the appropriate
location in order for the AM335x to eventually locate it.

I will continue to work on getting Umon to boot from a uSD and I will
update my progress along the way.

On Wed, Jun 24, 2015 at 7:44 AM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> On Wed, Jun 24, 2015 at 7:35 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
>> On 6/24/2015 10:35 AM, Jarielle Catbagan wrote:
>>>
>>> On Wed, Jun 24, 2015 at 7:17 AM, Ed Sutter <ed.sutter at alcatel-lucent.com>
>>> wrote:
>>>>
>>>> On 6/24/2015 10:12 AM, Gedare Bloom wrote:
>>>>>
>>>>> On Wed, Jun 24, 2015 at 9:37 AM, Ed Sutter
>>>>> <ed.sutter at alcatel-lucent.com>
>>>>> wrote:
>>>>>>
>>>>>> Jarielle,
>>>>>> Something to consider...
>>>>>>
>>>>>> I think the next two big steps are:
>>>>>> - Init DRAM
>>>>>> - Boot standalone (using uSD instead of UART)
>>>>>>
>>>>>> I believe your current plan was to work on DDR-init next; however it
>>>>>> may
>>>>>> be
>>>>>> better (your choice, just adding my 2cents) to consider booting from
>>>>>> microSD
>>>>>> as the next task.  Here's why I say that...
>>>>>>
>>>>>> As you are playing with DDR-init you'll have to do a lot of restarting
>>>>>> the
>>>>>> board.
>>>>>> Each time you do that, you'll have to reboot using Xmodem.  This
>>>>>> requires
>>>>>> a
>>>>>> few manual steps: hold boot button while power cycling, then issue
>>>>>> xmodem...
>>>
>>> If I am understanding you correctly, I actually don't have to power
>>> cycle the board anytime the board hangs.  I just simply reset via the
>>> reset button and then issue an xmodem transfer again without touching
>>> any cables and restarting my terminal emulator.  I hope I did not
>>> misunderstood you :-)
>>
>> Yep, either way (power cycle or reset button), its a simpler reboot if it
>> occurs without
>> xmodem.
>>
>
> I agree!  I'll get started asap.
>
>>>
>>>>>> Alternatively, if you get the boot-from-uSD card stuff working, and
>>>>>> then
>>>>>> erase
>>>>>> the eMMC (causing the cpu to automatically boot from uSD), you should
>>>>>> be
>>>>>> able to just push the reset button to restart a locked up board.
>>>>>>
>>>>> In other words, it has a tighter develop-execute-debug loop.
>>>>
>>>> Exactly.
>>>>>
>>>>>
>>>>>> It would just be easier (IMHO) if the board could reset with this basic
>>>>>> uMon
>>>>>> image
>>>>>> (what you have running now) by default.  Know what I mean?  If yes,
>>>>>> what
>>>>>> do
>>>>>> you think?
>>>
>>> I think it's a great idea.  Yesterday I was deciding what I should
>>> finish first, which was either DDR-init or boot off of an uSD card.
>>>
>>> I will definitely start getting the uSD card booting to work as soon
>>> as possible.
>>>
>>> Right now I am at my university (taking summer classes) and I don't
>>> have access to an uSD card (left it at home).  But I did bring my
>>> Beaglebone Black with me as well.  So I'll continue working on
>>> DDR-init, and when I get home I'll immediately start working on
>>> getting Umon to boot of a uSD card.
>>>
>>>>>> Ed
>>>>>> _______________________________________________
>>>>>> umon-devel mailing list
>>>>>> umon-devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Ed Sutter
>>>> Alcatel-Lucent Technologies -- Bell Laboratories
>>>> Phone: 908-582-2351
>>>> Email: ed.sutter at alcatel-lucent.com
>>>>
>>>>
>>>> _______________________________________________
>>>> umon-devel mailing list
>>>> umon-devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>
>>
>>
>> --
>> Ed Sutter
>> Alcatel-Lucent Technologies -- Bell Laboratories
>> Phone: 908-582-2351
>> Email: ed.sutter at alcatel-lucent.com
>>
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel