| Message ID | 20241207162339.10677-1-oleksii.kurochko@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-rockchip] u-boot: Update SRCREV for radxa-zero-3 | expand |
Hi Oleksii, On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org wrote: > [You don't often get email from oleksii.kurochko=gmail.com@lists.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > During the fetch stage of u-boot for radxa-zero-3, the following issue occurs: > Unable to find revision 8cdf606e616baa36751f3b4adcfaefc781126c8c in branch > rk3xxx-2024.07 even from upstream > > This happens because the hash of the head commit for the rk3xxx-2024.07 branch > is different from the one specified in the recipe. > This can be verified by running the following command in > <yocto>/build/tmp/work/radxa_zero_3e-poky-linux/u-boot/2024.01/git: > $ git rev-list -n 1 rk3xxx-2024.07 > 2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead > > Update the SRCREV to the hash of the current head commit corresponding to > the rk3xxx-2024.07 branch. > > Fixes: e0b13fe834b5("radxa-zero-3{e|w}: add") > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > --- > recipes-bsp/u-boot/u-boot_%.bbappend | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u-boot/u-boot_%.bbappend > index c939a48..9432e2b 100644 > --- a/recipes-bsp/u-boot/u-boot_%.bbappend > +++ b/recipes-bsp/u-boot/u-boot_%.bbappend > @@ -3,8 +3,8 @@ require u-boot-rockchip.inc > FILESEXTRAPATHS:prepend := "${THISDIR}/files:" > > SRC_URI:radxa-zero-3 = "git://github.com/Kwiboo/u-boot-rockchip.git;protocol=https;branch=rk3xxx-2024.07;name=Kwiboo" > -SRCREV:radxa-zero-3 = "8cdf606e616baa36751f3b4adcfaefc781126c8c" > -SRCREV:radxa-zero-3:rk-u-boot-env = "8cdf606e616baa36751f3b4adcfaefc781126c8c" > +SRCREV:radxa-zero-3 = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" > +SRCREV:radxa-zero-3:rk-u-boot-env = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" > Master poky now has v2024.10 and at a glance it seems the Zero 3E/W is supported, so maybe we could simply ditch those overrides for master branch in meta-rockchip? Other release branches should probably get a fix similar to the one in this patch though. Or ideally just download the patches from that tree and apply them on top of v2024.07 for styhead (we would need a new release branch for that though). Scarthgap has v2024.01 so that's a bit too old to apply patches destined to 2024.07. But we could maybe point to v2024.07 upstream+patches instead of pointing to Jonas (Kwiboo)'s personal git repo. What do you think? Trevor, an opinion here? Cheers, Quentin
Hello Quentin, On 12/9/24 4:22 PM, Quentin Schulz wrote: > Hi Oleksii, > > On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org wrote: >> [You don't often get email from >> oleksii.kurochko=gmail.com@lists.yoctoproject.org. Learn why this is >> important at https://aka.ms/LearnAboutSenderIdentification ] >> >> During the fetch stage of u-boot for radxa-zero-3, the following >> issue occurs: >> Unable to find revision 8cdf606e616baa36751f3b4adcfaefc781126c8c >> in branch >> rk3xxx-2024.07 even from upstream >> >> This happens because the hash of the head commit for the >> rk3xxx-2024.07 branch >> is different from the one specified in the recipe. >> This can be verified by running the following command in >> <yocto>/build/tmp/work/radxa_zero_3e-poky-linux/u-boot/2024.01/git: >> $ git rev-list -n 1 rk3xxx-2024.07 >> 2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead >> >> Update the SRCREV to the hash of the current head commit >> corresponding to >> the rk3xxx-2024.07 branch. >> >> Fixes: e0b13fe834b5("radxa-zero-3{e|w}: add") >> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >> --- >> recipes-bsp/u-boot/u-boot_%.bbappend | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend >> b/recipes-bsp/u-boot/u-boot_%.bbappend >> index c939a48..9432e2b 100644 >> --- a/recipes-bsp/u-boot/u-boot_%.bbappend >> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend >> @@ -3,8 +3,8 @@ require u-boot-rockchip.inc >> FILESEXTRAPATHS:prepend := "${THISDIR}/files:" >> >> SRC_URI:radxa-zero-3 = >> "git://github.com/Kwiboo/u-boot-rockchip.git;protocol=https;branch=rk3xxx-2024.07;name=Kwiboo" >> -SRCREV:radxa-zero-3 = "8cdf606e616baa36751f3b4adcfaefc781126c8c" >> -SRCREV:radxa-zero-3:rk-u-boot-env = >> "8cdf606e616baa36751f3b4adcfaefc781126c8c" >> +SRCREV:radxa-zero-3 = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" >> +SRCREV:radxa-zero-3:rk-u-boot-env = >> "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" >> > > Master poky now has v2024.10 and at a glance it seems the Zero 3E/W is > supported, so maybe we could simply ditch those overrides for master > branch in meta-rockchip? This is first time when I started to work with rockchip so I need some time what is the difference between Kwiboo's u-boot and upstream one. If there is no any specific patches and the difference is only that some patches haven't been upstreamed then I prefer this approach. Otherwise ... > > Other release branches should probably get a fix similar to the one in > this patch though. Or ideally just download the patches from that tree > and apply them on top of v2024.07 for styhead (we would need a new > release branch for that though). Scarthgap has v2024.01 so that's a > bit too old to apply patches destined to 2024.07. But we could maybe > point to v2024.07 upstream+patches instead of pointing to Jonas > (Kwiboo)'s personal git repo. > What do you think? Trevor, an opinion here? ... v2024.07 upstream + patches will be the best one option we could have now. I have the small issue here. At the moment I don't have radxa-zero-3 board so I can check only build. My target is RV1103 SoC for which I want to add support to Yocto. But I think that I can start in parallel update u-boot recipe for radxa-zero-3 too and then ask someone to test on a board. Thanks. ~ Oleksii
Hi Oleksii, On 12/10/24 5:16 PM, Oleksii Kurochko wrote: > Hello Quentin, > > On 12/9/24 4:22 PM, Quentin Schulz wrote: >> Hi Oleksii, >> >> On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org wrote: >>> [You don't often get email from >>> oleksii.kurochko=gmail.com@lists.yoctoproject.org. Learn why this is >>> important at https://aka.ms/LearnAboutSenderIdentification ] >>> >>> During the fetch stage of u-boot for radxa-zero-3, the following >>> issue occurs: >>> Unable to find revision 8cdf606e616baa36751f3b4adcfaefc781126c8c >>> in branch >>> rk3xxx-2024.07 even from upstream >>> >>> This happens because the hash of the head commit for the >>> rk3xxx-2024.07 branch >>> is different from the one specified in the recipe. >>> This can be verified by running the following command in >>> <yocto>/build/tmp/work/radxa_zero_3e-poky-linux/u-boot/2024.01/git: >>> $ git rev-list -n 1 rk3xxx-2024.07 >>> 2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead >>> >>> Update the SRCREV to the hash of the current head commit >>> corresponding to >>> the rk3xxx-2024.07 branch. >>> >>> Fixes: e0b13fe834b5("radxa-zero-3{e|w}: add") >>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >>> --- >>> recipes-bsp/u-boot/u-boot_%.bbappend | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u- >>> boot/u-boot_%.bbappend >>> index c939a48..9432e2b 100644 >>> --- a/recipes-bsp/u-boot/u-boot_%.bbappend >>> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend >>> @@ -3,8 +3,8 @@ require u-boot-rockchip.inc >>> FILESEXTRAPATHS:prepend := "${THISDIR}/files:" >>> >>> SRC_URI:radxa-zero-3 = "git://github.com/Kwiboo/u-boot- >>> rockchip.git;protocol=https;branch=rk3xxx-2024.07;name=Kwiboo" >>> -SRCREV:radxa-zero-3 = "8cdf606e616baa36751f3b4adcfaefc781126c8c" >>> -SRCREV:radxa-zero-3:rk-u-boot-env = >>> "8cdf606e616baa36751f3b4adcfaefc781126c8c" >>> +SRCREV:radxa-zero-3 = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" >>> +SRCREV:radxa-zero-3:rk-u-boot-env = >>> "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" >>> >> >> Master poky now has v2024.10 and at a glance it seems the Zero 3E/W is >> supported, so maybe we could simply ditch those overrides for master >> branch in meta-rockchip? > > This is first time when I started to work with rockchip so I need > some time what is the difference between Kwiboo's u-boot and upstream one. > Welcome to the community then :) https://github.com/Kwiboo/u-boot-rockchip/commits/rk3xxx-2024.07/ about ~30 patches on top of upstream 2024.07. Kwiboo is known for upstreaming his work so it's a good idea to check upstream every now and then. I don't think Kwiboo is guaranteeing his branches won't be rebased (and if he did, it has already happened here :) ). Another option is to ask Trevor or someone else to have a git repo with commit 8cdf606e616baa36751f3b4adcfaefc781126c8c hosted somewhere publicly and point at there while they guarantee they will never delete, remove or rebase the branch or repo. > If there is no any specific patches and the difference is only that some > patches haven't been upstreamed then I prefer this approach. Otherwise ... > I would personally just build upstream and see what's broken there (if there's something broken). >> >> Other release branches should probably get a fix similar to the one in >> this patch though. Or ideally just download the patches from that tree >> and apply them on top of v2024.07 for styhead (we would need a new >> release branch for that though). Scarthgap has v2024.01 so that's a >> bit too old to apply patches destined to 2024.07. But we could maybe >> point to v2024.07 upstream+patches instead of pointing to Jonas >> (Kwiboo)'s personal git repo. >> What do you think? Trevor, an opinion here? > > ... v2024.07 upstream + patches will be the best one option we could > have now. > > I have the small issue here. At the moment I don't have radxa-zero-3 > board so I can check only build. My target is RV1103 SoC for which I > want to add support to Yocto. But > I think that I can start in parallel update u-boot recipe for radxa- > zero-3 too and then ask someone to test on a board. It would be nice if Trevor still has in his DL_DIR in his build bots the archive for the commit that isn't reachable anymore. Then he can generate the patches on top of v2024.07 and it'll essentially be the exact same code as here and even guaranteed to not disappear. Then you don't need to be able to boot it if it's essentially the same patches on the same base. There doesn't seem to be support for RV1103 in the kernel right now and since we use the kernel device tree in U-Boot, there's probably going to be some work there. Do you know how similar RV1103 to RV1108 and RV1109 maybe? https://lore.kernel.org/linux-rockchip/a5d4f421-5120-4421-944e-d39d67e482bb@linumiz.com/ seems like someone is creating some board on that SoC as well, maybe there'll be patches at some point? I would recommend getting familiar with compiling and flashing the kernel and U-Boot manually on your RV1103 device before trying to compile them within Yocto, especially if there are patches to write for both to be able to boot upstream. For downstream (vendor kernel for example), that's a different topic :) Cheers, Quentin
On 12/10/24 5:37 PM, Quentin Schulz wrote: > Hi Oleksii, > > On 12/10/24 5:16 PM, Oleksii Kurochko wrote: >> Hello Quentin, >> >> On 12/9/24 4:22 PM, Quentin Schulz wrote: >>> Hi Oleksii, >>> >>> On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org wrote: >>>> [You don't often get email from >>>> oleksii.kurochko=gmail.com@lists.yoctoproject.org. Learn why this >>>> is important at https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> During the fetch stage of u-boot for radxa-zero-3, the following >>>> issue occurs: >>>> Unable to find revision 8cdf606e616baa36751f3b4adcfaefc781126c8c >>>> in branch >>>> rk3xxx-2024.07 even from upstream >>>> >>>> This happens because the hash of the head commit for the >>>> rk3xxx-2024.07 branch >>>> is different from the one specified in the recipe. >>>> This can be verified by running the following command in >>>> <yocto>/build/tmp/work/radxa_zero_3e-poky-linux/u-boot/2024.01/git: >>>> $ git rev-list -n 1 rk3xxx-2024.07 >>>> 2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead >>>> >>>> Update the SRCREV to the hash of the current head commit >>>> corresponding to >>>> the rk3xxx-2024.07 branch. >>>> >>>> Fixes: e0b13fe834b5("radxa-zero-3{e|w}: add") >>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> >>>> --- >>>> recipes-bsp/u-boot/u-boot_%.bbappend | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u- >>>> boot/u-boot_%.bbappend >>>> index c939a48..9432e2b 100644 >>>> --- a/recipes-bsp/u-boot/u-boot_%.bbappend >>>> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend >>>> @@ -3,8 +3,8 @@ require u-boot-rockchip.inc >>>> FILESEXTRAPATHS:prepend := "${THISDIR}/files:" >>>> >>>> SRC_URI:radxa-zero-3 = "git://github.com/Kwiboo/u-boot- >>>> rockchip.git;protocol=https;branch=rk3xxx-2024.07;name=Kwiboo" >>>> -SRCREV:radxa-zero-3 = "8cdf606e616baa36751f3b4adcfaefc781126c8c" >>>> -SRCREV:radxa-zero-3:rk-u-boot-env = >>>> "8cdf606e616baa36751f3b4adcfaefc781126c8c" >>>> +SRCREV:radxa-zero-3 = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" >>>> +SRCREV:radxa-zero-3:rk-u-boot-env = >>>> "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" >>>> >>> >>> Master poky now has v2024.10 and at a glance it seems the Zero 3E/W >>> is supported, so maybe we could simply ditch those overrides for >>> master branch in meta-rockchip? >> >> This is first time when I started to work with rockchip so I need >> some time what is the difference between Kwiboo's u-boot and upstream >> one. >> > > Welcome to the community then :) Thanks! > > https://github.com/Kwiboo/u-boot-rockchip/commits/rk3xxx-2024.07/ > about ~30 patches on top of upstream 2024.07. > > Kwiboo is known for upstreaming his work so it's a good idea to check > upstream every now and then. I don't think Kwiboo is guaranteeing his > branches won't be rebased (and if he did, it has already happened here > :) ). > > Another option is to ask Trevor or someone else to have a git repo > with commit 8cdf606e616baa36751f3b4adcfaefc781126c8c hosted somewhere > publicly and point at there while they guarantee they will never > delete, remove or rebase the branch or repo. > >> If there is no any specific patches and the difference is only that >> some patches haven't been upstreamed then I prefer this approach. >> Otherwise ... >> > > I would personally just build upstream and see what's broken there (if > there's something broken). Agree, it should the best one option ( considering that Zero 3E/W is present there ). > >>> >>> Other release branches should probably get a fix similar to the one >>> in this patch though. Or ideally just download the patches from that >>> tree and apply them on top of v2024.07 for styhead (we would need a >>> new release branch for that though). Scarthgap has v2024.01 so >>> that's a bit too old to apply patches destined to 2024.07. But we >>> could maybe point to v2024.07 upstream+patches instead of pointing >>> to Jonas (Kwiboo)'s personal git repo. >>> What do you think? Trevor, an opinion here? >> >> ... v2024.07 upstream + patches will be the best one option we could >> have now. >> >> I have the small issue here. At the moment I don't have radxa-zero-3 >> board so I can check only build. My target is RV1103 SoC for which I >> want to add support to Yocto. But >> I think that I can start in parallel update u-boot recipe for radxa- >> zero-3 too and then ask someone to test on a board. > > It would be nice if Trevor still has in his DL_DIR in his build bots > the archive for the commit that isn't reachable anymore. Then he can > generate the patches on top of v2024.07 and it'll essentially be the > exact same code as here and even guaranteed to not disappear. > > Then you don't need to be able to boot it if it's essentially the same > patches on the same base. > > There doesn't seem to be support for RV1103 in the kernel right now > and since we use the kernel device tree in U-Boot, there's probably > going to be some work there. Do you know how similar RV1103 to RV1108 > and RV1109 maybe? > https://lore.kernel.org/linux-rockchip/a5d4f421-5120-4421-944e-d39d67e482bb@linumiz.com/ > seems like someone is creating some board on that SoC as well, maybe > there'll be patches at some point? At the moment, I don't know the specific difference but I am expecting that it should not be too big. > > I would recommend getting familiar with compiling and flashing the > kernel and U-Boot manually on your RV1103 device before trying to > compile them within Yocto, especially if there are patches to write > for both to be able to boot upstream. For downstream (vendor kernel > for example), that's a different topic :) I started to play with their build system ( https://github.com/LuckfoxTECH/luckfox-pico/blob/main/project/build.sh ) but I am not really like it ( at least, sometimes I have to build several times to get finally compiled something ) and it is the reason why I decided to start Yocto port. My first step is to come up with recipes which repeat the way how they are building U-boot and kernel ( based on the source code available in their SDK ) as I am not understand at the moment how big difference is with upstream. Does it make sense to do in that way? And only after that start to look at how to optimize everything and make it looks closer to upstream. ~ Oleksii
Hi Oleksii, On 12/10/24 8:03 PM, Oleksii Kurochko wrote: > > On 12/10/24 5:37 PM, Quentin Schulz wrote: >> Hi Oleksii, >> >> On 12/10/24 5:16 PM, Oleksii Kurochko wrote: >>> Hello Quentin, >>> >>> On 12/9/24 4:22 PM, Quentin Schulz wrote: >>>> Hi Oleksii, >>>> >>>> On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org wrote: [...] >> >> I would recommend getting familiar with compiling and flashing the >> kernel and U-Boot manually on your RV1103 device before trying to >> compile them within Yocto, especially if there are patches to write >> for both to be able to boot upstream. For downstream (vendor kernel >> for example), that's a different topic :) > > I started to play with their build system ( https://github.com/ > LuckfoxTECH/luckfox-pico/blob/main/project/build.sh ) but I am not > really like it ( at least, sometimes I have to build several times to > get finally compiled something ) and it is the reason why I decided to > start Yocto port. > 3000 lines of shell script, what could go wrong. > My first step is to come up with recipes which repeat the way how they > are building U-boot and kernel ( based on the source code available in > their SDK ) as I am not understand at the moment how big difference is > with upstream. Does it make sense to do in that way? > I would still recommend to build the kernel and U-boot and whatever else this monstrosity builds that you need, outside of any build system. It'll help you figure out what is necessary to get your source to build AND be functional. Which will help you writing recipes as clean as possible. Building with Yocto (or any build system) may introduce unnecessary friction when developing low-level BSP code. > And only after that start to look at how to optimize everything and make > it looks closer to upstream. > Not sure what you mean by "optimize everything". For what it's worth, Rockchip's U-Boot vendor tree is absolute garbage and I'm a strong believer that it's a waste of time to try to support your board or fix broken stuff. It is usually not TOO difficult to add support for a new SoC even porting most from Rockchip's vendor tree. You can have a look at the support for the RK3576 on the U-Boot mailing list for example, that should give you some idea of the amount of work to do and which files to pick. But if you have some U-Boot that can already boot a Linux kernel, then maybe start with that instead, baby steps. The kernel is an old Rockchip's vendor kernel based on 5.10. I believe even Rockchip doesn't maintain that anymore (they switched to 6.1 a year ago). U-Boot is 2017.09, from Rockchip's vendor tree as well. I would highly recommend getting rid of this downstream U-Boot as soon as possible. It actually took me more time to support our board on Rockchip's U-Boot than upstream for our RK3588 Jaguar and it was only half working. The faster you can get yourself out of Rockchip assumptions about storage medium partitioning, naming, etc... the better off you'll be. Cheers, Quentin
On Mon 2024-12-09 @ 04:22:47 PM, Quentin Schulz wrote: > Hi Oleksii, > > On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org wrote: > > [You don't often get email from oleksii.kurochko=gmail.com@lists.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > During the fetch stage of u-boot for radxa-zero-3, the following issue occurs: > > Unable to find revision 8cdf606e616baa36751f3b4adcfaefc781126c8c in branch > > rk3xxx-2024.07 even from upstream > > > > This happens because the hash of the head commit for the rk3xxx-2024.07 branch > > is different from the one specified in the recipe. > > This can be verified by running the following command in > > <yocto>/build/tmp/work/radxa_zero_3e-poky-linux/u-boot/2024.01/git: > > $ git rev-list -n 1 rk3xxx-2024.07 > > 2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead > > > > Update the SRCREV to the hash of the current head commit corresponding to > > the rk3xxx-2024.07 branch. > > > > Fixes: e0b13fe834b5("radxa-zero-3{e|w}: add") > > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > > --- > > recipes-bsp/u-boot/u-boot_%.bbappend | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u-boot/u-boot_%.bbappend > > index c939a48..9432e2b 100644 > > --- a/recipes-bsp/u-boot/u-boot_%.bbappend > > +++ b/recipes-bsp/u-boot/u-boot_%.bbappend > > @@ -3,8 +3,8 @@ require u-boot-rockchip.inc > > FILESEXTRAPATHS:prepend := "${THISDIR}/files:" > > > > SRC_URI:radxa-zero-3 = "git://github.com/Kwiboo/u-boot-rockchip.git;protocol=https;branch=rk3xxx-2024.07;name=Kwiboo" > > -SRCREV:radxa-zero-3 = "8cdf606e616baa36751f3b4adcfaefc781126c8c" > > -SRCREV:radxa-zero-3:rk-u-boot-env = "8cdf606e616baa36751f3b4adcfaefc781126c8c" > > +SRCREV:radxa-zero-3 = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" > > +SRCREV:radxa-zero-3:rk-u-boot-env = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" > > > > Master poky now has v2024.10 and at a glance it seems the Zero 3E/W is > supported, so maybe we could simply ditch those overrides for master branch > in meta-rockchip? Yes, and it looks like it's time to also ditch the overrides for rk-u-boot-env as well. When I added that recipe from Jonas, he warned me at that time that switching to upstream would be a better option, but it worked, so I left it for the time-being. > Other release branches should probably get a fix similar to the one in this > patch though. Or ideally just download the patches from that tree and apply > them on top of v2024.07 for styhead (we would need a new release branch for > that though). Scarthgap has v2024.01 so that's a bit too old to apply > patches destined to 2024.07. But we could maybe point to v2024.07 > upstream+patches instead of pointing to Jonas (Kwiboo)'s personal git repo. > > What do you think? Trevor, an opinion here? > > Cheers, > Quentin
Hi Quentin, On 12/11/24 10:25 AM, Quentin Schulz wrote: > Hi Oleksii, > > On 12/10/24 8:03 PM, Oleksii Kurochko wrote: >> >> On 12/10/24 5:37 PM, Quentin Schulz wrote: >>> Hi Oleksii, >>> >>> On 12/10/24 5:16 PM, Oleksii Kurochko wrote: >>>> Hello Quentin, >>>> >>>> On 12/9/24 4:22 PM, Quentin Schulz wrote: >>>>> Hi Oleksii, >>>>> >>>>> On 12/7/24 5:23 PM, Oleksii Kurochko via lists.yoctoproject.org >>>>> wrote: > [...] >>> >>> I would recommend getting familiar with compiling and flashing the >>> kernel and U-Boot manually on your RV1103 device before trying to >>> compile them within Yocto, especially if there are patches to write >>> for both to be able to boot upstream. For downstream (vendor kernel >>> for example), that's a different topic :) >> >> I started to play with their build system ( https://github.com/ >> LuckfoxTECH/luckfox-pico/blob/main/project/build.sh ) but I am not >> really like it ( at least, sometimes I have to build several times to >> get finally compiled something ) and it is the reason why I decided >> to start Yocto port. >> > > 3000 lines of shell script, what could go wrong. Yes, I was surprised about that too... And it was one of the reason why I decided to switch to Yocto and add support for Yocto instead of using this script. > >> My first step is to come up with recipes which repeat the way how >> they are building U-boot and kernel ( based on the source code >> available in their SDK ) as I am not understand at the moment how big >> difference is with upstream. Does it make sense to do in that way? >> > > I would still recommend to build the kernel and U-boot and whatever > else this monstrosity builds that you need, outside of any build > system. It'll help you figure out what is necessary to get your source > to build AND be functional. Which will help you writing recipes as > clean as possible. > > Building with Yocto (or any build system) may introduce unnecessary > friction when developing low-level BSP code. > >> And only after that start to look at how to optimize everything and >> make it looks closer to upstream. >> > > Not sure what you mean by "optimize everything". > > For what it's worth, Rockchip's U-Boot vendor tree is absolute garbage > and I'm a strong believer that it's a waste of time to try to support > your board or fix broken stuff. It is usually not TOO difficult to add > support for a new SoC even porting most from Rockchip's vendor tree. > You can have a look at the support for the RK3576 on the U-Boot > mailing list for example, that should give you some idea of the amount > of work to do and which files to pick. > > But if you have some U-Boot that can already boot a Linux kernel, then > maybe start with that instead, baby steps. > > The kernel is an old Rockchip's vendor kernel based on 5.10. I believe > even Rockchip doesn't maintain that anymore (they switched to 6.1 a > year ago). > > U-Boot is 2017.09, from Rockchip's vendor tree as well. > > I would highly recommend getting rid of this downstream U-Boot as soon > as possible. It actually took me more time to support our board on > Rockchip's U-Boot than upstream for our RK3588 Jaguar and it was only > half working. > > The faster you can get yourself out of Rockchip assumptions about > storage medium partitioning, naming, etc... the better off you'll be. Thanks for recommendations! I will try to follow them. ~ Oleksii
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u-boot/u-boot_%.bbappend index c939a48..9432e2b 100644 --- a/recipes-bsp/u-boot/u-boot_%.bbappend +++ b/recipes-bsp/u-boot/u-boot_%.bbappend @@ -3,8 +3,8 @@ require u-boot-rockchip.inc FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI:radxa-zero-3 = "git://github.com/Kwiboo/u-boot-rockchip.git;protocol=https;branch=rk3xxx-2024.07;name=Kwiboo" -SRCREV:radxa-zero-3 = "8cdf606e616baa36751f3b4adcfaefc781126c8c" -SRCREV:radxa-zero-3:rk-u-boot-env = "8cdf606e616baa36751f3b4adcfaefc781126c8c" +SRCREV:radxa-zero-3 = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" +SRCREV:radxa-zero-3:rk-u-boot-env = "2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead" SRC_URI:append:rk-u-boot-env = " file://rockchip-enable-environment-mmc.cfg" SRCREV:rk-u-boot-env = "cdfcc37428e06f4730ab9a17cc084eeb7676ea1a"
During the fetch stage of u-boot for radxa-zero-3, the following issue occurs: Unable to find revision 8cdf606e616baa36751f3b4adcfaefc781126c8c in branch rk3xxx-2024.07 even from upstream This happens because the hash of the head commit for the rk3xxx-2024.07 branch is different from the one specified in the recipe. This can be verified by running the following command in <yocto>/build/tmp/work/radxa_zero_3e-poky-linux/u-boot/2024.01/git: $ git rev-list -n 1 rk3xxx-2024.07 2e2ae1fb69a25217640bfe2fb9abaf9f4fbacead Update the SRCREV to the hash of the current head commit corresponding to the rk3xxx-2024.07 branch. Fixes: e0b13fe834b5("radxa-zero-3{e|w}: add") Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> --- recipes-bsp/u-boot/u-boot_%.bbappend | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)