Re: [yocto-patches] [meta-rockchip][PATCH] u-boot: Update SRCREV for radxa-zero-3

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6460 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 9885 bytes --]