I'll definitely check out the AM335x TRM. Referring to this link (http://beagleboard.org/project/U-Boot+%28V1%29/), it briefly elaborates that the U-boot on the Beaglebone consists of two phases. First phase consists of the SPL which is transferred from eMMC or uSD (depending on boot switch) and must be in a specific format and location before being transferred to the internal SRAM of the AM335x. This SPL is really a file that is part of the U-boot secondary program loader functionality, which for now I am assuming is built along side when U-boot is built. This SPL performs initialization which includes initializing the off-chip memory, which in the case of the Beaglebone Black would be the DDR3 RAM. Once external RAM is initialized, main U-boot bootloader image is transferred to there.
I also found this thread in the U-boot mailing list: http://lists.denx.de/pipermail/u-boot/2013-December/168433.html Currently in the process of reading through it but for the most part I understand it to be focusing on where the sources of the SPL implementation can be found. On Thu, Mar 26, 2015 at 12:09 PM, Ed Sutter <ed.sut...@alcatel-lucent.com> wrote: > 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 >> <jcatbaga...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Ed Sutter > Alcatel-Lucent Technologies -- Bell Laboratories > Phone: 908-582-2351 > Email: ed.sut...@alcatel-lucent.com > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
