snagrecover: am6x: Support J721e platforms

[RomainNaour]

Support the J721e/DRA829/TDA4VM SoC family.

Its recovery flow is almost identical to the typical AM6x flow, the only major difference being an additional "sysfw.bin" binary firmware needed for "Split binary with a split firmware" boot flow [1] (like the AM654). Update send_tiboot3() accordingly to download "sysfw.bin" after "tiboot3.bin".

Add a new snagrecover template with all four binaries: tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img.

Use USB Vendor ID and Product ID from the TDA4VM TRM in Table 4-66 USB Boot Parameter Table [2]:

Vendor ID = 0x451
Product ID = 0x6163

But latter in 4.6.8.1.1 DFU Device Mode chapter the Product ID is the same as the am65 SoC (0x6162). This is likely a typo since Product ID 0x6163 is the one used by u-boot for the J721e EVM board [3].

Add Product ID 0x6163 to the TI rules list.

Tested on SK-TDA4VM [4] board using its usb-c port by setting SW1 switch in USB boot mode, see the user manual [5].

[1] https://docs.u-boot.org/en/latest/board/ti/k3.html#boot-flow-variations
[2] https://www.ti.com/lit/zip/spruil1
[3] https://source.denx.de/u-boot/u-boot/-/blob/v2026.01/configs/j721e_evm_r5_defconfig#L177
[4] https://www.ti.com/tool/SK-TDA4VM
[5] https://www.ti.com/lit/pdf/SPRUJ21

[RomainNaour]

I checked other (newer) TI SoC about their "Product ID" value... and it's a mess.

Every time we have to double check the "Product ID" really used in u-boot. We can also check the CTRLMMR_USB_DEVICE_ID register reset value.

Here is my draft for other TI SoC (I reordered some lines, removed the "am654x" since it use the wrong device ID)

"am6x": {
	# K3 AM62x
	"am623": "0451:6165",
	"am625": "0451:6165",
	# K3 AM62a
	"am62a7": "0451:6165",
	# K3 AM62d
	"am62d2": "0451:6165",
	# K3 AM62p
	"am62p": "0451:6165",
	# K3 AM64xx
	"am6411": "0451:6165",
	"am6412": "0451:6165",
	"am6421": "0451:6165",
	"am6422": "0451:6165",
	"am6441": "0451:6165",
	"am6442": "0451:6165",
	# K3 AM654x
	"am6548": "0451:6162",
	"am6546": "0451:6162",
	# K3 J7200/DRA821
	"j7200": "0451:6164",
	# K3 J721e/DRA829/TDA4VM/AM68p
	"j721e": "0451:6163",
	# K3 J722S/TDA4VEN/TDA4AEN/AM67
	"am67": "0451:6165",
	# K3 J721S2/TDA4VE/TDA4AL/TDA4VL/AM68
	"am68": "0451:6168",
	# K3 J784S4/AM69x/TDA4VH/TDA4AH/TDA4VP/TDA4AP
	"am69": "0451:6168",
},

About SoC family naming "am6x", It should be "K3" to include other TI SoC using "K3 Multicore SoC architecture platform". Indeed not all TI SoC are named "AM6x": DRA829, DRA821, TDA4VM...

For the J721e, the "AM68p" variant doesn't really exist (it appear only in the TRM). It should not be confused with the "real" AM68 that is a "J721S2" SoC.

Do you really want a exhaustive list of SoC or can we use their "generic" names ? or have all variant name?

	# K3 J722S/TDA4VEN/TDA4AEN/AM67
	"j722s": "0451:6165",
	"tda4ven": "0451:6165",
	"tda4aen": "0451:6165",
	"am67": "0451:6165",

[rgantois]

Hi, thanks a lot for the contribution! Looks good to me, aside from a small nitpick which I've mentionned

[rgantois]

About SoC family naming "am6x", It should be "K3" to include other TI SoC using "K3 Multicore SoC architecture platform". Indeed not all TI SoC are named "AM6x": DRA829, DRA821, TDA4VM...

Sure, I'd be open to that change.

For the J721e, the "AM68p" variant doesn't really exist (it appear only in the TRM). It should not be confused with the "real" AM68 that is a "J721S2" SoC.

Do you really want a exhaustive list of SoC or can we use their "generic" names ? or have all variant name?

The granularity is different for each SoC family. For TI, I've decided to be quite specific with the SoC model since the boot procedure is quite complex, so I expect some potential for breaking variations from one model to another.

So ideally for TI, we'd have one model name for each separate commercialized SoC. Now for rebranded SoCs where the chip is exactly the same but with a different name, I don't expect an exhaustive list. SoC aliases can always be added later if needed, like we did for i.MX8MP.

[RomainNaour]

About SoC family naming "am6x", It should be "K3" to include other TI SoC using "K3 Multicore SoC architecture platform". Indeed not all TI SoC are named "AM6x": DRA829, DRA821, TDA4VM...

Sure, I'd be open to that change.

For the J721e, the "AM68p" variant doesn't really exist (it appear only in the TRM). It should not be confused with the "real" AM68 that is a "J721S2" SoC.
Do you really want a exhaustive list of SoC or can we use their "generic" names ? or have all variant name?

The granularity is different for each SoC family. For TI, I've decided to be quite specific with the SoC model since the boot procedure is quite complex, so I expect some potential for breaking variations from one model to another.

So ideally for TI, we'd have one model name for each separate commercialized SoC. Now for rebranded SoCs where the chip is exactly the same but with a different name, I don't expect an exhaustive list. SoC aliases can always be added later if needed, like we did for i.MX8MP.

Thanks for the review.

I'm agree that we need to be careful between TI K3 SoC variants, but as soon as they share the same datasheet, the boot flow is the same.

I'm using the SK-TDA4VM, the BeagleboneAI64 (both using the TDA4VM SoC) and the J721E-EVM (XJ721E experimental) board for evaluation purpose but the customer product board use the DRA829 SoC. I can use snagboot without any trouble.

For convenience, I added "tda4vm" and "dra829" aliases for the "j721e".

[rgantois]

Nice, thanks!