Compile Kernel on RPI2 from RBP2-sources-osmc

infecticide · 18 February 2016 23:22

Hello,

I am attempting to compile a kernel using the rbp2-source-4.4.0-1-osmc package from the repo.

I have experience compiling kernels on x86 / x64 systems but I have had no luck getting a kernel to boot on the RPI2.

I have taken the following steps:

Downloaded and extracted the rbp2-source-4.4.0-1-osmc package from the repo
Copied /boot/config-4.4.0-1-osmc to .config in the source directory
Run make oldconfig
Run make menuconfig
Changed a module to builtin
Saved the config
Run: make zImage modules dtbs
Run: make modules_install
Run: cp arch/arm/boot/dts/*.dtb /boot/
Run: cp arch/arm/boot/dts/overlays/*.dtb /boot/overlays/
Run: cp arch/arm/boot/dts/overlays/README /boot/overlays/
Run: mkknlimg arch/arm/boot/zImage /boot/kernel_custom.img
Edited /boot/config.txt and added: kernel=kernel_custom.img
Reboot
Get black screen, no text, no pretty graphic

DBMandrake · 19 February 2016 00:10

You are probably better off using the build scripts that we use to build OSMC packages. So on your Pi 2 install git and build tools:

sudo apt-get install git build-essential

Then clone the OSMC repository:

git clone https://github.com/osmc/osmc.git

Then cd osmc/packages/kernel-osmc

and make rbp2

That’s it. You will end up with deb packages including an rbp2-image-xxxx-osmc.deb which is the binary version of the kernel ready to install with dpkg. If you want to change the kernel revision, (suffix) edit REV near the start of build.sh.

The way the kernel image packages are set up, which ever one is installed last becomes the active kernel. So you can revert to an earlier kernel by running sudo dpkg-reconfigure <kernel package name>

If you are experimenting with your own kernel builds you probably want to disable the removal of old kernels by editing /etc/osmc/prefs.d/update_preferences, otherwise next time you run a My OSMC update all kernels except for the currently running and most recent version will be uninstalled.

infecticide · 19 February 2016 13:25

Where is the .config file stored so that I can change what I what compiled in vs Modules?

DBMandrake · 19 February 2016 13:39

The RBP2 kernel .config is in the patches directory, as a patch against /dev/null:

github.com

osmc/osmc/blob/master/package/kernel-osmc/patches/rbp2-000-add-kernel-config.patch

--- /dev/null	2023-07-24 23:25:34.863999958 +0100
+++ b/.config	2023-07-25 00:51:35.222411917 +0100
@@ -0,0 +1,7579 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Linux/arm 5.15.92 Kernel Configuration
+#
+CONFIG_CC_VERSION_TEXT="arm-linux-gnueabihf-gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0"
+CONFIG_CC_IS_GCC=y
+CONFIG_GCC_VERSION=110300
+CONFIG_CLANG_VERSION=0
+CONFIG_AS_IS_GNU=y
+CONFIG_AS_VERSION=23800
+CONFIG_LD_IS_BFD=y
+CONFIG_LD_VERSION=23800
+CONFIG_LLD_VERSION=0
+CONFIG_CC_CAN_LINK=y
+CONFIG_CC_CAN_LINK_STATIC=y
+CONFIG_CC_HAS_ASM_GOTO=y
+CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y

This file has been truncated. show original

infecticide · 21 February 2016 01:37

Thank you for the direction, I have been able to compile a kernel that boots with the modules I need builtin.

My next issue is that the USB NIC still doesn’t appear to be detected on boot until after the onboard NIC gets a link.

To clairify, I want to NFS boot from the USB device instead of the onboard NIC. If I connect the network cable to the USB device, it does not register as a network device with a MAC address. If I then disconnect the cable from the USB device, plugin the onboard one, the USB device registers, the onboard NIC gets an address and the NFS boot continues.

[ 3.089318] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 3.092945] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.099291] smsc95xx v1.0.4
[ 3.162057] smsc95xx 1-1.1:1.0 eth0: register ‘smsc95xx’ at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:ef:9c:d4
[ 3.330983] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
[ 3.399080] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
[ 3.504837] usb 1-1.4: New USB device found, idVendor=0b95, idProduct=1790
[ 3.508616] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.512432] usb 1-1.4: Product: AX88179
[ 3.516167] usb 1-1.4: Manufacturer: ASIX Elec. Corp.
[ 3.519915] usb 1-1.4: SerialNumber: 000050B6CAB2C8
[ 13.329078] Waiting up to 110 more seconds for network.
[ 17.574868] random: nonblocking pool is initialized
[ 22.337246] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
[ 22.349767] ax88179_178a 1-1.4:1.0 eth1: register ‘ax88179_178a’ at usb-3f980000.usb-1.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:50:b6:ca:b2:c8
[ 22.369095] Sending DHCP requests …, OK
[ 24.479074] IP-Config: Got DHCP answer from 192.168.2.1, my address is 192.168.2.109
[ 24.483223] IP-Config: Complete:
[ 24.487139] device=eth0, hwaddr=b8:27:eb:ef:9c:d4, ipaddr=192.168.2.109, mask=255.255.255.0, gw=192.168.2.1

I thought perhaps I just didn’t wait long enough on the first attempt. This was not the case:

[ 3.389093] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
[ 3.494842] usb 1-1.4: New USB device found, idVendor=0b95, idProduct=1790
[ 3.498627] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.502477] usb 1-1.4: Product: AX88179
[ 3.506218] usb 1-1.4: Manufacturer: ASIX Elec. Corp.
[ 3.509985] usb 1-1.4: SerialNumber: 000050B6CAB2C8
[ 13.319087] Waiting up to 110 more seconds for network.
[ 18.236851] random: nonblocking pool is initialized
[ 23.319081] Waiting up to 100 more seconds for network.
[ 33.319082] Waiting up to 90 more seconds for network.
[ 43.319081] Waiting up to 80 more seconds for network.
[ 53.319082] Waiting up to 70 more seconds for network.
[ 63.319081] Waiting up to 60 more seconds for network.
[ 71.245553] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
[ 71.250127] ax88179_178a 1-1.4:1.0 eth1: register ‘ax88179_178a’ at usb-3f980000.usb-1.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:50:b6:ca:b2:c8

Any idea why this would be happening? I looked at the Kernel command line:

[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1680 bcm2708_fb.fbheight=1050 bcm2709.boardrev=0xa21041 bcm2709.serial=0xfdef9cd4 smsc95xx.macaddr=B8:27:EB:EF:9C:D4 bcm2708_fb.fbswap=1 bcm2709.uart_clock=3000000 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 root=/dev/nfs nfsroot=192.168.2.100:/nfsshares/rpi/retropie ip=dhcp rootwait osmcdev=rbp2

The only relevant thing I see in there is setting the MAC address for the builtin NIC.

sam_nazarko · 21 February 2016 02:05

This will be quite difficult for you.

ConnMan is set up to ignore eth0 if nfsroot is used. That will need adjusting

initramfs is set up to use eth0 if nfsroot is used, which will also need work.

You will also need to work on start-network to ensure leases are performed on the correct adapter.

SethCohn · 13 February 2017 02:10

Thank you. After trying some unsuccessful methods, this worked well for building a new OSMC kernel for my ATV. (It’s a bit annoying that the config is a diff only (as mentioned elsewhere on this thread), but if you can build a kernel, that’s doable.

sam_nazarko · 13 February 2017 02:13

If you have a better method then I’m open to suggestions.

SethCohn · 13 February 2017 02:41

What’s the advantage to making the standard be a diff against nothing, versus having a real “.config” file you just put into place? You’re already running a script, right? So rather than a patch file diff, you’d only have to maintain a single plain config, and changes would be much easier to track (and generate…) Otherwise, changes requiring making a patch TO a patch file, which is awkward.

In order to make changes I wasn’t sure would even work, I literally ran the script to build, stopped it with a ctrl Z once it did that ‘patch’, ran a make menuconfig to edit and add in the missing kernel options, and then restarted the paused script to let it finish. And crossed my fingers.

In order to make a patch to submit, I’d need to make an diff of the new config to nothing, then make a diff of that to the existing patch/diff. That’s offputting for contribution, honestly.

sam_nazarko · 13 February 2017 02:43

It’s not as complex as you’ve made it seem. Restoring the original config and generating a config based diff can be done with an individual command.

patch -p1 < atv-000*.patch to create config
diff -u /dev/null .config > atv-000*.patch to create the patch containing the config.

The build system is patch oriented, and allows a oneshot solution for applying patches and configuration in one command.

I’m not sure how diff’ing against /dev/null is difficult

The number of contributors to OSMC’s kernel configuration is pretty low, but most are happy to work this out. I’m reluctant to make invasive changes to the build system when the effort->reward ratio would be so low. If you have a proposed patch, then I’d be keen to see it. I’m still looking forward to some pull requests from you to improve OSMC.

sam_nazarko · 13 February 2017 02:46

This is not correct. There is no patching of patching here, unless you are integrating with another build system (like Buildroot in target inst).

SethCohn · 13 February 2017 02:47

Sorry, I wasn’t clearer. I see your point. Working on it now.