Dne četrtek, 07. julij 2022 ob 08:30:32 CEST je Samuel Holland napisal(a):

Hi Andre, Jernej,

On 7/6/22 8:16 AM, Andre Przywara wrote:

quoted

so after seemingly having finished writing this email, I realised that
this won't really help, as I think this diverts the discussion. And the
problem has been around for a while, and won't probably be solved easily
or quickly. I think we agree to disagree here, or we should admit that
there are different approaches ("bundled firmware" vs. "UEFI"), so in the
interest of not blocking the H616 series:

Shall I just keep the firmware node? This would work both ways, whereas
dropping the node would impede the "bundled firmware" approach?

Let me try to sum up the relevant portion of my thoughts (and save the rest
for elsewhere):

The only reason to add the reserved-memory node is to support
externally-loaded DTBs. By adding the node, we are committing to support
externally-loaded DTBs on this SoC.

Upgrading the kernel is not allowed to break boot. If we support
externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.

If we remove the reserved-memory node, the combination of old U-Boot + new
externally-loaded DTB will stop booting (the kernel version is irrelevant).
Therefore, if we add the node, we can never remove it, full stop.

I will (begrudgingly) accept that, as long as the node matches what TF-A
actually generates today. That means, please:
 - Drop the label and update the node name
 - Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)

In the interest of moving things forward, I agree to that.

Best regards,
Jernej





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel