<div dir="ltr">Great sleuthing, Nick. I appreciate  you looking into this. <div><br></div><div>I'm going to try the hack you recommended in order to get V0.2 loaded. I really want to play with that. I'll document it on my blog.</div>
<div><br></div><div>Now that I've played around with the Raspberry Pi and actually tried to load FreedomBox onto it, I'm more convinced than ever that it's an important piece of target hardware. These things are very easy to get into other peoples hands.</div>
<div><br></div><div>Cheers!</div><div><br></div><div>Chris Troutner</div><div><a href="http://experimentsinfreedom.wordpress.com/">http://experimentsinfreedom.wordpress.com/</a></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, May 13, 2014 at 7:12 PM, Nick Daly <span dir="ltr"><<a href="mailto:nick.m.daly@gmail.com" target="_blank">nick.m.daly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">Nick Daly <<a href="mailto:Nick.M.Daly@gmail.com">Nick.M.Daly@gmail.com</a>> writes:<br>
<br>
> The immediate cause of the issue has been discovered, but we don't yet<br>
> know why it's broken.  Using "kpartx -a $IMAGE.img", you can easily<br>
> mount each partition of the image file and verify that the first<br>
> (primary boot) partition of the Raspberry Pi image is empty other than a<br>
> zero-byte start.elf file.  Because the boot partition is empty, the<br>
> image has no data with which to boot.<br>
<br>
</div>It works fine with a DreamPlug.  Looking through F-M's<br>
bin/mk_freedombox_image, the only difference I can find is that the<br>
Raspberry Pi is missing uboot.  I'm trying to build an image with that<br>
now.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nick<br>
</font></span></blockquote></div><br></div>