OpenWrt Forum Archive

Topic: How to build the Kernel only?

The content of this topic has been archived on 13 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

We are using the OpenWRT build system to build an x86 based embedded environment. However, after taking in Kernel version 4.8.6, we are experiencing a couple of nasty errors.

In order to investigate these errors, I need to rig the Kernel and build it separately. I am not new to configuring, (cross-)building and installing a Kernel onto embedded platforms, but I am new to OpenWRT.

According to the documentation, I can build the Kernel using:
make -j8 target/linux/compile V=s
Unfortunately, this only seems to rebuild the Kernel modules.

I can get the Kernel configured and built cleanly using:
make -j8 target/linux/{clean,compile,install} V=s
But besides from taking a long time, this produces a Kernel almost double in size, so no identical to the one produced with:
make world V=99

Can anybody please tell me how I can do an incremental build on the kernel in build_dir, using the OpenWRT build system? Any help is appreciated.

robert_d wrote:

We are using the OpenWRT build system to build an x86 based embedded environment. However, after taking in Kernel version 4.8.6, we are experiencing a couple of nasty errors.

While compile or boot the system ??

elektroman wrote:

While compile or boot the system ??

No errors compile time. When I power up the system, it reboots half the times right after decompressing the Kernel. Once it reboots, it remains in an 'infinite' reboot loop. Only after a power-cycle there's a 1 in 2 chance it boots normally again.

It occurs to me as a hardware initialization error, yet at the same time I'm wondering what hardware could be initialized that early besides memory. To learn more, I would like to build the Kernel separately, but 'make world' takes a little bit too long. And 'ARCH=x86 CROSS_COMPILE=~/src/openwrt/staging_dir/toolchain-i386_gcc-4.8-linaro_eglibc-2.17/bin/i486-openwrt-linux-gnu- make -j8' in the build directory produces a Kernel double the size.

Oh, and by the way; The previous Kernel we used, 3.4.112, works and has always worked beautifully.

More questions ...
4.8.x kernel is not in stock OpenWRT git nor in LEDE git
how do you update the kernel ??

There is an separate section in
https://wiki.openwrt.org/doc/devel/patches
for kernel updates.
Do you follow the recipe
"Adding or editing kernel patches"
So in

target/linux/generic/

must be a directory

patches-4.8

and also in

target/linux/x86

You must copy every single patch here from the "older" patch directory i.e.

patches-4-4

separately and do a full kernel build with

make V=s -j1

maybe you can do more than one patch here

They are some crucial patches i.e.

target/linux/x86/patches-4.4/100-fix_cs5535_clockevt.patch

which is needed for AMD Geode platforms

elektroman wrote:

More questions ...
4.8.x kernel is not in stock OpenWRT git nor in LEDE git
how do you update the kernel ??

We updated the Kernel archive to 4.8.6, obtained from kernel.org, and we manually merged configuration, updated patches, etc.

The cause for slow builds is also found: OpenWRT also builds our userland application, in several configurations, and always clean. I'm gonna familiarize myself with OpenWRT a bit more to see how I can exclude that...

The most nasty error I was after, was the system resetting right after decompressing and starting the Kernel. The cause of that problem is also found: The Kernel was trying to update the CPU's MicroCode, without any MicroCode actually built in or in initrd. There's definitely some checking missing in the code there, but since the function responsible is called with the 32th instruction in .../arch/x86/kernel/head_32.S, debugging is a bit too cumbersome to figure out the exact error mode. Disabling CONFIG_MICROCODE all together cured the problem. However; Other suggestions are most welcome.

As for the clean builds: ccache is present on your system?

Not skilled enough to comment on the other problems smile.

Borromini wrote:

As for the clean builds: ccache is present on your system?

No, it is not; I hadn't even heard of it before reading your post.
Would you recommend installing it? Just on workstations, or on build servers too?

@elektroman: Thank you for the URL and the explanation. I wish we had that earlier. We figured it out all by ourselves, not necessarily coming up with the same solution. However, our end result is a pretty good match. We do have the patches directories, etc.

robert_d wrote:

The cause for slow builds is also found: OpenWRT also builds our userland application, in several configurations, and always clean. I'm gonna familiarize myself with OpenWRT a bit more to see how I can exclude that...

I would suggest first build only with minimal config and without your userland application in OpenWRT, i.e. clean new directory.
Use the new

git worktree

feature for this.
You can also copy

~/openwrt/dl

folder

robert_d wrote:

The most nasty error I was after, was the system resetting right after decompressing and starting the Kernel. The cause of that problem is also found: The Kernel was trying to update the CPU's MicroCode, without any MicroCode actually built in or in initrd.

initrd is out of date and not used in OpenWRT

Which subarch you are using ??
386, 486, ...
If you are using 386 current kernel will not boot and with 486 you need a hardware FPU
x86 is a big range of cpu's and variants. I knew about two/three vendors outside Intel/AMD which build their own cpu.

Bootlog please ...

I would suggest search from scratch.
For this you need the vanilla kernel only

I'm using 486. And there is no bootlog, because the error occurs _very_ early. Apparently, the code seems to detect a valid MicroCode update in random memory contents. When downloading this 'update' into the CPU, it resets.

We don't use MicroCode updates, so out-configuring CONFIG_MICROCODE in the Kernel was the easiest solution for me; Without printk or JTAG debugger, it is very cumbersome to diagnose this false positive detection.

Anyway, thanks of all the help guys!

To you want cut on the run ???

robert_d wrote:

I'm using 486. And there is no bootlog, because the error occurs _very_ early. Apparently, the code seems to detect a valid MicroCode update in random memory contents. When downloading this 'update' into the CPU, it resets.

It may possible ...

robert_d wrote:

We don't use MicroCode updates, so out-configuring CONFIG_MICROCODE in the Kernel was the easiest solution for me; Without printk or JTAG debugger, it is very cumbersome to diagnose this false positive detection.

No need for JTAG maybe serial output from printk ...

Do you considered using
"git bisect ??"
To test the vanilla kernel ..

The discussion might have continued from here.