I had hoped to find a document or an FAQ covering this topic. But it’s a fairly straight-forward question. Once you’ve gotten some logic that you are happy with working in the Cortex R5 processors and/or PRUs, how do you configure the TDA4VM to launch that logic at powerup without being manually loaded from Linux?
Specifically what I’m hoping to accomplish is to have the system powerup and be “ready for action” within milliseconds of being powered. I understand that the application code running in the A72’s is not going to be available for many seconds after powerup since the Linux kernel and a good bit of foundational logic must launch before application code can launch. But I’d like to know that I can get a tiny firmware application in at least one of the Cortex R5F cores and the PRUs loaded-n-running as quickly as possible after powerup…preferably in under 10ms.
For the purposes of this discussion, assume I have fully compiled & linked executable BINs of my code (one for the R5Fs, and one for each of the PRUs I plan to use). I just need the logic within those BINs loaded and called as part of powerup into their respective target processors. I have to believe there’s a document somewhere that details the procedure for setting this up.
There may be some race conditions with pin muxing that will have to be figured out and possibly some of that muxing may need to be done by the code launched in the R5s.
I have no doubt there’s more ignorance on display as part of this post than just my questions. So I’m looking for any starting points people can point me to.
In theory you might get close, depending on your definition of within milliseconds. I would imagine the POR for the chip will probably be in the 10’s of ms though. The ROM bootloader then runs and fetches the SBL from eMMC into the MCU R5.
The SBL will then load the various cores, configure memory and PLL’s etc.
I don’t think I have ever seen any timings in the documentation for boot times.
You will have to download the TI SDK for the chip and the datasheet for the MPU.
If you download the SDK there is some documentation and example code for the SBL, which is loaded into the MCU R5 core at power on. The bootloader example gives examples of loading R5/DSP cores, but no mention of the PRU’s, but should also be possible. The examples are written for the TI development board, but should not be too hard to get working on the BBAI64. They use different serial ports in the code, so you will need to tweak some lines of code. The DRAM setup might need different timings.
I am guessing the BBAI64 is using a version of this SBL to load and run uboot on one of the main cores. I don’t think it is being directly run on the MCU R5, but I could be wrong, Perhaps @RobertCNelson could comment on that.
The docs talk about SBL multicore boot images, so it may be possible to use this to load both uboot and the various cores. No idea how memory is setup for such cases though.
There is also a bit of TI firmware that is loaded into the MCU R5 core at power up.
The documentation while helpful, stops short of being a complete answer. The code is a massive tree of various drivers and while building under Linux was not too bad, trying to understand and bring together all of the parts is not a simple task.
Ok, this is sounding somewhat familiar with my experience and understanding with the Sitara AM335x where the ROM bootloader launches the processor enough to read an MLO file from eMMC. That configures a bunch of things including DDR timings and eventually launches uboot once DDR is available.
It sounds like a similar thing happens here. However I’m not sure I’m fully understanding things yet. So here are some questions that will hopefully clarify this:
In your explanation, is SBL similar to the AM335x MLO? Or is MLO still in the mix and SBL a new layer of abstraction in the boot process I’ll need to learn and make peace with?
I also couldn’t tell if the execution of the ROM bootloader is literally executing on the R-core(s) or if all ROM bootloading is done by the A72s and from there, the R-cores and other peripherals are configured and launched? I could see either being possible hence my confusion and request for clarification.
Use of the PRUs is also a cumbersome detail since they are there, but none of the TI documentation will acknowledge their presence for some unknown reason. So knowing what pinmux modes are used AND what peripherals are sacrificed when using certain pins for the PRUs is difficult to figure out. I remember even the AM335x was complicated enough that I used some TI pin-muxing program to figure out what combination of peripherals I could successfully get to be active simultaneously. My guess is TI has a similar program for this chip, but it likely isn’t going to acknowledge the presence of PRUs either. So it’ll have to be done the hard way. That said, Is this processor similar enough to another TI processor with PRU_ICSSGs that the mux-chart can be referenced from another processor’s Tech Docs? Or is there a hand-filled version of the TDA4VM’s pinmux mode chart floating around here that might help? I’d take an early revision of the TDA4VM’s tech doc that still had the PRUs mentioned or even the original XJ721E (superset prototype) tech doc. As I’m typing this, I’m wondering if this shouldn’t be a topic on its own.
And yes, I did and still do all my AM335x development on a dedicated Ubuntu VM. I remember dealing with the MLO and U-boot not being a lot of fun. But once we (my company) got it figured out, it’s been working fine and are actively developing on it today. We occasionally have to revisit the MLO each time our RAM supplier re-spins their die and thus changes DDR timing values or out-right discontinues our skew forcing us to find an alternative vendor which has happened a few times over the years. But that Sitara line is long in the tooth and investigations into “what’s next” is overdue. So I’m bringing myself up to speed on both the TDA4VM and AM5729 in hopes that what I learn will be useful for selecting our successor. Since one of our #1 complaints has been boot times on the AM335x, I’m trying to investigate microprocessors that have both application cores and real-time cores so we can return the core functionality of our product to an RTOS (where it was prior to our use of the AM335x) and relegate the A-series cores running Linux to managing the “WebUI” and coordinating configuration changes. That’ll be some pretty major restructuring, but to get better power-up responsiveness, it is going to be necessary.
So a lot of this investigation is to confirm that the TI Multi-series ARM microprocessors are actually capable of this and find examples of people using them in these ways as a proof of concept and possibly a launching pad for prototyping. We used the BB White and Black as our early development boards when we were developing our current product offerings. It made sense to come back here for this effort since R-Pi is not even close to having the peripheral mix we need.
The ROM code runs at boot, reads the SBL from hardware (depending on boot pins) into the internal MCU R5 static ram and then executes it. This can run in lockstep mode if required. The executable image needs to be wrapped in a header.
What happens next depends on the SBL code. In practice on the BBAI64, I don’t know if this is actually uboot, or the SBL is loading uboot. In theory the SBL can be anything that fits into approximately 768k and do what ever you want.
The last time I did a custom BBB image, I flashed uboot directly to the eMMC and it was booted in raw mode. No FAT partition, no MLO.
There is a downloadable utility ( SYSCONFIG ) to setup pin muxing and clocks. There is also a cloud version which requires you to setup an account with TI Cloud SYSCONFIG. No idea what the output is from these utilities.
I put together a spreadsheet with the various pin muxings on the header connectors PinMux Spreadsheet I think just about every pin on the connectors can be connected to one of the PRU’s if required.
At the very least you should download the PROCESSOR-SDK-RTOS-J721E There is a lot of documentation there and code examples, plus low level drivers. There is a section on the SBL with example code to load and run baremetal stuff.
I am interesting in running code on the MCU R5, but other than the SBL, that is not explained. I assume I would have to load the code into DDR and then jump there after the SBL code has executed. At the moment I don’t really have enough spare time to delve into it in the detail required.
I have got as far as compiling the SBL example code, modifying the debug UART to the MCU UART on mikroBUS header and output some text, but not to actually boot anything as yet. I have also built a custom cape with 6 CAN bus interfaces as the code to run in the MCU R5 needs at least 6 CAN buses. Maybe over Christmas I will get some free time to investigate things further.
So the SBL is executable suggesting it cannot be shared between A-series and R-series cores. So how is an SBL intended for the A-cores and SBL intended for the R-cores differentiated?
I keep reading “lockstep mode” but I haven’t quite worked out exactly when this is needed/necessary to know if it is a detail I should concern myself with. But it sounds like you are confirming that there’s a ROM bootloader for both the A-cores and R-cores. What I’m not clear on yet is whether they both make use of the same SBL or if they each have their own. I think seeing an example of both being launched will make sense when I get ready to NEED to know this.
Not surprising, but I think I need more understanding of the SBL before this will fully make sense.
On the AM335x, we didn’t have but 35k or something ridiculously small like that for the MLO to load into. So this limited how much we could do in the MLO. IIRC, we inherited as much of the MLO code as we could and found we only had about 10k of space to add what we needed. Now perhaps some digging could’ve found more room, but we didn’t want to take that time if we could work with what we had. Good to know the newer MPUs have a bit more internal RAM to work with.
Fascinating. I didn’t realize that was an option. I thought the ROM bootloader expected the “Partition 1” of eMMC to be FAT32 and was hard coded to look for an MLO there. I guess there’s another eMMC boot option in the ROM bootloader I’m not familiar with that allows for this. Or is this mode something similar to executing out of raw NAND?
I have a TI account so I logged into the Cloud version and sure enough, that version exposes the PRUs and allows you to click on them and see the PINs it will consume.
Downloaded and looked at it. This is very familiar to what I remember having to parse over when working with the AM335x way back.
Done. Will pour over this as I get the time. Thanks for pointing me there. I had not found that page on my own.
If/when you do, bump this thread to let me know what you came up with. But otherwise, it is sounding like what I am looking for is possible in these MPUs. TBO, the TDA4VM is way out of our budget, but a MPU similar to what the BBAI uses is probably closer to realistic for us. But I just wanted an excuse to buy and work with the BBAI-64, so I’m sticking with it for the time being.
I’d never heard of mikroBUS. Had to google-it to figure it out. That does bring up a good point, when debugging in the R5s, do you have to dedicate a UART for “system out” messages? Or can they be fed through the USB back to a monitoring PC?
What code is this? What are you working on that needs 6-CANbus networks operating simultaneously? 6 different devices or just something that requires the bandwidth of 6 networks?
As far as I can tell the SBL only runs on the MCU R5.
from the PDK docs
Bootloader Execution Sequence
Power On Reset
ROM Bootloader (RBL)
Software pre-programmed in Jacinto ROM memory starts executing
The RBL performs platform configuration and initialization.
It then checks sysboot pins and chooses booting device
The RBL then configures PLL and clock settings for R5, and boot media like eMMC, SD/MMC, OSPI, UART, PCIe, Ethernet etc for reliable boot.
If no valid bootloader found on booting device, the RBL checks for next booting device, based on sysboot pins
It then gets image size and load address by checking the X.509 certificate that is part of the bootloader image.
The RBL then verifies, optionally decrypts and loads the binary to internal memory at the load address specified in the X.509 certificate.
Finally it resets the R5 and passes control to Secondary Bootloader(SBL) running on the R5.
Secondary bootloader(SBL)
User level secondary bootloader(SBL) begins execution from internal memory. It enables ATCM, starts PMU timers for profiling, initializes the MCU, and sets up the stack, heap and globals. It then jumps to main().
Board Initialization is done by calls to Board_init() API.For additional details refer Processor SDK Board Support.
The RAT is setup. Pin MUX and UART console are setup by calling Board_init() API. The system firmware (SYSFW or TIFS) is then loaded from the boot media into the DMSC subsystem.
Once the system firmware is up and running, the rest of the initialization can be done.
This includes optionally using Board_init() to configure PLLs, LPSCs and DDR.
The SBL then loads the application from the boot media. If the image is signed, the application will be copied into a user specified reserved memory, and the SBL will attempt to verify the image by calling system firmware APIs. On HS devices, the boot proceeds only if image verification passes.
The SBL parses application image(s) for each of the core(s) from boot media and scatter loads it to memory.
Once the application is loaded, the SBL communicates with the system firmware to setup the clocks for the core(s) and release it from reset.
The core then starts executing from application entry point.
Great Information. That is not at all what I would’ve expected as a boot sequence that standing up the platform starts with the R-core(s), not the A-cores. Very good to know.
I just downloaded & installed the SYSCONFIG for offline use. It looks identical to the Cloud-based version.
And yes, they BOTH display the PRU peripherals on these parts.
Note the device-entry is:
J721E_DRA829_TDA4VM_AM752x
What’s odd is the Sitara AM752x reference, which doesn’t to appear to have ever been released. In fact, I can’t find AM7x anything on the TI website. But no matter, as long as the PRUs are listed and actually exist and are functional on all TDA4VM MPUs (not just the ones on BBAI64s).
I couldn’t find the PDK he was referring to searching directly on the TI website. I guess my searching prowess is not that good on their site.
But Google found it: PDK-Jacinto Users Guide>5.2. J721E SBL
Lots of good stuff in there, but one of the things I find odd is the lack of an Ethernet Boot (i.e. BOOTP/TFTP) Boot Mode. We use that extensively on our AM335x based products to boot into boards then direct uboot to continue to NFS-launch them to a Linux terminal to gain access to the board’s flash when a board has bricked itself for some reason and we are asked to do postmortems. Although reading through the Technical Reference Manual 4.3.10 and 4.6.7 (for some reason called spruil1c.pdf), there does seem to still be an Ethernet Boot mode.
How does one keep up with the TI Doc releases? I have been looking at a PDK version that is 2 revs back from this release.
With so much info to sort through, it would be good to be looking at the most current stuff.
EDIT: This is crazy. I was looking at PDK 07_00_00, Chris linked to PDK 07_03_00, this morning, I just found there is a PDK 08_02_00. Is there some top level link for this PDK Doc so we can ensure we are looking at the most recent one?
Thanks for including the link here. I did find that link, like I said, googling helped me locate it. And from there, I eventually got to that zip.
As for how to keep up with files as they change, I doubt TI has a “subscribe to changes” mechanism. My guess is most people use the documentation, get what they need done, and then do their best to never look at that documentation again until they need to design something else. So there’s likely just very little demand for that mechanism…in part thanks to forums like this and TI’s e2e.
Anyway, as it relates to this topic, I marked one of the earlier responses as the solution…with supporting info to follow deeper in the thread. I do have other questions, but I’ll post them as separate threads.