fwtool now requires .img file to exit - assume unintentional

[ghitchens]

Hi guys --- sorry I've been so "quiet" recently, I've been working on a non-software aspect of a couple of our nerves-based products -- the case, which right now has taken more than the software!!!!   Also been doing some management work so I've not been heads down on software -- getting back to it..

Not sure the best place to post bugs on fwtool - I noticed there's no "issues" area with public access.     The recent change to fwprogrammer to use the unzip:... util rather the built in zip support has created a dependency on mmccopy and introduced behavior that fwtool's -d argument must exist otherwise an error occurs -- this isn't a huge deal but I'm not sure it's intended behavior.  Seems like -d foo.img should create foo.img if it doesn't exist rather than throwing a rather obscure exception..

# fwtool/fwtool -d fwtool.img -t complete run test.fw

mmccopy: fwtool.img: No such file or directory

{"init terminating in do_boot",{{badmatch,{error,{mmccopy,1}}},[{fwprogrammer,run_command,2,[{file,"src/fwprogrammer.erl"},{line,199}]},{fwprogrammer,run_commands,2,[{file,"src/fwprogrammer.erl"},{line,185}]},{fwprogrammer,handle_call,3,[{file,"src/fwprogrammer.erl"},{line,119}]},{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,585}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}}

Took me a while to track this down and figure out why mmccopy was even involved since I was just creating an image -- not doing anything with an mmc.

I didn't submit a pull request, sorry, not sure what the intent is.

[Frank Hunleth]

Hi Garth,

It's good to hear from you again. I've been quiet on the list as well.

About fwtool, I've had it on the chopping block and the "unzip" patch was just to buy me some time. There are any number of problems with it, and I reached conclusion that without a ton of work I wasn't going to get Erlang to solve the problems that were most important to me without a ton of work. So I wrote a new one in C:

https://github.com/fhunleth/fwup

This one moves all of the platform specific code that was in fwtool back to the configuration file. It also removes the mmccopy, mtools, unzip, etc. dependencies. I wrote it so that you can stream a firmware update through it, which should be neat since you can avoid buffering the whole firmware update in memory or on disk. It doesn't support firmware signing yet, but I'll have to get to that before the end of the year due to a new cyber-security medical directive that's going to affect a device that uses it.

The catch is that I haven't finished writing the docs for it, I haven't ported the x86 configs in Nerves to use it, and there probably are a couple bugs. I'm working in the nerves "rpi-qt" branch and will try to get things in today. I'd much rather fix fwup than look at fwtool again.

Let me see how much I can get done this morning so that you don't have to debug fwtool.

Frank

--
You received this message because you are subscribed to the Google Groups "nerves-project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nerves-projec...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Frank Hunleth
Troodon Software LLC
Embedded Software Development
http://troodon-software.com/

[ghitchens]

Ok thanks frank! 

I worked around the problem for now by just doing a "touch" of the .img before running fwtool in my build script.  

I'll look at your new solution soon.

Garth

 

[Frank Hunleth]

Sounds good. The ag150 target isn't booting with fwup, and I'm not sure why. I'm not sure that it's fwup's fault, but syslinux doesn't give much in terms of error messages. The buildroot project also updated syslinux to 6.02 which seemed ok a couple months ago, but maybe is causing trouble now that it's been pulled into Nerves. Anyway, I'm slowing doing full rebuilds to track down the problem. I have to work on other things this afternoon, but I'll keep you posted.

Feel free to switch to the rpi-qt branch, but if there are errors, I wouldn't spend to much time on it. The Beaglebone and Raspberry Pi builds should work, but I should re-verify after all the x86 syslinux work is done.

Also, you may be interested in https://github.com/fhunleth/pljelixir. I've started switching my Nerves projects to build Nerves as a subdirectory like you do. The pljelixir project was for an Intro to Elixir presentation I did last month. It makes an SDCard image that you plug into a Raspberry Pi and then you plug the Raspberry Pi to a projector to give the presentation. The parts of interest would be the Makefile and the config directory, since it would be nice to have a canonical Nerves project directory structure. I'd be curious on your thoughts on this one.

Frank

--

You received this message because you are subscribed to the Google Groups "nerves-project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nerves-projec...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Frank Hunleth]

Garth, all,

On Tue, Jun 10, 2014 at 2:00 PM, Frank Hunleth <fhun...@troodon-software.com> wrote:
>
> Sounds good. The ag150 target isn't booting with fwup, and I'm not sure why. I'm not sure that it's fwup's fault, but syslinux doesn't give much in terms of error messages. The buildroot project also updated syslinux to 6.02 which seemed ok a couple months ago, but maybe is causing trouble now that it's been pulled into Nerves. Anyway, I'm slowing doing full rebuilds to track down the problem. I have to work on other things this afternoon, but I'll keep you posted.
>

I fixed the issue preventing ag150 from booting with fwup-generated images. It looks like all of the platforms are building, and I'm making my way through re-running the tests. I've updated master. This pulls in quite a few buildroot updates, so you'll want to rebuild everything. On the plus side, you'll have Elixir 0.14 now. Other platform-wide changes include:

1. unionfs support has been removed. This only affects people using relsync which I think is just me, but relsync can deal with this now. The plus side of this is that reliability is improved since the unionfs kernel patches were buggy.
   
2. I made a pass at creating a nerves.mk helper Makefile. This can be used to create projects that build nerves as part of building themselves. See https://github.com/fhunleth/pljelixir.
3. mtools is no longer used on the target on x86 and rpi builds to do firmware updates. fwup includes FAT read/write capability. This removes the only GPLv3 licensed project in use by Nerves and simplifies firmware update.
4. erlinit has a few updates. The most interesting one is to be able to specify helper programs between erlinit and erl. This lets you run strace to debug or dtach to redirect the Erlang or Elixir shell prompts to someplace more convenient. I use the latter to redirect the Elixir prompt to an on screen overlay graphic so that I can do live coding while running Nerves on the RPi.

As problems are found, I'll be updating master, but please let me know if you run into anything. In the next week or so, I hope to tag master and improve networking support.

Frank

[John Warwick]

Hi Frank,

I just pulled down the latest master and ran into some problems building for the raspi.

Here's what I did (running Ubuntu precise64 in a Vagrant Virtualbox VM):

sudo apt-get install libarchive-dev libconfuse-dev

make nerves_rpi_defconfig

make clean

make

Getting an error about finding host-libarchive when it's attempting to build fwup. host-libconfuse appears to build correctly:

make[1]: *** No rule to make target `host-libarchive', needed by `/home/vagrant/nerves-sdk/buildroot/output/build/host-fwup-v0.0.3/.stamp_configured'.  Stop.

make[1]: Leaving directory `/home/vagrant/nerves-sdk/buildroot'

make: *** [br-make] Error 2

thanks,

john

[Frank Hunleth]

Hi John,

On Wed, Jun 11, 2014 at 9:37 PM, John Warwick <jwar...@gmail.com> wrote:
>
> Hi Frank,
>
> I just pulled down the latest master and ran into some problems building for the raspi.
> Here's what I did (running Ubuntu precise64 in a Vagrant Virtualbox VM):
>
> sudo apt-get install libarchive-dev libconfuse-dev

In theory, I have Buildroot build these so that you shouldn't have to
do this on your host. Just an FYI, though, Ubuntu's libconfuse-dev has
a bug in it. The maintainer has accepted my patch, but I have no clue
how long it will take until it gets back to Ubuntu. I've included the
patch in Nerves.

>
> make nerves_rpi_defconfig
>
> make clean
>
> make
>
> Getting an error about finding host-libarchive when it's attempting to build fwup. host-libconfuse appears to build correctly:
>
> make[1]: *** No rule to make target `host-libarchive', needed by `/home/vagrant/nerves-sdk/buildroot/output/build/host-fwup-v0.0.3/.stamp_configured'. Stop.
>

It sounds like my recent patch to buildroot to add host-libarchive
wasn't applied. The simple way around this is to run:

make distclean
make nerves_rpi_defconfig
make

The "distclean" part deletes the buildroot directory. I suspect that
you had built the RPi configuration before the change, did a git pull
to get the recent update, and then tried to build. Since I only apply
the patches to buildroot when I download and create the buildroot
directory, new ones don't get applied. I haven't had the heart to
delete the buildroot directory completely on a clean since it takes so
long to rebuild, but it feels like the right thing to do. You wouldn't
be the first person to hit this issue.

Frank

[John Warwick]

Hi Frank,

Yes, I failed to do a distclean and that was causing the problem. Thanks for the speedy response!

thanks,

john