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.

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!

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..

selsinork,

you know it is not the fact of announcing "Android Development Kit" for this board that annoys me, it is rather the "exclusively from Farnell" the bad thing.

That's not very clever. I do not understand the interest of having a single distribution channel for a so called "open sourced hardware". For sure if they keep the exclusivity then this board will not be successful and loses its interest. 

I may keep then also the exclusivity of the DTS of this board only for my eyes. Anyway remember, the important thing it is not the board support it is the main chip-set (imx6). For those who are used to mess with kernel sources it is not really a problem, Freescale mx6 has a very thick reference manual !

I know what you mean. There's clearly some marketing nonesense behind it and probably an interest in tapping into the RPi/BBB market with an in-house design where they get to keep more of the profit.

Even so, I'd be less bothered by the 'exclusive' tag if there was some sign of a community developing around the board. All of the successful SBC's are largely single source even when distributed by others, but they all share two things. 1. a helpful manufacturer,  2. an active community.

Time will tell what develops around this board.

You're obviously right about the i.MX6, it has good support, and that's probably why it was chosen.  So even if you don't publish it, I'd be interested in knowing if you get a working DTS for this board. Just knowing it's been done increases my interest somewhat...

Hi there,

Im very interested in a dts for the Riot. Im trying to get a hard float version of linux up and running and have not had success yet. As soon as you can get the dts please publish it!

Thanks.

There should be no problem in doing that. hard-float vs soft-float is primarily a userspace problem.  You can probably take one of Robert Nelsons Debian armhf filesystems from http://eewiki.net/display/linuxonarm/i.MX6x+SABRE+Lite and boot it using the default 3.0.35 kernel.

The main issue with the 3.0.35 kernel will be that it's old and if the (e)glibc in the filesystem has been compiled for a newer kernel  then you won't be able to boot.  In that event, you either need to rebuild glibc against 3.0.35, or port any drivers required from 3.0.35 to a more recent kernel.   What one of those ends up being more work is something you'll need to find out for yourself..

When you will compile the kernel with suitable configs options you will have the floating point unit operational. The key CONFIG_xxx options are :

CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

... and the Makefile will set the flags as convenient... ...you do not need to do anything else. When building packages and root file system libraries (typically with .config.in files or other lib build tools) normally the build scripts will query your kernel and will set the proper flags to compile and use the VFP. As simple as that.

Pablo.

---