Applying DTB Overlays from ATF on RZ/G2
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 Working fdt: e631e588 => fdt resize 8192 => fdt apply 0xe631e588
At this point, I would expect the reserved-memory node to be merged with the main FDT, but it appears to be missing.
=> fdt print /reserved-memory libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC =>
There are no errors, but there are no overlays either.
Does someone have any suggestions as to what I am doing wrong? Without the reserved memory node, Linux can crash if it tries to use the memory in that restricted area, and that node might change depending on how ATF is compiled.
Thanks for any help.
adam
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?
Working fdt: e631e588 => fdt resize 8192 => fdt apply 0xe631e588
Here you are apply the devicetree at e631e588 to itself which cannot work.
Best regards
Heinrich
At this point, I would expect the reserved-memory node to be merged with the main FDT, but it appears to be missing.
=> fdt print /reserved-memory libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC =>
There are no errors, but there are no overlays either.
Does someone have any suggestions as to what I am doing wrong? Without the reserved memory node, Linux can crash if it tries to use the memory in that restricted area, and that node might change depending on how ATF is compiled.
Thanks for any help.
adam
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:
=> run loadfdt 65932 bytes read in 6 ms (10.5 MiB/s) => fdt addr $fdt_addr Working FDT set to 48000000 => fdt resize 8192 => fdt apply 0xe631e588 => fdt print /reserved-memory libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND =>
Working fdt: e631e588 => fdt resize 8192 => fdt apply 0xe631e588
Here you are apply the devicetree at e631e588 to itself which cannot work.
Best regards
Heinrich
At this point, I would expect the reserved-memory node to be merged with the main FDT, but it appears to be missing.
=> fdt print /reserved-memory libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC =>
There are no errors, but there are no overlays either.
Does someone have any suggestions as to what I am doing wrong? Without the reserved memory node, Linux can crash if it tries to use the memory in that restricted area, and that node might change depending on how ATF is compiled.
Thanks for any help.
adam
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 -@)?
Best regards
Heinrich
=> run loadfdt 65932 bytes read in 6 ms (10.5 MiB/s) => fdt addr $fdt_addr Working FDT set to 48000000 => fdt resize 8192 => fdt apply 0xe631e588 => fdt print /reserved-memory libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND =>
Working fdt: e631e588 => fdt resize 8192 => fdt apply 0xe631e588
Here you are apply the devicetree at e631e588 to itself which cannot work.
Best regards
Heinrich
At this point, I would expect the reserved-memory node to be merged with the main FDT, but it appears to be missing.
=> fdt print /reserved-memory libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC =>
There are no errors, but there are no overlays either.
Does someone have any suggestions as to what I am doing wrong? Without the reserved memory node, Linux can crash if it tries to use the memory in that restricted area, and that node might change depending on how ATF is compiled.
Thanks for any help.
adam
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.
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?
adam
On Sat, Jan 7, 2023 at 6:01 AM Adam Ford aford173@gmail.com 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"; }; }; =>
+ 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
Hi Adam,
Subject: Re: Applying DTB Overlays from ATF on RZ/G2
On Sat, Jan 7, 2023 at 6:01 AM Adam Ford aford173@gmail.com 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"; }; }; => >
- 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/hi...
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/boo...
[2] https://github.com/renesas-rcar/linux-bsp/blob/v5.10.41/rcar-5.1.3.rc10/arch...
Cheers, Biju
On Mon, Jan 9, 2023 at 2:46 AM Biju Das biju.das.jz@bp.renesas.com wrote:
Hi Adam,
Subject: Re: Applying DTB Overlays from ATF on RZ/G2
On Sat, Jan 7, 2023 at 6:01 AM Adam Ford aford173@gmail.com 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"; }; }; => >>
- 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/hi...
Right now, my device trees have the memory node(s), but not the reserved-memory node which I'm trying to insert dymanically based on how ATF is built.
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/boo...
[2] https://github.com/renesas-rcar/linux-bsp/blob/v5.10.41/rcar-5.1.3.rc10/arch...
Your custom repo has the reserved-memory node in the device tree. I was trying to figure out how to get the reserved-memory node to propagate from ATF through U-Boot to Linux without needing to have the reserved-memory node in the device tree. I had attempted to add the reserved-memory node upstream, and Geert asked me to use ATF insead. I added debug code into the function that reads the ATF node that is passed to U-Boot and it doesn't appear to be getting called unless I modify the code to explicitly do it. I wasn't sure if I am missing a Kconfig option somewhere.
adam
Cheers, Biju
Hi Adam,
Subject: Re: Applying DTB Overlays from ATF on RZ/G2
On Mon, Jan 9, 2023 at 2:46 AM Biju Das biju.das.jz@bp.renesas.com wrote:
Hi Adam,
Subject: Re: Applying DTB Overlays from ATF on RZ/G2
On Sat, Jan 7, 2023 at 6:01 AM Adam Ford aford173@gmail.com 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
> 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"; }; }; => >>>
- 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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix ir.bootlin.com%2Fu-boot%2Flatest%2Fsource%2Fboard%2Fhoperun%2Fhihope-r zg2%2Fhihope-rzg2.c%23L83&data=05%7C01%7Cbiju.das.jz%40bp.renesas.com% 7C0852ecec21cd4a3c09a908daf260323d%7C53d82571da1947e49cb4625a166a4a2a% 7C0%7C0%7C638088792215848419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat a=RWHfDYQgV7duNwRByGAoqv%2BekIxYMEfUzQLJFME9sQY%3D&reserved=0
Right now, my device trees have the memory node(s), but not the reserved- memory node which I'm trying to insert dymanically based on how ATF is built.
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].
Your custom repo has the reserved-memory node in the device tree. I was trying to figure out how to get the reserved-memory node to propagate from ATF through U-Boot to Linux without needing to have the reserved-memory node in the device tree. I had attempted to add the reserved-memory node upstream, and Geert asked me to use ATF insead. I added debug code into the function that reads the ATF node that is passed to U-Boot and it doesn't appear to be getting called unless I modify the code to explicitly do it. I wasn't sure if I am missing a Kconfig option somewhere.
May be Marek can help here. May be U-boot[1] needs patching similar to Optee For lossy-compression.
[1] https://elixir.bootlin.com/u-boot/latest/source/lib/optee/optee.c
Cheers, Biju
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 ?
On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut marex@denx.de wrote:
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 ?
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.
adam
On 1/10/23 14:19, Adam Ford wrote:
On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut marex@denx.de wrote:
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 ?
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
?
If so, then it is up to U-Boot to pass its own reserved memory nodes onward to Linux.
On Tue, Jan 10, 2023 at 7:40 AM Marek Vasut marex@denx.de wrote:
On 1/10/23 14:19, Adam Ford wrote:
On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut marex@denx.de wrote:
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 ?
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@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?
adam
?
If so, then it is up to U-Boot to pass its own reserved memory nodes onward to Linux.
On 1/12/23 00:06, Adam Ford wrote:
On Tue, Jan 10, 2023 at 7:40 AM Marek Vasut marex@denx.de wrote:
On 1/10/23 14:19, Adam Ford wrote:
On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut marex@denx.de wrote:
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 ?
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@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 ?
participants (4)
-
Adam Ford -
Biju Das -
Heinrich Schuchardt -
Marek Vasut