Still undergoing attempt to boot Umon from SD

[Chris Johns]

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.

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

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

Is umon building with the RTEMS tools ?

I have a BBB with JTAG here.

Chris