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

Fri Jun 26 12:16:23 UTC 2015

Jarielle,
This is gonna be tough 'cause now you have a lot more manual steps for
each attempt.  I spent some time on this a while ago (unsuccessfully).
My approach was the "raw" mode, but I'm not suggesting you go back to
that.
I have some notes at home, so tonight I'll forward you whatever I have.
I'll be banging on this with you in parallel, so two heads are better 
than one.
IMHO, this will be a big one to get checked off the list because then 
the board
will truly boot standalone.
Good start!
Ed

BTW, I finally got myself set up to be able to push your patches (thanks 
Amar!),
so hopefully this weekend they will be part of the master, and it will 
include
a (possibly temporary) fix for the ctype.h issue you were having earlier.

> 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