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

Fri Jun 26 15:47:04 UTC 2015

On Fri, Jun 26, 2015 at 5:16 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> 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.

Sounds good!

> IMHO, this will be a big one to get checked off the list because then the
> board
> will truly boot standalone.

I think so too!

> 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 can't wait to see the master branch updated! :-)

Once the master branch is updated, I'll be pulling in the changes to
ensure that I am synced up especially to make sure that I incorporate
the fix to the ctype.h issue (although possibly temporary as you have
stated).

>
>
>> 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
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel