Applying DTB Overlays from ATF on RZ/G2

[Marek Vasut]

On 1/7/23 13:01, Adam Ford wrote:
> On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut <marex at denx.de> wrote:
>>
>> On 1/5/23 00:48, Heinrich Schuchardt wrote:
>>> Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford <aford173 at gmail.com>:
>>>> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>>>
>>>>> On 1/4/23 22:35, Adam Ford wrote:
>>>>>> ATF generates a couple memory nodes based on how it's compiled and
>>>>>> generates a reserved-memory node, and I want to overlay it with the
>>>>>> device tree so Linux knows about this reserved memory.
>>>>>>
>>>>>> When I boot U-Boot, I can read the reserved-memory node:
>>>>>>
>>>>>> => fdt addr 0xe631e588
>>>>>> Working FDT set to e631e588
>>>>>> => fdt print /reserved-memory
>>>>>> reserved-memory {
>>>>>> lossy-decompression at 54000000 {
>>>>>> renesas,formats = <0x00000000>;
>>>>>> no-map;
>>>>>> reg = <0x00000000 0x54000000 0x00000000 0x03000000>;
>>>>>> compatible = "renesas,lossy-decompression", "shared-dma-pool";
>>>>>> };
>>>>>> };
>>>>>> =>
>>>>>>
>>>>>> I attempt to overlay it with the following:
>>>>>>
>>>>>> => run loadfdt
>>>>>> 65932 bytes read in 6 ms (10.5 MiB/s)
>>>>>> => fdt addr $load_addr
>>>>>
>>>>> When actually setting the address you will see a message "Working FDT
>>>>> set to %lx\n". So I assume $load_addr is empty.
>>>>>
>>>>> Did you mean $loadaddr or $fileaddr?
>>>>
>>>> Opps, that was a copy-paste error.  Even with that, I still get the
>>>> failure to overlay:
>>>>
>>>
>>> Did you load a .dtbo file to apply? You cannot apply a devicetree.
>>>
>>> Is the fdt that you want to apply the overlay to built with symbols (dtc parameter -@)?
>>
>> Note that the fragment passed to U-Boot by upstream ATF is already
>> automatically merged into the U-Boot control DT (see
>> board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
>> Linux automatically.
> 
> I ran some tests, and it appears the function fdtdec_board_setup is
> never getting called.  That looks like the code that grabs the blob
> from ATF.  I intentionally removed the memory nodes from the kernel
> device tree expecting the memory nodes to get added from ATF, but when
> I booted it, it promptly hung.  That implied to me that the memory
> nodes didn't get added from ATF.
> 
> I added some debug code and noticed that ft_board_setup did not get
> executed, so I created a call to fdtdec_board_setup from
> ft_board_setup and my board booted just fine.  I am curious to know if
> other rcar/rzg2 boards are seeing something similar?  Is calling
> fdtdec_board_setup from ft_board_setup appropriate?

Note that fdtdec_board_setup() is called very early on when U-Boot 
itself starts up and it is used to patch the fragment passed from ATF 
into U-Boot control DT. The ft_board_setup() is called before booting 
OS, i.e. at much later stage.

Can you maybe summarize what exactly it is that you're trying to pass 
through , and from where to where ?