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