2 Replies Latest reply on May 20, 2015 11:54 AM by intel_jassowski

    Bitbaking Edison Realtime Xenomai Kernel

    intel_jassowski

      Previously, I attempted (and failed) to compile a realtime Xenomai kernel on Edison itself.  Didn't work.  I couldn't even compile a regular kernel on Edison itself.

      Not to be discouraged, I decided to get over my Yoctophobia and try to bitbake a Xenomai kernel.  And failed again.

       

      This post is an overview of what I did:

      1. In case someone out there sees something I did wrong, or
      2. Someone can figure out what is not working with the resultant image and get this to work.

       

      Starting point: A standard bitbake of an edison-image following the steps in the Edison BSP guide.

      This works great.  The challenges start when I attempt to apply the Xenomai patch.

      1. There is no ipipe patch for the 3.10.17 kernel.  The closest patch is for 3.10.32.  So I figure: "What's 15 revision between friends"?  Apparently only 3 source files.
      2. Three files didn't patch automatically.  I was able to merge the changes manually by inspection.  I created an ipipe-core-3.10.17.patch file to apply these manual changes automatically (attached).
      3. I struggled constantly with patching ipipe code in the middle of bitbake'ing.  Bitbake usually detected that I modified the code, and did it's best to re-download new code to reverse the changes I made.  Yes: a bitbake recipe would be ideal here.  But that turned out to be far beyond my ability.  I was eventually able to find a set of bitbake commands that appeared to allow me to continue baking with the ipipe patch applied.
      4. Linux-yocto compile then failed in sst.c, apparently some DSP code in the Intel SoC sound section.  Do I need sound? Nah...
      5. I attempted to switch off that portion of code using CONFIG_SND_INTEL_SST=n, but that didn't work.  So a comment in the linux/sound/soc/intel/Makefile to comment out the OBJ line for sst/ seemed in order.
      6. After a "successful" compile, I got an image that I was able to flash to the Edison.

       

      Unfortunately, but not unexpectedly, I got a kernel oops (also attached).

       

      The lines which seem most interesting are:

      [    0.839479] BUG: unable to handle kernel NULL pointer dereference at   (null)

      [    0.839618] IP: [<  (null)>]   (null)

      [    0.839685] *pdpt = 0000000000000000 *pde = c000faf9c000faf4

      [    0.839780] Oops: 0010 [#1] PREEMPT SMP

      .....

      [    0.847575] Code:  Bad EIP value.

      [    0.847651] EIP: [<00000000>] 0x0 SS:ESP 0068:f6c3799c

      [    0.847740] CR2: 0000000000000000

      [    0.847852] ---[ end trace 3283f48702799447 ]---

      [    0.847921] note: swapper/0[1] exited with preempt_count 1

       

      To replicate my lack of success, here are the steps to follow:

      ./meta-intel-edison/setup.sh --dl_dir=bitbake_dl_dir/ --sstate_dir=bitbake_sstate_dir/

      source poky/oe-init-build-env

      vi conf/local.conf  # Set Threads/CPUs

      bitbake -c compile linux-yocto

      cd ..

      xenomai-2.6.3/scripts/prepare-kernel.sh --adeos=<path to>/ipipe-core-3.10.17.patch --linux=build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux

      cd build/

      bitbake virtual/kernel -f -c menuconfig # Set all of the variables as is defined in the attached defconfig

      cp tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux-edison-standard-build/.config ../meta-intel-edison/meta-intel-edison-bsp/recipes-kernel/linux/files/defconfig

      cp tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux-edison-standard-build/.config tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux/arch/x86/configs/i386_edison_defconfig

      bitbake virtual/kernel -c configure -f -v # Dang... this re-downloads the source and reverses my xenomai patch...

      cd ..

      xenomai-2.6.3/scripts/prepare-kernel.sh --adeos=<path to>/ipipe-core-3.10.17.patch --linux=build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux

      cd build

      cp edison_xenomai_defconfig tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux/arch/x86/configs/i386_edison_defconfig

      cp edison_xenomai_defconfig tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux-edison-standard-build/.config

      bitbake virtual/kernel -c configure -f -v # Now the patch seems to stick...

      bitbake edison-image  # this fails with an error in sst.c

      vi tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux/sound/soc/intel/Makefile  # comment out OBJ target with sst/ in it

      bitbake edison-image

      ../meta-intel-edison/utils/flash/postBuild.sh

       

      Now you have a Real-time, but brain-dead kernel.

       

      Now, to phrase this in a question: can anyone see anything I did wrong (other than the obvious: try to compile a realtime kernel :-))