Ok, so the LEDEV rig is up and running and a 4.4 test image is finally working on the device. When it comes to bumping up the kernel version, is this the correct way of working (for example using "~/src/lede/target/linux/ar71xx"):
- Alter Makefile to KERNEL_PATCHVER:=4.9
- Rename/copy "config-4.4" to "config-4.9"
- Rename/copy "patches-4.4" to "patches-4.9"
- Walking through all patches in "patches-4.9"
Anything else?
updating the cofig-4.9 with the necessary decisions related to new/changed options.
E.g. with "make kernel_oldconfig"
And updating the patches can be a lot of work. You might look at the discussion in Netgear R7800 exploration (IPQ8065, QCA9984) - #101 by dissent1
Yeah, but it's "only" 91 patches! 
Well, it's just rolling up the sleeves and start digging...
Sorry for being so lazy but what script is applying all the patches? I was thinking to modify it so I can apply one patch at the time manually...
It is actually one of the tools, "quilt". A special tool to apply patch series.
But I have never bothered to really learn quilt. (I have just used make prepare to apply patches and then edited them by hand, when needed.)
And "prepare" step in Makefile does it.
This cmd applies the generic & target patches to kernel sources:
make target/linux/{clean,prepare} V=s
Info also in https://wiki.openwrt.org/doc/devel/patches
(you may also need make target/linux/{clean,refresh} to adjust line numbers & context changes automatically, but refresh may also make erroneous selections if the upstream source has changed too much.)
Excellent, thanks for explaining the patching process! I'll see if I can learn how to make use of quilt to start with.
It seemed that Quilt was only used to generate patches. The script that actually applies all the kernel patches is ~/src/lede/scripts/patch-kernel.sh. It's used both for generic, specific target patches and it's possible to run the patching manually by using the script in following way:
$ patch-kernel.sh linux-targetdir patch-srcdir [single-patch]
where:
- "linux-targetdir" is the automatically generated build dir for the specific target and contains the extracted linux kernel source code to be patched.
- "patch-srcdir" contains all patches to be applied.
- "single patch" - is a single patch that must reside in the patch-srcdir
In my case I use the following syntax:
$ patch-kernel.sh ~/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10 ~/src/lede/target/linux/ar71xx/patches-4.9
I've modified the script (patch-kernel.sh) so that in case a patch either fails or was already applied upstreams, it'll be moved to two different subfolders in the patchdir called "failed" respectively "upstreamed"
From the 91 patches that were originated from 4.4, it all boiled down to the following:
> - Applied Ok: 77
> - Upstreamed: 2
> - Failed: 12
I'll work with the failed patches during the upcoming weeks and I've already identified of bunch of patches that's just outdated and probably already implemented upstream in v4.9.
There are some patches I need help to solve since I don't get the logic and the lack of comments is not very helpful either. The one I'm thinking on in this particular case is the mdt driver (m25p80.c) patch 407 and 412. ppdata seems totaly obsolete and it looks like part_probes is already implemted but in a different way. Any comments would be helpful and greatly appreciated!
Here is my current ar71xx/4.9 tree on github: (Boilerplate4u/source)
- branch ar71xx_kernel4.9: https://github.com/Boilerplate4u/source/tree/ar71xx_kernel4.9
- ar71xx target: https://github.com/Boilerplate4u/source/tree/ar71xx_kernel4.9/target/linux/ar71xx
- 4.9 patch dir: https://github.com/Boilerplate4u/source/tree/ar71xx_kernel4.9/target/linux/ar71xx/patches-4.9
- failed: https://github.com/Boilerplate4u/source/tree/ar71xx_kernel4.9/target/linux/ar71xx/patches-4.9/failed
- upstreamed: https://github.com/Boilerplate4u/source/tree/ar71xx_kernel4.9/target/linux/ar71xx/patches-4.9/upstreamed
- script patch-kernel.sh: https://github.com/Boilerplate4u/source/blob/ar71xx_kernel4.9/scripts/patch-kernel.sh
- exampel of patch-kernel.sh usage: do49patches.sh
I've completed most patches and am in an early alpha phase when trying to compile the 4.9 kernel and have some issues.
I’m trying to make use a .config file that was extracted from a standard dist (lede-imagebuilder-ar71xx-mikrotik.Linux-x86_64.tar.xz) but got the error “No rule to make target 'modules'”. The problem is that I'm quite inexperienced when comes to the build process and the different configuration stages thus I'm not sure if it’s a technical problem or procedural issue caused by the config file.
Btw, is it sufficient to just run "make menuconfig", load the config file from a standard dist and then run Make or do you need to prepare any additional changes?
Snippet error log (full log in http://pastebin.com/X3t2RLJu)
make[3]: Entering directory '/home/lars/src/lede/target/linux'
make[4]: Entering directory '/home/lars/src/lede/target/linux/ar71xx'
make -C /home/lars/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10 HOSTCFLAGS="-O2 -I/home/lars/src/lede/staging_dir/host/include -I/home/la
/lede/staging_dir/host/usr/include -Wall -Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="mips-openwrt-linux-musl-" ARCH="mips" KBUILD_HAVE_NLS=no KBUILD_BUILD
"" KBUILD_BUILD_HOST="" KBUILD_BUILD_TIMESTAMP="Tue Feb 21 10:14:58 2017" KBUILD_BUILD_VERSION="0" HOST_LOADLIBES="-L/home/lars/src/lede/staging_dir/host/lib" CONFIG_SH
ash" V='' CC="ccache_cc" modules
make[5]: Entering directory '/home/lars/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10'
make[5]: *** No rule to make target 'modules'. Stop.
make[5]: Leaving directory '/home/lars/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10'
Makefile:24: recipe for target '/home/lars/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10/.modules' failed
make[4]: *** [/home/lars/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10/.modules] Error 2
make[4]: Leaving directory '/home/lars/src/lede/target/linux/ar71xx'
Makefile:13: recipe for target 'compile' failed
--
Any ideas?
Standard dist has no real default config. Just the defaults that the buildbot has picked up from the package & target definitions.
It is enough to delete .config totally and then just select the device in "make menuconfig. It creates the whole .config. Then normal make.
Using imagebuilder's .config will not work. Imagebuilder is a special build by itself and sets abnormal options. Scrap that idea.
Okidoki, thanks!
I discovered I've actually had an old D-Link DIR-615 that was just lying around but got the same error using the v4.9 environment. When I went back to v4.4, then everything worked flawlessly even with the imagebuilder config file.
I have a feeling that the problem originates from the kernel front end program (scripts/config/config) that feeds the linux config process. My guess it's either a bug in the config process that needs to be adjusted to work with v4.9 or perhaps something else that must to be configured to make it all work.
Output from the linux-4.4 environment when all runs normally:
make[5]: Entering directory '/home/boilerplate/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.4.49' HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig net/sched/Kconfig:44: warning: menuconfig statement without prompt # # configuration written to .config # CHK include/config/kernel.release UPD include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s CHK include/generated/bounds.h UPD include/generated/bounds.h CHK include/generated/timeconst.h UPD include/generated/timeconst.h CC arch/mips/kernel/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h CALL scripts/checksyscalls.sh HOSTCC scripts/dtc/dtc.o . . . . . .
Same output from the linux-4.9 environment when it fails. See line "Restart config...
make[5]: Entering directory '/home/boilerplate/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.9.10' HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig net/sched/Kconfig:44: warning: menuconfig statement without prompt * * Restart config... * * * Kernel type * Kernel code model > 1. 32-bit kernel (32BIT) choice[1]: 1 KVM Guest Kernel (KVM_GUEST) [N/y/?] n Kernel page size > 1. 4kB (PAGE_SIZE_4KB) 2. 16kB (PAGE_SIZE_16KB) 3. 64kB (PAGE_SIZE_64KB) choice[1-3]: 1 Maximum zone order (FORCE_MAX_ZONEORDER) [11] 11 SmartMIPS or microMIPS ASE support > 1. None (CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS) choice[1]: 1 Allow for memory compaction (COMPACTION) [N/y/?] n Enable KSM for page merging (KSM) [N/y/?] n Low address space to protect from user allocation (DEFAULT_MMAP_MIN_ADDR) [4096] 4096 Enable cleancache driver to cache clean pages if tmem is present (CLEANCACHE) [N/y/?] n Enable frontswap to cache swap pages if tmem is present (FRONTSWAP) [N/y/?] n Contiguous Memory Allocator (CMA) [N/y/?] n Common API for compressed memory storage (ZPOOL) [N/m/y/?] n Low (Up to 2x) density storage for compressed pages (ZBUD) [N/m/y/?] n Memory allocator for compressed pages (ZSMALLOC) [N/m/y/?] n Enable idle page tracking (IDLE_PAGE_TRACKING) [N/y/?] n Timer frequency 1. 24 HZ (HZ_24) 2. 48 HZ (HZ_48) > 3. 100 HZ (HZ_100) 4. 128 HZ (HZ_128) 5. 250 HZ (HZ_250) 6. 256 HZ (HZ_256) 7. 1000 HZ (HZ_1000) 8. 1024 HZ (HZ_1024) choice[1-8?]: 3 Preemption Model > 1. No Forced Preemption (Server) (PREEMPT_NONE) 2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) 3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT) choice[1-3]: 1 Kexec system call (KEXEC) [N/y/?] n Kernel crash dumps (CRASH_DUMP) [N/y/?] n Enable seccomp to safely compute untrusted bytecode (SECCOMP) [N/y/?] n Support for O32 binaries using 64-bit FP (MIPS_O32_FP64_SUPPORT) [N/y/?] n MIPS FPU Emulator (MIPS_FPU_EMULATOR) [N/y/?] n Kernel appended dtb support > 1. None (MIPS_NO_APPENDED_DTB) 2. vmlinux (MIPS_ELF_APPENDED_DTB) 3. vmlinux.bin or vmlinuz.bin (MIPS_RAW_APPENDED_DTB) choice[1-3]: 1 Kernel command line type 1. Dtb kernel arguments if available (MIPS_CMDLINE_FROM_DTB) 2. Extend dtb kernel arguments with bootloader arguments (MIPS_CMDLINE_DTB_EXTEND) > 3. Bootloader kernel arguments if available (MIPS_CMDLINE_FROM_BOOTLOADER) 4. Extend builtin kernel arguments with bootloader arguments (MIPS_CMDLINE_BUILTIN_EXTEND) (NEW) choice[1-4]: aborted!
Not sure which command you used to get there. Does the error materialize if you do it manually, with "make kernel_oldconfig" or "make kernel_menuconfig"?
(If there is a new option prompt without default answer, the automatic oldconfig does not know what you want.)
Or alternatively, some patch contains a formatting error that invalidates the config source script.
Sorry, forgot to mention the output came from running a normal make at the build root. All the v4.9 patches succeeds.
My gut feeling says it's related to the build system that loses sync when talking to the linux kernel config system, like getting a EOF that causes the "choice[1-4]: aborted!"
In the case of v4.4 it says
scripts/kconfig/conf --silentoldconfig Kconfig net/sched/Kconfig:44: warning: menuconfig statement without prompt # # configuration written to .config #
By using v4.9 you will instead get:
scripts/kconfig/conf --silentoldconfig Kconfig net/sched/Kconfig:44: warning: menuconfig statement without prompt * * Restart config... * * * Kernel type * . . . . . . Kernel command line type 1. Dtb kernel arguments if available (MIPS_CMDLINE_FROM_DTB) 2. Extend dtb kernel arguments with bootloader arguments (MIPS_CMDLINE_DTB_EXTEND) > 3. Bootloader kernel arguments if available (MIPS_CMDLINE_FROM_BOOTLOADER) 4. Extend builtin kernel arguments with bootloader arguments (MIPS_CMDLINE_BUILTIN_EXTEND) (NEW) choice[1-4]: aborted!
If that error comes during the normal make, then it is quite similar to what happens in buildbot when there is an unanswered kernel option change.
your config-4.9 is missing a few new kernel options and you need to provide answers.
try "make kernel_oldconfig".
That's probably the root cause, thumbs up! I'll test that tomorrow...
Btw, are there any docs available how to utilize "make kernel oldconfig"? Google just gives me some scattered results...
Not really.
(and it is kernel_oldconfig . Don't forget _ )
Basically the config routine goes through the existing config file (probably one you copied from config-4.4), and presents you with new options from 4.9 and usually offers a default answer. New options are marked with "(NEW)". kernel_oldconfig jumps over the already known options.
You should usually take the default, but in cases where the option has relevancy to the router functionality, you should make the correct selection... (at the first stage, just answer the default)
E,g, for ipq806x there are new drivers in 4.9 for new chips. Do I want them? Likely not.
perus@ub1610:/Openwrt/r7800$ make kernel_oldconfig
make[1]: Entering directory '/Openwrt/r7800/target/linux'
make[2]: Entering directory '/Openwrt/r7800/target/linux/ipq806x'
...
net/sched/Kconfig:44: warning: menuconfig statement without prompt
*
* Restart config...
*
*
* Qualcomm Support
*
Qualcomm Support (ARCH_QCOM) [Y/n/?] y
Enable support for MSM8X60 (ARCH_MSM8X60) [Y/n] y
Enable support for MSM8960 (ARCH_MSM8960) [Y/n] y
Enable support for MSM8974 (ARCH_MSM8974) [Y/n] y
Enable support for MDM9615 (ARCH_MDM9615) [N/y] (NEW)
Kernel version bump from 4.4 to 4.9 is not an easy jump. Quite much depends what has happened for that target/chipset in Linux.
Thanks! And yes, porting it's definitely a challenge! :- ) Fortunately most older SoC drivers haven't changed very much but parts of the IPv6 stack is totally rewritten. I found alot of very useful patches that IMO should be handed over to the linux maintainers. That will also easy up future porting to new linux versions...
Hi Boilerplate4U. Did you succeed in building a 4.9 kernel?
Is anyone working on 4.9 for ar71xx?