Still undergoing attempt to boot Umon from SD

Jarielle Catbagan jcatbagan93 at gmail.com
Sun Jun 28 22:31:13 UTC 2015


Ed,

Unfortunately, I did not get Umon to boot from an SD card just yet,
despite having a go at it for the last three days.  But during the
course of my attempts, I have observed some things, some of which
confirmed some notions I previously had while others have left me
puzzled.

With the various configurations that I have done when formatting the
SD that I have with a FAT filesystem or without and then transferring
the Umon image to the SD, I was able to confirm that the internal ROM
code of the AM335x can boot from an SD if it contains a Master Boot
Record (MBR) and a FAT32 primary partition marked as Active.  The
internal ROM code then locates for a file named "MLO" in the FAT32
primary partition where this file will ultimately contain the Umon
image.

When attempting to boot from an SD card, via the boot switch on the
BBB held down, the boot device order is SPI, MMC/SD, USB, and then
UART.  Since the SPI is not set up explicitly to interface with a
memory medium to boot from and the USB is not set up as well, if the
attempt to boot from SD fails the processor will try to boot from
UART.  The way to see if the SD boot does not come through and has
defaulted to attempt to boot from UART is if 'C's are being outputted
on the serial port.

>From my attempts, the SD boot fails based on two different situations
that I have encountered.  One is if the SD card does not contain an
MBR/FAT filesystem.  The second is if an MBR and FAT filesystem does
exist but the FAT formatted primary partition is not marked Active.

I wanted to confirm that the SD card that I have is set up properly
and so I tested booting from an SD using U-boot's first stage
bootloader as well as TI's bootloader which was part of their
StarterWare distribution.  These bootloaders were named "MLO" and were
placed in the FAT32 partition of the SD card and they were able to
boot up with no issues at all.  One thing that I noticed when I
inspected the binaries was that the former bootloader both had a a
Configuration Header TOC structure and GP header while the latter
bootloader only had a GP header.  This is the first part of my
confusion.  These headers were described in Section 26 of the AM335x
TRM.

I set up the Umon image that I had both with a Configuration Header
followed by a GP header as well as a GP header only, and then placed
the Umon image ("MLO" file) in the FAT32 primary partition and then
booted the BBB from the SD card with no success.

With the Umon images in the SD card, if the FAT32 partition is not
active, SD booting fails and the AM335x attempts to boot from UART,
but with the FAT32 partition marked as active it results in what it
appears to be the AM335x "hanging".
Renaming the Umon images from "MLO" to some other name or deleting the
file completely also results in the SD booting to fail and the UART
booting procedure to be initiated by the internal ROM code.  From this
I am able to conclude that the internal ROM code is able to locate the
Umon image, but for some reason it can not boot up.

I really need to know what the processor is doing at the time it loads
the Umon image and/or to verify that it is in fact getting loaded in
correctly and in its entirety.  Furthermore, I need to verify that the
execution is in fact starting at the right place after the Umon image
is loaded, assuming if it does get loaded properly,   Once I verify if
the Umon image does get loaded properly, I need to determine at what
point is the program "hanging" and whether or not it is caused by an
exception.

The situation that I am facing right now has greatly emphasized the
importance of a JTAG debugger and so I finally got around to
purchasing one which should arrive by the end of this week.  I figured
that I am doing myself a disservice if I don't have one especially
when trying to debug and solve issues like the one I am facing.  That
way I'll be able to walk through each and every step that the AM335x
undergoes at bootup, up until it attempts to load the Umon image from
the SD card.

In the meantime I will be proceeding to work on the other aspects of
Umon.  Nonetheless, once I have my JTAG debugging set up, booting Umon
from an SD card on the BBB will be my number one priority.

Best Regards
Jarielle


On Fri, Jun 26, 2015 at 8:47 AM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> 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


More information about the umon-devel mailing list