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
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 
Otto Römmich wrote:
I´ve tried your files and could get an SD Card running with it.
Only thing is there seems no ext3 filesystem in your kernel image?
Probably not, I did say it was a very minimal build 
I tend not to use ext3 if I can avoid it, but especially not on flash. Data journaling with ext3 increases the number of writes, combine that with Write amplification due to wear levelling and you have a recipe for horribly bad performance.
Having checked the config, there's ext2 and nfs, that's it.
Then removed the SD-Card put the switches to 2-Off 5-Off.
And... nothing.
No response at all.
That happens if you have the switches set to boot from a device that doesn't contain the correct data. As far as I can tell, there's no fallback to a different device within the on-chip boot rom (however looking at the boot flow charts in section 8.5.3.2 of the ref manual... well, it's complicated.. easily possible I'm missing something), other than 'Manufacture Mode' which would allow boot from a full size SD card (or, seemingly from the OpenSDA).
Building a full table of what the switches do is complicated by the fact that changing one switch from off to on might change the function of another three switches. Simplistically, with D1 On, D2 Off, you have D4 on for eMMC mode, off for SD mode, then D7 & D8 pick one of four possible SD interfaces.
So, are you using a full size card in J6 on the underside of the board ? Or a uSD in J7 on the top ? You'll need to change D7 & D8 to match.
Then I inserted the SDCard again.
And... it´s booting from the SD-Card although the switches are set to boot from eMMC.
SD & eMMC are very similar, it's quite possible you can boot from an SD card while D4 is set to eMMC mode, assuming D7 & D8 have picked one of the SD slots. (or you're using a full size SD card and booting in mfg mode)
You're making me wonder if there's a problem with the physical switches themselves.. So even though you've turned a switch on, it's not physically shorted the two pins. Matthias was having similar problems that could probably be explained by this. If you have a multimeter, it should be easy enough to check if anything like that is happening.
Part of the reason I'd posted the photos was to make sure there wasn't something like some boards having the switches mounted in reverse causing counting from the wrong end or on/off reversals.
As I've said in earlier posts, I'm able to boot exactly the same u-boot image from any of eMMC, a full size SD, or a uSD in the appropriate slots.
So we're left with
I suppose it's also possible that the eFUSEs have been blown on some boards in a way that overrides some switch settings, but hopefully that's something we don't have to worry about.
I should probably add that as I don't have a windows machine, I've never used the MFG Tool. Possibly it can let you do things like blowing eFUSEs that'll never have been done to my board outside whatever the factory did.
One last thing, when you change the switches, are you doing a proper power cycle ? Or just pushing the reset button ? I always do a hard power cycle.
I've not checked the docs in enough detail for i.MX6, but some devices only sample the boot config on power up, not on reset. So I do a hard power cycle to be sure..
Otto Römmich wrote:
All dip switches are on except for D2 and D5 and it boots from the card. You said when D4 is set to on it´s in eMMC mode and it then can boot from the SD card in mfg mode. That´s the case I suppose.
So if you have only D2 & D5 off, then it would seem that as long as what's at 1KB in the eMMC isn't seen as being a valid boot image then it'll try uSDHC1 which is connected to the OpenSDA and uSDHC2 which is your full size SD card. Using this mode obviously isn't ideal as it's using 1bit rather than 4bit to access the card, so it'll be slower, but presumably u-boot will then use 4bit mode and you're fine from there.
I wonder why you were having problems with the switches set differently then. Forgetting about actually booting to linux for a moment, it should be simple to get the u-boot prompt on any of eMMC, SD, uSD by just writing a u-boot.imx starting at 1KB, there doesn't appear to be anything special needed other than that. Once you have u-boot loaded it's a relatively simple task to script what you need, even booting from the network.
I've successfully installed the new u-boot boot loader on the eMMC with the MfgTool2.exe 
For this I've modified the ucl2.xml file for the configuration, replaced the u-boot-mx6solo-riot.bin, powered off the board, changed the dip switches to serial download mode, switched the board back on, chekced cfg.ini, started MfgTool2.exe and programmed the boot loader. Than poweroff the board set the dip switches back to boot from eMMC and power on.
I've replaced the file files/u-boot-mx6solo-riot.bin and very important delete the last two parameters skip=2 conv=fsync!
The corresponding line in ucl2.xml should look like this:
<CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk0 bs=512 seek=2">write u-boot.bin to sd card</CMD>
I've successfully installed the new u-boot boot loader on the eMMC with the MfgTool2.exe
For this I've modified the ucl2.xml file for the configuration, replaced the u-boot-mx6solo-riot.bin, powered off the board, changed the dip switches to serial download mode, switched the board back on, chekced cfg.ini, started MfgTool2.exe and programmed the boot loader. Than poweroff the board set the dip switches back to boot from eMMC and power on.
I've replaced the file files/u-boot-mx6solo-riot.bin and very important delete the last two parameters skip=2 conv=fsync!
The corresponding line in ucl2.xml should look like this:
<CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk0 bs=512 seek=2">write u-boot.bin to sd card</CMD>
