Still undergoing attempt to boot Umon from SD

Ed Sutter ed.sutter at
Mon Jun 29 12:25:22 UTC 2015

I second Chris' comments...
Great work and summary of what you've done.
Some comments embedded; but basically, I agree with your investment.
Let me know which one you get, so if I end up following in your footsteps
we'll learn from the same tool.

> 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.
Yep, I recall similar confusion when I was trying to do this in raw mode.
I didn't send you anything over the weekend because, while I did spend a few
nights (last month) on this, I didn't take notes, so all I have are some 
and some binary images (the various headers you mention above) attached to
the boot.bin image in various ways while attempting to get this to boot.
The problem certainly does not have an obvious solution.
I preferred raw mode (over FAT) just because its simpler (I like 
simple); nevertheless
I didn't get it working either.
> 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> wrote:
>> On Fri, Jun 26, 2015 at 5:16 AM, Ed Sutter <ed.sutter at> 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
>>>> 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> wrote:
>>>>> On Wed, Jun 24, 2015 at 7:35 AM, Ed Sutter <ed.sutter at>
>>>>> 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>
>>>>>>> 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>
>>>>>>>>> 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
>>>>>>>> --
>>>>>>>> Ed Sutter
>>>>>>>> Alcatel-Lucent Technologies -- Bell Laboratories
>>>>>>>> Phone: 908-582-2351
>>>>>>>> Email: ed.sutter at
>>>>>>>> _______________________________________________
>>>>>>>> umon-devel mailing list
>>>>>>>> umon-devel at
>>>>>> --
>>>>>> Ed Sutter
>>>>>> Alcatel-Lucent Technologies -- Bell Laboratories
>>>>>> Phone: 908-582-2351
>>>>>> Email: ed.sutter at
>>>>>> _______________________________________________
>>>>>> umon-devel mailing list
>>>>>> umon-devel at
>>> _______________________________________________
>>> umon-devel mailing list
>>> umon-devel at

More information about the umon-devel mailing list