Intel® Makers
Intel® Edison, Intel® Joule™, Intel® Curie™, Intel® Galileo
Welcome - This is a Peer-to-Peer Forum only. Intel has discontinued these products but you may find support from other customers on this Forum
9877 Discussions

Updating gen1 firmware: ASSERT_EFI_ERROR


Hi everyone,

I recently started using the Galileo gen1 board, without any issues. When I first got it I updated the firmware to the latest version 1.0.4, and it was running perfectly for a couple months. However, after I carried the board in my backpack for some time while traveling abroad, it stopped working normally. I couldn't establish communication via the Arduino IDE or access the Linux. I also noticed the USB led was not on, which I think indicated that the linux image might not have been loaded properly.

To try to fix this, I looked around the forum and found the FVMAIN.fv file from /message/240391# 240391 240391 . I followed the instructions and put it in my USB stick and restored the firmware successfully, back to version 1.0.0. After this restoration I was able to once again access the Linux in the Galileo.


However, I could still not upload sketches from the Arduino IDE to the board (it recognizes the board but every uploaded sketch fails to execute, even the Blink one). In addition, it is strongly recommended to update the firmware once the restoration procedure is complete, so I tried doing that in two ways, without success. I used the Firmware Updater tool, which after 10 minutes or so, gave me error 128 and refused to work (this is the same as in /thread/96370 except trying many times didn't get rid of the error in my case). I also tried the old Arduino IDE version 1.5.3, which already comes with an updater inside, but that didn't work either (this is how I updated the firmware the first time I got the board). I remembered from my first time playing with the Galileo that I was only able to run sketches once the original firmware was updated to the latest version.


Looking around some more I found that I could try to manually update the SPI flash by following the discussion here: . It seems that contains the 1.0.4 version which is the latest one I think. However, after the update is finished, I get the infamous ASSERT_EFI_ERROR and a refuse to boot. Note that at this point I can still do the recovery firmware procedure again, and restore the board back to 1.0.0. That seems to always work -- what is not working is updating the firmware to the latest version, which seems like an important thing to be able to do, and possibly the reason why my sketches are not running.


Any help will be appreciated with these issues!





8 Replies

Hello noxitcs,

Did you make sure to remove the SD Card before trying to upgrade the firmware? This process requires not using the SD Card. Also, are you using the correct COM port?

On the other hand, I recommend you to check this guide: . It's about the FVMAIN.fv file, but this version recovers the board with the firmware 1.0.1. I recommend you to use this file because there might be a difference if you try to upgrade the firmware form the 1.0.1 version instead from the 1.0.0 version.

The other suggestion I recommend you to try is to use the Firmware Updater Tool, but using the .cap file to upgrade the firmware. As you can see, there are two options to upgrade the firmware. Select the "Browse for .cap file" option. The .cap file you should use can be downloaded from the following link: Flash-missingPDAT_Release-1.0.4.cap




Hi Diego,

I tried the two suggestions you gave me, without much success. I took the FVMAIN.fv file from the link you shared, repeating the procedure I used before, which I think it's the right way for the gen1 (i.e. grounding the specific resistor mentioned). However, I got a one-line error when trying to recover using this file (unfortunately I forgot to copy the message, but I can do try that again later). I then tried again with the old FVMAIN.fv file just to make sure the procedure was right, and the recovery worked as expected. I wonder if the link you sent me is specifically for the gen2 board, including the .fv file?

Then I tried the Firmware Updater tool, using the Flash-missingPDAT_Release-1.0.4.cap instead. I got the same error as before, code 128. I also noticed in my Linux debug terminal (using the 3.5 mm jack) that as soon as I start the update procedure this happens:

root@clanton:~# [ 87.154986] irq 40: nobody cared (try booting with the "irqpo

ll" option)

[ 87.160041] Pid: 197, comm: kworker/0:1 Not tainted 3.8.7-yocto-standard # 1

[ 87.160041] Call Trace:

[ 87.160041] [] __report_bad_irq.isra.6+0x24/0xa0

[ 87.160041] [] note_interrupt+0x162/0x1b0

[ 87.160041] [] ? gs_rx_push+0x15f/0x1b0 [g_serial]

[ 87.160041] [] handle_irq_event_percpu+0x70/0x140

[ 87.160041] [] ? printk+0x38/0x3a

[ 87.160041] [] ? handle_simple_irq+0x50/0x50

[ 87.160041] [] handle_irq_event+0x1c/0x30

[ 87.160041] [] handle_edge_irq+0x52/0xd0

[ 87.160041] [] ? do_IRQ+0x3a/0xb0

[ 87.160041] [] ? common_interrupt+0x2c/0x31

[ 87.160041] [] ? gs_rx_push+0x15f/0x1b0 [g_serial]

[ 87.160041] [] ? tasklet_action+0x39/0x70

[ 87.160041] [] ? __do_softirq+0x7f/0x120

[ 87.160041] [] ? local_bh_enable_ip+0x80/0x80

[ 87.160041] [] ? irq_exit+0x85/0x90

[ 87.160041] [] ? do_IRQ+0x43/0xb0

[ 87.160041] [] ? common_interrupt+0x2c/0x31

[ 87.160041] [] ? tty_ldiscs_seq_stop+0x10/0x10

[ 87.160041] [] ? tty_ldisc_ref+0x8/0x10

[ 87.160041] [] ? flush_to_ldisc+0x19/0x110

[ 87.160041] [] ? process_one_work+0x10e/0x370

[ 87.160041] [] ? common_interrupt+0x2c/0x31

[ 87.160041] [] ? worker_thread+0x101/0x330

[ 87.160041] [] ? busy_worker_rebind_fn+0xb0/0xb0

[ 87.160041] [] ? kthread+0x8e/0xa0

[ 87.160041] [] ? ret_from_kernel_thread+0x1b/0x30

[ 87.160041] [] ? kthread_create_on_node+0xa0/0xa0

[ 87.160041] handlers:

[ 87.160041] [] pch_udc_isr [pch_udc]

[ 87.160041] Disabling IRQ # 40

Do you think this could be somehow related to the problem? No idea what it means though.

Another possibility I just thought about is if I could somehow recover the firmware to version "732", which I remember was the version that came with the board when I first got it. Maybe if I could restore back to that version and then try the update again it would work? Do you know if and where I could find this firmware version?

Oh, and I'm pretty sure I have the right serial port (i'm on a Mac using a usb adapter, but i'm using cu.usbserial for my port and that always seemed to work before), and no SD cards attached to the board.

Thanks for your help,



Hello noxitcs,

There is another method we could try but you need a DediProg for it. Do you have one, or have access to one? The process is described in the following document (section 11):

If you don't have a DediProg, there is an alternative method shared by other user a while ago. However, this method requires a second Galileo that works as the DediProg. You can check it in the following site: xbolshe/galiprog · GitHub




Hi Diego,


Unfortunately I don't have a DediProg, and it seems to cost a bit more than the board itself, so... But I did order a gen2 board which should be arriving soon, once I get it all set up I can give this method a try.

Regarding the usual methods, I am now using a better serial terminal emulator for mac that allows me to actually see what's going on (Serial, for mac). I have tried again restoring the firmware, using three different FV files:

1) The original one that had worked before, v1.0.0 -- this one still works!

2) The one you suggested above, which should be v1.0.1 -- this one still didn't work, and the only message I get from my terminal is:

Recovery boot selected..........

Failed to add memory space :0xE2000000 0x0

ASSERT_EFI_ERROR (Status = Access Denied)

Note that after I unplug and plug the power back on, the board still boots to the internal linux and everything seems ok (i.e. despite the firmware recovery having failed it didn't seem to get bricked).

3) I used a live Ubuntu usb stick to try and install the BSP package and build those firmware files myself. I didn't go all the way, but I got to the part where a FVMAIN.fv was built. So I tried that one -- the version of the guide I used was 1.1 (from January 2015). This time the error message I got was quite long:

Recovery boot selected..........

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B EACE960

HOBLIST address in DXE = 0xEFDB010

Memory Allocation 0x00000004 0xEA99000 - 0xEAB8FFF

Memory Allocation 0x00000004 0xEFBF000 - 0xEFBFFFF

Memory Allocation 0x00000004 0xEFB6000 - 0xEFBEFFF

Memory Allocation 0x00000004 0xEFAB000 - 0xEFB5FFF

Memory Allocation 0x00000004 0xEFA5000 - 0xEFAAFFF

Memory Allocation 0x00000004 0xEF95000 - 0xEFA4FFF

Memory Allocation 0x00000004 0xEF83000 - 0xEF94FFF

Memory Allocation 0x00000004 0xEF72000 - 0xEF82FFF

Memory Allocation 0x00000004 0xEF70000 - 0xEF71FFF



Memory Allocation 0x00000003 0xEF3F000 - 0xEF3FFFF

Memory Allocation 0x00000003 0xEF3E000 - 0xEF3EFFF

Memory Allocation 0x00000004 0xEF3C000 - 0xEF3DFFF

Memory Allocation 0x00000004 0xEAD3000 - 0xEF3BFFF

Memory Allocation 0x00000004 0xEAB9000 - 0xEAD2FFF

Memory Allocation 0x00000003 0xEAB9000 - 0xEAD2FFF

Memory Allocation 0x00000004 0xEA99000 - 0xEAB8FFF

Memory Allocation 0x00000004 0xBFE0000 - 0xBFFFFFF

FV Hob 0xEF72000 - 0xEF81FFF

FV2 Hob 0xEF72000 - 0xEF81FFF

FV Hob 0xEAD3400 - 0xED173FF

InstallProtocolInterface: D8117CFE-94A6-11D4-9A3A-0090273FC14D EACE3A8

InstallProtocolInterface: 8F644FA9-E850-4DB1-9CE2-0B44698E8DA4 EFD769C

InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B EFD7610

InstallProtocolInterface: 8F644FA9-E850-4DB1-9CE2-0B44698E8DA4 EFD731C

InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B EFD7290

InstallProtocolInterface: 220E73B6-6BDB-4413-8405-B974B108619A EFD3E9C

InstallProtocolInterface: 220E73B6-6BDB-4413-8405-B974B108619A EFD389C

InstallProtocolInterface: FC1BCDB0-7D31-49AA-936A-A4600D9DD083 EACE668

InstallProtocolInterface: EE4E5898-3914-4259-9D6E-DC7BD79403CF EACE668

InstallProtocolInterface: A31280AD-481E-41B6-95E8-127F4C984779 EACE668

Loading driver 9B680FCE-AD6B-4F3A-B60B-F59899003443

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B EFDDC28

Loading driver at 0x0000E938000 EntryPoint=0x0000E938273 DevicePathDxe.efi

InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF E94AA10

InstallProtocolInterface: 0379BE4E-D706-437D-B037-EDB82FB772A4 E93E490

InstallProtocolInterface: 8B843E20-8132-4852-90CC-551A4E4A7F1C E93E488

InstallProtocolInterface: 05C99A21-C70F-4AD2-8A5F-35DF3343F51E E93E480

Loading driver 80CF7257-87AB-47F9-A3FE-D50B76D89541

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B EFDDAA8



Loading driver at 0x0000E8AD000 EntryPoint=0x0000E8AD273 BdsDxe.efi

InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF E8F4990


InstallProtocolInterface: 665E3FF6-46CC-11D4-9A38-0090273FC14D E8BD0A4

Loading driver D58EBCE1-AF26-488D-BE66-C164417F8C13

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B E8FD928

Loading driver at 0x0000E8E9000 EntryPoint=0x0000E8E9273 PciHostBridge.efi

InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF E8F4490

InstallProtocolInterface: CF8034BE-6768-4D8B-B739-7CCE683A9FBE E8F42A8

Address of resource Aperture: E8F4090

IIO_resource[0].BusBase: 0

IIO_resource[0].BusLimit: FF

IIO_resource[0].PciResourceMem32Base: 90000000<...


Hello noxitcs,

Unfortunately I don't have another FVMAIN.fv file that you could try. And yes, this issue is definitely weird, not only because the board can be recovered with only one FVMAIN.fv file, but because after recovering the board with that method, the firmware cannot be upgraded at all.

I'd say that the best thing to do is to try using the Galileo Gen2 you ordered to try to recover the Galileo Gen1 with the GaliProg method. If it didn't work I would say that the board is unrecoverable. It could be that the board is unrecoverable at software level, even though the hardware works fine.

If recovering the board with the Galileo Gen2 doesn't work, you could submit a warranty ticket using the following form: Intel® Support. The Warranty Team might help you with your board, however be sure you bought the Galileo Gen1 less than a year ago, otherwise the Warranty Team won't be able to provide you much help.




Hi Diego,

I have some updates regarding the whole process, especially because it's getting interesting and a little confusing...

After setting up my gen2 board, I tried the GaliProg method by xbolshe. I followed all the steps carefully, and the Arduino program told me that the firmware had been successfully written to the SPI. However, after rebooting upon completion of the process, I once again ran into the ASSERT_EFI_ERROR code (this time saying 'status = aborted'). I then plugged my usb stick with the old FVMAIN.fv file that always works, and recovered the firmware (by pressing 'R' on the error screen).

After this step, I would have assumed that my firmware version would go back to 1.0.0. However, the flash_version file tells me that my version is in fact 0x01000105! I think this is the 1.0.1 version, but I'm not sure. So apparently even after recovering the firmware with my old fv file I still kept the same version, 1.0.1.

I then tried rebooting with an SD card with a full linux image, and to my surprise this time it worked! So now I can access the board using ssh and do pretty much everything on the linux side, including running the Node.js server that I made.

However, and this is the sad part, I still seem to fail to access the 'Arduino side' of the board. Running the two versions of the Intel Arduino IDE seems to work, in that they both say that the Blink sketch was successfully transferred to the board. But no LED comes on, and my serial debugging console gives this message:


[ 132.112523] pch_udc 0000:00:14.2: pch_udc_ep_clear_nak: RxFIFO not Empty

[ 132.112523] pch_udc 0000:00:14.2: pch_udc_ep_clear_nak: RxFIFO not Empty

[ 133.210346] ttyGS0: RX not scheduled?

[ 133.214284] ttyGS0: RX not scheduled?

[ 133.228657] ttyGS0: RX not scheduled?

[ 133.232585] ttyGS0: RX not scheduled?

[ 133.236333] ttyGS0: RX not scheduled?

[ 133.251581] ttyGS0: RX not scheduled?

[ 133.255396] ttyGS0: RX not scheduled?

[ 133.259292] ttyGS0: RX not scheduled?

[ 133.310042] pch_udc 0000:00:14.2: pch_udc_ep_clear_nak: RxFIFO not Empty

This makes me think that maybe there is something wrong with the USB Host port, or with the driver, or something like that?

I then tried updating the firmware to 1.0.4 using the Firmware Updater Tool, which showed me that indeed I am on 1.0.1 version now. However, when trying to update, the tool returned with "failed upload integrity check" message and on my debugging I saw similar messages as above.

To investigate whether the USB could be responsible for this problem, I scp'd the compiled sketch.elf from the temp folder of my Arduino IDE installation, and manually moved the sketch to /sketch/sketch.elf and issued 'chmod +x sketch.elf' and './sketch.elf' to see if that might work. However, the LED still didn't turn on, so I'm a bit suspicious if the USB could really be the culprit.

So the story right now seems to be that most of the functionality of the board is restored, except for the Arduino side of things. Do you (or anybody else) have any ideas of what could be going on?

Thanks for the help!


PS: This board is no longer under warranty because the engineer in my research lab bought it a couple years ago to play around and gave it to me recently, so unfortunately that's not an option.


Hi noxitcs,

The message "ttyGS0: RX not scheduled?" has been discussed before, check the following threads:

It's caused because the firmware is not upgraded. I recommend you to try upgrading the firmware using the .cap file as I mentioned in a previous post:

The other suggestion I recommend you to try is to use the Firmware Updater Tool, but using the .cap file to upgrade the firmware. As you can see, there are two options to upgrade the firmware. Select the "Browse for .cap file" option. The .cap file you should use can be downloaded from the following link: Flash-missingPDAT_Release-1.0.4.cap

You can also try the following method: . Hopefully, since the board seems to have a different firmware now (1.0.1), you might get a different result with the methods above.




Hi Diego,

I figured out that the Firmware Updater error I got above "failed integrity check" was due to me being silly and forgetting to remove the SD card when updating. After trying again without the SD, the entire update process finished, but then the "ASSERT_EFI_ERROR (status = aborted)" came on when the board tried to reboot. This happened with both the downloaded .cap file and the native one in the Updater tool. I also tried flashing the firmware using the UEFI shell and the same error appears after rebooting. It seems the board will simply refuse to update to the latest firmware. I can always recover the firmware using the FVMAIN.fv file though, and now I'm back to the 0x01000105 version. However, any communication using the USB client port with the Arduino results in the "Rx not scheduled" error above, so I can't really use the Arduino side anymore.

I guess I have pretty much exhausted the options here, so I'll just put this board aside and forget about it for now, until perhaps some new idea comes around. I appreciate your help with this issue though! At least I got to learn a lot about the inner workings of the galileo board.



PS: For some reason I just found this thread: It is the exact same problem I'm facing, don't know why I didn't see it before. I guess the conclusion is that indeed it is a bad board and there's not much to do about it...