On 1/7/23 13:01, Adam Ford wrote:
On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut marex@denx.de wrote:
On 1/5/23 00:48, Heinrich Schuchardt wrote:
Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford aford173@gmail.com:
On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt xypron.glpk@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"; }; }; =>
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 ?