[Buildroot] [PATCH v9 06/11] board/ti/am62x_sk|am64x_sk: switch to TI SDK v8.6 sources

Peter Korsgaard peter at korsgaard.com
Sun Jun 25 15:22:35 UTC 2023


>>>>> "Arnout" == Arnout Vandecappelle <arnout at mind.be> writes:

Hi,

 >>> * TI Linux Kernel v5.10
 >> So this means going from a 6.3 kernel back to a 5.10 (the current
 >> latest
 >> if 6.3, which is what is used in the defconfigs from the two previous
 >> patches). That's a bit unfortunate.
 >> Do you have plans to update to a more recent kernel in the (near)
 >> future? Can't we keep using 6.3 anyway?

 >  We don't actually have a clear policy on whether to use upstream or
 >  vendor kernels for the defconfigs. We have a few boards with both,
 > but IMHO that's not a great approach either.

 >  Personally, I think it makes sense to focus on vendor kernels for the
 >  defconfigs. Using upstream is generally easy, you just have to find
 > the appropriate device tree. But for the vendor kernel, you have to
 > find the repository, which branch is "current", and often also make
 > sure you sync up with U-Boot and OP-TEE etc. versions. @Andreas don't
 > take this as law, though, it's just personal opinion.

Correct, but given the poor quality of most vendor kernels, using a
board with mainline is typically a lot nicer (if the IP blocks you care
about are supported naturally).

Same about the support, E.G. we had issues with various vendor
kernels/bootloaders breaking with newer toolchain versions.


 >  That said, I think for each board we should look at what the vendor
 >  kernel really brings. If everything, including GPU, is working with
 > the upstream kernel, it doesn't make sense to use the vendor kernel. I
 > don't know if that's the case in this specific situation.

 >  Yann, Peter, Romain, Thomas, what do you think?

Agreed. I would in general say go for mainline, unless there is no
decent support in mainline. I would not necessarily think that GPU
support is a requirement, but at least the things used by the defconfig
(E.G. storage, serial, network).

-- 
Bye, Peter Korsgaard



More information about the buildroot mailing list