| Message ID | 20231003041941.4760-1-twoerner@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-rockchip] KERNEL_DEVICETREE: 32-bit re-org | expand |
Hi Trevor, On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote: > The upstream kernel reorganized the 32-bit arch/arm device-tree directory structure > to separate out the device-trees by manufacturer (similar to the organization > of the arch/arm64 device-trees). Update the references to 32-bit arm > device-trees to match. > Does this work with linux-yocto and linux-yocto-dev from master or do we need to add some logic to support both (do you want to?). Cheers, Quentin
On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote: > Hi Trevor, > > On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote: > > The upstream kernel reorganized the 32-bit arch/arm device-tree directory structure > > to separate out the device-trees by manufacturer (similar to the organization > > of the arch/arm64 device-trees). Update the references to 32-bit arm > > device-trees to match. > > > > Does this work with linux-yocto and linux-yocto-dev from master or do we > need to add some logic to support both (do you want to?). This doesn't work at all. I figured this was an easy one, made the tweak, submitted it, then added it to my jenkins builder to verify overnight. Woke up to find the do_image_wic() tasks failed. It's the same layout as the 64-bit machines but I'll have to dig in to figure out why it didn't work. As for the linux-yocto vs linux-yocto-dev question I'll take a look. This happened with linux-yocto, so I would assume it is already the case with linux-yocto-dev. But if oe-core supports multiple versions of linux-yocto, that might be the tricky bit and yes, I would look into supporting both for the time-being until the transition period ends. Although... any BSP layer supporting 32-bit machines will have similar issues, so perhaps there's a better way to solve this in oe-core? Best regards, Trevor
Hi Trevor, On 10/3/23 15:38, Trevor Woerner wrote: > On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote: >> Hi Trevor, >> >> On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote: >>> The upstream kernel reorganized the 32-bit arch/arm device-tree directory structure >>> to separate out the device-trees by manufacturer (similar to the organization >>> of the arch/arm64 device-trees). Update the references to 32-bit arm >>> device-trees to match. >>> >> >> Does this work with linux-yocto and linux-yocto-dev from master or do we >> need to add some logic to support both (do you want to?). > > This doesn't work at all. I figured this was an easy one, made the tweak, > submitted it, then added it to my jenkins builder to verify overnight. Woke up > to find the do_image_wic() tasks failed. It's the same layout as the 64-bit > machines but I'll have to dig in to figure out why it didn't work. > > As for the linux-yocto vs linux-yocto-dev question I'll take a look. This > happened with linux-yocto, so I would assume it is already the case with > linux-yocto-dev. But if oe-core supports multiple versions of linux-yocto, > that might be the tricky bit and yes, I would look into supporting both for > the time-being until the transition period ends. > This was done in v6.5-rc1 so anything before won't work sadly. master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto (linux-yocto-dev being typically newer than the latest linux-yocto and the latest linux-yocto already having the change, I'll omit the change for linux-yocto-dev). For reference, denix on IRC suggested you look at https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300 for what we're trying to do here. But I think this isn't applying to how the DTB is found but rather where it's put and this is too late for us. I think we need to modify get_real_dtb_path_in_kernel in meta/classes-recipe/kernel-devicetree.bbclass instead. We could handle it this way for example to allow a fallback: """ get_real_dtb_path_in_kernel:arm () { dtb="$1" dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb" # Handle pre-v6.5 layout for Aarch32/ARM DTB if [ ! -e "$dtb_path" ]; then dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")" fi if [ ! -e "$dtb_path" ]; then dtb_path="${B}/arch/${ARCH}/boot/$dtb" fi # Handle pre-v6.5 layout for Aarch32/ARM DTB if [ ! -e "$dtb_path" ]; then dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")" fi echo "$dtb_path" } """ (to be determined if "arm" is a valid OVERRIDES, otherwise we need to check against "ARCH" bb variable; also not sure about the second basename if it's necessary at all). Then you would just have KERNEL_DEVICETREE done the same way as in this patch: KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" and we wouldn't have to handle it on the recipe level. Otherwise, we could do the following: RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}" then have a bbappend for all old-layout recipes: linux-yocto-rt_6.1.bbappend linux-yocto-tiny_6.1.bbappend linux-yocto_6.1.bbappend linux-yocto-rt_6.4.bbappend linux-yocto-tiny_6.4.bbappend linux-yocto_6.4.bbappend KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in d.getVar('RK_KERNEL_DEVICETREE').split())}" or something like that. We probably want to have something a bit more precise than just arm to avoid breaking other arm machine conf files which do not define RK_KERNEL_DEVICETREE, maybe KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly. > Although... any BSP layer supporting 32-bit machines will have similar issues, > so perhaps there's a better way to solve this in oe-core? > Adding Bruce in Cc, I hope he doesn't mind being summoned like this. Maybe you have an idea on how to handle both the new and old layout for ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable? Cheers, Quentin
With Bruce in Cc for real this time :) On 10/4/23 15:45, Quentin Schulz wrote: > Hi Trevor, > > On 10/3/23 15:38, Trevor Woerner wrote: >> On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote: >>> Hi Trevor, >>> >>> On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote: >>>> The upstream kernel reorganized the 32-bit arch/arm device-tree >>>> directory structure >>>> to separate out the device-trees by manufacturer (similar to the >>>> organization >>>> of the arch/arm64 device-trees). Update the references to 32-bit arm >>>> device-trees to match. >>>> >>> >>> Does this work with linux-yocto and linux-yocto-dev from master or do we >>> need to add some logic to support both (do you want to?). >> >> This doesn't work at all. I figured this was an easy one, made the tweak, >> submitted it, then added it to my jenkins builder to verify overnight. >> Woke up >> to find the do_image_wic() tasks failed. It's the same layout as the >> 64-bit >> machines but I'll have to dig in to figure out why it didn't work. >> >> As for the linux-yocto vs linux-yocto-dev question I'll take a look. This >> happened with linux-yocto, so I would assume it is already the case with >> linux-yocto-dev. But if oe-core supports multiple versions of >> linux-yocto, >> that might be the tricky bit and yes, I would look into supporting >> both for >> the time-being until the transition period ends. >> > > This was done in v6.5-rc1 so anything before won't work sadly. > > master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto > (linux-yocto-dev being typically newer than the latest linux-yocto and > the latest linux-yocto already having the change, I'll omit the change > for linux-yocto-dev). > > For reference, denix on IRC suggested you look at > https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300 for what we're trying to do here. But I think this isn't applying to how the DTB is found but rather where it's put and this is too late for us. > > I think we need to modify get_real_dtb_path_in_kernel in > meta/classes-recipe/kernel-devicetree.bbclass instead. > > We could handle it this way for example to allow a fallback: > """ > get_real_dtb_path_in_kernel:arm () { > dtb="$1" > dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb" > # Handle pre-v6.5 layout for Aarch32/ARM DTB > if [ ! -e "$dtb_path" ]; then > dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")" > fi > if [ ! -e "$dtb_path" ]; then > dtb_path="${B}/arch/${ARCH}/boot/$dtb" > fi > # Handle pre-v6.5 layout for Aarch32/ARM DTB > if [ ! -e "$dtb_path" ]; then > dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")" > fi > > echo "$dtb_path" > } > """ > (to be determined if "arm" is a valid OVERRIDES, otherwise we need to > check against "ARCH" bb variable; also not sure about the second > basename if it's necessary at all). > > Then you would just have KERNEL_DEVICETREE done the same way as in this > patch: > KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" > > and we wouldn't have to handle it on the recipe level. > > Otherwise, we could do the following: > RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" > KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}" > > then have a bbappend for all old-layout recipes: > linux-yocto-rt_6.1.bbappend > linux-yocto-tiny_6.1.bbappend > linux-yocto_6.1.bbappend > linux-yocto-rt_6.4.bbappend > linux-yocto-tiny_6.4.bbappend > linux-yocto_6.4.bbappend > > KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in > d.getVar('RK_KERNEL_DEVICETREE').split())}" > > or something like that. We probably want to have something a bit more > precise than just arm to avoid breaking other arm machine conf files > which do not define RK_KERNEL_DEVICETREE, maybe > KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly. > >> Although... any BSP layer supporting 32-bit machines will have similar >> issues, >> so perhaps there's a better way to solve this in oe-core? >> > Adding Bruce in Cc, I hope he doesn't mind being summoned like this. > Maybe you have an idea on how to handle both the new and old layout for > ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable? > > Cheers, > Quentin
On Wed, Oct 4, 2023 at 9:59 AM Quentin Schulz via lists.yoctoproject.org <quentin.schulz=theobroma-systems.com@lists.yoctoproject.org> wrote: > Hi Trevor, > > On 10/3/23 15:38, Trevor Woerner wrote: > > On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote: > >> Hi Trevor, > >> > >> On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote: > >>> The upstream kernel reorganized the 32-bit arch/arm device-tree > directory structure > >>> to separate out the device-trees by manufacturer (similar to the > organization > >>> of the arch/arm64 device-trees). Update the references to 32-bit arm > >>> device-trees to match. > >>> > >> > >> Does this work with linux-yocto and linux-yocto-dev from master or do we > >> need to add some logic to support both (do you want to?). > > > > This doesn't work at all. I figured this was an easy one, made the tweak, > > submitted it, then added it to my jenkins builder to verify overnight. > Woke up > > to find the do_image_wic() tasks failed. It's the same layout as the > 64-bit > > machines but I'll have to dig in to figure out why it didn't work. > > > > As for the linux-yocto vs linux-yocto-dev question I'll take a look. This > > happened with linux-yocto, so I would assume it is already the case with > > linux-yocto-dev. But if oe-core supports multiple versions of > linux-yocto, > > that might be the tricky bit and yes, I would look into supporting both > for > > the time-being until the transition period ends. > > > > This was done in v6.5-rc1 so anything before won't work sadly. > > master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto > (linux-yocto-dev being typically newer than the latest linux-yocto and > the latest linux-yocto already having the change, I'll omit the change > for linux-yocto-dev). > > For reference, denix on IRC suggested you look at > > https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300 > for what we're trying to do here. But I think this isn't applying to how > the DTB is found but rather where it's put and this is too late for us. > > I think we need to modify get_real_dtb_path_in_kernel in > meta/classes-recipe/kernel-devicetree.bbclass instead. > > We could handle it this way for example to allow a fallback: > """ > get_real_dtb_path_in_kernel:arm () { > dtb="$1" > dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb" > # Handle pre-v6.5 layout for Aarch32/ARM DTB > if [ ! -e "$dtb_path" ]; then > dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")" > fi > if [ ! -e "$dtb_path" ]; then > dtb_path="${B}/arch/${ARCH}/boot/$dtb" > fi > # Handle pre-v6.5 layout for Aarch32/ARM DTB > if [ ! -e "$dtb_path" ]; then > dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")" > fi > > echo "$dtb_path" > } > """ > (to be determined if "arm" is a valid OVERRIDES, otherwise we need to > check against "ARCH" bb variable; also not sure about the second > basename if it's necessary at all). > > Then you would just have KERNEL_DEVICETREE done the same way as in this > patch: > KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" > > and we wouldn't have to handle it on the recipe level. > > Otherwise, we could do the following: > RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" > KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}" > > then have a bbappend for all old-layout recipes: > linux-yocto-rt_6.1.bbappend > linux-yocto-tiny_6.1.bbappend > linux-yocto_6.1.bbappend > linux-yocto-rt_6.4.bbappend > linux-yocto-tiny_6.4.bbappend > linux-yocto_6.4.bbappend > > KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in > d.getVar('RK_KERNEL_DEVICETREE').split())}" > > or something like that. We probably want to have something a bit more > precise than just arm to avoid breaking other arm machine conf files > which do not define RK_KERNEL_DEVICETREE, maybe > KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly. > > > Although... any BSP layer supporting 32-bit machines will have similar > issues, > > so perhaps there's a better way to solve this in oe-core? > > > Adding Bruce in Cc, I hope he doesn't mind being summoned like this. > Maybe you have an idea on how to handle both the new and old layout for > ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable? > My last run in with this may have been before some of the most recent device tree handling patches, and/or I may have been doing it wrong. But my solution was to simply override the variable in a kernel version specific bbappend, and not do it in the conf files. But of course, if that variable is being interpreted by a different class in the global namespace, then the kernel bbappend approach isn't going to work anymore. I've stayed away from utilities or searching, etc, rather just a way for the configuration to specify directly what to find, as anything that searches ends up being fragile. Bruce > > Cheers, > Quentin > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#61235): > https://lists.yoctoproject.org/g/yocto/message/61235 > Mute This Topic: https://lists.yoctoproject.org/mt/101728482/1050810 > Group Owner: yocto+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [ > bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Wed 2023-10-04 @ 10:39:14 AM, Bruce Ashfield wrote: > On Wed, Oct 4, 2023 at 9:59 AM Quentin Schulz via lists.yoctoproject.org > <quentin.schulz=theobroma-systems.com@lists.yoctoproject.org> wrote: > > > Hi Trevor, > > > > On 10/3/23 15:38, Trevor Woerner wrote: > > > On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote: > > >> Hi Trevor, > > >> > > >> On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote: > > >>> The upstream kernel reorganized the 32-bit arch/arm device-tree > > directory structure > > >>> to separate out the device-trees by manufacturer (similar to the > > organization > > >>> of the arch/arm64 device-trees). Update the references to 32-bit arm > > >>> device-trees to match. > > >>> > > >> > > >> Does this work with linux-yocto and linux-yocto-dev from master or do we > > >> need to add some logic to support both (do you want to?). > > > > > > This doesn't work at all. I figured this was an easy one, made the tweak, > > > submitted it, then added it to my jenkins builder to verify overnight. > > Woke up > > > to find the do_image_wic() tasks failed. It's the same layout as the > > 64-bit > > > machines but I'll have to dig in to figure out why it didn't work. > > > > > > As for the linux-yocto vs linux-yocto-dev question I'll take a look. This > > > happened with linux-yocto, so I would assume it is already the case with > > > linux-yocto-dev. But if oe-core supports multiple versions of > > linux-yocto, > > > that might be the tricky bit and yes, I would look into supporting both > > for > > > the time-being until the transition period ends. > > > > > > > This was done in v6.5-rc1 so anything before won't work sadly. > > > > master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto > > (linux-yocto-dev being typically newer than the latest linux-yocto and > > the latest linux-yocto already having the change, I'll omit the change > > for linux-yocto-dev). > > > > For reference, denix on IRC suggested you look at > > > > https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300 > > for what we're trying to do here. But I think this isn't applying to how > > the DTB is found but rather where it's put and this is too late for us. > > > > I think we need to modify get_real_dtb_path_in_kernel in > > meta/classes-recipe/kernel-devicetree.bbclass instead. > > > > We could handle it this way for example to allow a fallback: > > """ > > get_real_dtb_path_in_kernel:arm () { > > dtb="$1" > > dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb" > > # Handle pre-v6.5 layout for Aarch32/ARM DTB > > if [ ! -e "$dtb_path" ]; then > > dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")" > > fi > > if [ ! -e "$dtb_path" ]; then > > dtb_path="${B}/arch/${ARCH}/boot/$dtb" > > fi > > # Handle pre-v6.5 layout for Aarch32/ARM DTB > > if [ ! -e "$dtb_path" ]; then > > dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")" > > fi > > > > echo "$dtb_path" > > } > > """ > > (to be determined if "arm" is a valid OVERRIDES, otherwise we need to > > check against "ARCH" bb variable; also not sure about the second > > basename if it's necessary at all). > > > > Then you would just have KERNEL_DEVICETREE done the same way as in this > > patch: > > KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" > > > > and we wouldn't have to handle it on the recipe level. > > > > Otherwise, we could do the following: > > RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" > > KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}" > > > > then have a bbappend for all old-layout recipes: > > linux-yocto-rt_6.1.bbappend > > linux-yocto-tiny_6.1.bbappend > > linux-yocto_6.1.bbappend > > linux-yocto-rt_6.4.bbappend > > linux-yocto-tiny_6.4.bbappend > > linux-yocto_6.4.bbappend > > > > KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in > > d.getVar('RK_KERNEL_DEVICETREE').split())}" > > > > or something like that. We probably want to have something a bit more > > precise than just arm to avoid breaking other arm machine conf files > > which do not define RK_KERNEL_DEVICETREE, maybe > > KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly. > > > > > Although... any BSP layer supporting 32-bit machines will have similar > > issues, > > > so perhaps there's a better way to solve this in oe-core? > > > > > Adding Bruce in Cc, I hope he doesn't mind being summoned like this. > > Maybe you have an idea on how to handle both the new and old layout for > > ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable? > > > > My last run in with this may have been before some of the most recent > device tree handling patches, and/or I may have been doing it wrong. > > But my solution was to simply override the variable in a kernel version > specific bbappend, and not do it in the conf files. > > But of course, if that variable is being interpreted by a different class in > the global namespace, then the kernel bbappend approach isn't going > to work anymore. > > I've stayed away from utilities or searching, etc, rather just a way for the > configuration to specify directly what to find, as anything that searches > ends up being fragile. The biggest tangle is that the master branch supports 6.1, 6.4, and 6.5. Getting something to work with one version at at time isn't hard; getting it to work simultaneously with all 3 (and others?) is the tricky part. In a perfect world we could have linux-kernel-version-specific machine conf sections/files... but that would be crazy! I've been poking at this from different angles off-and-on for the last couple days. The more I look at it, the more I like what meta-ti-bsp did. That's probably what I'm going to do: conf/machine/MACHINE.conf file has: - KERNEL_DEVICETREE that just lists the bare dtb file (without directories) - KERNEL_DEVICETREE_PREFIX that lists possible directory names recipes-kernel/linux/linux-yocto% bbappends have logic to check combinations of KERNEL_DEVICETREE_PREFIX+KERNEL_DEVICETREE to find the actual dtb. Something probably also needs to be added to IMAGE_BOOT_FILES so wic works too. NOTE: given that this is meta-rockchip, the KERNEL_DEVICETREE_PREFIX could simply be known to be "rockchip" a-priori; it doesn't necessarily need to be that flexible. And the real catch is that this is only a problem today because a specific OE branch has both pre- and post- cleanup kernel versions. If the OE branches didn't mix the two, this wouldn't be a problem. And someday once master has moved away from having both pre- and post- cleanup kernel versions, we can throw all this infrastructure out (on master) going forward. Best regards, Trevor
diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf index 3270bb9f1657..6ff1be822008 100644 --- a/conf/machine/firefly-rk3288.conf +++ b/conf/machine/firefly-rk3288.conf @@ -9,5 +9,5 @@ require conf/machine/include/rk3288.inc require conf/machine/include/rockchip-wic.inc -KERNEL_DEVICETREE = "rk3288-firefly.dtb" +KERNEL_DEVICETREE = "rockchip/rk3288-firefly.dtb" UBOOT_MACHINE = "firefly-rk3288_defconfig" diff --git a/conf/machine/marsboard-rk3066.conf b/conf/machine/marsboard-rk3066.conf index 52fd256a3445..36945e8e407b 100644 --- a/conf/machine/marsboard-rk3066.conf +++ b/conf/machine/marsboard-rk3066.conf @@ -8,4 +8,4 @@ require conf/machine/include/rk3066.inc -KERNEL_DEVICETREE = "rk3066a-marsboard.dtb" +KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb" diff --git a/conf/machine/radxarock.conf b/conf/machine/radxarock.conf index 42d8848e1d09..6ad8474669d0 100644 --- a/conf/machine/radxarock.conf +++ b/conf/machine/radxarock.conf @@ -9,4 +9,4 @@ require conf/machine/include/rk3188.inc -KERNEL_DEVICETREE = "rk3188-radxarock.dtb" +KERNEL_DEVICETREE = "rockchip/rk3188-radxarock.dtb" diff --git a/conf/machine/rock2-square.conf b/conf/machine/rock2-square.conf index 46064eebcc67..9468b9a6b559 100644 --- a/conf/machine/rock2-square.conf +++ b/conf/machine/rock2-square.conf @@ -9,7 +9,7 @@ require conf/machine/include/rk3288.inc SPL_BINARY = "u-boot-spl-dtb.bin" -KERNEL_DEVICETREE = "rk3288-rock2-square.dtb" +KERNEL_DEVICETREE = "rockchip/rk3288-rock2-square.dtb" UBOOT_MACHINE = "rock2_defconfig" # This board doesn't support the combined idbloader, so resort to the older diff --git a/conf/machine/tinker-board-s.conf b/conf/machine/tinker-board-s.conf index 870b9bcdf8c7..3a656136c554 100644 --- a/conf/machine/tinker-board-s.conf +++ b/conf/machine/tinker-board-s.conf @@ -7,5 +7,5 @@ require conf/machine/include/tinker.inc -KERNEL_DEVICETREE = "rk3288-tinker-s.dtb" +KERNEL_DEVICETREE = "rockchip/rk3288-tinker-s.dtb" UBOOT_MACHINE = "tinker-s-rk3288_defconfig" diff --git a/conf/machine/tinker-board.conf b/conf/machine/tinker-board.conf index 8fe5f6305d70..ef1a1c1ac098 100644 --- a/conf/machine/tinker-board.conf +++ b/conf/machine/tinker-board.conf @@ -7,5 +7,5 @@ require conf/machine/include/tinker.inc -KERNEL_DEVICETREE = "rk3288-tinker.dtb" +KERNEL_DEVICETREE = "rockchip/rk3288-tinker.dtb" UBOOT_MACHINE = "tinker-rk3288_defconfig"
The upstream kernel reorganized the 32-bit arch/arm device-tree directory structure to separate out the device-trees by manufacturer (similar to the organization of the arch/arm64 device-trees). Update the references to 32-bit arm device-trees to match. Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- conf/machine/firefly-rk3288.conf | 2 +- conf/machine/marsboard-rk3066.conf | 2 +- conf/machine/radxarock.conf | 2 +- conf/machine/rock2-square.conf | 2 +- conf/machine/tinker-board-s.conf | 2 +- conf/machine/tinker-board.conf | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-)