I should clarify that the terms SPL and MLO seem to be used
interchangeably. So I guess it's pretty much a matter of figuring out
where the internal ROM-based bootloader exactly transfers the "second
stage" bootloader from (i.e. location in memory) and to what location
in the internal SRAM to do the basic initializations.
Yep, I think "SPL" is uboot language and "MLO" is TI language; both
apparently
referring to the initial image that is pulled into the Sitara's internal
RAM at 0x402f0400
(section 26.1.3.2).
Once I can find
the sources of the SPL implementation this might be used for reference
as the functionality is originally integrated with U-boot and probably
can't be used (note: not a license expert, please correct me if I am
wrong) since it is licensed under GPLv2.
>From what I read very briefly, the AM335x internal SRAM seems to have
limited memory so "second stage" bootloader might only have basic
functionality to do basic initialization (perhaps like UART) and then
locating and transferring the real bootloader. I'll be verifying
this.
According to the TRM, this is about 100K of space. You can do a lot
with 100K!
At the time of this message, I have a little over 22 hours to finish
my proposal before the deadline. So far it has been adjusted to
reflect that the effort is to port MicroMonitor to the Beaglebone
Black in the most general sense. I am still lacking a bit of
specifics. Any advice on what can constitute as something that I
should do for this project as well as any ways I can perhaps improve
my proposal?
Couple of thoughts (just my own shots from the hip here, and certainly
subject to
disapproval by RTEMS maintainers)...
- Consider this a project that is more than just a port of Micromonitor
(aka uMon) to
beaglebone. That should be the first step. Once completed, then you
look at how
RTEMS can use the uMon API. This implies that the work isn't done
when the
micromonitor port is complete, you just move to the next phase.
- The RTEMS and uMon know about each other, the better they co-exist in
a smaller
memory constrained system (like Cortex-M3/4).
-
Here is the link to my proposal:
https://docs.google.com/document/d/1pGQ60e5A4JcXl9_gkBEutIgb6AhiQ00MPJN6J1rSKT8/edit#
Thank you!
On Thu, Mar 26, 2015 at 1:08 PM, Jarielle Catbagan
<jcatbaga...@gmail.com> wrote:
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
--
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
