- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Interesting... are you sure that copying a .elf file in /sketch would be all you need?
Fernando.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Great, this is exactly what I was looking for, thank you very much,
Fernando.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
[ ...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page