Just to check you were following this guide right http://downloadmirror.intel.com/24748/eng/IntelGalileoFirmwareUpdaterUserGuide-1.0.4.pdf ? Notice at the end there is a Known issues section. Make sure that you are not running from the SD card image or that you have a sketch running.
There is also a thread where another user has reported a similar issue and it has a workaround. Take a look at Re: Demora para atualização Firmware Galileo and let me know if you managed to update correctly.
I had to go to the office and pick up the Galileo stuff to try again, just to make sure that a sketch wasn't running. My procedure is this:
1) Plug in power supply.
2) Reboot with switch.
3) Plug in USB cable.
4) Run the firmware updater. Sometimes it doesn't notice the board (nothing shows up in the serial port pull down). If that happens, I replug the usb into another port and try restart the firmware updater. Finally it works; then I see if the old (732) firmware is recognized. (Sometimes it isn't, so I restart the upgrade until it is.) Then I click update firmware and answer ok to the power supply question, and yes to the do you wish to overwrite the firmware with 1.0.4. and I get this in the terminal:
Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
Output was: 0x000002dc
Exception in thread "serial-input" java.lang.NullPointerException
at com.intel.galileo.flash.tool.JsscZmodemService$SerialInputPipe.run(Unknown Source)
Aug 11, 2015 2:03:45 PM com.intel.galileo.flash.tool.GalileoFirmwareUpdater updateFirmwareOnBoard
INFO: Uploading: /home/frohro/.galileo/firmware.cap
Aug 11, 2015 2:03:45 PM com.intel.galileo.flash.tool.AbstractZmodemService sendFile
INFO: [/home/frohro/.galileo/lsz, --escape, --binary, --overwrite, --verbose, firmware.cap]
And the progress bar goes about 1/50 of the way across and stays there until I reboot or disconnect the usb cable.
Any other ideas?
Just some more information. I don't always get the Null pointer exception that showed up above. This time I tried sudo too, but it behaves the same, except as I said sometimes the Null pointer exception is not there, and the timeout message appears instead.
frohro@frohro-e6420:~/Downloads$ sudo ./firmware-updater-1.0.4
Output was: 0x000002dc
Aug 11, 2015 2:11:17 PM com.intel.galileo.flash.tool.JsscZmodemService$SerialInputPipe run
SEVERE: Stream closed
Aug 11, 2015 2:11:50 PM com.intel.galileo.flash.tool.GalileoFirmwareUpdater updateFirmwareOnBoard
INFO: Uploading: /root/.galileo/firmware.cap
Aug 11, 2015 2:11:50 PM com.intel.galileo.flash.tool.AbstractZmodemService sendFile
INFO: [/root/.galileo/lsz, --escape, --binary, --overwrite, --verbose, firmware.cap]
In case this helps....
I was able to go to my old arduino-1.5.3 and make the blink program from here
work. Then I was able to reboot, and using the arduino IDE, was able to upgrade to 0.7.8.2. Then I went and downloaded arduino-1.6.5 assuming it has later firmware. Here is what happened when I tried to run the blink program.
frohro@frohro-e6420:~/Downloads/arduino-1.6.5$ ls /dev/ttyA*
Picked up JAVA_TOOL_OPTIONS:
Board Intel:i586:izmir_fd doesn't define a 'build.board' preference. Auto-set to: I586_IZMIR_FD
Board Intel:i586:izmir_fg doesn't define a 'build.board' preference. Auto-set to: I586_IZMIR_FG
Sketch uses 58,002 bytes (0%) of program storage space. Maximum is 10,000,000 bytes.
starting download script
# clupload script to invoke lsz
# Copyright (C) 2014 Intel Corporation
Args to shell: /home/frohro/.arduino15/packages/Intel/tools/sketchUploader/1.6.2+1.0/x86/bin /tmp/build3996036043816227516.tmp/sketch_aug11c.cpp.elf /dev/ttyACM4
Serial Port PORT
# This library is free software; you can redistribute it and/or
Using tty Port /dev/ttyACM4
# modify it under the terms of the GNU Lesser General Public
Sending Command String to move to download if not already in download mode
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
echo "starting download script"
echo "Args to shell:" $*
# ARG 1: Path to lsz executable.
# ARG 2: Elf File to download
# ARG 3: TTY port to use.
#path may contain \ need to change all to /
echo "Serial Port PORT" $com_port_id
echo "Using tty Port" $tty_port_id
echo "Sending Command String to move to download if not already in download mode"
echo "~sketch downloadGalileo" > $tty_port_id
#Give the host time to stop the process and wait for download
Deleting existing sketch on target
#Move the existing sketch on target.
echo "Deleting existing sketch on target"
"$fixed_path/lsz" --escape -c "mv -f /sketch/sketch.elf /sketch/sketch.elf.old" < $tty_port_id > $tty_port_id
# Execute the target download command
#Download the file.
"$fixed_path/lsz" --escape --binary --overwrite $host_file_name < $tty_port_id > $tty_port_id
Bytes Sent: 57844 BPS:528699
#mv the downloaded file to /sketch/sketch.elf
Moving downloaded file to /sketch/sketch.elf on target
echo "Moving downloaded file to /sketch/sketch.elf on target"
"$fixed_path/lsz" --escape -c "mv $target_download_name /sketch/sketch.elf; chmod +x /sketch/sketch.elf" < $tty_port_id > $tty_port_id
but unfortunately the LED does NOT blink. Also, now when I hit reboot, the green LED next to the USB port does not light. It does if I remove the usb cable and then re power the board. Also, I found that this version of the IDE doesn't contain the update firmware option.
I am beginning to see why my students ditched the Galileo board for their senior project in favor of another. :-( I did go back to the arduino-1.5.3, and I can upload the blink file and it works, so it doesn't seem to be that the new firmware bricked it.
Well, I guess I need to find some more information on updating the firmware. I was able to transfer the firmware.cap to the board using:
frohro@frohro-e6420:~/Downloads/arduino-1.5.3$ /home/frohro/Downloads/arduino-1.5.3/hardware/tools/lsz64 --escape --binary --overwrite --verbose ~/.galileo/firmware.cap </dev/ttyACM4 >/dev/ttyACM4
but that isn't all that is needed apparently, as it still thinks it has firmware 0.7.8.2.
Well, I tried to connect using the serial port. I am able to see the Galileo booting, but it doesn't receive anything I send with minicom. I've tried software flow control and a bunch of other things without any luck. It just times out and does a normal boot. Even after it is booted, I can't get any characters through, so I can't log in or anything. I do have some more boards at school I could try next week if you think it is a hardware issue. Here is my minicom minirc.dfl file:
# Machine-generated file - use setup menu in minicom to change parameters.
pu port /dev/ttyUSB0
pu baudrate 115200
pu bits 8
pu parity N
pu stopbits 1
pu xonxoff Yes
Thanks for the suggestion!
Funny, I was just seeing this problem yesterday too on my old Gen 1 Galileo board. Monitoring the update from the serial port, I saw this strange IRQ 40 during the update:
6 BPS:[ 134.14978omm: clloade 3.8.7-yoc150096] Cal6] [<c107edrt_bad_irq+096] [<e077e_udc_isr+0x15d/0x1028 [40>] note_i60/0x1a0
 [<c107d6ercpu+0x70/34.150096] irq_event+0x 134.150096irq_event+06] [<c107f2q+0x70/0x70
e8bf1>] ? co6 ? do_IRQace_hardirq0x9a/0x170
[ 134.r_del+0xb/0xc1035ed5>] rq+0x55/0x130
[ 134.150096] [<c134.150096] <IRQ> [<c10360f5>] ? irq_exit+0RQ+0x43/0xb050096] [<c1trace_hardirqs_on_calle50096] [<c1x36
[ 134>] pch_udc_i]
[ 134.1bling IRQ #40
Byte 9] irq 40: nobody cared (try booting with the "irqpoll" option)
[ 134.150096] Pid: 875, cr Tainted: G W to-standard #1
[ 134.l Trace:
[ 134.1500974>] __repox24/0xc0
[ 134.15004ad>] ? pchpch_udc]
This breaks the communication with the updater and nothing happens afterwards. It might be nice to see some script what should happen, and if the firmware update could be done from the command line.
Interestingly, the firmware upgrade from a MacOS Java environment worked.
I also tried to reproduce this update manually, but got stuck too.
First, I copied a "firmware.cap" file with a zterminal file transfer protocol to the board:
lsz --escape --binary --overwrite firmware-1.0.4.cap < /dev/cu.usbmodem1421 > /dev/cu.usbmodem1421
Then, the question is how to do the firmware update on the board itself?
looks interesting, but somehow it requires a .bin file. All we have from the Downoad site is a .cap file. So, I did not follow up the manual path too far. It might be usueful to have it though to understand where an update breaks.
here is my opinion about:
I think you will fail with Firmware Updater, because a capsule update method (using .cap file) was implemented in FW 1.0.0 or closer (see Old BSP version (0.7.x, 0.8.x), boot problem from SD card and efi_capsule_update.ko ). Intel do not recommend to use firmware update tools in OS with FW version 0.7.x because of some problems with file links.
Need to boot from SD card with Linux image like 1.0.4 and use 1) Firmware Updater or 2) manual update as described in the Chapter # 10.2 "Programming flash using Linux* run-time system" of the document called "Intel ® Quark™ SoC X1000 Board Support Package (BSP) Build and Software User Guide, Release 1.0.1, 22 May 2014" (link to the document: https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23197 or https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23962)
From my MacOS machine, the firmware upgrade worked as expected. On the Mac, there runs Java 1.7.
From the Linux machine, the firmware upgrade hangs during upload of the file to the board. On the Linux machine there is Java:
~$ java -version
java version "1.6.0_33"
OpenJDK Runtime Environment (IcedTea6 1.13.5) (6b33-1.13.5-2~deb7u1)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
Maybe there were other differences too. Before the upgrade, I uploaded the firmware manually to the board with the zterminal protocol (sz). That worked from both Linux and Mac. I was also able to run remote commands with "sz -c" similar to what the Arduino IDE does. The last step, upgrading the firmware from the board itself, I could not make working. I should log the screen session next time when I do an upgrade.