Ubuntu 14.04

Only alternative right now is compiling the Kernel yourself.

There is a branch of the original Kernel in which the reboot error is corrected.

I described here how to compile the Kernel.

Re: Linux : Where is UART's

You then just have to replace the Kernel image file when flashing Ubuntu.

Hallo Mr. Römer sadly copy and paste didn't work at all.

I always receive following error

linaro@linaro-ubuntu-desktop:~/linux-imx$ sudo make ARCH=arm CROS_COMPILE=arm-linux-gnueabihf- uImage

make: arm-fsl-linux-gnueabi-gcc: Command not found

scripts/kconfig/conf --silentoldconfig Kconfig

make: arm-fsl-linux-gnueabi-gcc: Command not found

  CHK     include/linux/version.h

  CHK     include/generated/utsrelease.h

make[1]: `include/generated/mach-types.h' is up to date.

  CC      kernel/bounds.s

/bin/sh: 1: arm-fsl-linux-gnueabi-gcc: not found

make[1]: *** [kernel/bounds.s] Error 127

make: *** [prepare0] Error 2

linaro@linaro-ubuntu-desktop:~/linux-imx$

I tried to do i tby manual and replaced u-boot and linux to embest_imx_3.0.35_4.1.0. and also downloaded the compiler from toochain.

Make u-boot worked fine, but creating kernel image delivered still the same error.

I tried on ubuntu 11. now on 12.11 but still the same problem.

basically because u-boot can be setup in such a way that it will read the uImage from the file in /boot which eliminates an extra step and removes any confusion people have with the file being there.  From a technical point of view, reading the file from the filesystem also means the kernel can grow outside the current hard limit of 4MB without requiring any changes.

There are several typical u-boot usage patterns that are not necessary today, probably they still happen due to historic reasons.  I think it's good to drop those things that are not needed, it removes confusion and means nobody has to answer the 'why am I doing this unnecessary step?' type of question

Anyway, glad the dd command worked!

Just came home but selsinork did help already.
I´m glad it´s working now.

Eugen

As suggested by Otto, can you please share your stable Linux Ubuntu 12.04 image with the community ?

I have limited Linux experience and a slow computer but I would like test it on my RiOT board

Thanks in advance
Greg

You can use the official Linux download and just replace the kernel image in the files folder with mine.

Then flash it normally with mfgtools.

You then have the same image as Eugen.

I don't think we need a whole system image for this.

I agree, however mfgtool is a difficulty for a lot of people. Especially with the file in the current download needing renamed before it will work!

In a lot of ways, I think it could be preferable to have simple img files that can be written to SD card, or a BBB style 'flasher' SD card image. Most people can handle win32diskimager by now as it's a common thing to use for most boards. RIoT being different by using mfgtool just adds an obstacle that could easily be removed..

Jup that´s right. But the only problem is you can´t flash an image directly on the internal eMMC. You´d have to manually copy the image from the sdcard onto the internal flash.

And I think a lot of people like me want to use the riotboard without extra sdcards.

By the way. I tried putting the board into bootloader mode (the mode when MFGTool writes it´s data onto the board.) and then copy the image onto the flash drive you get then. But no luck. It just crashes.

i guess greg is asking for ubuntu 12.04 which Eugen got working

mfgtool is a difficulty for a lot of people

almost every MFG newbie hits the .txt to .xml roadblock, will notify vendor on this .

RIoT being different by using mfgtool just adds an obstacle that could easily be removed

thats a standard set by freescale , RIoT being a i.MX bundle just carries it,  however flashing images in linux is not at all a constraint for linux users.

tushar panda wrote:

almost every MFG newbie hits the .txt to .xml roadblock, will notify vendor on this .

I saw you specifically added instructions for that to http://www.element14.com/community/docs/DOC-68063/l/riotboard-updating-os-images-in-windows-environment

So we can point people to that now

thats a standard set by freescale , RIoT being a i.MX bundle just carries it,  however flashing images in linux is not at all a constraint for linux users.

Having several other i.MX6 based boards, I've never come across MFGTool before..  Have used the Linux imx_usb (https://github.com/boundarydevices/imx_usb_loader) variant to update u-boot in spi on both Sabre-Lite and MarS, but that's much more straightforward.

Other SoC vendors have similar ideas - FEL mode on AllWinner devices for example, where it's a pain as well. Olimex IIRC were at one point charging an extra 10 euros for boards with NAND/Android specifically due to the difficulty of using it (think production line where you're testing lots of boards but can only do one board per Windows PC and it needs manual touch time as the windows util can't easily be automated).

The BBB took the opposite route of using a bootable SD card that when booted automatically formats the eMMC and unpacks a tar.gz file onto it..  This is much the same as what mfgtool does, just less complex from the perspective of the users

The method described in that blog post is good for linux users, but it's fairly clear from the people asking questions here that most of them are using windows.  The BBB method wins simply because it's useable, and almost identical in operation, whether you're using Mac/Windows/Linux.

but it's fairly clear from the people asking questions here that most of them are using windows

    will try to layout some thing simple for windows users .

but it's fairly clear from the people asking questions here that most of them are using windows

    will try to layout some thing simple for windows users .