Kernel compilation

Ive got a wifi card that is nor supported, (based on the rtl8188 chip)
its actually in the kernel sources 3.14.14 but needed to have a config set…

is there a place we can get hold of the kernel source + patches + config used to build the organelles kernel?

or… can you upload the kernel headers somewhere…

I did look to pacman, pacman -S linux-headers, but its unclear which to take… , id assume either linux-headers-imx6-cubox, or linux-imx6-headers… the later seem to be on 3.14.79-3… so close to this version, but really I need the exact version, also with any appropriate patches applied

I can then build the driver using the following sources:


The following are my notes from compiling the kernel for Organelle:

General instructions here:

starting with this one:

Then making the following config changes:

  1. set default CPU freq / gov to 1GHz (somewhere in power save section, or CPU config… can’t really remember)

  2. enable PREEMPT

Then quick fix for audio right channel click:

in sound/soc/codecs/sgtl5000.c

comment out the line that sets codec to mono to save power in sgtl5000_pcm_hw_params. around line 701

1 Like

ok, so got the ‘unmaintained repo’ :slight_smile:

I can see the preempt, nothing to set cpu frequency… but I would have thought you just set the default scaler to performance (which selects max frequency)

but the above repo is for 3.10.x , whereas organelle is using 3.14.14…

I thought perhaps you merged the solid run upstream 3.14 branch, but thats not possible, as that create hundreds of conflicts.

I did compile the above 3.10 kernel, which was a bit of a pain since you need to go back to gcc 4.7 … as the arm tools have all moved to gcc 5, which is incompatible with kernels younger than 3.18… but hey it worked.

so, it compiled, but doesn’t really get me any further… as its not whats on the organelle :frowning:

its a real pain with SoC boards, they so often use such old kernels, which then leads to other issues…
I’m amazed that SolidRun haven’t tried to document the process for a 4.x kernel

ok, came back to this for another go…

given the kernel version your using is 3.14, Im guessing you must have used the 3.14 LTS… which is not incorrectly linked on the above dev site (to 3.10)

so Ive compiled the latest 3.14 from solid run, which is this:

following the instructions from your link above, with the 3.14 LTS , with
make imx_v7_cbi_hb_defconfig

builds, and boots, but it gets stuck waiting for mmcblk0p1
(this is the same issue I had before when upgrading to a 4.x kernel, so kind of useful if I can get to the bottom of, might enable a much newer kernel)

basically on a normal console you see:

[    1.953073] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[    1.964744] EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature incompatibilities
[    1.965438] EXT4-fs (mmcblk0p1): couldn't mount as ext2 due to feature incompatibilities
[    1.981761] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)

but with this it says, after RAMDISK above

waiting for root device /dev/mmcblk0p1

so… seems like either:
a) something wrong with mmc setup… DTB?
b) cant read the EXT4-fs

(fyi: I’m using the existing u-boot/SPL, I could rebuild, but I suspect that wont make any difference)

is this something you came across when you built the kernel?

is there a way I can attach a serial UART cable to get a console log?
perhaps there is an error earlier that I’m not seeing, that might be enlightening
(over HDMI, theres a screen refresh, so you dont see early part, and some of it zooms off to fast to see)


EDIT: hmm, also seeing the same mmc -110 device error
a search on this says the SD card is corrupt, but its not, I can mount it on another Linux system, change /boot back to old kernel, and it works fine.

I did experience this issue when trying to upgrade, but hadn’t seen it when building the original 3.14. The SOM module only has 1 UART which is wired to the STM32 MCU (and stupidly doesn’t have a jumper and header to attach debug cable). I have managed to get something connected before, soldering right onto a pcb via to TX for listening. for interactive you would need to cut the RX trace… (and also reenable the serial port tty which gets shut off)

Are you able to drop into uboot? not sure if you could get any information from any of the commands in there… probably not.

not the one compiled… I think it has 0 timeout, id assume I could rebuild uboot and extend that, but then I introduce another variable.
did come across a few odd things whilst trying:
a) if I press esc on my mac usb keyboard wildly whilst booting, I can see more messages, so it is doing something, just doesnt drop into u-boot
b) my mac keyboard does not work when organelle drops into the bash prompt !?
though a wireless keyboard i have works fine… but unfortunately is not initialised during uboot
c) because of (a) , even during a ‘good’ boot, I can see uboot is initially complaining about not finding zImage etc, but obviously then later does find it, and boot it… perhaps this is normal

hmm, not sure if i should try to rebuild u-boot now, given I’m a bit unsure if my mac keyboard will work (and i dont have another to use)… and if its going to tell me much.

also i dont think the issue is uboot… since, if I replace the zImage (kernel) I can move between it working and not working, so from this my assumption is, the kernel is building loaded from /boot/zImage … so the error I’m seeing is from the kernel NOT uboot… which means uboot is seeing the mmc ok, since its loading zImage from it.
its rather the kernel, that has the issue accessing mmc, I think to load the root fs.

perhaps something has changed in the device overlays during 3.14 dev, seems odd , to make changes like that in a minor kernel update.

you might be able to halt uboot with ctrl-C, this is supposed to still work if bootdelay=0, but oh yeah maybe not for usb keyboard…

One thing I remember when messing this stuff before was having an image that worked on the Hummingboard but not on Organelle (similar mmc access issue). This is troubling because they have the same boot configuration, suggesting there might be a difference with how the mmc is actually wired… although it has always worked previously without issues. There was some confusion about the card detect signal (always a little different on every uSD card connector), but does the kernel even use this signal?

just to bring this alive again :slight_smile:

ok, so i did a google search for:
“RAMDISK: Couldn’t find valid RAM disk image starting at 0”

and that comes up with some interesting links, I wonder this is the first problem to solve…

some interesting things on this thread -
unfortunately like many imx6/nxp posts, there is no real answer, or suggestions in it.

hmm… so ive got to decide, if im going to give this another shot… where to start?

my ultimate goal now, would be to get the latest arch linux working… which involves the kernel upgrade, but possibly more.
I knowing doing the upgrade, ultimately gives a slightly different (but possibly related error)
about MMC0 - 11 failed to init (as detailed above)

hmm, i also need to decide if the best process is to do cross compilation…

where to start :wink: (again!)