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.

You're absolutely right, devicetree is the way to go today for current kernels. Unfortunate then that this particular board has no upstream support in current kernels, or in upstream u-boot.  Personally, I'm holding off on getting one until there's at least some indication that there's at least a plan to push support upstream. Like you say, it's mostly just an appropriate dts that's needed. The manufacturer not doing it isn't a particularly good sign though. That said, it does appear to be firmly aimed at android, so possibly Linux isn't something they're particularly interested in.

The commit to add RIoT support is this one: https://github.com/embest-tech/linux-imx/commit/a0660f4c989e6874d79b9a6d737b3f9fe7228057

the detail of the pinmux configuration is buried in there, mostly in the board files arch/arm/mach-mx6/board-mx6q_riot.c & arch/arm/mach-mx6/board-mx6dl_riot.h in the way that was normal for Arm before devicetree came along.

Freescale have moved on to a 3.10.17 base kernel here http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.17_1.0.0_beta that does include devicetree, but as far as I can tell there's nothing in there for RIoT either.

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.

One thing that I notice being different for RIoT is the PMIC driver. None of the other i.MX6 drivers appear to have it.  So I wonder if it'll be as simple as producing the dts, you may also need to write the PMIC driver for the newer kernel - it might be there, I didn't check.

It's all very well saying it's not the way it should be done.. fact is this is the way it has been done. We either have to live with that, fix it ourselves, or use a different board. Wandboard is cheap, easy to use and already has support, so maybe it's a better choice for you. It is for me

I do not think PMIC management is a big deal. I think it is driven by I2C right ?

If it is the case you can handle it at application level.

You can always consider it as fixed regulator in the dts it will not hurt.

Wandboard is cheapest ?! I'm not sure of that. Take a look at Mouser supplier.

Wandboard in equilavent "Solo" version, has less DDR memory and no NAND Flash, right ?

... and fixed regulators by the way.

OK Wandboard is better supported today but Riotboard is younger ... it is just a question of time. It will surely end-up having good support as well.

Ignoring the PMIC may, or may not be as easy as you make out.  Ask yourself why it's on the board and why the supplied kernel has a driver. What functionality do you lose by not having the driver?  Does the board boot at all without it?   I don't have the answer, but I'd want to know the consequences before assuming I could do what you suggest.

I didn't say wandboard was cheaper, just that it's cheap.  The RIot having more memory, NAND or whatever is not in any way important if it's not useable due to lack of support

As to whether the RIoT will gain better linux support than it has today.. Well that's down to either it's manufacturer to develop, or for the community to provide.

Generally the place to look for i.MX community support is in the tree Shawn Guo at linaro provides here http://git.linaro.org/people/shawn.guo/linux-2.6.git and there's no sign of RIoT there. 

The MarS board is the immediate predecessor to the RIoT, http://www.element14.com/community/docs/DOC-55820?ICID=knode-sabre-space

it's been around quite a bit longer and yet there's been no sign of it gaining community support, involvement, or any interest whatsoever. No upstream support of any sort that I've been able to find. So your argument that it's just a question of time doesn't hold up, otherwise we'd have good MarS support by now.

Early days for RIoT. From what we know it's being aimed at Android. Possibly only at Android.

So it's unclear at this point whether a linux community will evolve around it or not. I don't think we can assume it will become the next Raspberry Pi, but anything is possible if the manufacturer wishes to push it in a particular direction.

So if I well understood you are not interested in my DTS and  my tunned Linux kernel 3.14-rc3 running on this board right ?  ;-p.

You know, all you can do with a board like this it is not always available on the net.

I'm interested, sure.  Is anyone else ?

That said, I'm not interested if your dts that doesn't bother with proper PMIC configuration causes my board to release it's magic smoke

Remember in all of this, I'm just another user wondering if I want to waste my time/money/energy with this board or not.  I'm not a representative of the manufacturer, the distributor, Freescale or anything similar.  My interest is in boards that already run 3.14-rc3 and that therefore have viable upstream kernel support.  If you happen to make that a reality for RIoT, then it becomes much more interesting for me!

So this popped up on the main site the other day.

That seems to make it clear that it's aimed very much at Android..