What did you add to the SPI image? And how did you do it? Were the data you appended added as a file or as a package? If you appended it to the file system then I believe you should be able to find it on Linux. Where did you append it?
So, to sum up, what did you added? How did you do it? And where did you put it?
Amazing, your questions already gave me new ideas :D
I created a textfile, added it to the layout.conf and then created the image. So: No it is not accessible via the linux filesystem. And yes i could try putting the data there, BUT most of the time i work with a sd card linux image, then i have the same problem: How to tead the spi flash filesystem (and mount it?!?) to access the data?
There MUST be a way, think about firmware updates via USB (from stick or over Arduino IDE), there you modify the flash from a running OS. I hope its not an Intel secret...
1. SPI flash has no filesystem like EXT3. It has an initial RAM disk only to boot non-SD card Linux. A reason is a small SPI flash memory size.
2. It is possible to make a hole (a range of memory addresses) in SPI flash image and use it for own reason. Just need to make such SPI flash image and write a kernel driver for SD card Linux image to access this hole in a flash memory.
3. It is possible to use own EFI variable like shown below to store a data
4. more, more, more....
Thanks for the reply!
1. Yes I know, maybe I was a bit unclear here: I added a textfile like for example the grub.conf is added to the image, not like some kind of filesystem...
2. That's what I was trying! I modified the layout.conf and added a textfile at 0x71c000 in the image, that means at the middle of the mfh block (which is now half size). the mfh itself only contains 168 bytes of data and the platformdata patched into a "hole" like you said, so there was more than enough empty space. Now the missing part is the "kernel driver" or any other mechanism to read that "range of memory addresses" as you call it. My hope was that there already is such a kernel driver, because firmware updates are already done from a running Linux.
3. Another good idea to store date! Thanks! I will have a look at it.
Basically what I am trying to achieve is similar to what you did with your galiprog (amazing work, thanks for that!) but not from "outside" the board over the dediprog pins but from "inside", that means from the pins connected to the quark.
Hi, me again...
I managed to create an efi variable! Exactly what I needed. Thanks for this hint!
For anyone who is interested: In the file system mapping for each variable there is a file called "raw_value". With "cat raw_value > ~/variable.txt" I read the content of the variable (in the text file you will find the data of the whole struct efi_variable), changed the value and wrote back again with "cat ~/variable.txt > raw_value".
xbolshe Thanks again for that solution!