8 Replies Latest reply on Jan 26, 2016 1:54 PM by noxitcs

    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 https://communities.intel.com/message/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 https://communities.intel.com/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: Intel® Galileo - Programming SPI Flash through the UEFI Internal Shell . 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!



        • 1. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

          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: Intel® Galileo – Recovery Mode. 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




          • 2. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

            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]  [<c106d324>] __report_bad_irq.isra.6+0x24/0xa0

            [  87.160041]  [<c106d562>] note_interrupt+0x162/0x1b0

            [  87.160041]  [<e06586ef>] ? gs_rx_push+0x15f/0x1b0 [g_serial]

            [  87.160041]  [<c106bb90>] handle_irq_event_percpu+0x70/0x140

            [  87.160041]  [<c12bec27>] ? printk+0x38/0x3a

            [  87.160041]  [<c106d670>] ? handle_simple_irq+0x50/0x50

            [  87.160041]  [<c106bc7c>] handle_irq_event+0x1c/0x30

            [  87.160041]  [<c106d6c2>] handle_edge_irq+0x52/0xd0

            [  87.160041]  <IRQ>  [<c100401a>] ? do_IRQ+0x3a/0xb0

            [  87.160041]  [<c12c346c>] ? common_interrupt+0x2c/0x31

            [  87.160041]  [<e06586ef>] ? gs_rx_push+0x15f/0x1b0 [g_serial]

            [  87.160041]  [<c102fb79>] ? tasklet_action+0x39/0x70

            [  87.160041]  [<c102fe5f>] ? __do_softirq+0x7f/0x120

            [  87.160041]  [<c102fde0>] ? local_bh_enable_ip+0x80/0x80

            [  87.160041]  <IRQ>  [<c1030025>] ? irq_exit+0x85/0x90

            [  87.160041]  [<c1004023>] ? do_IRQ+0x43/0xb0

            [  87.160041]  [<c12c346c>] ? common_interrupt+0x2c/0x31

            [  87.160041]  [<c11c7d20>] ? tty_ldiscs_seq_stop+0x10/0x10

            [  87.160041]  [<c11c7d58>] ? tty_ldisc_ref+0x8/0x10

            [  87.160041]  [<c11c8ee9>] ? flush_to_ldisc+0x19/0x110

            [  87.160041]  [<c103db1e>] ? process_one_work+0x10e/0x370

            [  87.160041]  [<c12c346c>] ? common_interrupt+0x2c/0x31

            [  87.160041]  [<c103e9f1>] ? worker_thread+0x101/0x330

            [  87.160041]  [<c103e8f0>] ? busy_worker_rebind_fn+0xb0/0xb0

            [  87.160041]  [<c104248e>] ? kthread+0x8e/0xa0

            [  87.160041]  [<c12c2efb>] ? ret_from_kernel_thread+0x1b/0x30

            [  87.160041]  [<c1042400>] ? kthread_create_on_node+0xa0/0xa0

            [  87.160041] handlers:

            [  87.160041] [<e0640200>] 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,


            • 3. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

              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): http://downloadmirror.intel.com/23962/eng/Quark_BSP_BuildandSWUserGuide_329687_007.pdf


              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




              • 4. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

                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

                IIO_resource[0].PciResourceMem32Limit: AFFFFFFF

                IIO_resource[0].PciResourceMem64Base:  B0000000

                IIO_resource[0].PciResourceMem64Limit: DFFFFFFF

                IIO_resource[0].PciResourceIoBase:    2000

                IIO_resource[0].PciResourceIoLimit:    FFFF


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

                InstallProtocolInterface: 2F707EBB-4A1A-11D4-9A38-0090273FC14D E8F6F84

                Loading driver 4D35A5A7-622E-4955-A5D2-CDA812940D74

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

                Loading driver at 0x0000F058000 EntryPoint=0x0000F058273 FwBlockService.efi

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

                Supported SPI Flash device found, Vendor Id: 0xEF, Device ID: 0x4017!

                Fvb base : FFF30000  Attributes : 00000000!

                Fvb base : FFF40000  Attributes : 00000000!

                Fvb base : FFF30048  Attributes : 00000000!

                Fvb base : FFF3E000  Attributes : 00000000!

                Fvb base : FFF30000  Attributes : 00000000!

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

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

                InstallProtocolInterface: 53A4C71B-B581-4170-91B3-8DB87A4B5C46 F0DE754

                InstallProtocolInterface: F496922D-172F-4BBC-A1EB-0EEB949C3486 0

                Fvb base : FFF40000  Attributes : 00000000!

                Fvb base : FFF30048  Attributes : 00000000!

                Fvb base : FFF3E000  Attributes : 00000000!

                Loading driver C7EA9787-CA0A-43B4-B1E5-25EF87391F8D

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

                Loading driver at 0x0000E8C7000 EntryPoint=0x0000E8C7273 QncS3Support.efi

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

                InstallProtocolInterface: C7EA9787-CA0A-43B4-B1E5-25EF87391F8D 0



                ASSERT_EFI_ERROR (Status = Invalid Parameter)

                    I omitted some lines in the middle to shorten it (but let me know if they could be useful), but the point is that this ASSERT_EFI_ERROR is still showing up. Note again that I can still boot the board as normal after this failed attempt.


                I just find it so weird that one particular version of this FV file is working but the others are not?! This must mean that at least the hardware is not damaged, right? Do you think that if I downgrade the firmware version instead of trying to upgrade it I could have better luck? Also if you happen to have one of those FV files before 1.0.0. that could be worth a try. I'm thinking in particular about that "732" (which I think at this point is really version which came with my board and from which I was able to upgrade directly to 1.0.4.


                Thanks again!


                • 5. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

                  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.




                  • 6. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

                    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.

                    • 7. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

                      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: Intel® Galileo - Programming SPI Flash through the UEFI Internal Shell. Hopefully, since the board seems to have a different firmware now (1.0.1), you might get a different result with the methods above.




                      • 8. Re: Updating gen1 firmware: ASSERT_EFI_ERROR

                        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: New to Galileo.  Boots, but sketches do not run, and I am unable to update firmware. 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...