Still undergoing attempt to boot Umon from SD

Jarielle Catbagan jcatbagan93 at gmail.com
Mon Jun 29 02:10:30 UTC 2015


Hi Chris,


On Sun, Jun 28, 2015 at 4:05 PM, Chris Johns <chris at contemporary.net.au> wrote:
> Hi Jarielle,
>
> Great write up and investigation.
>
> On 29/06/2015 8:31 am, Jarielle Catbagan wrote:
>> 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.
>
> I am not familiar with the boot modes for the chip but "raw" mode sound
> interesting.
>
> FAT booting also available on the Zynq device and my personal view is
> FAT booting is not suitable in the type of embedded systems RTEMS
> typically gets used in. Using FAT as a production boot system with RTEMS
> requires you support a number of partitions. The key issue is the way
> the FAT works opening the primary partition and updating it could
> corrupt the FAT and brick the board. If raw mode offers an alternative
> that would be nice.
>
> Also watch out for long file names (LFN) and short file names (SFN). For
> example if you have "MIO" in the root directory and on a Windows, Linux,
> MacOS etc box you mount the SD then do something like "mv MIO MIO.x.1"
> the directory entry for the MIO file will changes from a SFN to an LFN
> and if you then move it back with "mv MIO.x.1 MIO" there will be no
> change back to SFN, it stays as an LFN. Typically the ROM loaders will
> not parse LFN directory entries. It is a pain to remove the entry.
>

I did worked on trying to get "raw" mode working very briefly before I
switched over to try to boot off of an MBR/FAT filesystem.  I actually
did not take into account about the potential issue with SFN/LFN, but
now that you mentioned it I'll try to get "raw" mode working.

>>
>> 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.
>
> I remember Jason talking about a USB boot tool for the BB. It is in
> github somewhere. I am not sure if this is useful.
>

Interesting, I'll definitely take a look into it to see if I could use this.

>>
>> 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.
>>
>
> If you need any help with JTAG please let me know.
>

Thank you! I already have a sense that I'll have a few questions about
JTAG as I have never worked with JTAG before, let alone done JTAG
debugging.

> Is umon building with the RTEMS tools ?
>

I did manage to get Umon built using the RTEMS tools.  One thing worth
mentioning is that the current Umon sources has an external dependence
on the C library, and so I had to link it with the RTEMS C library.
The reason for this external dependence is that the previous Umon
version contained files that defined functions that would otherwise be
defined by the C library but had to be removed due to a conflict in
licenses.  In the meantime until a solution is provided to remove this
dependence on the external C library, Ed has provided me with the
necessary files as a temporary fix for now.  With these temporary
files, I am able to build the current version of Umon that I have
right now with the RTEMS tools without linking to the RTEMS C library.

> I have a BBB with JTAG here.
>
> Chris



More information about the umon-devel mailing list