Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1] 2
Author Topic: Debianized Packaged Kernels
EHeM
Advanced
Posts: 58
Permalink
Post Debianized Packaged Kernels
on: June 26, 2014, 07:03
Quote

The topic is a goal I've been hoping to get accomplished and have been doing experiments in this direction. Figuring out the structure of how OpenWRT does its kernel/module builds is the first step. Sometimes merely figuring out all the variables to enable full debug output is a bit of a trick. So far the ones I've got are DUMP=1 KBUILD_VERBOSE=1 NO_COLOR=2 V=99 during the openwrt/all build step. In order to get even more detail running the command:

find ${builddir} ( -name Makefile -o -name \*.mk ) | xargs sed -i -es/^\^V^I@/\^V^I/

After the OpenWRT Subversion tree has been checked also gets you more output (note ^V^I is control-V/tab). So far it looks like the build goes into the kernel tree multiple times, and some of the key kernel modules are outside the kernel tree (the broadcom wireless driver, the switch driver and "wprobe").

I currently foresee creating 4 packages: linux-patch-openwrt, linux-patch-brcm47xx, linux-package-brcm4716, and linux-image-rt-n16. While OpenWRT has fully merged their brcm4716 support into their brcm47xx support, right now Debian is on a 3.2 kernel where the 4716 patches are still separate.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: July 1, 2014, 03:53
Quote

List of (some) current puzzles/issues.

I've noticed OpenWRT's generic patch 910-kobject_uevent.patch. This appears to only be used by the broadcom-diag kernel module. Despite the filename, this kernel module appears to be a diagnostic tool created by OpenWRT, not Broadcom. Pretty well the only thing this patch does is move the sequence number incrementing in the function kobject_uevent_env() file lib/kobject_uevent.c into a new function uevent_next_seqnum(). I'm left with two concerns, first the usage inside broadcom-diag increments the sequence number and throws it away, second I'm left wondering about performance implications of this. With this situation, I think disabling the patch and removing the call from broadcom-diag is the way to go.

The real puzzle is where 3 kernel modules are coming from: ledtrig-netdev.c, yaffs2 and crypto/ocf. I see the files after the kernel is built, but I haven't found where the heck in the OpenWRT tree they originate. Somehow it looks like somewhere something ignores the debug build flags.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: July 19, 2014, 06:40
Quote

The actual kernel build directory for OpenWRT is <openwrt-dir>/build_dir/target-*/linux-<processor/config>/linux-<linux-ver>/ The kernel source gets downloaded into <openwrt-dir>/dl, then unpacked into the build directory. Patches and added files are located in <openwrt-dir>/target/linux. The first piece is to identify the OpenWRT architecture ("brcm47xx" for the Broadcom 4718 in an ASUS RT-N16), everything is setup in <openwrt-dir>/target/linux/<arch>. The setting "LINUX_VERSION" in the architecture Makefile determines the kernel version. First everything in <openwrt-dir>/target/linux/generic/files and <openwrt-dir>/target/linux/<arch>/files is copied into the kernel directory. Second, the patches in <openwrt-dir>/target/linux/generic/patches-<kernelver> are applied, followed by the patches in <openwrt-dir>/target/linux/<arch>/patches-<kernelver>.

Originally I had hoped to aim for basing everything off of Debian stable's kernel, version 3.2. This would have been based off OpenWRT's trunk, revision 30857 and the RT-N16 patches of 2012-03-09T19-52; unfortunately trying to adjust all the patches seems to be a bit too complex to make a realistic goal. Debian has a 3.10 kernel available on backports, the current package is linux-source-3.10_3.10.11-1~bpo70+1_all.deb, this can be readily merged with OpenWRT's revision 37999 patches.

Once patched, using the command `make-kpkg --arch mipsel --initrd --cross-compile mipsel-linux-gnu- kernel_image` on a Debian system with kernel-package and gcc-<ver>-mipsel-linux-gnu packages should result in an appropriate kernel package. So far though I haven't gotten a build to successfully get kexec'd. I'm guessing either some kernel module needs to be built-in or kernel config option is wrong. I'm now waiting for a TTL-level serial cable to arrive before pushing further.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: July 26, 2014, 06:17
Quote

Well, good news, bad news.

The good news is I have built and packaged a 3.2 kernel that boots on an ASUS RT-N16. The bad news is I need to figure out building the switch support. As of right now I only get to talk to the device via the serial port, networking isn't functional right now.

Another quirk is the kernel command-line. I've noticed OpenWRT adds a feature that overrides the passed-in kernel command-line. I'm sure OpenWRT likes this, but this is bad for DebWRT's purposes. Then there is the task of getting everything to properly interface with kernel-package (right now I've got a tarball of some files plus all the patches ported from OpenWRT). Then there is the issue of the 802.11n interface...

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: August 5, 2014, 06:19
Quote

I got to the point where I had enough confidence in the kernel patches to place them in Subversion and they are now in the contrib branch. They've ended up as 5 beginnings of packages, linux-patch-openwrt, linux-patch-brcm47xx and linux-patch-brcm4716 are the primary ones. OpenWRT though includes many patches/files with their primary patches, so I've split out linux-patch-yaffs2 and linux-patch-ocf. Nominally you'll need all of these to produce a truly "compatible" OpenWRT kernel, but I wouldn't be surprised if the two extras get removed in the future.

Then comes the issue that dh-kpatches is orphaned. I've generated scripts for helping with application and removal (these also warn about ordering and their inter-dependencies), but I'm left unsure of the appropriate path to take.

Beware as noted in the previous message, while these can produce a kernel image that can be successfully kexec'd the support for the switch chip is a separate module which isn't yet taken care of.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: August 6, 2014, 04:15
Quote

I'm continuing this project and I've now got what looks to be pretty well working kernel patch packages. Note these are for the build host, not the router. They can be built by running the command `dpkg-buildpackage -b` in the appropriate directory. Now comes the issue of finding kernel .config files for the various devices DebWRT targets. Then will be the issue of porting all the other hardware/device specific patches. I suggest staying with OpenWRT's revision 30857 to match the existing patches.

I'm now aiming towards packaging the switch module.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: August 9, 2014, 06:30
Quote

I've managed to successfully get the kernel modules built, at the moment though Debian packaging is a ways from working. With the kernel modules manually installed, telling the switch to act like needed was successful. Unfortunately this led to me discovering the system clock is severely fast with the patch revision I've got. As such two major issues remain before having an ASUS RT-N16 working with pure Debian packaged tools, then the next issue will be getting the 802.11 portion operational.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: August 20, 2014, 03:47
Quote

Finally got the switch module fully packaged and appears to function well enough to get the switch working. The Real Solution(tm) of course is generating an updated swconfig package, but this was faster for the moment. With that the immediate issue becomes getting the Broadcom 4716 patches updated to fix the system clock. After that I think I'll be aiming to improve the libnl-tiny and swconfig packaging jobs.

Anyone know whether ASUS has a Developer Relations department? If so, does anyone have contact information for them?

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: August 22, 2014, 04:45
Quote

Appears everything is more or less packaged and working. Right now my two greatest concerns are, first it is quite likely the setups are missing dependancies, second the copyright notices aren't in the greatest shape (I claim copyright over the packaging jobs, but everything else belongs to others). All of these packages in their basic form are intended for the build host, they're then meant to be used to build kernel packages/module packages which get installed on the device. For people wanting to experiment, these are currently in the contrib tree and the target "debian/package/buildhost"
should build all of them. Next step will be gathering working configurations known to work on devices and generating make rules for building kernels for all hardware. In addition to working over the swconfig build, I also need to generate similar packaging for the other key modules (notably broadcom-wl).

If anyone is wondering why I'm spending the time to fully package the kernel, the answer is simple: security updates. While network exploits of the Linux kernel are pretty uncommon, even local vulnerabilities need to be addressed (lest they allow escalation of other vulnerabilities). So the point is these allow rebuilding based on Debian's kernel source, which gets security updates.

EHeM
Advanced
Posts: 58
Permalink
Post Re: Debianized Packaged Kernels
on: September 7, 2014, 06:32
Quote

I'm continuing to experiment with the aim of getting working 802.11 on top of a Debian-packaged kernel. There are 3 distinct drivers for the Broadcom chips, mentioned here. The one pure OpenWRT uses is the Broadcom 'wl' driver; however, it looks like George's patches for the RT-N16 include at least an attempt to get the b43 driver working. The b43 driver simply needs minor kernel reconfiguration plus the firmware-b43-installer package to get the required firmware. For the wl driver, the broadcom-sta-source package should make it possible to get Broadcom's binary-only driver working.

I think I've got a kernel configuration that includes the b43 driver, but some work with the patches is still needed. This should be fairly straightforward, but I may have to fall back to the wl driver.

Pages: [1] 2
Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.037 seconds.