Board device tree.

It's my understanding that the supported linux kernel is the 3.0.35 version, this is before devicetree came to the arm architecture.

I've not been able to find anything beyond the kernels at https://github.com/embest-tech/linux-imx as mentioned in the users manual.  So it's likely there simply isn't a dts for this board.

Depends on how they've configured the default kernel, but you may be able to get the config used by looking at the contents of /proc/config.gz

Well this helps a little bit but it is not really the way it should be done.

iMX6 has multifunctional IOs and each board use them in different ways. At

the given pointer it is rather difficult to know how io muxing has been

done.

If you have a look at similar boards like "wandboard" you will see that

same IOs are not used for the same functions.

Official linux kernel release provides already support for Wandboard,

Olinuxino, Zedboard and other equivalent boards based on A10, A13, A20.

I do not like the idea of having a cooked kernel for this one, I prefer to

have the freedom of doing all from scratch.

I asked the question just not to do the work twice. Apparently nobody has

done the dts file for this board yet. I'll try to get it done based on

latest kernel release. The compiled kernel should be the same for all iMX6

platforms, the only thing that should change is the device tree for each

specific board this is the trend to follow on ARM Linux kernels now and

forget on specific mach-xxxx directories.

Hi selsinork. Can you share the updated dts, or where you got it from?

Hi Ian,

Basically I put it together myself, partly based on looking at what Pablo did, and partly by comparing what various other i.MX6 boards were doing.

However there's a wrinkle.. quite a big one actually.  The various devicetree files for i.MX6 underwent a large-ish reorganisation in the 3.15 merge window,  this changes a list of aliases that Pablos dts references meaning that his dts won't compile after the change. My version is based on having these changes in place.

It seems likely that a compiled dtb from either will work across the boundary. My dts might work prior to the change, but I've not tested it that way.

The change in question is "ARM: dts: imx6qdl: make pinctrl nodes board specific" 817c27a128e18aed840adc295f988e1656fed7d1 and rather than trying to pick a commit ID thats far enough past it I've simply been waiting for 3.15-rc1 to be released as an easy to find point where we know the changes are in place.

FWIW, Eric Bénard said he might submit a dts for RIoT to mainline last weekend here http://article.gmane.org/gmane.comp.boot-loaders.u-boot/183812 but so far I've not seen them posted. We're essentially in the same position with Erics u-Boot patches, they've been accepted but won't get merged until sometime after the release of v2014.04 which may happen tomorrow.

For now, you can find my dts at https://github.com/selsinork/linux/commit/bd96f28b53a34f4aabfe34e22ceccf60e33f8ae8 in the riotboard-dts branch

There are still some things to resolve:

• i2c4 is missing a clock and I've not had time to figure out how to solve that
• I've not tested usb-otg
• haven't added led class support for the two user leds yet
• camera interfaces are missing
• hdmi/lvds missing

the last two are not so much of a problem right now as there are no drivers in mainline for them at this point.

I've tested audio out, usb hotplug, eMMC/SD/uSD cards all of which work. UART and PWM drivers load although I've only physically confirmed the debug uart works so far.

Any gpio pins on the expansion header that are not claimed by another driver will probably work ok, I've only confirmed a couple so far.

Hope you find it useful, please let me know if you find any problems as if Eric doesn't post his dts then I'll probably submit this to mainline once I'm happy with it.

So, having had a look, i2c4 needs something more invasive than a change to the devicetree.

It appears that the imx6quad & dual have ecspi5 where the duallite/solo have i2c4 instead, this causes some changes to the clock infrastructure that appear to have been overlooked up to now - nothing else is currently using i2c4.

So for now since i2c4 is only used for the camera interfaces, I think we'll leave it non-functional while I go and find the right people to propose a fix to.  It's likely any fix will miss the 3.15 merge window anyway, so no big loss for now, we have some time to get the fix ready for 3.16.

Thanks for the info selsinork. I'd like to help out with testing etc., but I'm busy climbing the yocto learning curve, having used ltib & ptxdist before (and pre-devtree kernels). I'll get there, eventually. The camera interface is of interest to me, since that's partly why I got the board.

I'd seen Eric's u-boot patch, but missed his comment about his dts. Thanks for that pointer too.

good luck with yocto, I gave up and used linuxfromscratch.org to build myself out of all of the distro nightmares.

Cameras are something I'm interested in as well, any sort of sensible support in upstream anything seems to be quite rare currently. I've seen a couple of cameras for Sabre-Lite and wandboard which in theory should be useable. Only problem is that they're either insanely expensive, or shipping charges to the UK are.

Anyway, I hopefully have a patch for i2c4, just need to test it.  devicetree setup for the physical camera interface is probably simple enough too.

Getting a test setup running is probably fairly easy outside yocto, all you really need is patched u-boot, patched kernel, and it's likley easy enough to adapt one of Robert Nelsons minimal Debian filesystems - use the wandboard or sabre-lite ones and there may be no changes needed at all.

If you're willing to tackle yocto, you'll probably find that easy

Probable i2c4 fix here https://github.com/selsinork/linux/commit/307b206ca99e74c9555555de6849ce22518c9185

It appears to work for me, but waiting for some confirmation from upstream that nothing else is required.

Looks good. Is there a handy way to correlate <&clks 116> to clk[ecspi5], other than counting the enum (which is a bit tedious)? If not, then some comments in the enum wouldn't go amiss.

Also, I hadn't realised that i.MX6S and i.MX6DL are the same silicon. Bond option to disable the other A9 core I guess (and the unbonded DDR channel).

I don't know enough about the clock framework to be sure, but I think that enum is totally arbitrary.  I found the one to change by using the register offset for i2c4, identified what that was in the quad then looked for the clock it was using in the matching dtsi.  Slightly less tedious than counting the enum

Only later did I find Documentation/devicetree/bindings/clock/imx6q-clock.txt which has a list.

I've posted to the appropriate ML asking if it's acceptable to do it this way, I'm slightly worried they'll ask to split it to clk-imx6dl.c since the name is different, but we'll see.

Going by the datasheets, essentially the Quad/Dual are the same, the DualLite/Solo are the same, and then the SoloLite is the third variant.  There also seems to be variants within these groups depending on whether it's an automotive/consumer/whatever but I assume, perhaps wrongly, that's mostly bonding options as the code doesn't seem to differentiate.

Updated devicetree files can be found in my github repo here https://github.com/selsinork/linux/commits/riotboard-dts2

It includes support for everything there's a driver available for in 3.15-rc*. There seems to be some problems with the imx-drm driver picking invalid modes/clocks at the moment, so to get output on hdmi I need to add video=HDMI-A-1:800x600@60 to the kernel command line.

LVDS output to the LCD8000-97C works fine, however there's no driver for the touchscreen controller it uses in mainline at the moment.

For useable ethernet you probably also want to add enable_wait_mode=off

Probable i2c4 fix here https://github.com/selsinork/linux/commit/307b206ca99e74c9555555de6849ce22518c9185

It appears to work for me, but waiting for some confirmation from upstream that nothing else is required.

The change was accepted upstream, but will take some time to filter through.

Probable i2c4 fix here https://github.com/selsinork/linux/commit/307b206ca99e74c9555555de6849ce22518c9185

It appears to work for me, but waiting for some confirmation from upstream that nothing else is required.

The change was accepted upstream, but will take some time to filter through.