[PATCH 0/2] rpi: Copy properties from firmware DT to loaded DT
Sjoerd Simons submitted the original patch (0001) to carry over some firmware-provided properties into the loaded device tree. This did not fix an issue with Raspberry Pi 400 rev 1.1 boards which would not be able to find the ethernet PHY device at the address specified by the kernel device tree.
Patch 0002 expands on Sjoerd's design to also carry over the real ethernet PHY address, enabling the kernel to find and enable a working ethernet on pi 400 rev 1.1 boards.
Antoine Mazeas (2): rpi: Copy properties from firmware dtb to the loaded dtb rpi: Copy eth PHY address from fw DT to loaded DT
board/raspberrypi/rpi/rpi.c | 51 +++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+)
base-commit: 3dd4e916324efc825a7ee8e412f5cf1ded839021
The RPI firmware adjusts several property values in the dtb it passes to u-boot depending on the board/SoC revision. Inherit some of these when u-boot loads a dtb itself. Specificaly copy:
* /model: The firmware provides a more specific string * /memreserve: The firmware defines a reserved range, better keep it * emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as present on rpi 400 and some rpi 4B boards) has different values for these then the B0T revision. So these need to be adjusted to boot on these boards * blconfig: The firmware defines the memory area where the blconfig stored. Copy those over so it can be enabled. * /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage of that.
Signed-off-by: Sjoerd Simons sjoerd@collabora.com --- board/raspberrypi/rpi/rpi.c | 48 +++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 17b8108cc8..28b6f52506 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err) return (void *)fw_dtb_pointer; }
+int copy_property(void *dst, void *src, char *path, char *property) +{ + int dst_offset, src_offset; + const fdt32_t *prop; + int len; + + src_offset = fdt_path_offset(src, path); + dst_offset = fdt_path_offset(dst, path); + + if (src_offset < 0 || dst_offset < 0) + return -1; + + prop = fdt_getprop(src, src_offset, property, &len); + if (!prop) + return -1; + + return fdt_setprop(dst, dst_offset, property, prop, len); +} + +/* Copy tweaks from the firmware dtb to the loaded dtb */ +void update_fdt_from_fw(void *fdt, void *fw_fdt) +{ + /* Using dtb from firmware directly; leave it alone */ + if (fdt == fw_fdt) + return; + + /* The firmware provides a more precie model; so copy that */ + copy_property(fdt, fw_fdt, "/", "model"); + + /* memory reserve as suggested by the firmware */ + copy_property(fdt, fw_fdt, "/", "memreserve"); + + /* Adjust dma-ranges for the SD card and PCI bus as they can depend on + * the SoC revision + */ + copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges"); + copy_property(fdt, fw_fdt, "pcie0", "dma-ranges"); + + /* Bootloader configuration template exposes as nvmem */ + if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0) + copy_property(fdt, fw_fdt, "blconfig", "status"); + + /* kernel address randomisation seed as provided by the firmware */ + copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed"); +} + int ft_board_setup(void *blob, struct bd_info *bd) { int node;
+ update_fdt_from_fw(blob, (void *)fw_dtb_pointer); + node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer"); if (node < 0) fdt_simplefb_add_node(blob);
On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas antoine@karthanis.net wrote:
The RPI firmware adjusts several property values in the dtb it passes to u-boot depending on the board/SoC revision. Inherit some of these when u-boot loads a dtb itself. Specificaly copy:
- /model: The firmware provides a more specific string
- /memreserve: The firmware defines a reserved range, better keep it
Is this the CMA range or a different one? If so this makes sense.
- emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as present on rpi 400 and some rpi 4B boards) has different values for these then the B0T revision. So these need to be adjusted to boot on these boards
- blconfig: The firmware defines the memory area where the blconfig stored. Copy those over so it can be enabled.
- /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage of that.
U-Boot has a rpi4 iproc_rng200 driver for this and provides it via the UEFI random seed as well, if you're booting using UEFI that takes precedence so providing this might not be useful but also it doesn't matter much.
Signed-off-by: Sjoerd Simons sjoerd@collabora.com
Reviewed-by: Peter Robinson pbrobinson@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on RPi400 and it solves the issues with the kernel DT I've seen plus some RPi4s although no the rev 1.3+ devices that also have the newer SoC rev that's the same in the rpi400
board/raspberrypi/rpi/rpi.c | 48 +++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 17b8108cc8..28b6f52506 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err) return (void *)fw_dtb_pointer; }
+int copy_property(void *dst, void *src, char *path, char *property) +{
int dst_offset, src_offset;const fdt32_t *prop;int len;src_offset = fdt_path_offset(src, path);dst_offset = fdt_path_offset(dst, path);if (src_offset < 0 || dst_offset < 0)return -1;prop = fdt_getprop(src, src_offset, property, &len);if (!prop)return -1;return fdt_setprop(dst, dst_offset, property, prop, len);+}
+/* Copy tweaks from the firmware dtb to the loaded dtb */ +void update_fdt_from_fw(void *fdt, void *fw_fdt) +{
/* Using dtb from firmware directly; leave it alone */if (fdt == fw_fdt)return;/* The firmware provides a more precie model; so copy that */copy_property(fdt, fw_fdt, "/", "model");/* memory reserve as suggested by the firmware */copy_property(fdt, fw_fdt, "/", "memreserve");/* Adjust dma-ranges for the SD card and PCI bus as they can depend on* the SoC revision*/copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");/* Bootloader configuration template exposes as nvmem */if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)copy_property(fdt, fw_fdt, "blconfig", "status");/* kernel address randomisation seed as provided by the firmware */copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");+}
int ft_board_setup(void *blob, struct bd_info *bd) { int node;
update_fdt_from_fw(blob, (void *)fw_dtb_pointer);node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer"); if (node < 0) fdt_simplefb_add_node(blob);-- 2.37.1
Hi Peter, Thanks for looking at this patch
Le 05/09/2022 à 15:41, Peter Robinson a écrit :
On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas antoine@karthanis.net wrote:
The RPI firmware adjusts several property values in the dtb it passes to u-boot depending on the board/SoC revision. Inherit some of these when u-boot loads a dtb itself. Specificaly copy:
- /model: The firmware provides a more specific string
- /memreserve: The firmware defines a reserved range, better keep it
Is this the CMA range or a different one? If so this makes sense.
This a different range than that of the CMA (which itself is defined at /reserved-memory/linux,cma): it's a reserved memory range for the VideoCore module on the SoC. In the case of the rpi 400 (and sister boards like 4B based on the same chip), the dummy value in the DTB is patched by the firmware to a dynamic value set in config.txt; absent this config, the default amount is 76 MiBs (see: datasheet https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf and rpi config reference https://www.raspberrypi.com/documentation/computers/config_txt.html#memory-o...). I can see this happening on my board, where looking at the device tree on a running system:
memreserve = <0x3b400000 0x4c00000>; // 0x4c00000 == 76 MiBs
Note the start of the range is also patched in. Given the dynamic nature of this setting on at least bcm2711 rpi boards, I think this is worth carrying over.
- emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as present on rpi 400 and some rpi 4B boards) has different values for these then the B0T revision. So these need to be adjusted to boot on these boards
- blconfig: The firmware defines the memory area where the blconfig stored. Copy those over so it can be enabled.
- /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage of that.
U-Boot has a rpi4 iproc_rng200 driver for this and provides it via the UEFI random seed as well, if you're booting using UEFI that takes precedence so providing this might not be useful but also it doesn't matter much.
Signed-off-by: Sjoerd Simons sjoerd@collabora.com
Reviewed-by: Peter Robinson pbrobinson@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on RPi400 and it solves the issues with the kernel DT I've seen plus some RPi4s although no the rev 1.3+ devices that also have the newer SoC rev that's the same in the rpi400
board/raspberrypi/rpi/rpi.c | 48 +++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 17b8108cc8..28b6f52506 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err) return (void *)fw_dtb_pointer; }
+int copy_property(void *dst, void *src, char *path, char *property) +{
int dst_offset, src_offset;const fdt32_t *prop;int len;src_offset = fdt_path_offset(src, path);dst_offset = fdt_path_offset(dst, path);if (src_offset < 0 || dst_offset < 0)return -1;prop = fdt_getprop(src, src_offset, property, &len);if (!prop)return -1;return fdt_setprop(dst, dst_offset, property, prop, len);+}
+/* Copy tweaks from the firmware dtb to the loaded dtb */ +void update_fdt_from_fw(void *fdt, void *fw_fdt) +{
/* Using dtb from firmware directly; leave it alone */if (fdt == fw_fdt)return;/* The firmware provides a more precie model; so copy that */copy_property(fdt, fw_fdt, "/", "model");/* memory reserve as suggested by the firmware */copy_property(fdt, fw_fdt, "/", "memreserve");/* Adjust dma-ranges for the SD card and PCI bus as they can depend on* the SoC revision*/copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");/* Bootloader configuration template exposes as nvmem */if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)copy_property(fdt, fw_fdt, "blconfig", "status");/* kernel address randomisation seed as provided by the firmware */copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");+}
int ft_board_setup(void *blob, struct bd_info *bd) { int node;
update_fdt_from_fw(blob, (void *)fw_dtb_pointer);node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer"); if (node < 0) fdt_simplefb_add_node(blob);-- 2.37.1
Hi Antoine,
The RPI firmware adjusts several property values in the dtb it passes to u-boot depending on the board/SoC revision. Inherit some of these when u-boot loads a dtb itself. Specificaly copy:
- /model: The firmware provides a more specific string
- /memreserve: The firmware defines a reserved range, better keep it
Is this the CMA range or a different one? If so this makes sense.
This a different range than that of the CMA (which itself is defined at /reserved-memory/linux,cma): it's a reserved memory range for the VideoCore module on the SoC. In the case of the rpi 400 (and sister boards like 4B based on the same chip), the dummy value in the DTB is patched by the firmware to a dynamic value set in config.txt; absent this config, the default amount is 76 MiBs (see: datasheet https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf and rpi config reference https://www.raspberrypi.com/documentation/computers/config_txt.html#memory-o...). I can see this happening on my board, where looking at the device tree on a running system:
memreserve = <0x3b400000 0x4c00000>; // 0x4c00000 == 76 MiBs
Note the start of the range is also patched in. Given the dynamic nature of this setting on at least bcm2711 rpi boards, I think this is worth carrying over.
The gpu_mem is used by the old firmware based closed source video driver, the old version of the camera driver and a few other things. If those aren't used it's generally recommended to reduce it as a low as possible on the rpi4 if you're using the upstream kernel drivers etc. although I do agree it makes sense to reserve it.
Given the newer open driver, which is now the default for rpi4 even in Raspian, uses CMA for it's memory I think it also makes sense to pass through the the CMA setting if set as well.
- emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as present on rpi 400 and some rpi 4B boards) has different values for these then the B0T revision. So these need to be adjusted to boot on these boards
- blconfig: The firmware defines the memory area where the blconfig stored. Copy those over so it can be enabled.
- /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage of that.
U-Boot has a rpi4 iproc_rng200 driver for this and provides it via the UEFI random seed as well, if you're booting using UEFI that takes precedence so providing this might not be useful but also it doesn't matter much.
Signed-off-by: Sjoerd Simons sjoerd@collabora.com
Reviewed-by: Peter Robinson pbrobinson@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on RPi400 and it solves the issues with the kernel DT I've seen plus some RPi4s although no the rev 1.3+ devices that also have the newer SoC rev that's the same in the rpi400
board/raspberrypi/rpi/rpi.c | 48 +++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 17b8108cc8..28b6f52506 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err) return (void *)fw_dtb_pointer; }
+int copy_property(void *dst, void *src, char *path, char *property) +{
int dst_offset, src_offset;const fdt32_t *prop;int len;src_offset = fdt_path_offset(src, path);dst_offset = fdt_path_offset(dst, path);if (src_offset < 0 || dst_offset < 0)return -1;prop = fdt_getprop(src, src_offset, property, &len);if (!prop)return -1;return fdt_setprop(dst, dst_offset, property, prop, len);+}
+/* Copy tweaks from the firmware dtb to the loaded dtb */ +void update_fdt_from_fw(void *fdt, void *fw_fdt) +{
/* Using dtb from firmware directly; leave it alone */if (fdt == fw_fdt)return;/* The firmware provides a more precie model; so copy that */copy_property(fdt, fw_fdt, "/", "model");/* memory reserve as suggested by the firmware */copy_property(fdt, fw_fdt, "/", "memreserve");/* Adjust dma-ranges for the SD card and PCI bus as they can depend on* the SoC revision*/copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");/* Bootloader configuration template exposes as nvmem */if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)copy_property(fdt, fw_fdt, "blconfig", "status");/* kernel address randomisation seed as provided by the firmware */copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");+}
int ft_board_setup(void *blob, struct bd_info *bd) { int node;
update_fdt_from_fw(blob, (void *)fw_dtb_pointer);node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer"); if (node < 0) fdt_simplefb_add_node(blob);-- 2.37.1
Sorry following up on your last comment, what specific issues are you referring to on the rev 1.3+ pi 4s ? It may be worth hunting them down, although I may lack access to such boards.
Le 05/09/2022 à 15:41, Peter Robinson a écrit :
Tested on RPi400 and it solves the issues with the kernel DT I've seen plus some RPi4s although no the rev 1.3+ devices that also have the newer SoC rev that's the same in the rpi400
On Mon, 2022-09-05 at 21:11 +0200, Antoine Mazeas wrote:
Sorry following up on your last comment, what specific issues are you referring to on the rev 1.3+ pi 4s ? It may be worth hunting them down, although I may lack access to such boards.
Le 05/09/2022 à 15:41, Peter Robinson a écrit :
Tested on RPi400 and it solves the issues with the kernel DT I've seen plus some RPi4s although no the rev 1.3+ devices that also have the newer SoC rev that's the same in the rpi400
For reference the newer RPI4 boards is why i wrote the patch in the first place as some folks in our team were hitting issues with them :) So i can confirm my patch solves the issue there as well;
Unfortunately i don't have newer revisions RPI4's myself, but behaviour wise they seem the same as the RPI 400 as they share the same SoC revision
On Mon, Sep 5, 2022 at 8:11 PM Antoine Mazeas antoine@karthanis.net wrote:
Sorry following up on your last comment, what specific issues are you referring to on the rev 1.3+ pi 4s ? It may be worth hunting them down, although I may lack access to such boards.
There was slight changes in the never rev of the SoC that affects some things, there's various threads about it around the place and how to address it. The Pi firmware live patches the DT basically.
Le 05/09/2022 à 15:41, Peter Robinson a écrit :
Tested on RPi400 and it solves the issues with the kernel DT I've seen plus some RPi4s although no the rev 1.3+ devices that also have the newer SoC rev that's the same in the rpi400
Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address for the ethernet PHY device than what is provided by the kernel DTB. The correct address is provided by the firmware, so we should carry it over into the loaded device tree so that ethernet works on such boards.
Signed-off-by: Antoine Mazeas antoine@karthanis.net --- board/raspberrypi/rpi/rpi.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 28b6f52506..793fd1aa30 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -548,6 +548,9 @@ void update_fdt_from_fw(void *fdt, void *fw_fdt)
/* kernel address randomisation seed as provided by the firmware */ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed"); + + /* address of the PHY device as provided by the firmware */ + copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg"); }
int ft_board_setup(void *blob, struct bd_info *bd)
On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas antoine@karthanis.net wrote:
Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address for the ethernet PHY device than what is provided by the kernel DTB. The correct address is provided by the firmware, so we should carry it over into the loaded device tree so that ethernet works on such boards.
Minor nit: this should be properly wrapped.
Signed-off-by: Antoine Mazeas antoine@karthanis.net
Reviewed-by: Peter Robinson pbrobinson@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on the RPi400 and a couple of different RPi4s
board/raspberrypi/rpi/rpi.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 28b6f52506..793fd1aa30 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -548,6 +548,9 @@ void update_fdt_from_fw(void *fdt, void *fw_fdt)
/* kernel address randomisation seed as provided by the firmware */ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
/* address of the PHY device as provided by the firmware */copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg");}
int ft_board_setup(void *blob, struct bd_info *bd)
2.37.1
Le 05/09/2022 à 15:19, Peter Robinson a écrit :
On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas antoine@karthanis.net wrote:
Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address for the ethernet PHY device than what is provided by the kernel DTB. The correct address is provided by the firmware, so we should carry it over into the loaded device tree so that ethernet works on such boards.
Minor nit: this should be properly wrapped.
Yes, I did end up resending the patch a few days later with proper formatting and superseding this series. I'm very sorry for the confusion.
Resent on the 19th Aug.: https://patchwork.ozlabs.org/project/uboot/list/?series=314524
No change apart from the formatting of the commit messages.
Signed-off-by: Antoine Mazeas antoine@karthanis.net
Reviewed-by: Peter Robinson pbrobinson@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on the RPi400 and a couple of different RPi4s
board/raspberrypi/rpi/rpi.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 28b6f52506..793fd1aa30 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -548,6 +548,9 @@ void update_fdt_from_fw(void *fdt, void *fw_fdt)
/* kernel address randomisation seed as provided by the firmware */ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
/* address of the PHY device as provided by the firmware */copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg");}
int ft_board_setup(void *blob, struct bd_info *bd)
-- 2.37.1
On Mon, Sep 5, 2022 at 8:16 PM Antoine Mazeas antoine@karthanis.net wrote:
Le 05/09/2022 à 15:19, Peter Robinson a écrit :
On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas antoine@karthanis.net wrote:
Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address for the ethernet PHY device than what is provided by the kernel DTB. The correct address is provided by the firmware, so we should carry it over into the loaded device tree so that ethernet works on such boards.
Minor nit: this should be properly wrapped.
Yes, I did end up resending the patch a few days later with proper formatting and superseding this series. I'm very sorry for the confusion.
Resent on the 19th Aug.: https://patchwork.ozlabs.org/project/uboot/list/?series=314524
No change apart from the formatting of the commit messages.
Probably should have been a v2 instead of a resend IMO.
Signed-off-by: Antoine Mazeas antoine@karthanis.net
Reviewed-by: Peter Robinson pbrobinson@gmail.com Tested-by: Peter Robinson pbrobinson@gmail.com
Tested on the RPi400 and a couple of different RPi4s
board/raspberrypi/rpi/rpi.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 28b6f52506..793fd1aa30 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -548,6 +548,9 @@ void update_fdt_from_fw(void *fdt, void *fw_fdt)
/* kernel address randomisation seed as provided by the firmware */ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
/* address of the PHY device as provided by the firmware */copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg");}
int ft_board_setup(void *blob, struct bd_info *bd)
-- 2.37.1
participants (3)
-
Antoine Mazeas -
Peter Robinson -
Sjoerd Simons