Applying DTB Overlays from ATF on RZ/G2

[Marek Vasut]

On 1/12/23 00:06, Adam Ford wrote:
> On Tue, Jan 10, 2023 at 7:40 AM Marek Vasut <marex at denx.de> wrote:
>>
>> On 1/10/23 14:19, Adam Ford wrote:
>>> On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut <marex at denx.de> wrote:
>>>>
>>>> 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 ?
>>>
>>> There is a reserved-memory node generated by ATF and I want to pass
>>> that node to the Linux Kernel, so the memory is reserved, because
>>> accessing the memory will cause Linux to crash.  I wanted to put the
>>> reserved-memory node into the kernel dts file, but Geert asked me to
>>> pass the blob from ATF instead of hard-coding it into the dts.
>>> I am just trying to figure out how to make that happen, because it
>>> appears the memory isn't being reserved.
>>
>> So, can you check whether the U-Boot control DT does contain this
>> reserved memory node ?
>>
>> => fdt addr $fdtcontroladdr
>> => fdt print /path/to/the/node
>>
> => fdt addr $fdtcontroladdr
> Working FDT set to bbedccb0
> => fdt print /reserved-memory
> reserved-memory {
> lossy-decompression at 54000000 {
> compatible = "renesas,lossy-decompression", "shared-dma-pool";
> reg = <0x00000000 0x54000000 0x00000000 0x03000000>;
> no-map;
> renesas,formats = <0x00000000>;
> };
> };
> =>
> 
> So it does appear that the reserved-memory is showing up here.
> 
> Is there a way to export just this node and append it to the kernel's DTB?

Hmmmm, I would start digging around boot/image-fdt.c 
boot_fdt_add_mem_rsv_regions() .

Can you check in 'bdinfo' whether this lossy decomp area is already 
protected by LMB in U-Boot ?