3 Replies Latest reply on Jul 21, 2016 9:34 AM by Johan Kruger

    Custom binaries on Galileo SPI Flash image cannot run

    Johan Kruger

      I am using the Galileo SDK to cross compile binaries that I want to run on a STANDARD distributed Galileo image present in the SPI flash.

      Intel® Quark™ SoC X1000 Board Support Package (BSP)

       

      As an example, I have a Galileo Gen 2 booted with the following default image (as shipped) that is present in the SPI flash:

       

      Galileo image as shipped in the SPI flash

      root@clanton:/var/volatile/tmp# uname -a

      Linux clanton 3.8.7-yocto-standard #1 Fri Jun 6 22:18:10 PDT 2014 i586 GNU/Linux

       

      The SPI image contains binaries that are part of busybox.

       

      When I copy an external binary that I compiled with the SDK to /tmp/, it does not execute.

       

      Copying external binary to target

      root@clanton:~#

      root@clanton:~# cd /tmp

      root@clanton:/var/volatile/tmp# wget http://xxx.xxx.xxx.xxx/files/galileo/test1

      Connecting to xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx:80)

      root@clanton:/var/volatile/tmp# ls -l /tmp/test1

      -rw-r--r--    1 root     root          8613 Jan  1 00:38 /tmp/test1

      root@clanton:/var/volatile/tmp# chmod a+x /tmp/test1

      root@clanton:/var/volatile/tmp# ls -l /tmp/test1

      -rwxr-xr-x    1 root     root          8613 Jan  1 00:38 /tmp/test1

      root@clanton:/var/volatile/tmp# /tmp/test1

      -sh: /tmp/test1: not found

      root@clanton:/var/volatile/tmp

       

      My guess is that only signed files are allowed to run, however, I am not sure.

      If that is the case, what is the point of external SDKs that allow you to compile binaries, if one cannot copy them to the target individually ?

      If this is the case, are there a way to sign externally compiled binaries so that they can be executed on the default boot image that customers get when they buy a Galileo Gen 2 ?

       

      If it's not an unsigned/security problem, what would be the reason that the SDK compiled binaries cannot execute on the default boot image provided in the SPI flash ?

       

      NOTE:

      When I install the following image, and do not use the one that is shipped in the SPI flash, then the binaries DO work:

      IoT - Step 1: Make a bootable micro SD card | Intel® Software

       

      Is this the expected behavior ?

       

      Thanks

        • 1. Re: Custom binaries on Galileo SPI Flash image cannot run
          Intel Corporation
          This message was posted on behalf of Intel Corporation

          Hello Johan Kruger,
           
          Everything you've done is fine, what is happening is that when you try to run test1 with the command  /tmp/test1 you are not actually running it. If you are already on the /tmp/ directory you can run it with the command ./test1.
           
          Try that little difference and let me know if this time it works.
          -Peter.

          • 2. Re: Custom binaries on Galileo SPI Flash image cannot run
            Johan Kruger

            I did try that. I also added "." to the path, just in case.

            I then copied "/bin/ls" to "/tmp/ls" and executed "/tmp/ls" which worked.

            I then copied "/tmp/test1" to "/tmp/ls" and executed "/tmp/ls" and it gave "-sh: /tmp/ls: not found" error.

             

            Maybe the binaries I compiled with the new SDK, is not compatible with the older image that is shipped with the board, however, they are simply 32-bit elf binaries and should be compatible.

            • 3. Re: Custom binaries on Galileo SPI Flash image cannot run
              Johan Kruger

              Solved.

              It appears that if I compile the binaries staticly, that it works.

              It turns out that the message received ("-sh: ./test: not found") is just not the usual to indicate missing libraries.

              Since the SDK I used is newer, it linked with libraries that are not part of the SPI flash image.

              This is normally easily observed if the correct message is returned, in this case it seemed as if the file was not visible on the file-system.

              1 of 1 people found this helpful