Integrate with upstream Trusted Firmware

[ghost]

What is the reason for keeping this out of tree? There are just a few small files here, it would be better to integrate it with the TF to make it easier to maintain (if a path changes or something).

[kostapr]

The only reason was a non-standard BL (actually pre-TF-A, aka BootROM stage). We expected that this will not be accepted. I can go ahead and add it into the upstream. Should I add it as is?

[ghost]

In this case I think we can make an exception. I mean, we can't build the TF without this code, and keeping it off-tree is a bit painful for us, specially for our CI. We already have to deal with Mbed TLS and your DDR library. I think that as long as this can be hidden in your platform's makefile it should be fine.

[kostapr]

OK, so I will try to create a new PR tomorrow. Should I put BLE folder under the root of the source tree or under the plat/marvell ?

[kostapr]

@antonio-nino-diaz-arm
BTW, the A3700 support, that I am going to add shortly, contains an external tools and ROM code repository as well (I already mentioned it in the documentation). This SoC has different architecture and BootROM design, so it cannot share A8K image building tools and BLE code. Should I add this code under the tools or platform folder of TF-A as well?

[ghost]

Keep it under plat/marvell. However, now that you mention the A3700 case... I guess that this code is public, right? Don't prepare a PR for this until we know how we can deal with both cases. In case it's public and small, you could just have a ble folder such as a8k/ble and then another a3700/ble, or something like that. If, for some reason, the ble for a3700 is very different and big, and you are going to need the build option to pass the path anyway, maybe we need to rethink it. I imagine that it's similar.

Having weird platform code isn't necessarily a problem, in general. It would be a problem if it interacted with generic code, but this is decoupled from the rest of the codebase and quite simple. The problem is that having a TF that doesn't build without external repositories isn't ideal.

Having extra tools is not a problem. Do you mean that doimage can't be used for a3700? Maybe we could have tools/marvell in that case.

To be honest, we only have a few platforms that follow the BL1->BL2->BL31 bootflow, most of the upstream platforms have a custom BL1/BL2 and only have ported BL31. BL2_AT_EL3 was also created because some platforms didn't want to use BL1 at all. Not to mention that platforms such as Juno have a bootloader that is way more complicated than the TF itself. So I think that as long as this code can be isolated from the rest, it should be fine. Strictly speaking, only FVP and QEMU actually use the "correct" bootflow, with BL1 in ROM, and considering them platforms is a stretch...

CC: @dp-arm

[kostapr]

As far as I know all A3700 components including out of tree ones are public. I should check the out of tree sources for the license type, but I think it's BSD.

[ghost]

Then it should be fine.

By the way, what was the reason for not upstreaming the DDR library?

[kostapr]

The DDR contains some components that are not open source, for instance Synapsys PHY FW. So we supply it as pre-compiled header file. I think all the rest is Marvell code and it's at least open source (again, not sure about the license terms, but I think it has 3-license headers - proprietary, GPL and BSD)

[ghost]

Ok, understood.