Still undergoing attempt to boot Umon from SD

Mon Jun 29 14:53:36 UTC 2015

On Mon, Jun 29, 2015 at 5:25 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> Jarielle,
> 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.

Being that this will be my first time using a JTAG debugger I wanted
one that was cost-effective as well as easy to set up with the BBB, I
did some research and the one I ended up getting was the Flyswatter2
which can be found here:
http://www.tincantools.com/JTAG/Flyswatter2.html.  I also got the JTAG
adapter kit in order to connect the BBB to the Flyswatter2 which can
be found here: http://www.tincantools.com/JTAG/BeagleBone-Black-JTAG-Adapter-Kit.html.

They also have a wiki on how to set up the JTAG debugging with the BBB
which can be found here:
http://www.tincantools.com/wiki/Flyswatter2_BeagleBone_Black_How_To

I have to admit that this will be a learn-as-I-go process.

> Ed
>
>
>> 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
> procedures
> 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.

Unfortunately, it does not. :-(

> I preferred raw mode (over FAT) just because its simpler (I like simple);
> nevertheless
> I didn't get it working either.

I also prefer raw mode as well, but I was also encountering some
issues as well and so I wanted to see if I could boot from FAT
instead.  Since Chris mentioned about the SFN/LFN filename issue that
I did not take into account and I did not get it to boot from FAT just
yet, I am going to try to get raw mode working again.

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