Re: [yocto] Want to select a SoC with good Yocto support, please advise

Hi Quentin,

Am Fr, 16. Jan 2026, um 12:07, schrieb Quentin Schulz via lists.yoctoproject.org:
> Hi Manuel,
>
> On 1/15/26 3:52 PM, Manuel Wagesreither via lists.yoctoproject.org wrote:
>> Hello everyone,
>> 
>> I'm looking for SoCs that can read 3 MIPI CSI-2 virtual channels (768x576x60fps), do (preferably hardware-accelerated) Lens Distortion Correction (= de-fisheye) and encode the streams to h.264/h.265 or VP8/VP9. I'm not yet sure if I need hardware-assisted auto-exposure control loops via V4L2 and I2C to the camera sensor. Might very well be.
>> 
>> Based on my research, the following SoCs qualify. I don't yet have any practical experience with any of them, and would like to consider the quality of their Yocto support in my decision finding process. In other words: I don't want to shoot myself in the foot by selecting a chip that is a pain to work with or is lazy in updating newer Yocto versions.
>> 
>
> I think you're getting your priorities backwards. People always think 
> they are stuck with whatever vendor BSP layer they get. You're not. You 
> can always port the recipes to newer versions of Yocto. It's not THAT 
> difficult most of the time (I've had extremely cursed BSP layers that I 
> would call BitBake compatible rather than OE-Core/Yocto compatible).
>
> As a matter of fact, the first thing I always do is get rid of the 
> vendor BSP layer and write my own, so I don't get all their crap.
>
> What should matter to you is the actual software support. Kernel support 
> (is it fully upstreamed? if not, is everything you want to use 
> upstreamed? does the vendor participate in efforts in upstreaming (or 
> have a known consulting company doing it for them)). If only downstream, 
> how ugly is it, how much effort would it be for you to port to upstream 
> so you get security and bug fixes without relying on your vendor, U-Boot 
> (or any bootloader), same questions. TF-A, OP-TEE OS, etc... Is there 
> upstream support for the video encoder, if so with which userspace stack 
> (ffmpeg, gstreamer, their own (looking at you Rockchip MPP)). Is it 
> supported upstream or in a fork? If you're planning on selling/operating 
> in the EU, think how much work CRA compliance will be for you if you 
> have to support everything in BSP dowstream forks yourself.
>
> Also be extremely wary of marketing claims. It's not because they say 
> "up to X" that this is actually even achievable in theory. I believe 
> they most of the time just copy whatever the IP vendor tells them and 
> then don't even bother checking if they can actually reach it once 
> integrated in the silicon. Then you have silicon errata where something 
> may not even be achievable (CAN-FD on Rockchip for example from what 
> I've heard), so check those as well.
>
> Rockchip has an FEC (Fish-Eye Correction) ISP, but I don't think they 
> even have software support in their downstream kernel, so you need to 
> check that as well if the selected SoC has actual support for it.
>
> Writing recipes isn't always straight-forward, but compared to patching 
> the kernel, bootloader, userspace video stacks, it's probably a walk in 
> the park.

That's a lot of input and much of it things I didn't consider before. I'll bookmark your mail and come back to it once I have sufficient data to check all the things you mentioned. In the mean time I'll go with Texas Instruments to set up a prototype and gain some actual experience.

Thanks Quentin!

Regards, Manuel