Is it posible to compile an .o/.elf file to the 8Mbit SPI Linux of Galileo gen2?

[RGao2]

Thanks for your time!

Hi everyone

When programing the Galileo gen2 board by the Arduino IDE, an *.elf executable file is produced and transfer to the Galileo gen2 board /Shelf/*.elf .

But when reboot the Galileo gen2 board, that file was removed since the onboard linux system is stored in the 8Mbit Flash.

Now i don't want to use the SD card image method for my products costs concern.

So I'm trying to use yocto to add my .o/.elf executable file to the final Flash-missing.bin, so my program would be executed each time system reboot.

I want to know is this posible?

Regards

[FTinetti]

Interesting... are you sure that copying a .elf file in /sketch would be all you need?

Fernando.

[RGao2]

Hi FGT

Thanks for your attention, yes.

I need the .elf file is build to the rootfs files of my image-spi-galileo, and flash the .bin file to onboard 8Mbit Flash memory.

So each time after system reboots, my .elf file will be there.

Regards

[idata]

Hi GGidea,

Unfortunately, that's not possible. When you upload an Arduino sketch, the .elf file is store in the /sketch directory. This directory will be there until the board reboots. The same happens with any other file you create, the file created will be deleted once the board reboots. The only way to store an Arduino sketch permanently is using the Yocto SD image.Regards,Diego

[RGao2]

Hi Intel Corporation

Thanks for your reply!

According to my understanding, the SD card & the onboard 8Mbit FLASH are all power down nonvolatile memory.

why SD card would, while FLASH not?

Since i'm not familiar with the linux os, just thinking about building my .elf file into the rootfs files of my image-spi-galileo,

and flash the .bin file to onboard 8Mbit Flash memory.So each time after system reboots, my .elf file will be there.

Regards

[asss]

Hi,

my experience shows that it is possible to have a sketch in SPI flash memory.

Here is a small example:

1. I used the Blink sketch

2. After preparing a flash image (it was a long work), I wrote it into Galileo Gen1 board:

3. Next boot a SPI image

This image is based on Kernel 3.19.8:

4. After booting the board is blinking.

Even if /sketch/sketch.elf will be deleted, it will be restored after the next boot.

PS: I'm not a wizard, just a maker.

BTW, here I attach my SPI image with Blink example for Galileo Gen1 board.

PLEASE USE IT FOR OWN RISKS ONLY!!!

IT IS NOT RECOMMENDED FOR REGULAR USERS!!! 

It is possible to program it into a board using Dediprog (see Intel's manual) or Galiprog (https://github.com/xbolshe/galiprog Galiprog ).

BR,

xbolshe

[FTinetti]

Great, this is exactly what I was looking for, thank you very much,

Fernando.

[RGao2]

Hi xbolshe

It's really nice to see your test result! . I had test your Flash-missingPDAT.bin file on my Gen2 board, the linux OS can boot up successfully, and there is a sketch.elf sleeping! That's Great!

There is some confuse about the step 2 of your test:

"2. After preparing a flash image (it was a long work), I wrote it into Galileo Gen1 board"

The way i had try to put my own sketch.elf into /sketch/ , was simply to :

1.decompress the rootfs file *.cpio.lzma which was created by the yocto bitbake image-spi-galileo commad;

2.copy sketch.elf to the decompressed location /sketch/ .

3.pack and compress to *.cpio.lzma manually;

4.create file Flash-missing.bin file by the system-image tool;

5.program it into Gen2 board using Dediprog;

But finally the linux OS can't bootup normally. But the Flash-missing.bin which hadnot changed by me could bootup successfully..

Sorry for my poor English...

So would you please share me some detail of the step 2.

Thanks. xbolshe!

Regards 

[asss]

Hi,

I also just wrote sketch into initramfs file as you have mentioned, but it was a longer way.

Flash-missing.bin requires to be processed using spi-flash-tool before programming using Dediprog.

It adds some bytes related with a board model and MAC addresses.

Also problems may be related with system-image tool configuration.

May you clarify "But finally the linux OS can't bootup normally" ?

BR,

xbolshe

[RGao2]

Sorry for so long boot messages here...

Press [Enter] to directly boot.

Press [F7] to show boot menu options.

GNU GRUB version 0.97 (604K lower / 244604K upper memory)

+-------------------------------------------------------------------------+

| ---- No "boot/grub/grub.conf" file found on 1st USB or SD device ---- |

| Clanton SVP kernel-SPI initrd-SPI IMR-On IO-APIC/HPET NoEMU |

| Clanton SVP kernel-SPI initrd-MassStorage big-rootfs IMR-On IO-APIC/H> |

| Clanton SVP kernel-MassStorage initrd-MassStorage small-rootfs IMR-On> |

| Clanton SVP kernel-MassStorage initrd-MassStorage big-rootfs IMR-On I> |

| Clanton SVP kernel-MassStorage initrd-MassStorage big-rootfs IMR-On I> |

| |

| |

| |

| |

| |

| |

+-------------------------------------------------------------------------+

Use the ^ and v keys to select which entry is highlighted.

Press enter to boot the selected OS, 'e' to edit the

commands before booting, 'a' to modify the kernel arguments

before booting, or 'c' for a command-line.

Found layout.conf @ 0xffcff000 len 0x00000beb

# WARNING: this file is indirectly included in a Makefile where it

# defines Make targets and pre-requisites. As a consequence you MUST

# run "make clean" BEFORE making changes to it. Failure to do so may

# result in the make process being unable to clean files it no longer

# has references to.

[main]

size=8388608

type=global

[MFH]

version=0x1

flags=0x0

address=0xfff08000

type=mfh

[Flash Image Version]

type=mfh.version

meta=version

value=0x01000105

[ROM_OVERLAY]

address=0xfffe0000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/EDKII_BOOTROM_OVERRIDE.Fv

type=some_type

[signed-key-module]

address=0xfffd8000

item_file=config/SvpSignedKeyModule.bin

svn_index=0

type=some_type

in_capsule=no

# On a deployed system, the SVN area holds the last known secure

# version of each signed asset.

# TODO: generate this area by collecting the SVN from the assets

# themselves.

[svn-area]

address=0xfffd0000

item_file=config/SVNArea.bin

type=some_type

# A capsule upgrade must implement some smart logic to make sure the

# highest Security Version Number always wins (rollback protection)

in_capsule=no

[fixed_recovery_image]

address=0xfff90000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/EDKII_RECOVERY_IMAGE1.Fv

sign=yes

type=mfh.host_fw_stage1_signed

svn_index=2

# in_capsule=no

[NV_Storage]

address=0xfff30000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/EDKII_NVRAM.bin

type=some_type

[RMU]

address=0xfff00000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/RMU.bin

type=none_registered

[boot_stage1_image1]

address=0xffec0000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/EDKII_BOOT_STAGE1_IMAGE1.Fv

sign=yes

boot_index=0

type=mfh.host_fw_stage1_signed

svn_index=1

[boot_stage1_image2]

address=0xffe80000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/EDKII_BOOT_STAGE1_IMAGE2.Fv

sign=yes

boot_index=1

type=mfh.host_fw_stage1_signed

svn_index=1

[boot_stage_2_compact]

address=0xffd00000

item_file=../../Quark_EDKII/Build/QuarkPlatform/RELEASE_GCC/FV/FlashModules/EDKII_BOOT_STAGE2_COMPACT.Fv

sign=yes

type=mfh.host_fw_stage2_signed

svn_index=3

[Ramdisk]

address=0xffa60000

item_file=../../meta-clanton/yocto_build/tmp/deploy/images/image-spi-clanton.cpio.lzma

sign=yes

type=mfh.ramdisk_signed

svn_index=7

[LAYOUT.CONF_DUMP]

address=0xffcff000

type=mfh.build_information

meta=layout

[Kernel]

address=0xff852000

item_file=../../meta-clanton/yocto_build/tmp/deploy/images/bzImage

sign=yes

type=mfh.kernel_signed

svn_index=6

[grub.conf]

address=0xff851000

item_file=grub/grub-spi.conf

sign=yes

type=mfh.bootloader_conf_signed

svn_index=5

[grub]

address=0xff800000

item_file=../../meta-clanton/yocto_build/tmp/deploy/images/grub.efi

sign=yes

fvwrap=yes

guid=B43BD3E1-64D1-4744-9394-D0E1C4DE8C87

type=mfh.bootloader_signed

svn_index=4

[Linux-EFI SPI, setup=0x107f, size=0x1e0c50]

[Initrd SPI, addr=0xdb58000, size=0x29d9b3]

[ 0.000000] Initializing cgroup subsys cpuset

[ 0.000000] Initializing cgroup subsys cpu

[ 0.000000] Linux version 3.8.7-yocto-standard (ggidea@ggidea-NV44) (gcc version 4.7.2 (GCC) ) # 1 Mon Apr 11 19:30:01 CST 2016

[ 0.000000] Disabling PGE capability bit

[ 0.000000] e820: BIOS-provided physical RAM map:

[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000096fff] usable

[ 0.000000] BIOS-e820: [mem 0x0000000000097000-0x0000000000097fff] reserved

[ 0.000000] BIOS-e820: [mem 0x0000000000098000-0x000000000009ffff] usable

[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000000efdefff] usable

[ 0.000000] BIOS-e820: [mem 0x000000000efdf000-0x000000000f01efff] ACPI data

[ 0.000000] BIOS-e820: [mem 0x000000000f01f000-0x000000000f0defff] reserved

[ 0.000000] BIOS-e820: [mem 0x000000000f0df000-0x000000000fddefff] ACPI NVS

[ 0.000000] BIOS-e820: [mem 0x000000000fddf000-0x000000000fdeefff] reserved

[ 0.000000] BIOS-e820: [mem 0x000000000fdef000-0x000000000fdeffff] usable

[ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000e1ffffff] reserved

[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved

[ ...

[RGao2]

Hi xbolshe

My unpack and repack steps :

1. unpack *.rootfs.cpio.lzma.

2.add sketch.elf to /sketch/.

3.find . | cpio >test.cpio

4.lzma test.cpio

5.cd sysimage-relese and run ../../spi-flash-tool/Makefile

6.Flash-missing.bin processed using spi-flash-tool

7.programming using Dediprog.

8.poweron the gen2 board.

Regards

[asss]

Hi,

it seems your grub/grub-spi.conf has an error:

you use console=ttyQRK1,115200n8 instead of console=ttyS1,115200n8

First need to fix it.

BR,

xbolshe

[RGao2]

Hi

Thanks for all your reply!

Finally my problem was solved successfully.

It was my pack command wrong lead to the unnormal boot up problem.

find . | cpio -H newc -o | gzip -9 > ../initrd.gz

is the right command.

Regards

[MBlak2]

There is a very nice Getting Started Tutorial at SparkFun that details a way to edit /etc/inittab -- I think that path is where you want to go to change how the Galileo boots up. The nifty part about their Arduino code is that it is actually Linux system calls. The Galileo boots up either running node.js or an Arduino sketch, but --- either way, Yocto Linux command line is available at all terminal endpoints.

https://learn.sparkfun.com/tutorials/galileo-getting-started-guide# introduction https://learn.sparkfun.com/tutorials/galileo-getting-started-guide# introduction

[RGao2]

Hi jinzai

Thanks for your suggestion!

I had already looked into the Getting Started Trtorial at SparkFun. It is illusttrate the way to change how the Galileo boots up, is helpful to me .

But the key of my problem is how to change the rootfs to include my program and the inittab which will not affected by system reboot.

Thank you! jinzai

Regards

[MBlak2]

Yes, we all have that same issue, in fact. The size of the root filesystem is fixed in the kernel. The only alternative I can see is rebuilding it, unfortunately. That requires a Linux desktop, so -- in lieu of Intel providing and image with a larger root filesystem, the only way I can see is to get a Linux desktop and rebuild the kernel for a larger root space. For what it is worth, I cannot even get that large image to boot my Galileo 2 at all.

I have been able to make a third partition in Linux and mount that, which gives me more space, but not in the root filesystem. I run out of room even updating the app daemon, but I have been able to use that third partition to get around that issue this time.

[FTinetti]

jinzai wrote:

Yes, we all have that same issue, in fact. The size of the root filesystem is fixed in the kernel. The only alternative I can see is rebuilding it, unfortunately. That requires a Linux desktop, so -- in lieu of Intel providing and image with a larger root filesystem, the only way I can see is to get a Linux desktop and rebuild the kernel for a larger root space. For what it is worth, I cannot even get that large image to boot my Galileo 2 at all.

I have been able to make a third partition in Linux and mount that, which gives me more space, but not in the root filesystem. I run out of room even updating the app daemon, but I have been able to use that third partition to get around that issue this time.

Hmmm... I'm sorry for my lack of time and experience to experiment on this, I'm just guessing: If the current filesystem

a) has room for a small sketch

b) a small sketch can be placed in the filesystem

c) that sketch can be made to run at startup

then the sketch can issue the necessary commands to mount any other filesystem or anything else.

Again: just guessing...

Fernando.