Good morning (where I am anyway),
Yeah it is definitely a dated part; it turns out the actual part is an OMAP2530, but it is effectively the same as the 2430 (not sure what the difference is but from a Linux perspective the 2430 works). As I mentioned, the product has been around for a while (i.e., mid-2009) with a mature application (both ARM and DSP) that runs on Linux (2.6.28-omap1). The company is moving forward with a new iteration of hardware that is still based on the 2530 (not sure why honestly) and they have requirements of BT and Wifi among other things. Instead of trying to back port that functionality I thought it would be better to upgrade the kernel to mainline LTS. In so doing I *have* noticed that the OMAP2xxx has some holes in the mainline, and I just figured that not many people use this part any more so regression testing of drivers has not been great. I have been able to get past everything else (e.g., RFBI missing from mainline DISPC, USB DMA not working, device-tree mistakes on USB, etc.).
I am extremely grateful for this mailing list and people willing to respond to my question; thank you! It turns out this particular problem was a bone-headed mistake on my part when porting the old DSP driver; previously there were calls to omap_readl() and omap_writel() to generically read or write some peripheral registers — these no longer exist in the mainline so I had to ioremap the base of SYSC and PRCM. I then created #define’s for some registers. The original driver referenced the initialization from a GEL file (code-composer studio) similar to what Richard had suggested. It turns out my #defines were off so the calls to reset the DSP were incorrect.
In the event anyone is interested, the sequence that works is:
/* Configure boot mode 0 and boot address at the beginning of SDRAM */
write_sysc_reg(e, SYSC_OCP1_IVA2_BOOTADDR, DSP_VADDR_START);
write_sysc_reg(e, SYSC_OCP1_IVA2_BOOTMOD, 0x0);
/* Release L3S reset and perhaps power-on reset (clear bit 1) at the same time */
write_prcm_reg(e, PRCM_RM_RSTCTRL_DSP, 0x1);
This allowed me to initialize the DSP MMU, then download the DSP binary via request firmware, followed by:
/* Release DSP from reset */
write_prcm_reg(e, PRCM_RM_RSTCTRL_DSP, 0x0);
val = read_prcm_reg(e, PRCM_CM_IDLEST_DSP);
if (val & 1) {
dev_info(dev, "DSP is active\n");
} else {
dev_info(dev, "DSP is NOT active\n");
}
Again, thank you for your quick responses; very appreciated. I intend on submitting some patches in the near future to address some of the previously mentioned 2430-holes, especially affecting the USB.
Regards,
Dave
> On Jun 8, 2021, at 11:20 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>
> Hi,
>
> * Woodruff, Richard <r-woodruff2@xxxxxx> [210607 15:40]:
>> Guess: this bit in JTAG script used for IVA tests probably is missing and needs to be worked in. The generic linux-omap clock code probably handles the IVA clock but maybe not the resets.
>>
>> /* Enable IVA-ss functional clock (set bit 0) */
>> (*(int*)0x49006800) |= 0x1;
>>
>> /* Release l3s_idle_req */
>> (*(int*)0x49006810) |= (1 << 1);
>>
>> /* Release L3S reset and power-on reset (clear bit 1) at the same time */
>> (*(int*)0x49006850) &= ~(( 1 << 1));
>
> Heh and I thought nobody is using 2430 any longer :)
>
> FYI, the current mainline kernel actually can deal with all that using
> reset driver and genpd, see for example commits:
>
> ae57d1558908 ("ARM: dts: Configure interconnect target module for dra7 iva")
> effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva")
>
> Similar setup should also work for 2430 but needs the power domains
> configured for drivers/soc/ti/omap_prm.c at least for iva.
>
> David, I think what you're seeing is iva getting released from reset with
> an unconfigured MMU, and then the system will hang.
>
> Regards,
>
> Tony
