arm64: dts: qcom: sa8775p: add symbols to dtb

ABL uses the __symbols__ section to process the DTB before passing it
forward. Without it, the bootstrap is interrupted.

Signed-off-by: Eric Chanudet <echanude@redhat.com>
---
Depends on initial sa8775p-ride.dts:
https://lore.kernel.org/all/20230214092713.211054-3-brgl@bgdev.pl/

 arch/arm64/boot/dts/qcom/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

On 14.03.2023 05:48, Prasad Sodagudi wrote:
> 
> 
> On 3/9/2023 3:47 PM, Konrad Dybcio wrote:
>>
>>
>> On 10.03.2023 00:39, Eric Chanudet wrote:
>>> ABL uses the __symbols__ section to process the DTB before passing it
>>> forward. Without it, the bootstrap is interrupted.
>>>
>>> Signed-off-by: Eric Chanudet <echanude@redhat.com>
>>> ---
>> Fix your ABL.
> Hi Konrad,
> 
> Apps boot-loader need __symbols__ for dynamic overlay operation. Qualcomm firmware passes an overlay file to apps boot-loader to overlay some of the nodes based on firmware configuration. Without __symbols__ apps boot-loader is not able to overlay.
Yes/no. There are a plenty of libfdt functions that let you do that,
especially if you know something about the node.

> 
> Qualcomm hypervisor/gunyah would like to overlay arch timer node with always-on property, So adding __symbols__ helps boot-loader to overlay.
For the arch timer, you can simply iterate over the top-level nodes (or
in the worst case scenario, over all nodes which would not take very
long on cortex-a / cortex-x cores) and look for the specific timer
compatible that has been with us for like 10 years at this point and
use libfdt's fdt_add_property without overlays.

> 
> I think, commit text is misleading here and I will request Eric to fix the commit text.
Sort of, but then the design you explained is very error-prone as it's
dependent on the device tree always satisfying your hypervisor's needs.

Konrad
> 
> -Thanks, Prasad
> 
>>
>> Konrad
>>> Depends on initial sa8775p-ride.dts:
>>> https://lore.kernel.org/all/20230214092713.211054-3-brgl@bgdev.pl/
>>>
>>>   arch/arm64/boot/dts/qcom/Makefile | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>>> index b63cd1861e68..72e85ab31d74 100644
>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>> @@ -1,4 +1,8 @@
>>>   # SPDX-License-Identifier: GPL-2.0
>>> +
>>> +# Enable support for device-tree overlays required on sa8775p-ride.
>>> +DTC_FLAGS_sa8775p-ride := -@
>>> +
>>>   dtb-$(CONFIG_ARCH_QCOM)    += apq8016-sbc.dtb
>>>   dtb-$(CONFIG_ARCH_QCOM)    += apq8094-sony-xperia-kitakami-karin_windy.dtb
>>>   dtb-$(CONFIG_ARCH_QCOM)    += apq8096-db820c.dtb
>>
>>

On Tue, Mar 21, 2023 at 07:55:19PM -0700, Bjorn Andersson wrote:
> On Thu, Mar 09, 2023 at 06:39:48PM -0500, Eric Chanudet wrote:
> > ABL uses the __symbols__ section to process the DTB before passing it
> > forward. Without it, the bootstrap is interrupted.
> > 
> 
> If the reason is that ABL refuses to boot without it, then please have
> ABL fixed. If on the other hand there is a valid reason for ABL to
> require the dtb to have __symbols__ defined, please describe that - if
> nothing else so that others know when this is supposed to be used.

Here is what I understand from the ABL sources and discussions with
Prasad:

Android Boot Loader (ABL), the UEFI application to run before executing
the kernel, implements the Qualcomm SCM protocol to call into TZ. One of
these SCM call is trapped by the hypervisor, itself provided with the
firmware package for the board, and returns to ABL some information
about our VM. These information may include one or more DTBO. ABL then
proceeds and tries to apply the overlays on the DTB it loaded from the
Android Boot Image it is trying to boot.

If there is an hypervisor and it returned at least one DTBO, ABL treats
a failure to apply the DTBO (e.g, if __symbols__ are not available in
the DTB) as critical and ends the boot. I was only ever given a firmware
package that included the hypervisor and it always returned at least one
DTBO. So enabling overlays is required to run this board, using the
firmware I know of, with an upstream kernel and DTB at time of writing.

I suppose ABL could be made to handle such failure as a warning and
continue booting? Which comes down to ignoring the DTBO provided by the
hypervisor. Maybe that still allows the kernel to run the board with
limited functionality?

Prior cases in the git history for enabling overlays covered board
variants and extension headers (ti and nvidia). These do not fit what is
happening here. In hindsight, I should have sent this as an RFC, with
the above explanation to begin with, to ask about the limits and
requirements.

Maybe Prasad, or someone with a more comprehensive knowledge of this
board, can fill the remaining gaps or correct my understanding of the
boot sequence if I got something wrong?

Thanks,