On Wed, 2014-12-10 at 19:24 +0800, Chen Baozi wrote:
> Hi Ian,
>
> > On Dec 10, 2014, at 19:05, Ian Campbell <i...@hellion.org.uk> wrote:
> >
> > On Wed, 2014-12-10 at 18:24 +0800, Chen Baozi wrote:
> >> However, I found that it (menuconfig) doesn’t actually affect the real
> >> configs while doing binary-arch packaging (though it does change
> >> debian/build/build_armhf_none_armmp-lpae/.config). What I have done
> >> (while testing) was adding the required configs to the end of
> >> debian/build/config.armhf_none_armmp-lpae (for temporary packaging test).
> >
> > To make them permanent you want to be adding the differences from the
> > baseline to debian/config/armhf/config*. Most likely to config.armmp
> > (which is the baseline for armmp-lpae too).
>
> Thanks. But I guess people usually do that after they can be sure what
> configs should be included? I’m wondering if there would be a way
> to change the configurations which then leads to incrementally building
> rather than rebuilt the binary from scratch, which does take a relatively
> long time :) Or people are just simply “make” the debian kernel rather
> than doing real packaging while testing?
If it is a non-trivial change (like more than enabling one or two
options given in a bug report) then I usually start from the current
Debian config with a tree outside the Debian build (but with similar
contents) and iterate building and testing there until I have something
working. I'll cherry pick patches etc as necessary as well as
tweaking .config.
Once I have a working tree then for the config I essentially:
make -f ./debian/rules.gen setup_armhf
and diff the resulting debian/build/..../.config with what I iterated to
manually, then edit debian/config/..., rerun setup_armhf, repeat.
Any cherry-picked patches I'll move into debian/patches in the usual
way.
> >> The second question is about adding missing .ko while making initrd.
> >> Right now, in order to include necessary regulator drivers
> >> (palmas-regulator.ko etc.) in the initrd, I have to manually add
> >> the required modules in /etc/initramfs-tools/modules. Is it necessary
> >> to look into initramfs-tools and make a patch to include the required
> >> .ko by default? Or there are other preferred ways to solve the
> >> problem if the OMAP5432 uEVM can be called supported by Debian.
> >
> > This is the job or initramfs-tools. v0.118 in sid tries harder to load
> > things like regulators, clk, phy and pinctrl, what version are you
> > using?
>
> v0.118 is the current version I used, but looks like it doesn’t include
> the regulator .ko properly on OMAP5432 uEVM unless I told it explicitly...
Probably best to file a bug then. The maintainers will likely want to
know the names of all the missing modules, plus the contents of /sys
("find /sys -ls", I suppose).
If you want to dig into this yourself then look for the file
hook-functions in initramfs-tools and search for "regulator", there are
two references corresponding to the MODULES=dep and MODULES=most
configurations. Since it isn't working I expect you are using
MODULES=dep which is handled with:
# sys walk some important device classes
for class in gpio phy regulator; do
for device in /sys/class/$class/*; do
device="$(readlink -f "$device")" \
&& sys_walk_mod_add "$device"
done
done
MODULES=most copies the whole of kernel/drivers/regulator, which seems
less likely to be able to go wrong.
Ian.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1418211729.3505.13.ca...@hellion.org.uk
