information on sources and abilities of i.MX6q

Hello

MCIMX6Q-SL is a community board manufactured and supported by Element14 based on the Freescale Sabre Lite design.

Linux and Android Image files and Sources published on Freescale website are only compatible with Freescale Sabre Smart Device (SD) Platform (P) or Board (B) hardware tools.

Element14 MCIMX6Q-SL and Boundary Devices Sabre-Lite are based on the same Freescale Sabre-Lite rev D hardware.

Element14 tech team are currently working on an updated version of the Android BSP for this board which should be published soon in this section.

Roadtest enrollment for Element14 Sabre-Lite has just started here : http://www.element14.com/community/roadTests/1141

A webinar introducing Freescale i.MX6 series and detailing Sabre-Lite with its ecosystem has just been published on Element14 in the webinar section here :

http://www.element14.com/community/videos/7858/l/Freescale-SABRE-Lite-Board:-i.MX-Your-Interface-to-the-World

Hi there!

and thank you for the reply!

I realise now (that I have read alot about the board) that i shouldn't even bother with the freescale's sources!:)

The questions is, should I get ltib and a linaro toolchain and I should be set?

Should I download a linux mainline? or are there element14 / boundary devices git's that I should prefer?

And provided I have a toolchain and a rootfs, should i get the latest kernel?

You only refer to an updated Android BSP. will there be no Linux BSP?

Also I am unsure about the difference of a platform (P) as opposed to a board

Is there a guide .or a forum discussion or whatever, with a guide that has information

and (hopfully) a step by step guide  about what sources to download and how to configure them

so as to have a toolchain with specific gcc options, a rootfs, and the necessary libraries..?

Thank you for your help!

What you do depends on what features you want. The freescale trees are based on a kernel version that by now is getting very old. However it is the only place to get the latest support for the hardware - or in some cases any support at all.

The boundary devices tree here https://github.com/boundarydevices/linux-imx6 is also a good place to look as they seem to be actively developing and working on bug fixes and enhancements. Their blog is worth watching as well.

For a current vanilla/mainline kernel you can have a look at Robert Nelsons stuff over on eewiki, but expect to lose various functionality as the drivers simply haven't been ported to the recent kernels. There's been a lot of churn in the arm parts of the linux kernel between the 3.0.x kernels that freescale/linaro/boundary are using and the 3.8 mainline devicetree kernel, so it's not clear how much effort would be needed to port the existing drivers.

I'm going with some combination of Robert Nelsons stuff and the boundary stuff as that's where the active development seems to be happening currently

Hi there,

thank you for the info.

It is not clear from what you say, whether the kernel 3.0 from boundary devices git supports all drivers.

It is not critical for me to use a 3.8 kernel at the moment. it is more important to have access to the hardware though.

Also, i presume it IS possible to recompile the filesystem (not-stripped versions) and still keep the current u-boot and kernel images (found under /boot in the microSD card.

I am wondering though why Linaro in this guide: https://wiki.linaro.org/Boards/MX6QSabreLite

chooses to load its image from the SD card instead of the microSD. I wonder if it was a choice they made , or they didn't have an option (for whatever reason) and if this affects me too.

the boundary 3.0 kernel appears to be directly based off the freescale 3.0 kernel with the addition of the stuff the boundary guys have done, so I'd expect it to support everything the freescale kernel does, and then some. However I haven't tried it myself, so can't be sure of that.

I replaced the fs on the supplied card with Robert Nelsons minimal debian fs (which includes much more than the supplied card) but kept the uboot in nand flash and the kernel from the supplied card. No reason you can't do the same with any fs or distor you choose.

Yeah, Linaro, Boundary and Robert Nelson all seem to have went different ways on whether to load the image from SD, microSD or wherever. It's slightly problematic as you need to pick which bootloader to put into nand-flash, there's one for the microSD and one for the full size SD. So it'll be less than easy to flip between a linaro and Boundary setup - you can't just swap the card, you have to change the bootloader too. Not really sure what linaro were thinking there.

I'm tempted to try getting an up to date version of uBoot into nand, that way it could have a bootscript that looked for the fs on microSD and if that fails try again with full size SD - It would make swapping distros a lot easier.

I replaced the fs on the supplied card with Robert Nelsons minimal debian fs (which includes much more than the supplied card) but kept the uboot in nand flash and the kernel from the supplied card. No reason you can't do the same with any fs or distor you choose.

I  will do  that. Could you please verify for me if the debian image you have contains stripped libraries under /lib? Thank you

I also lack some basic knowledge about the boot process on this card.

I am refering to the TimesysLinux that was preinstalled on the microSD card.

Please correct me where i'm wrong . SPI Nor flash contains a small (uboot?) bootloader, which is read on powerup and it loads another(uboot again?) bootloader from nand flash on the board. Then uboot reads boot parameters from (/boot/6q_bootscript.* files - which one?) from the microSD card. Finally, uboot is ready to load the kernel (/boot/uImage) as instructed in the bootscript.

Is it like that?

What is re-flashed with Linaro and Robert's guides? the nand flash? and it is done so that uboot will look for bootscripts in SD instead of microSD? or just to find the kernel image?

Thank you for all the help and excuse my ignorance - it is the 1st development board I lay my hands on.

nass sil wrote:

I  will do  that. Could you please verify for me if the debian image you have contains stripped libraries under /lib? Thank you

Yes, as far as I can tell they're all stripped. The one I used was debian-wheezy-minimal-armhf-2012-10-22

I also lack some basic knowledge about the boot process on this card.

I am refering to the TimesysLinux that was preinstalled on the microSD card.

Please correct me where i'm wrong . SPI Nor flash contains a small (uboot?) bootloader, which is read on powerup and it loads another(uboot again?) bootloader from nand flash on the board. Then uboot reads boot parameters from (/boot/6q_bootscript.* files - which one?) from the microSD card. Finally, uboot is ready to load the kernel (/boot/uImage) as instructed in the bootscript.

Is it like that?

Right, first an apology, I've been getting my nand and nor mixed up, sorry if that's caused any confusion.  If you re-read whatever I previously wrote and replace 'nand' with 'nor' it's probably going to make more sense.

The boot process goes something like this AFAIK.

1. on cpu bootrom (which we don't have access to) looks at the fuses and/or switches and pulls some bit of code from the indicated place and runs it. by default the switches are set to look at the fuses and the fuses are set to boot from the SPI SST25VF016B-50-4C-S2AFSST25VF016B-50-4C-S2AF at U17

2. by default the SPI device contains the outdated version of uBoot which looks for 6q_bootscript on the first partition of mmc0 which is the microSD. This isn't the /boot/6q_* files directly, it's the 6q_bootscript (& 6q_upgrade) in /

3. /6q_bootscript then tries to load /boot/uImage and sets root=/dev/mmcblk0p1

When you reflash with the Linaro, or Roberts guide you're replacing the uBoot in SPI flash with a simple bootloader that as far as I can tell simply sets a couple of bootconfig registers to something different from the defaults supplied by the fuses and resets the cpu. The embedded bootrom then tries to load from whatever was set in those registers.

There are two versions of the minimal bootloader:

iMX6DQ_SPI_to_uSDHC3.bin - microSD boot

iMX6DQ_SPI_to_uSDHC4.bin - normal size SD

so you have to pick one that makes sense for the sdcard you're using

The boundary guys have a slightly better way. Their latest uBoot stuff is intended to stay in the SPI flash, but has an embedded script that looks for 6x_bootscript (yes, new name) on sata, then mmc0, then mmc1.

It's my intention to do a compromise, keep a version of the boundary uBoot in SPI flash, but apply some of Roberts patches to allow use of uEnv.txt. This gets me to a point where the only changeable thing is uEnv.txt and it's a simple text file, unlike 6x_bootscript that needs 'compiled'. He also enables other stuff in uBoot that allows the use of a plain zImage instead of needing the additional step of modifying that into a uImage.

Hi selsinork.

OK finally most bits of info have fallen into place.

It seems everyone (Boundary devices, Robert, Linaro) are out to replace the uboot. I still am fuzzy about the disadbantages of keeping the current bootloader.

If you know something  (whenever you have time - its just encyclopedic knowledge) please let me know.

I was looking for some sort of manual / user guide on u-boot website just to clarify how and when is uboot configured to look for bootscript files and even why is it important to have a level of configurability on the boot process but didn't find something relevant on the Manual and the FAQ.

I didn't find anything regarding the imx files and what is different about them from the .bin files (I see Robert instructs us to dl an imx file that we have to write on the 1st sectors (2, length 512 bytes) of the SD card and then create a partition+fs to place the uSDHCx.bin file inside.)

Thank you very much for your help

nass sil wrote:

 

It seems everyone (Boundary devices, Robert, Linaro) are out to replace the uboot. I still am fuzzy about the disadbantages of keeping the current bootloader.

If you know something  (whenever you have time - its just encyclopedic knowledge) please let me know.

Basically it's out of date, lacks some features, and if you read the latest boundary blog posts (http://boundarydevices.com/i-mx-6dq-u-boot-updates/) it seems that the DRAM setup done by older uBoot versions is incorrect and can cause the board to lock up under some circumstances.

The newer versions will also handle the dual core, single core and versions with 2Gb RAM (not sure if there will be a sabre-lite with 2Gb, but one of the other boundary boards will do)

see http://boundarydevices.com/main-line-u-boot-for-i-mx6-sabre-lite-and-nitrogen6x/ for a probably incomplete list of the differences

I didn't find anything regarding the imx files and what is different about them from the .bin files (I see Robert instructs us to dl an imx file that we have to write on the 1st sectors (2, length 512 bytes) of the SD card and then create a partition+fs to place the uSDHCx.bin file inside.)

my understanding is that the .bin files have the 1024 bytes of rom header and padding, so you write these into flash at address 0, I don't think they work when loaded directly from an SDcard. The imx files on the other hand don't have the header or padding, need to be written to flash at 0x400 or can be loaded from SD. I've not researched that in detail though, so take it as what it is, just my understanding.  I'm sure I read a description of the differences somewhere, but I can't find it right now.. (actually http://boundarydevices.com/i-mx-6dq-u-boot-updates/ has a bunch of details if you read through it)

Hello there,

in an earlier post you mentioned that

I replaced the fs on the supplied card with Robert Nelsons minimal debian fs (which includes much more than the supplied card) but kept the uboot in nand flash and the kernel from the supplied card. No reason you can't do the same with any fs or distor you choose.

I, too, would like to do the same now. I used the omap-image-builder from Robert Nelsons git and got 5 separate rootfs. I trien nfs boot to the debian-wheezy-minimal-armel-2013-03-04 image, which I extracted and pointed to the nfs exports file. I left the factory provided uboot image and

used the kernel from the LTIB 2012-04 which claims to have te same kernel with the demo timesys image (even though I get different md5sums).

While uboot starts up fine and the uImage is loaded fine from the tftp, and the kernel boots fine, I do get some kernel panics:

any clue?

Thank you for your help

INIT: version 2.88 booting

[info] Using makefile-style concurrent boot in runlevel S.

[....] Starting the hotplug events dispatcher: udevd. ok

[....] Synthesizing the initial hotplug events...Division by zero in kernel.

[<8004482c>] (unwind_backtrace+0x0/0xf8) from [<802144d4>] (Ldiv0+0x8/0x10)

[<802144d4>] (Ldiv0+0x8/0x10) from [<802446d0>] (mxcfb_check_var+0x12c/0x300)

[<802446d0>] (mxcfb_check_var+0x12c/0x300) from [<8022e2e4>] (fb_set_var+0x44/0x290)

[<8022e2e4>] (fb_set_var+0x44/0x290) from [<8033d9b4>] (release_disp_output+0xfc/0x164)

[<8033d9b4>] (release_disp_output+0xfc/0x164) from [<8033ec48>] (mxc_vout_release+0x60/0x74)

[<8033ec48>] (mxc_vout_release+0x