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

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

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