42 Replies Latest reply on Apr 21, 2014 5:46 AM by agrahambell

    Board device tree.

    madewish

      It would be nice if someone can post or point for riotboard device tree file.

       

      Just the .dts file that supersedes/overloads the existing arch/arm/boot/dts/imx6qdl.dtsi in linux kernel.

      ... a kernel defconfig file would be also appreciated.

       

      Pablo.

      ---

        • Re: 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

            • Re: Board device tree.
              madewish

              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.

                • Re: Board device tree.

                  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.

                • Re: Board device tree.
                  madewish

                  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.

                    • Re: Board device tree.

                      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

                        • Re: Board device tree.
                          madewish

                          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.

                            • Re: Board device tree.

                              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.

                                • Re: Board device tree.
                                  madewish

                                  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.

                                    • Re: Board device tree.

                                      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!

                                        • Re: Board device tree.

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

                                            • Re: Board device tree.
                                              madewish

                                              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 !

                                                • Re: Board device tree.

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

                                                    • Re: Board device tree.
                                                      audumla

                                                      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.

                                                        • Re: Board device tree.

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

                                                            • Re: Board device tree.
                                                              madewish

                                                              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.

                                                              ---

                                                  • Re: Board device tree.
                                                    audumla

                                                    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,

                                                      • Re: Re: Board device tree.
                                                        madewish

                                                        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.

                                                        ---

                                                          • Re: Board device tree.
                                                            audumla

                                                            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

                                                              • Re: Board device tree.
                                                                audumla

                                                                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?

                                                                  • Re: Board device tree.
                                                                    madewish

                                                                    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.

                                                                    ---

                                                                      • Re: Board device tree.
                                                                        audumla

                                                                        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

                                                                          • Re: Board device tree.
                                                                            madewish

                                                                            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.

                                                                            --

                                                                              • Re: Board device tree.
                                                                                audumla

                                                                                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

                                                                                  • Re: Board device tree.
                                                                                    madewish

                                                                                    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.

                                                                                      • Re: Board device tree.
                                                                                        audumla

                                                                                        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

                                                                                          • Re: Board device tree.
                                                                                            audumla

                                                                                            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

                                                                                      • Re: Board device tree.
                                                                                        audumla

                                                                                        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

                                                                                          • Re: Board device tree.

                                                                                            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

                                                                                • Re: Re: Board device tree.

                                                                                  Pablo Madewish wrote:

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

                                                                                  Awww..  you've spoiled all my fun

                                                                                  • Re: Board device tree.

                                                                                    Pablo Madewish wrote:

                                                                                    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.

                                                                                    GPU stuff hasn't been well supported until very recently, you have to look under drivers/staging at imx-drm

                                                                                    If that's not available in the kernel you're using, you can find it in Shawn Guos git tree here

                                                                                    http://git.linaro.org/people/shawn.guo/linux-2.6.git/tree/refs/heads/for-next:/drivers/staging/imx-drm

                                                                                    • Re: Board device tree.

                                                                                      Pablo Madewish wrote:

                                                                                       

                                                                                      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 !

                                                                                      Pablo,

                                                                                      Did you test USB hotplug with this kernel and config ?

                                                                                       

                                                                                      USB devices work OK as long as they're plugged in at boot, but hotplugging a device leads to

                                                                                      [   85.347056] usb 2-1: USB disconnect, device number 2
                                                                                      [   85.347742] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.347780] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.347811] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.347841] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.347870] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.347882] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
                                                                                      [   85.347947] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.347988] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348025] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348055] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348084] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348096] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
                                                                                      [   85.348160] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348190] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348218] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348247] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348277] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348288] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
                                                                                      [   85.348345] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348371] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348397] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348421] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348444] hub 2-0:1.0: cannot reset port 1 (err = -32)
                                                                                      [   85.348455] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
                                                                                      [   85.348485] hub 2-0:1.0: unable to enumerate USB device on port 1

                                                                                      I see other reports of USB hotplug problems on SabreLite and Wandboard, so I suspect this is related, but was wondering if you had any success.

                                                                                       

                                                                                      Additionally, wired ethernet seems not to work on 3.13.5 with your config.  Although it's functional with 3.14 as long as you add enable_wait_mode=off to the kernel command line (~25% packet loss otherwise due to known chip errata). Wait mode fixes for ethernet only appear to apply to TO1.2+, the RIot appears to use TO1.1, and the cpuidle driver for the i.MX6solo isn't available in mainline at this point.

                                                                                       

                                                                                      I notice there's a driver available for the PFUZE100 PMIC as well now, so I'm going to have a go at getting that working too.

                                                                                        • Re: Board device tree.

                                                                                          Never mind, got usb working with 3.15-rc and an updated devicetree. PMIC driver seems to work as well.

                                                                                            • Re: Board device tree.
                                                                                              arkver

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

                                                                                                • Re: Board device tree.

                                                                                                  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.

                                                                                                    • Re: Board device tree.

                                                                                                      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.

                                                                                                        • Re: Board device tree.
                                                                                                          arkver

                                                                                                          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.

                                                                                                            • Re: Board device tree.

                                                                                                              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

                                                                                                            • Re: Board device tree.

                                                                                                              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.

                                                                                                                • Re: Board device tree.
                                                                                                                  arkver

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

                                                                                                                    • Re: Board device tree.

                                                                                                                      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.

                                                                                                                        • Re: Board device tree.

                                                                                                                          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

                                                                                                                      • Re: Board device tree.
                                                                                                                        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.