GSOC 2015: Porting MicroMonitor to the Beaglebone Black

[Ed Sutter]

On 3/26/2015 2:18 PM, Joel Sherrill wrote:
> On 03/26/2015 11:35 AM, Jarielle Catbagan wrote:
>> 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. :)
>>
> My off the top of my head recommendation is to document the
> sequence the BB goes through during initialization. Then
> start with a goal of replacing U-Boot in that sequence with
> Micromonitor. This keeps us in the world of at least documented
> with code. However U-Boot has to be formatted, linked, etc.
> is exactly what you will have to do with your Micromonitor.
>
> U-Boot can be a reference but not a source of code.
>
> The previous stages may be able to be replaced later but
> I wouldn't worry about that now.
>> 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 and the authors of the RTEMS code would have to agree but,
> in principle, anything in the Beagle BSP should be fair game for
> reuse in Micromonitor.
Anything that is compatible with Apache works for me.
One of my action items is to transfer the Micromonitor code to github
but do whatever is necessary to make it Apache compliant.
>>> 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.
>>>
> This is how we do a lot of our testing. It isn't worth the effort
> to put something on the board itself. Plus it places wear and
> tear on a replaceable item, not on the built-in flash.
Just keep in mind that we're trying to boot the *RAW* image here, so 
unless I
misunderstand the text above, you have to think lower level now. The 
only thing
between the bootcode we provide and the bare board is the ROM code in 
the Sitara.
>>> [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