TDA4VEN-Q1: Cold Boot Optimisation Documentation

Hi Thomas,

https://www.ti.com/lit/pdf/sprad09

The above is a good starting point on boot time optimization. 

If you are following Linux SPL based boot flow you can start R5 SPL directly loading Linux to cut down on the additional time spent on a53 uboot and SPL phase.

Best Regards,

Keerthy 

Hi Keerthy,

So that's quite slow compared to the AM62P, I also need to boot into a fully initialised DRM display, is there any documentation which can help me with that in the quickest possible speed?

Thanks

Tom

Thomas,

https://www.ti.com/lit/an/sprade5/sprade5.pdf

The above is an even more detailed app note that shows the fastest way to boot and get to optimized surround view.
R5 SBL can load Linux and MCU2_0(that initialized display). Do you want Linux to own/control the display?

What is the expectation on time?

- Keerthy

Hi Keerthy,

So we have a requirement on us of time to boot, and be displaying a live display with a linux app within 2-3 seconds.

Happy to share more information via email as that'll be easier?

Thanks

Tom

Hello Thomas,

https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/09_02_01_09/exports/docs/system/Demo_User_Guides/Display_Cluster_User_Guide.html

Usually in the case of ADAS applications for J7 SoCs the display is owned by FreeRTOS running on MCU2_0. That makes the display come up faster.
Is that acceptable?

- Keerthy

Hi Keerthy,

For boot up that would be acceptable but not for runtime, we'd need the MCU to run another application rather than being taken up by the display.

This isn't a traditional ADAS application, again more details can be provided via email.

Thanks

Tom

Hi Thomas,

There is an application note for AM62P which uses the same display architecture as TDA4VEN where we use the SPL/U-Boot running on the A53 core to achieve a splash screen under a second from PORz: https://www.ti.com/lit/an/spradk8/spradk8.pdf?ts=1787340018702

Let me know if this works as reference for your usecase. The splash screen under a certain amount of time is the most common usecase we see, since that allows some time for the main applications to start running in the background before display control being handed off.

Otherwise, apply the techniques for booting up Linux quickly in general, noted in the application note that Keerthy shared in his previous response. In addition to his previous link, there is also this user guide for boot time optimization for AM62P which the techniques should apply to TDA4VEN as well: https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/12_01_00_05_03/exports/docs/linux/How_to_Guides/Target/How_to_boot_quickly.html 

^ This one may be more fitting for your usecase since TDA4VEN is more similar to AM62P than DRA821. But techniques used for DRA821 has overlap with the techniques discussed for AM62P, which would be applicable to TDA4VEN.

Regards,

Takuma

Hi Takuma,

Thank you for the pointers, I managed to get it to 5 seconds from cold boot to linux displaying the app via DRM. However, that isn't quite where we need it to be.

We also need to do a fast ethernet load on the R5 core before handing the ethernet over to linux when it's finished loading it's driver. Any advice for any of those items?

Could it be worth arranging a call to run through possible optimisations and solutions?

Thanks

Tom

Hi Thomas,

I am not too well versed with the ethernet side, so looped in a colleague who is an expert. But from what I have seen other developers do, they create a virtual client in Linux that interfaces with the ethernet driver running on the R5F like in this document: https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/ethfw/docs/user_guide/ethfw_c_ug_top.html. 

Would this work for your purpose?

Otherwise, getting it down from 5 seconds is going to be an iteration of performance benchmarking, then optimization. That is, you would need to answer where the 5 seconds is coming from, and to answer this, you will either need expensive hardware (such as a Lauterbach), or some software development to put in "timestamps" to see where the boot is taking most amount of time (and by timestamp, it could be logs which may add some boot time, and/or the GPIO method). The details for the second method using software to profile is in the previously shared documentation: https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/12_01_00_05_03/exports/docs/linux/How_to_Guides/Target/How_to_boot_quickly.html

But how many of the optimization in the shared doc were implemented, and do you have timestamps for how long it took in each part of the boot?

Regards,

Takuma

Hi Thomas,

What are the requirements for ethernet on A53 Linux cores and on the R5 cores?

As Takuma said, we have a ethfw solution which allows for multicore utilization of CPSW switch. Please see the ethfw user guide for more details on this: https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j722s/11_02_00_11/exports/docs/mcu_plus_sdk_j722s_11_02_00_18/source/networking/ethfw/docs/user_guide/ethfw_c_ug_top.html

We do not have a readymade solution where we can handover the ethernet controller from R5 to A72 during a boot.

Regards,
Tanmay

Hi Takuma,

Perfect, thanks! It comes down to reliability and speed, if ethernet can run for 48 hours with no issues and high throughput and allow linux to boot within 2-3 seconds and display live data within that time too or as close to that time then that is all we care about.

So that 5 seconds is implementing DSS share and Falcon boot together, there is some time left on the table from the usage of an SD card and reducing what is enabled at start up. I'll be using the GPIO method of measuring soon, I need to dive through the schematics of the board to get the output from the regulator so I can remove the USB negotiation from the boot time measurement.

I'm still going through the document (I had done this on the AM62P so it is not too bad to port over) but what actual times have you guys seen on the devboard for the TDA4VEN?

Thanks

Tom 

Hi Tanmay,

So as long as the ethernet can run for 48 hours with no issues and high throughput and allow linux to boot within 2-3 seconds and display live data within that time too or as close to that time then that is all we care about.

It'll need to communicate primarily from 4 wire ethernet before we then will need to implement 2 wire automotive ethernet on following feature building.

I'm absolutely not expecting a readymade solution here, but I've got some tight deadlines to work to and therefore reaching out for whatever help and advice we can get.

Thanks

Tom

Hi Thomas,

Thomas Carr said:

what actual times have you guys seen on the devboard for the TDA4VEN?

I don't think we have measurements for TDA4VEN, but architecturally, TDA4VEN is similar to AM62P - they actually share a common device tree. Main difference is TDA4VEN has the SerDes, and high speed interconnects that use the SerDes. 

So, I would expect times to be similar to AM62P. 5 seconds from just DSS share and Falcon boot sounds quite promising. Other things that I am not sure if you have done already would be:

• Adding "quiet" to the kernel args to suppress logs
• Smaller kernel (i.e., taking out kernel drivers for parts of the SoC not used to reduce driver initialization time)
• Tiny initramfs to reduce filesystem loading
• Boot media. In general, SD card is slower than eMMC. And eMMC is slower than OSPI. 

Regards,

Takuma