On Thu, Mar 18, 2021 at 8:25 PM Adam Ford aford173@gmail.com wrote:
The arch/arm/mach-omap2/omap3/clock.c is being forced to compile with an ARM target even when thumb2 is the preferred target. The note in the makefile states it's due to a bootup issue with OMAP35.
Since Thumb2 can help reduce code size, I thought I'd run some tests.
The DM3730 can boot with clock.c built for Thumb2, but I can confirm that omap3530 still fails. Instead of tuning the entire file for ARM, I thought I might try to identify which function needs to be compiled for ARM.
I was able to confirm that the AM3517 EVM can boot with thumb2
I was able to set the target attribute for prcm_init() to build for ARM while compiling the rest of the file for Thumb, and the OMAP3530 was able to successfully boot. Unfortunately, doing that broke the DM3730.
I started looking at the differences between the OM36xx and OM34xx inside prcm_init() it appears as if there are a bunch of static functions that are unique to either omap34 or omap36, but they are not drastically different except for one area where some math is done to a pointer on the OMAP35 and not on the OMAP36/DM7.
/* Moving to the right sysclk and ES rev base */ ptr = ptr + (3 * clk_index) + sil_index;
I could be nothing, but I am not well versed in Thumb2 assembly. If someone has any suggestions to try, it would be nice to be able to let the file be built for Thumb2 for both OMAP35 and OMAP36/DM37.
Because I could confirm the AM3517 can boot with thumb2, I think my original theory is out. My next theory is that there are some timing constraints that need to be considered. I tried to make a bunch of functions static, since they are only used in that same C file, but depending the platforms (DM37 or OMAP35) stuff may break.
Part of me wants to create new targets like OMAP36XX and AM35XX similar to what we have for OMAP34XX and set them accordingly then use those flags to set the arm/thumb target in the makefile for this.
adam
adam