Hi,
there is no method described in the manual. I guess many (most?) people interested in an open
hardware development device are using linux.
I hope there are any tools available and the documentation can be extended.
Thanks
Steffen
Hi,
there is no method described in the manual. I guess many (most?) people interested in an open
hardware development device are using linux.
I hope there are any tools available and the documentation can be extended.
Thanks
Steffen
Remember that the RIoT board is targeted specifically for Android development, not mainline linux.
It's also not a truly open hardware design as the actual CAD files are not provided. There are Gerbers available now which allow you to produce an exact copy, but the Mentor/KiCad/Eagle/whatever source files are not available so you can't easily modify it.
There are better choices if you want an open hardware board, for eaxmple the Olimex OLinuXino boards.
However, the user manual has section 5 on how to build linux kernel images and you'll find a linux download on this page RIoTboard
James Carruthers wrote:
AFAIK you can only boot Linux from the internal eMMC — not from the external.
Where did you get that information ?
The user manual says otherwise (and other i.MX6 systems can boot from varying places)
So once you set the boot switches to SD you can boot whatever you like from SD.
anthony_h wrote:
It's on Page 44 of the UM that it mentions that Linux currently only boots from eMMC.
Unfortunately that's so vague as to be pointless.. From a Linux point of view eMMC and SD are identical as they use the same driver. If u-boot can load android from eMMC there's no reason to believe it can't load Linux - since android is based on a linux kernel.
The wording seems strange too "Currently the Linux system on the RIoTboard supports only booting from the eMMC" but as we all know it arrives with Android installed, so 'currently' there is no linux on the board... If there was, it wouldn't be an issue 
I'm wondering if what it really means is that the ancient 3.0.35 based image from the download page is brain-damaged enough that it's incapable of doing so. In a different thread there's a devicetree file for the 3.13 kernel which should effectively remove any kernel based obstacles. The only remaining problem would be if u-boot or the ubuntu image have hard-coded something and any of those should be fixable.
It's a pity there's no SPI rom like the Sabre-Lite. A decent version of u-boot in SPI essentially makes it possible to easily boot from anywhere.
Not really sure if that attachment will work or not, I uploaded a 319KB u-boot.imx and seem to have ended up with a zip file that's a different size 
Yes the sha256sum is correct. I think the problem is not the u-boot.imx image. Either the dd call failed or the system needs additional information on the boot device, perhaps the u-boot parameters or some checksum. Or something on my board is corrupt.
I tried dd to /dev/mmcblk0 and /dev/mmcblk1 directly from ubuntu on the RIoT-board and dd to /dev/sda from an x86 linux system with USB to SD converter. Same effect with both. I checked the dip switches multiple times. Are there different board revisions with different switch settings?
When I'm using your u-boot in the serial download mode for BootStrap your UBoot-2014.04-rc2...dirty starts, first success 
Switch settings:
<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>
or maybe this is better with them highlighted?
uSD Card:
<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>
Card installed here:
<html><head><title>Jive SBS</title></head>
<body><font face="arial,helvetica,sans-serif">
<b>Error</b><br><font size="-1">
An general error occurred while processing your request.
</font></font></body></html>
# fdisk -l /dev/sdc
Disk /dev/sdc: 7948 MB, 7948206080 bytes
10 heads, 4 sectors/track, 388096 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdc1 2048 2099199 1048576 83 Linux
filesystem is ext2, but none of that should matter to get output from u-boot itself.
/bootscript sits in that ext2 partition and contains the following
fdt_high=0xffffffff
initrd_high=0xffffffff
kaddr=0x12000000
loadkernel=load ${dtype} ${disk}:1 ${loadaddr} /boot/zImage
bargs=setenv bootargs console=ttymxc1,115200n8 rootwait root=/dev/mmcblk0p1 enable_wait_mode=off
loadfdt=load ${dtype} ${disk}:1 0x11000000 /boot/${fdt_file}
foobar=run bargs; if run loadkernel; then echo kernel_loaded ; if run loadfdt; then echo fdt_loaded; bootz ${loadaddr} - 0x11000000 ; else echo fail1; bootz ; fi ; fi ; echo failed to boot
and yes, that last line needs to be on a single line..
required kernel files go in /boot and are imx6s-riotboard.dtb & zImage, all three of which are attached..
sha256sums:
32d4b7d5ecc0b8838c8575e62cb689124fcaee6dc3babf0bbb76e975f9ad8ab8 bootscript
1e9f7ae6820a2febe71b8591d079995b36c7e07a80cc52dd3bf8c937aefddc5a imx6s-riotboard.dtb
5078d1023d49d62146826cd33af67789337aecd32240ff836d25fb9abf275ee4 zImage
Note that the kernel is quite minimal, there may not be enough in it to run a traditional distro like debian or ubuntu, but it's enough to prove booting works.
Thanks a lot for your detailed information! 
Especially the kernel file and the dtb will be very useful to try.
At the moment I don't see what I've done wrong and suspecting some hidden misconfiguration of the board.
Another question. How do u-boot know which serial console and speed it should use for the output before the boot parameter of u-boot are set (setenv console...)? Perhaps everything is working except the console output.
Matthias Schwartz wrote:
- Your u-boot.imx on internal eMMC: no message at all, same as above but used /dev/mmcblk0 instead /dev/mmcblk1
From my booted uSD, I've wiped the eMMC, created a blank partition, wrote u-boot.imx as follows:
root@riotboard:~# dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 2,27716 s, 9,2 MB/s
root@riotboard:~# fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.24).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x9f52ed0f.
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7503871, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-7503871, default 7503871):
Created a new partition 1 of type 'Linux' and of size 3,6 GiB.
Command (m for help): p
Disk /dev/mmcblk1: 3,6 GiB, 3841982464 bytes, 7503872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9f52ed0f
Device Boot Start End Blocks Id System
/dev/mmcblk1p1 2048 7503871 3750912 83 Linux
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
root@riotboard:~# dd if=u-boot.imx of=/dev/mmcblk1 bs=1024 seek=1
319+0 records in
319+0 records out
326656 bytes (327 kB) copied, 0,0783677 s, 4,2 MB/s
then powered down, reset the switches to the default eMMC boot settings from table 4-2 in the manual, removed all SD cards, powered it back on and I instantly get the U-Boot 2014.04-rc2... It obviously doesn't boot fully as it's still missing a kernel and filesystem, but it seems there's nothing particularly special needed.
So possibly your board does have a problem... Or it'll be something so simple that you can't see it when it's staring you in the face... We've all been there 