Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote:
> I have a glance at the kernel’s installer configs and tried the netboot
> without any modification. Some work should be done to make debian-installer
> support OMAP5 uEVM (e.g., ethernet driver etc).
Right, those should be listed in e.g.
debian/installer/armhf/modules/armhf-armmp/nic-modules.
> By waiting the kernel building with some initial attempted configs added,
> just one question to ask. I looked through the
> debian/installer/armhf/modules/armhf-armmp/, but it looks like none of
> files is about regulator modules. However, according to my previous
> experience, missing regulator driver modules is the main reason that
> the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer
> deal with this situation (if it does need extra regulator drivers included?)
Long term its a bit of an open question what we do wrt modules such as
regulators, clocks, pinctrl etc.
So far we have been a bit lucky: either such things are so central to
the platform that it is acceptable (at least for now) to just build them
into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410
which is for the main power controller on arndale) or they are closely
associated with some particular device and it makes sense to put them in
that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in
usb-modules).
Eventually I expect that we will end up creating separate udebs for
these things, but I'm hoping that we can defer that until at least
Stretch to avoid needing to mess around with any more new packages for
Jessie.
If uEVM has some module which either shouldn't be built in or isn't
obviously associated with a particular device let us know what it is and
we can have a think about how best to approach it.
One thing I've played with, and I'm not sure if this is acceptable or
not, is to put core drivers which aren't =y into the kernel-image udeb
itself. I'm not really sure if that's a good idea, we don't currently do
this for anything AFAIK, but it's perhaps an option.
Ian.
Reply to: