[MP]I’d recommend a separate board under the K3 lowend (am62l) platform. I would assume your flow differs in a way that you need BL1, while the existing TI AM62L support is set up to RESET_TO_BL31. Keeping a dedicated board target avoids complicating the default TI path and makes the boot flow explicit. You can use existing TARGET_BOARD to make distinction in common k3 lowend code.

- How much abstraction should we implement for EEPROM and I2C drivers?

[MP] If you introducing new drivers for I2C/EEPROM and you see it might be useful in future for other ti platforms then keeping it in drivers/ti would make sense.

From: Florijan Plohl via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 10 September 2025 08:37
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] Adding support for phyCORE AM62L in TF-A

Hello!

We’d like to add support in TF-A for the PHYTEC phyCORE AM62L. On this
board we need BL1 to read the on-board EEPROM via I2C to set the correct
DRAM timings.
Right now we have it working by editing the TI AM62L files on TI's TF-A
fork and adding the EEPROM and I2C drivers.

Our questions are:
- Should we create a separate board for phyCORE AM62L, or would it make
more sense to include this as an option in the TI AM62L support?
- How much abstraction should we implement for EEPROM and I2C drivers?

Thanks for any advice!

Best regards,
Florijan Plohl

--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org