Our board configuration requires reading only a variation type and modify certain DDR4 timing parameters. We aim to invest minimal effort, so it would be ideal if it were possible to implement this as an option configuration rather than creating a fully separate board.

Please find my answers [MP]

- 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?

[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.

Thanks

Manish

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