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.

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.

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.

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.

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.