Hi Yann,
Thanks for the patch updates. I'll look at them soon.
On Mon 2021-03-22 @ 04:31:01 PM, Yann Dirson wrote:
> BTW, I'm also unclear on what to do next to better support those
> boards: with the default
> kernel config only a subset of the hardware is supported, and for
> state-of-the-art hw
> support we'll also need patches not yet in upstream kernel (from eg.
> armbian and libreelec).
>
> I feel it would be good to provide defconfig files for those machines,
> but then there are
> several options to handle that. Would a minimal hw-focused defconfig
> suitable for
> `KCONFIG_MODE = "--allnoconfig"` be a good option ?
I feel exactly the same way.
By default all arm64 kernels are configured with the one, in-kernel, generic
arm64 defconfig. That gives me a kernel that is over 11MB in size, and
includes all sorts of useless drivers.
I've been working off-and-on on a mechanism for meta-rockchip that would allow
users to decide between the default in-kernel arm64 defconfig (which would
be selected by doing nothing) or using a leaner defconfig that I have been
tweaking specifically for each board. Currently I only have a lean defconfig
for rock-pi-4b, but it was my hope to generate defconfigs for all supported
boards.
Ideally I had wanted to leverage the linux-yocto kmeta mechanism to generate
defconfigs dynamically based on the specific machine and specific user
preferences, but that didn't go as smoothly as I was hoping, then I got
distracted by other things.
I had created a spreadsheet with a comparison between the various boards that
would have been a basis for the individual kmeta pieces. Maybe I'll find some
more time to poke at it later this week. I could also push my WIP stuff to
somewhere if you'd like to take a look.
In any case, my point is, I'm very interested in something better than what
currently exists :-)
One thing that I'd like to keep clear in meta-rockchip is to always allow the
user to choose between upstream and "extras". My feeling is: the simplest
build, if the user does nothing explicit, will always pull from pure upstream
with no out-of-tree patches or vendor pieces. But I'm not opposed to having
a mechanism whereby if the user does something explicit, they can choose to
use a vendor tree or make use of out-of-tree patches for various things.
Best regards,
Trevor
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52796): https://lists.yoctoproject.org/g/yocto/message/52796
Mute This Topic: https://lists.yoctoproject.org/mt/81524395/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
