Applying DTB Overlays from ATF on RZ/G2

[Biju Das]

Hi Adam,

> Subject: Re: Applying DTB Overlays from ATF on RZ/G2
> 
> On Sat, Jan 7, 2023 at 6:01 AM Adam Ford <aford173 at gmail.com> 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"; }; }; =>
> > > >>>>
> 
> + CC Biju Das

> > > >>>> 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.  

Without that board detection and proper memory detection in u-boot/kernel won't happen.
[1] https://elixir.bootlin.com/u-boot/latest/source/board/hoperun/hihope-rzg2/hihope-rzg2.c#L83


> > 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?

It should be working as we are using lossy compression for media playback for VLP release
and VLP release[1] is using Mainline ATF and U-boot. Similar case for R-Car.
I remember correctly for lossy compression case, we explicitly add a node in kernel [2].

[1] https://github.com/renesas-rz/rz_linux-cip/blob/rz-5.10-cip17/arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n.dts#L27

[2] https://github.com/renesas-rcar/linux-bsp/blob/v5.10.41/rcar-5.1.3.rc10/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts#L32


Cheers,
Biju