Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
Right... I'm catching up on this CPU, I've done a bit more of this on the iMX6, but it appears to be quite similar... Referring to the schematic here: https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf?raw=true When the CPU first starts out of a cold reset, it will execute code that is internal to the Sitara chip, totally independent of what memory devices are tied to it. It will initially look at some of its GPIO pins (configured via pullups on pg 6) to determine how it is supposed to attempt to access external devices to pull in the initial image you're referring to. Note that the boot-mode button (pg 6) simply allows the user to select either eMMC or uSD; however there are other modes by which the CPU can boot. Based on the table on pg 6, apparently this device (as is typical) can boot from UART, USB or SPI flash as well as the eMMC/uSD it is currently configured for. For example, a few years ago I worked on a Blackfin based board that only had SPI flash and DRAM. We had a jumper on the board (similar to the button on pg 6) that we could set so that upon reset, the boot mode was Boot-from-UART. Then I was able to simply use a terminal emulator to push down an initial set of images (in an expected format documented for the Blackfin) that eventually loaded a real boot image into the SPI flash. Its very likely that this will be the same case, just using eMMC and uSD as the boot sources instead. The important thing to realize here is that the CPU is booting up initially with built-in code, and then it looks at some pins to figure out how the actual hardware design is configured to boot the next stage. Good stuff! Ed 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 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
Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
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 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
Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
__ 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
Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
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 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@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
Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
On 3/26/2015 2:22 PM, Gedare Bloom wrote: On Thu, Mar 26, 2015 at 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 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. Yeah you have to get explicit permission, the RTEMS license is not compatible to the Micromonitor one in that direction. Keep in mind we're referring to Apache license for Micromonitor now, so as far as I know (keep in mind I am by no means a license guru), RTEMS and Micromonitor can play together. Right? 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. [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 -- -- Joel Sherrill Ask me about RTEMS: a free RTOS Support and Training Available ___ 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 -- 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
Re: GSOC 2015: Porting MicroMonitor to the Beaglebone Black
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 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 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 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-b
