On Sat, Jan 7, 2023 at 6:01 AM Adam Ford <aford...@gmail.com> wrote:
>
> On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut <ma...@denx.de> wrote:
> >
> > On 1/5/23 00:48, Heinrich Schuchardt wrote:
> > > Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford <aford...@gmail.com>:
> > >> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt <xypron.g...@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@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. 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?
>
> adam
