Intel® Makers
Intel® Edison, Intel® Joule™, Intel® Curie™, Intel® Galileo
Welcome - This is a Peer-to-Peer Forum only. Intel has discontinued these products but you may find support from other customers on this Forum
9882 Discussions

i2c speed reduction II: Grafting yocto kernel into ubilinux

New Contributor II

Hi All

There is finally someone responding over at Emutex Labs.

I discussed the issue of i2c bus speed reduction and how the kernel needs to be recompiled with certain flags set as per

Now while the obvious solution is for Emutex to do this I get the feeling that their position is that they are using the current yocto kernel and won't change until yocto does and even them I'm guessing it will be just a vanilla yocto.

Now firstly it seems to me to be almost an oversight that yocto isn't compiled by default with these flags, well at least the yocto that intel uses for the edision anyway.

However I did float the idea that if the kernel unbilinux is the same as the yocto one then perhaps if could be grafted into a ubilinux system.

Now is this sane/possible?? I know this is Emutex's responsibility but can I get some advice as to whether this is an idea worth perusing.



12 Replies

Hi John

Do you want to build the kernel using the BSP for Yocto and then use the filesystem and all the configurations to set Ubilinux?

If this is the case, I think it is possible but you must spend some time while attaching the Ubilinux OS.


Why you don't try to build the image with the changes you mentioned? I think it would be easier than including another OS to the BSP.



New Contributor I

Yeah, it works; I've helped do it before. I don't recall the steps exactly, since I was only half helping with this part of the project, but it involved setting up the kernel config you want in yocto, running the yocto build process, extracting the kernel and modules from the resulting yocto image, copying them to an Edison running ubilinux, and rebooting.

New Contributor II

Thanks guys

I'll look into it

New Contributor II

Hi All

As and update I have learnt that the yocto BSP 2.1 has the required CONFIG_I2C_DW_SPEED_MODE_DEBUG flag already set. Well the kernel's defconfig file has it set so I'm guessing that a default compile of the BSP will have it set.

So is there an easy way of telling which kernel the ubilinux used? I'm guessing it can't have had this flag set as there are missing files / directories on the system for changing the i2c speed.

I guess at least the good news is that I should be able to use a precompiled BSP for the grafting.

Any thoughts anyone?


Hi John,

You can run uname -a in the board, you should see the Kernel version of the board.

You can use the BSP for Yocto and check if you get improvements with it.



New Contributor II

Thanks. Yes that was a bone headed question as I found uname about 2sec after I made the last post.

But now I'm confused as the kernel version is 3.10.17 in the BSP 2.1 (where supposedly the flag is set) and ubilinux also has 3.10.17

So now I'm beginning to question whether the ubilinux kernel has the ability to change the speed of the i2c bus or not.

Ubilinux doesn't have the files/directories present for the step [ write "std" to < /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode > file ]

There is no i2c_dw_sysnode directory

So what makes these directories? are they real or do they get mapped from the kernel on boot???

Any ideas. Perhaps I need to flash an edison back to std with the BSP to see if there is a difference.


Hi John,

Have you tried another way to change the I2C speed? Did you contacted EmutexLabs with this?

What is the output of ls /sys/device ?

Did you move to Yocto?



New Contributor II


I finally got around to reflashing yocto. The i2c speed change just works and the directory /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode is present

unlike ubilinux.

Yes I contacted ubilinux but it seems all a bit beyond them. Their position was that that they use the intel yocto kernel. So beyond that they don't know.

So I'm now just looking for people who might know anything about the issues. So where do the directories come from. Is it possible that ubilinux DOES have the correct flag set in the kernel but that the directories haven't been set up correctly? I don't know? I just don't know enough about linux to know what goes on.


Perhaps I'll have to stick with yocto for my application.


the output of uname -a is


3.10.17-poky-edison-ww42+ # 4 SMP PREEMPT Wed Oct 29 12:41:25 GMT 2014 i686

BSP 2,1

3.10.17-poky-edison+ # 1 SMP PREEMPT Fri Jun 19 12:06:40 CEST 2015 i686 GNU/Linux


Hi John,

I'm glad to know that you have found a workaround for your situation.

Now, I encourage you to open a new discussion in our communities or in EmutexLabs where you and other makers that use the Ubilinux image could discuss about the image and it features.

As you know the supported image is Yocto but I know there are other makers that use Ubilinux and they could help you with this.



New Contributor II

So I have taken the plunge and swapped out the kernel.

It broke heaps of stuff but I have the new kernel in ubilinux. The directories ARE present to change the i2c speed. So when I get back to a CRO I'll test it.

For anyone else who is interested how

- You download version 2.1 of the complete yocto image from intel


- unzip

- copy edison-image-edison.ext4 onto a linux machine or the edison with WinSCP

- mount edison-image-edison.ext4 on a linux machine or the edison with

# mkdir -p /tmp/mount_tmp/

# mount -o loop,rw,edison-image-edison.ext4 /tmp/mount_tmp

- then extract the kernel file from /tmp/mount_tmp/boot (I can't remember the name of the file, I'll look and update this post)

- and copy it into /boot

- move vmlinuz (the current kernel file) to somewhere safe as a backup

- I then renamed the new kernel vmlinuz but this might not be necessary

I'll keep people posted on any progress


Here is my dmesg output for anyone interested to see the mess, but hey it boots!

[ 0.000000] Initializing cgroup subsys cpuset

[ 0.000000] Initializing cgroup subsys cpu

[ 0.000000] Initializing cgroup subsys cpuacct

[ 0.000000] Linux version 3.10.17-poky-edison+ (sys_dswci@tlsndgbuild004) (gcc version 4.9.1 (GCC) ) # 1 SMP PREEMPT Fri Jun 19 12:06:40 CEST 2015

[ 0.000000] e820: BIOS-provided physical RAM map:

[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000097fff] usable

[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000003ffffff] usable

[ 0.000000] BIOS-e820: [mem 0x0000000004000000-0x0000000005ffffff] reserved

[ 0.000000] BIOS-e820: [mem 0x0000000006000000-0x000000003f4fffff] usable

[ 0.000000] BIOS-e820: [mem 0x000000003f500000-0x000000003fffffff] reserved

[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved

[ 0.000000] BIOS-e820: [mem 0x00000000fec04000-0x00000000fec07fff] reserved

[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved

[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved

[ 0.000000] NX (Execute Disable) protection: active

[ 0.000000] SMBIOS 2.6 present.

[ 0.000000] DMI: Intel Corporation Merrifield/BODEGA BAY, BIOS 466 2014.06.23:19.20.05

[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable

[ 0.000000] e820: last_pfn = 0x3f500 max_arch_pfn = 0x1000000

[ 0.000000] MTRR default type: uncachable

[ 0.000000] MTRR fixed ranges enabled:

[ 0.000000] 00000-9FFFF write-back

[ 0.000000] A0000-BFFFF uncachable

[ 0.000000] C0000-FFFFF write-back

[ 0.000000] MTRR variable ranges enabled:

[ 0.000000] 0 base 000000000 mask FC0000000 write-back

[ 0.000000] 1 base 03F600000 mask FFFE00000 uncachable

[ 0.000000] 2 base 03F800000 mask FFF800000 uncachable

[ 0.000000] 3 base 004000000 mask FFE000000 uncachable

[ 0.000000] 4 disabled

[ 0.000000] 5 disabled

[ 0.000000] 6 disabled

[ 0.000000] 7 disabled

[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

[ 0.000000] original variable MTRRs

[ 0.000000] reg 0, base: 0GB, range: 1GB, type WB

[ 0.000000] reg 1, base: 1014MB, range: 2MB, type UC

[ 0.000000] reg 2, base: 1016MB, range: 8MB, type UC

[ 0.000000] reg 3, base: 64MB, range: 32MB, type UC

[ 0.000000] total RAM covered: 982M

[ 0.000000] Found optimal setting for mtrr clean up

[ 0.000000] gran_size: 64K chunk_size: 512M num_reg: 5 lose cover RAM: 0G

[ 0.000000] New variable MTRRs

[ 0.000000] reg 0, base: 0GB, range: 512MB, type WB

[ 0.000000] reg 1, base: 64MB, range: 32MB, type UC

[ 0.000000] reg 2, base: 512MB, range: 512MB, type WB

[ 0.000000] reg 3, base: 1014MB, range: 2MB, type UC

[ 0.000000] reg 4, base: 1016MB, range: 8MB, type UC

[ 0.000000] e820: update [mem 0x04000000-0x05ffffff] usable ==> reserved

[ 0.000000] initial memory mapped: [mem 0x00000000-0x023fffff]

[ 0.000000] Base memory trampoline at [c0094000] 94000 size 16384

[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]

[ 0.000000] [mem 0x00000000-0x000fffff] page 4k

[ 0.000000] init_memory_mapping: [mem 0x37800000-0x379fffff]

[ 0.000000] [mem 0x37800000-0x379fffff] page 2M

[ 0.000000] init_memory_mapping: [mem 0x34000000-0x377fffff]

[ 0.000000] [mem 0x34000000-0x377fffff] page 2M

[ 0.000000] init_memory_mapping: [mem 0x00100000-0x03ffffff]

[ 0.000000] [mem 0x00100000-0x001fffff] page 4k

[ 0.000000] [mem 0x00200000-0x03ffffff] page 2M

[ 0.000000] init_memory_mapping: [mem 0x06000000-0x33ffffff]

[ 0.000000] [mem 0x06000000-0x33ffffff] page 2M

[ 0.000000] init_memory_mapping: [mem 0x37a00000-0x37bfdfff]

[ 0.000000] [mem 0x37a00000-0x37bfdfff] page 4k

[ 0.000000] BRK [0x01e27000, 0x01e27fff] PGTABLE

[ 0.000000] 121MB HIGHMEM available.

[ 0.000000] 891MB LOWMEM available.

[ 0.000000] mapped low ram: 0 - 37bfe000

[ 0.000000] low ram: 0 - 37bfe000

[ 0.000000] BRK [0x01e28000, 0x01e28fff] PGTABLE

[ 0.000000] Zone ranges:

[ 0.000000] DMA [mem 0x00001000-0x00ffffff]

[ 0.000000] Normal [mem 0x01000000-0x37bfdfff]

[ 0.000000] HighMem [mem 0x37bfe000-0x3f4fffff]

[ 0.000000] Movable zone start for each node

[ 0.000000] Early memory node ranges

[ 0.000000] node 0: [mem 0x00001000-0x00097fff]

[ 0.000000] node 0: [mem 0x00100000-0x03ffffff]

[ 0.000000] node 0: [mem 0x06000000-0x3f4fffff]

[ 0.000000] On node 0 totalpages: 251031

[ 0.000000] free_area_init_node: node 0, pgdat c1c59e40, node_mem_map f740e020

[ 0.000000] DMA zone: 32 pages used for memmap

[ 0.000000] DMA zone: 0 pages reserved

[ 0.000000] DMA zone: 3991 pages, LIFO batch:0

[ 0.000000] Normal zone: 1752 pages used for memmap

[ 0.000000] Normal zone: 216062 pages, LIFO batch:31

[ 0.000000] HighMem zone: 243 pages used for memmap

[ 0.000000] HighMem zone: 30978 pages, LIFO batch:7

[ 0.000000] Using APIC driver default

[ 0.000000] SFI: Simple Firmware Interface v0.81

[ 0.000000] SFI: SYST E61F0, 0060 (v1 INTEL INTELFDK)

[ 0.000000] SFI: CPUS E6296, 0020 (v1 INTEL INTELFDK)

[ 0.000000] SFI: FREQ E62C2, 0030 (v1 INTEL INTELFDK)

[ 0.000000] SFI: MMAP E62FE, 01A4 (v1 INTEL INTELFDK)

[ 0.000000] SFI: XSDT E64B0, 002C (v1 INTEL INTELFDK)

[ 0.000000] SFI: APIC E653E, 0020 (v1 INTEL INTELFDK)

[ 0.000000]...

New Contributor II

Right, so success!!! I have fixed the modules issues and confirmed that I can change the i2c speed on ubilinux To fix the modules issues you copy the /lib/modules files out of the new BSP from intel in the same way as the kernel an put them on the ubilinux device. Reboot and all should be well. I'll post the exact commands when I get a chance. So you can use STD FAST and HIGH modes but FAST and HIGH are both at 384kHz. STD is a solid 100kHz for i2c bus 1 # echo std > /sys/devices/pci0000:00/0000:00:08.0/i2c_dw_sysnode/mode for i2c bus 6 # echo std > /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode I can't guarantee that there are more things broken but basic drivers now work.

New Contributor II

I just found out that the permissions on the tmp directory were all screwed up. sudo chmod 1777 /tmp sudo chown root:root /tmp ironically I have discovered that the device I was want to use will work at FAST speeds after all :(