GSOC 2015: Porting MicroMonitor to the Beaglebone Black

[Ed Sutter]

The lower 5 bits of the SYSBOOT pins determine the order that the ROM 
bootloader
will follow when trying to boot from something external (memory or device).
Referring to the schematic (pg6), the default value of SYSBOOT[4:0] is 
11100.
Referring to table 26-7 of the TRM, this corresponds to the sequence 
shown on the
schematic:    MMC1 (eMMC), MMC0 (uSD), UART0, USB
This means the ROM bootloader will first attempt to get valid data from MMC1
(eMMC), if unsuccessful it will try MMC0 (uSD), followed by UART and USB 
(obviously
it breaks out of this sequence if the data is valid).

With the uSD_BOOT button depressed, SYSBOOT[4:0] is 11000, changing the 
sequence
to: SPI1, MMC0,  USB, UART0

Notice that if we hold the uSB-BOOT button down but do not have a uSD 
card installed,
that will cause the MMC0 boot to fail, allowing it to sequence through 
the last two
attempts: USB then UART0.

This is the same UART as the debug header (those BeagleBone Black 
designers did good!).
That means we can attempt to boot from UART by simply holding down 
theuSB-BOOT button
with no uSD card installed and then resetting the board.

There are a couple of reasons why this could turn out to be handy:
1. no wear and tear on the uSD card hardware
2. since the ROM bootloader is already using the UART, we *may* be able 
to assume that
     the uart is already initialized; hence in the first few lines of 
our test bootcode we can do
     the equivalent of a putchar('!') to indicate a successful load.

Getting this far would prove that we actually understand the boot image 
format described
in section 26.1.9 of the TRM.  That would be a good start.


> Refer to chapter 26 of this document (AM335x TRM):
> http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
> for more detail on the booting process of the chip.
>
> Depending on how hard it is to reconfigure the SYSBOOT pins, it may be
> simpler to initially try to boot this off the UART.  Then once that 
> works,
> its likely that it would easily transition over to the uSD card. I 
> suggest
> this only to eliminate the need for 'dd' and burning the uSD card till we
> get it right.
>
> Gotta learn about the format of this initial image pulled into the 
> device.
>> It looks like the internal ROM-based bootloader looks for a secondary
>> program loader (SPL) that initializes the necessary devices to
>> continue the boot process and pass control to a third-stage
>> bootloader.  So now I believe it's a matter of finding whether there
>> are existing code implementations of this SPL, or last-case scenario
>> this would have to be implemented.  Time for more investigating. :)
>>
>> On Thu, Mar 26, 2015 at 9:27 AM, Jarielle Catbagan
>> <jcatbagan93 at gmail.com> wrote:
>>> To put things into context in regards to the conversation that I was
>>> having with Ed, Dr. Joel, and Gedare:
>>>
>>> I am currently in the process of looking into porting MicroMonitor to
>>> the Beaglebone Black.  As indicated by Ed, "[t]he difficulty of the
>>> port will depend on how much existing CPU-initialization
>>> (clocks, cache, etc..) code we can reuse."
>>>
>>> Ed has also indicated to me that there might be an internal bootloader
>>> stored in a ROM-based memory that might look for an image in a
>>> specific format.  I will definitely be investigating more into this.
>>> I did manage to briefly browse through the Beaglebone Black System
>>> Reference Manual Rev C.1 [1], and I have found that the boot
>>> configuration/process is briefly elaborated in section 6.7. For
>>> convenience, since it's a short section I will post it here:
>>>
>>> "The design supports two groups of boot options on the board. The user
>>> can switch between these modes via the Boot button. The primary boot
>>> source is the onboard eMMC device. By holding the Boot button, the
>>> user can force the board to boot from the microSD slot. This enables
>>> the eMMC to be overwritten when needed or to just boot an alternate
>>> image...
>>>
>>> [T]the processor-external boot code is composed of two stages. After
>>> the primary boot code in the processor ROM passes control, a secondary
>>> stage (secondary program loader -- "SPL" or "MLO") takes over. The SPL
>>> stage initializes only the required devices to continue the boot
>>> process, and then control is transferred to the third stage "U-boot".
>>> Based on the settings of the boot pins, the ROM knows where to go and
>>> get the SPL and UBoot code. In the case of the BeagleBone Black, that
>>> is either eMMC or microSD based on the position of the boot switch."
>>>
>>> I was kindly guided to look into programming a uSD card as it might be
>>> more efficient to run MicroMonitor off of the uSD for quick testing
>>> after every build.  If all goes well, either an application image will
>>> be located and booted off of the same SD card or via a network boot.
>>> For serial debugging I have an FTDI 3.3V USB-to-Serial cable that I
>>> have been previously using to access the U-boot monitor on the
>>> Beaglebone Black.
>>>
>>>
>>> [1] 
>>> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>


-- 
Ed Sutter
Alcatel-Lucent Technologies -- Bell Laboratories
Phone: 908-582-2351
Email: ed.sutter at alcatel-lucent.com