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.

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.

Hi pablo

Im interested in the dts and linux build that you may have put together for this board. Are you able to send a link to these If you have made them available?

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

Sorry, I've been quite busy lately and I couldn't play with the board.

Attached dts and linux config files that you can use to build the kernel. I made a quick test with kernel 3.13.5 (latest stable) taken directly from kernel.org.

It seemed to work well, "selsinork" should not be worried : there was no smoke coming out from the board ;-p !

I did not verify everything (not much time to play with). I'm not a graphical man I mainly work on basic UART console but there is no reason why the frame buffer on HDMI should not work.

I'll verify of course but I need time to sit down and install a windows manager or something...

Are you OK with these files ? do know how to build the kernel on your own with a dtb file or do you need instructions ? Please, feel free to ask.

By the way, do you have a suitable bootloader. I made also some patch on u-boot repository to boot on uSD... If you need it I need to recover my sources from my mess ! ... I had a little problem with my disk.

Pablo.

---

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.

---

Thanks Pablo!

I haven't build a kernel before so Ill be learning on the go for this one. Any help you can give will be appreciated.

Thanks

Marius

Thanks Pablo!

I haven't build a kernel before so Ill be learning on the go for this one. Any help you can give will be appreciated.

Thanks

Marius

I started a discussion regarding this on google+ at https://plus.google.com/106211083737445953476/posts/ahYHhxRZt6a

Do you know what is required to get this into the mainline kernel as suggested by Peter?

OK then let's do it from scratch then.

First : get the cross compile toolchain.

You have several choices. Build the toolchain from scratch ... or take one already "baked".

I advise you to take the later one. I guess that your host system will be a desktop PC (i686 or similar) running Linux, right ?

Then, go to for example to http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/

and download - "Download the GNU/Linux Release" for ARM processors.

You need to register to get a download link (it will be sent by mail). So use your real mail or a secondary mail to get it.

Install it to your home directory. It should be ".tar.bz2" file. Just

tar xvjf arm-2013.11-33-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

OK the toolchain for cross compiling should be fine.

Second : The kernel sources.

wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.13.5.tar.gz

Well, If you want to get this into the kernel main line you need to spend some time reading in kernel.org how to proceed. It is not a simple process. I personally do not have time to do it. But of course, this is open source you can submit by yourself if you are really motivated. In that case I suggest you to use git to clone the kernel repository and generate a patch in order to submit the change. You need to be familiar with git and how it works and follow the rules of kernel repository...

So, either you use "wget" to do something locally on your system or you use "git" to clone the kernel repository.

I need to go now. Make a reply to this when you are ready and I'll continue the instructions.

Pablo.

---

Howdy Pablo,

I managed to get the new kernel compiled on the RIOT itself with your config and dts last night before I read your response. However what I do not know is what to do next. I ran the make install as instructed on kernel.org, however it hasn't made the RIOT actually boot the new kernel. I have all the images ( vmlinuz-3.13.5, initrd.img-3.13.5, System.map-3.13.5, etc) in the /boot directory and even built a new uImage from the compiled kernel, however Im not sure what to do next. Ive never played with the linux boot process so am learning on the fly.

Cheers,

Marius

OK Marius,

I see, we may skip some steps here. So you have compiled the kernel. I assume that you paid attention to set ARCH=arm CROSS_COMPILE=<toolchain/bin/prefix-> properly when you compiled the kernel and also that you have compiled the DTS file :

make ARCH=arm CROSS_COMPILE=...  imx6sdl-riotboard.dtb

Right ?

The kernel config file that I sent was configured to use an appended device tree. Therefore there is one essential step that I assume you also did.

(I'm taking the zImage )

cat   zImage   imx6sdl-riotboard.dtb   > zImage_dtb

This "cat" command is essential to get your kernel boot with RIoT working.

Assuming then that you have the "zImage_dtb" lets say at /boot/ directory :

Now there are two things to take care about. The bootloader (u-boot) and the file system.

It is the bootloader that it is going to load the kernel in memory (in the DDR) and then execute.

Obviously if you do not tell the bootloader where the kernel is it is not going to guess it by its own.

To do so, it depends on where you intend to boot.

Let's use the SD card interface (not the uSD). In the RIoT official deliveries (Linux OS) I think I saw a "u-boot-xxx.bin" image (sorry I'm not at home and I have limited access to the net, I'm just writing by heart). You need to prepare a SD card and make 2 partitions.

Using fdisk, make 2 partitions. First partition 10Mbytes should be enough and the rest for second partition (Linux filesystem partition).

Usually you will see the SD card as /dev/sd<letter> (but it depends on your host).

fdisk /dev/sd<letter>

(Be careful do not mistake on the device <letter> otherwise you may lose a hard disk or something else).

Once you made the partitions make a ext4 file system on the second partition :

mkfs.ext4 -L "ROOTFS" /dev/sd<letter>2

(Again be careful to choose the right device /dev/...).

Write the bootloader :

dd if=u-boot-xxx.bin of=/dev/sd<letter>

(No need a number after <letter>).

Then mount the ROOTFS partition :

mkdir /mnt/rootfs

mount  /dev/sd<letter>2  /mnt/rootfs

Then in /mnt/rootfs you just copy (untar) your favorite Linux 3.x ARM compatible file system. Debian, Archlinux (ARM), or build your own (but I do not think it is worth doing so)...

Then replace the kernel where ever it is (normally at /mnt/rootfs/boot/). Copy your "zImage_dtb" there.

... and to be honest you should also install the modules "*.ko" that were compiled with the kernel and also the headers. (There is an install target for that in the Kernel Makefile, ... you need some reading because I do not remember very well).

Your SD is ready. Well nearly because I'm not sure the u-boot provided has the right bootargs variable set... but we can instruct that by hand. Let's ensure first that our Kernel and filesystem is OK and we will rework the u-boot later.

Unpower the RIoT board and insert your SD card, set the boot switches in the right position to boot from SD card.

U-boot provided is set to wait about 5 seconds before loading the kernel. Within this 5 seconds a key press will stop the process and give you a kind of command line prompt.

I forgot to mention that the console I'm using is on UART2.

Are you able to connect through UART2 ?

Do you have the material to do so, FTDI, or whatever ?

Tell me if you need instructions to get the console on UART2.

Pablo.

--

Howdy Pablo,

I probably missed a few steps in my compilation. I grabbed all the source from git and put it onto an sd card on the riot board. Then copied the dts into the directory with all the other dts files, copied your config file over the .config and then made the whole kernel as described at

FAQ/KernelCompilation - Linux Kernel Newbies

This may not have built what you have described though. Ill have another play around today, but will be out of action for the next few days so will come back to it next week.

Cheers,

Marius

Howdy,

I thought that by dropping the DTS file into the dts directory the build process would pick it and compile it. It did not. so I have tried to compile it manually however whenever I get an error on the #include when I run 'dtc imx6sdl-riotboard.dts'

Do you know what I am doing wrong?

Thanks

put the dts into arch/arm/boot/dts in your kernel source tree and then add a line to the Makefile in that directory under the "dtb-$(CONFIG_ARCH_MXC) +=" line where you see something like

        imx6dl-sabresd.dtb \
        imx6dl-wandboard.dtb \

just change it to

        imx6dl-sabresd.dtb \

        imx6sdl-riotboard.dtb \
        imx6dl-wandboard.dtb \

then just make dtbs again to get the compiled file

Marius,

"I probably missed a few steps in my compilation. I grabbed all the source from git and put it onto an sd card on the riot board. Then copied the dts into the directory with all the other dts files, copied your config file over the .config and then made the whole kernel as described at

FAQ/KernelCompilation - Linux Kernel Newbies"

I'm not sure this is the best way to proceed. Bear in mind that the FAQ about the kernel compilation you showed it is mainly intended for those who want to compile the Kernel in x86  (common PC)  architectures. Concerning RIoT is more about cross compilation of embedded Linux ARM platforms ... it is slightly different. Hardware discovery process in PC BIOS based architectures is also very different from what we have here. In those system DTS is not used at all.

I also have the impression that there is a confusion on kernel sources and root file system. I'm not sure to understand your compile environment.

What is your host system ? Are you compiling directly on the RIoT board ?! I do not understand  why you put the kernel sources in the SD card.

Howdy Pablo

i mounted the sd card on the riot so that I had enough space to build. I then compiled directly on the riot as I thought at least that way the binaries would have to compatible. I'll bring myself up to speed on tool chain stuff.

cheers,

marius

Howdy,

Im going to take a step back from trying to get a later version of linux running on the Riot and revert it back to android. My original aim was to build a set of reusable libraries for linux on SBCs (BBB, RPi, Odroid, etc). So if Element14 are not going to properly support Linux then who am I to waste my time building this for them and adding support for a platform that will not be utilized. Thanks for the help Pablo, hopefully Element14 will get around to releasing a fully supported hard float linux, and hopefully even provide kitkat support for Android.

Personally I find it disappointing that a board released in 2014 has not come standard with strong support for one of the most widely used OS.

Marius