Debian wheezy on RIoTboard

howto?

Not yet

I'm still working through it myself, trying to document things as I go.  Watch out for my blog posts in the RIoTboard area as I walk through the various different steps.

For that I used one of Robert Nelsons minimal filesystem builds from his wandboard page, then did the update from 7.4 to 7.5 and installed xfce, mostly as a proof of concept and to show that there is light at the end of the tunnel

I'm running through how to do it myself using debootstrap now in an effort to get less junk and more useful things installed.  I'm not very familiar with Debian installs, so it's a bit of trial and error right now.

Did you use your u-boot fork or Nelson's?

Somehow build_kernel.sh doesn't produce anything for me, doesn't give an error either.

It's using the mainline u-boot v2014.04 with Erics RIoTboard patches and the couple of changes I made, you can find the exact version in my github repo here

https://github.com/selsinork/u-boot/commits/embest-boards-fixes

Somehow build_kernel.sh doesn't produce anything for me, doesn't give an error either.

I don't know what build_kernel.sh is or where it came from, so unfortunately I can't help you with it.

I try not to rely on black-magic scripts, instead I'll try to do everything step-by-step showing the exact commands I used.  I'm hoping that means that people will learn how to do things themselves as well as giving them the opportunity to customise things at every step for their own purposes.

Hopefully at the end of it all I can create an image that anyone who doesn't want to do it manually can just write to an SD card and use.

I meant build_kernel.sh from Robert Nelson's wandboard tutorial (with his armv7 generic kernel).

I have your u-boot fork working, I just need to understand now how u-boot finds the kernel to boot? is it a fixed address? is that what that LOADADDR in the uImage build is for?

I'm also trying your linux fork, btw the riotboard-dts2 branch has a bug in arch/arm/boot/dts/Makefile  line 207 is missing the suffix "imx6s-riotboard.dtb"

Daniel Tralamazza wrote:

 

I meant build_kernel.sh from Robert Nelson's wandboard tutorial (with his armv7 generic kernel).

 

Ok, I don't use that, and I won't.  I respect Robert for a lot of the work he does, but IMHO that's the wrong way to do things.

I have your u-boot fork working, I just need to understand now how u-boot finds the kernel to boot? is it a fixed address? is that what that LOADADDR in the uImage build is for?

Don't use uImage...   It's unnecessary and gives you a double problem in recent kernels where you appear to have to specify the load address in several places and then the kernel will ignore it all regardless.

 

I'm also trying your linux fork, btw the riotboard-dts2 branch has a bug in arch/arm/boot/dts/Makefile  line 207 is missing the suffix "imx6s-riotboard.dtb"

Yes it does doesn't it.  I was wondering if anyone would notice

Next steps on kernel build are here http://www.element14.com/community/community/knode/single-board_computers/riotboard/blog/2014/05/04/part-3-building-mainline-linux-kernel-for-riotboard

If you're using my u-boot version, then it simply looks for a file called /bootscript in the root of the first partition on each of J6, J7 & eMMC, loads the content into the environment and runs the environment variable called 'doboot'.  The idea is to punt as much of the decisions as possible to the script instead of the hard-coded part inside u-boot.

I'll attached the current /bootscript I'm using here in a minute - I don't seem to have the option in this editor.  It loads a zImage not a uImage at 0x12000000 from the same mmc device that /bootscript was loaded from.

It has some issues in that you might have an SD card installed that doesn't have /bootscript, so end up loading the kernel from eMMC, but then by having /dev/mmcblk0p1 hard-coded you'll get your root partition from the SD card.  I'll sort that out later - it's why I modified my u-boot build to include the part command.

Attaching a file seems to be rather problematic..

You probably want to add "rw" to your bargs.

Not really.  If you do that then you won't be able to run fsck on the root filesystem to cleanup after an unclean shutdown as you'll be trying to run fsck on an already rw mounted filesystem.  Generally the distro boot scripts will take care of it all for you as long as the root fs is mounted ro to begin with, after they've verified everything is ok they'll do a mount / -o remount,rw to enable writes.

So if anything I should probably add ro to bargs.  Thanks for pointing it out though..

debian booted in rw mode, but archlinux boots in ro mode by default. I've to check how to set rw in the boot scripts.

thanks

in theory, all distros should boot with the fs set to rw without problem - as long as you have a clean fs

if the fs hasn't been cleanly unmounted and because of that the boot scripts want to run fsck is where the problems begin. In some cases trying to mount an unclean fs can cause the kernel to panic and crash, other filesystems have been designed such that they typically can't get into that state and from a fs perspective will always mount cleanly.  Like everything, there are trade-offs to be made on which fs is suitable for any given purpose.

usually you can't run fsck on a filesystem that's mounted rw, so it's a catch22, sufficient damage may mean you can't mount rw, although you can often mount ro, use fsck and force a reboot which brings the fs up cleanly on second attempt.  The trade off is that on a sufficiently large fs, running fsck can take many hours or even days.

in theory, all distros should boot with the fs set to rw without problem - as long as you have a clean fs

if the fs hasn't been cleanly unmounted and because of that the boot scripts want to run fsck is where the problems begin. In some cases trying to mount an unclean fs can cause the kernel to panic and crash, other filesystems have been designed such that they typically can't get into that state and from a fs perspective will always mount cleanly.  Like everything, there are trade-offs to be made on which fs is suitable for any given purpose.

usually you can't run fsck on a filesystem that's mounted rw, so it's a catch22, sufficient damage may mean you can't mount rw, although you can often mount ro, use fsck and force a reboot which brings the fs up cleanly on second attempt.  The trade off is that on a sufficiently large fs, running fsck can take many hours or even days.