Project

General

Profile

Using EEPROM available on MitySOM-5CSX

Added by Jared Kirschner almost 7 years ago

Context:

My team would like to store some non-volatile data specific to a unit of hardware (independent of the SD card / image) in our system, and decided the appropriate place to store this information would be the EEPROM available on the MitySOM-5CSX module.

Questions:

I see from this link (https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/U-Boot_on_the_MitySOM-5CSX#Below-is-a-breakdown-of-the-v13-I2C-EEPROM-FT24C16A-16Kbit-memory-usage) that said EEPROM is already being used for some other information. The text of the page says:

The factory configuration data include the serial number, model number, a version number, and a checksum.

There is also a breakdown of the memory usage (e.g., v1.3):

u-boot-socfpga.git/board/cl/mityarm-5csx/config_block.h

u32               ConfigMagicWord;  /** CONFIG_I2C_MAGIC_WORD */
u32               ConfigVersion;    /** CONFIG_I2C_VERSION */
u8                MACADDR[6];       
u32               FpgaType;         
u32               Spare;            /** Not Used */
u32               SerialNumber;     /** serial number assigned to part */
char              ModelNumber[32];   /** board model number, human readable text, NULL terminated */
u8                MACADDR2[6];      /** Default to 0.. Contact Critical Link for allocation of second MAC if both MACs used */

From the above breakdown, it sounds like after the first 64 bytes, the remaining 2048 - 64 bytes are available for custom application use (though, I might make the start index for custom data something larger than 64, in case more entries are added to the above breakdown in the future, to maintain compatibility).

That said, though a checksum was mentioned in the text, I don't see a checksum included in the breakdown. Which raises the questions:
  • Is there a checksum?
  • Will writing custom data after the first 64 bytes of the EEPROM mess anything up? (e.g., the preloader seeing an invalid checksum in the EEPROM, and thus preventing boot)
  • And is writing custom application data to the module's EEPROM an intended / supported use?

Thanks,
Jared


Replies (9)

RE: Using EEPROM available on MitySOM-5CSX - Added by Michael Williamson almost 7 years ago

Hi Jared,

Before you get into the I2C EEPROM, does the MitySOM you are using have the QSPI NOR FLASH installed (most do)? If you are booting from SD card than that should be wide open (and ranges from 8 to 32 MB depending on the install option). Would that work?

The EEPROM does have some spare space, but if you corrupt the data in the first 64 bytes you will lose the serial number information as well as the MAC address assigned by Critical Link. It would be better if you could avoid using it.

-Mike

RE: Using EEPROM available on MitySOM-5CSX - Added by Adam Dziedzic almost 7 years ago

Hi Jared,

If you are looking for a small amount of space, there is also some memory available in the RTC. There is 256B of battery backed RAM on the AB1805-T3 RTC. Assuming you have a battery, this will hold the data until the battery dies or the MitySOM is removed from the socket.

- Adam

RE: Using EEPROM available on MitySOM-5CSX - Added by Stephen Snyder almost 7 years ago

We're using the 5CSX-H6-4YA so we should have 32MB of QSPI NOR, and we are booting from SD card, though it's possible we may want to put the preloader + uboot in their so we can TFTP a new SD image.

If we did use the QSPI NOR, what kind of driver support exists in Linux?

RE: Using EEPROM available on MitySOM-5CSX - Added by Michael Williamson almost 7 years ago

The QSPI NOR is supported by the MTD layer, so you should be able to partition it and mount it using JFFS2 (or perhaps UBIFS, but I personally don't have a lot of experience with that) or even access it RAW if you like with flash_eraseall and flash_cp.

Our default device tree should have it configured already with a default partition scheme. You might want to look at that and see if you could use one of those partitions.

Let me know if you need a little more help sorting out mounting an MTD partition with JFFS2. Typically you run a flash_erase -j /dev/mtdX and then a mount -t jffs2 /dev/mtdX /mountpoint ....

-Mike

RE: Using EEPROM available on MitySOM-5CSX - Added by Jared Kirschner almost 7 years ago

Hello Mike and Adam,

I very much appreciate you both providing other suggestions readily available with our MitySOM.

We don't have a lot of data that we need to store off the SD card (well under 1 kB). Most of it will probably be written once (or rarely, such as upon servicing).

However, there is at least one piece of data which will likely be updated 20,000 - 40,000 times over the life of the device.

As best as I can tell, the QSPI Flash Device available on our MitySOM is rated to 100,000 erase cycles per sector (https://www.altera.com/support/support-resources/supported-flash-devices-for-cyclone-v-and-arria-v-soc.html, https://www.micron.com/parts/nor-flash/serial-nor-flash/n25q512a83gsf40f). Is that your understanding as well? If so, the QSPI Flash Device is likely a better option than the RTC, and possibly a safer option than the I2C EEPROM (in case the first 64 bytes are corrupted).

We may reach out again on this thread once we start attempting to use the QSPI Flash Device (assuming it meets our requirement for write cycles), such as if we need help mounting an MTD partition with JFFS2 (as suggested by Mike).

Thanks,
Jared

RE: Using EEPROM available on MitySOM-5CSX - Added by Nicholas Herbert over 6 years ago

Mike,

I recently picked up this task and haven't been able to see the NOR flash device in the MTD devices list. On boot-up I get the following message:

[ 1.159717] cadence-qspi ff705000.spi: couldn't determine tshsl-ns
[ 1.165883] cadence-qspi ff705000.spi: Cadence QSPI NOR probe failed -6

Two things I have turned up in my search relate to a config driver name and a compatible #. In the Critical Link document for "Utilizing QSPI NOR Memory" it mentions needing to enable CONFIG_SPI_CADENCE_QSPI, however throughout our file tree I found it was always referred to as CONFIG_SPI_CADENCE_*QUADSPI* (there is no instance of CONFIG_SPI_CADENCE_QSPI).
I also read in the Cyclone 5v4 documentation that it "Supports the Micron N25Q512A (512 Mb, 108 MHz) and Micron N25Q00AA (1024 Mb, 108 MHz) Quad SPI flash memories that are verified working with the HPS", however the compatible code we use is N25Q128A11 (associated with another valid Micron NOR P/N). I was considering whether this compatible number does not correspond with the module on our system. Which flash module is included with our SOM (P/N 5CSX-H6-4YA-RC)?

Are there any other things you think I should check based on the error we're getting?

Thanks,
Nick

RE: Using EEPROM available on MitySOM-5CSX - Added by Michael Williamson over 6 years ago

What version of the kernel are you using? From our site? Version 3.16?

-Mike

RE: Using EEPROM available on MitySOM-5CSX - Added by Nicholas Herbert over 6 years ago

We are using kernel version 4.1.22

-Nick

RE: Using EEPROM available on MitySOM-5CSX - Added by Nicholas Herbert over 6 years ago

Update: Thanks to your help we have been able to successfully use a partition of the QSPI NOR flash to store critical system information. There was a change of formatting for the device tree between kernel versions such that after updating the device tree for the MTD QSPI driver to match the formatting in the newer kernel the QSPI NOR memory became available to us. Simply by erasing the 'data' partition of the NOR flash through the terminal with "flash_eraseall -j /dev/mtd6" and mounting it using "mount -t jffs2 /dev/mtdblock6 <destination_path>" we were able to interact with it like any other file system. Some useful information came out this article as well: http://free-electrons.com/blog/managing-flash-storage-with-linux/

Thanks for the support!

-Nick

    (1-9/9)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)