mechanism for config.txt to persist across reboots

Hi skorson ,

The mechanism is not documented, but it is not complex either. The two components which you will need to modify are:

- create_system_files () which builds the conf.txt file at boot from the U-boot environment variables. You will need here to extract your own variables using fw_printenv, and write your own section and variables to the conf.txt file as shown in create_system_files ().

- update.sh process_ini() : in this file there is a loop that computes the MD5 of conf.txt and if it's different from the one that was computed at boot, it calls process_ini( ). In process_ini( ) you will need to add:
    - ini_parser $FILE "own_section" (I recommend adding a new section, so you keep things separate from already existing configs)
Then
   - write the variables that you want to be saved to the temp file (echo "own_var $own_var" >> /opt/fw_set.tmp) that will be written to the non-volatile(I presume) U-boot environment variables: (fw_setenv -s /opt/fw_set.tmp)

After adding your own variables, you will need to rebuild the pluto firmware and upload to the board.
Build instructions for the plutosdr firmware are available in the repository: plutosdr-fw (exporting VIVADO_SETTINGS is optional since you are not modifying HDL)

If you need support with any of the steps above, mention it

Dumitru

Thank you so much. I will try these steps and see where it gets me. I might just take the simplest approach and use fw_setenv to set my own variables and just use them from there; I noticed I can set a variable and have it persist across reboots. Now I need to figure out how to access a variable set using fw_setenv from a C program.

To access the variables you need to call "fw_printenv -n variable". Although it would be easier for you if you passed the value as an argument to the C program when calling:
# ./executable $(fw_printenv -n variable 2> /dev/null || echo "default_value")

In this manner you will only need to handle parsing of the char array argument in C.

Dumitru

I have a question about this, I'm just learning this stuff, so it's possibly not a smart thing to do. I see there is a device /dev/mtd1ro

If I cat this to a file and parse it, it would appear it contains a bunch of null terminated strings of the persistent variables (after what appears to be a 4 byte header.) Code to do this is pretty straightforward and I can extract my applications variables with a carefully chosen prefix.

1. Is it OK to rely on this /dev/mtd1ro to hold fw environment variables?

2. If it's OK, is there a way to access this data without having to cat to a file first? Is it mounted somewhere?

I'm trying to have my application query for some fw settings and I'd like to avoid cat'ing them in as arguments (it just seems cleaner to me if I have a handful of variables rather than one variable that's a list. If I have a handful, passing them as arguments gets ugly. I can do it the one list variable way if necessary.) If I can read the variable strings from the file equivalent of /dev/mtd1ro directly that would simplify my application. (Not here, but in another thread, I'm interested in how to get systemd or equivalent to auto-run my application after boot.)

Regards

Steve

1. I already suggested indirectly to hold your environment variables in mtd1 above as uboot environment variables are stored in that partition of the spi flash:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00010000 "qspi-fsbl-uboot"
mtd1: 00020000 00010000 "qspi-uboot-env"
mtd2: 000e0000 00010000 "qspi-nvmfs"
mtd3: 01e00000 00010000 "qspi-linux"

# cd /mnt/jffs2/
# echo "test_val" > test
# cat test
test_val
# reboot

Welcome to:

 __   __  ____
|  \ /  |(___ \
|   v   |  __) ) _  __
| |\_/| | / __/ | |/ /
| |   | || |___ |   <
|_|   |_||_____)|_|\_\
01001101 00110010 01101011

v0.33-dirty
https://wiki.analog.com/university/tools/m2k
# cat /mnt/jffs2/test
test_val
#

Thank you dumitruCeclan . I apologize but I missed this context from the previous replies.

This works perfectly (I must've had a mistake prior, I can indeed open /dev/mtd1ro for reading.)

This can be closed. I hope others find it useful.

Regards 

Steve