Fix #486, Update location of simulated EEPROM file path

[dmolock-NASA]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution

Fixes #486 by updating the location of the simulated EEPROM.DAT file to always be created/opened based on PSP_CONFIG_SIMULATED_EEPROM_FILE_PATH parameter.

Testing performed
Steps taken to test the contribution:

1. Linux Build steps
   • Configure PSP_CONFIG_SIMULATED_EEPROM_FILE_PATH to ./cf
   • make native_std.distclean
   • make native_std.prep
   • make native_std.install
   • make native_std.runtest
2. QNX Build steps
   • Configure PSP_CONFIG_SIMULATED_EEPROM_FILE_PATH to /temp/cfs/cpu1/cf
   • make aarch64le_qnx_gnu.distclean
   • make aarch64le_qnx_gnu.prep
   • make aarch64le_qnx_gnu.install
3. Linux Execution steps
   • cd build-native_std/exe/cpu1/
   • ./core-cpu1
   • Verify cFS boots and simulated EEPROM.DAT file is located in CF directory.
   • ls build-native_std/exe/cpu1/cf
4. QNX Execution steps
   • Build QNX IFS Image including cFS
   • Boot QNX IFS Image on Raspberry Pi 4 via U-boot and TFTP
   • cd /temp/cfs/cpu1/
   • ./core-cpu1
   • Verify cFS boots and simulated EEPROM.DAT file is located in CF directory.
   • ls /temp/cfs/cpu1/cf/

Expected behavior changes

The cFS applications operates as normal but now the simulated EEPROM.DAT file is located in directory specified by PSP_CONFIG_SIMULATED_EEPROM_FILE_PATH parameter.

System(s) tested on

• Hardware: PC/VM, Raspberry Pi 4
• OS: RHEL 9, QNX 8.x

Additional context

N/A

Third party code

N/A

Contributor Info - All information REQUIRED for consideration of pull request

Dwaine Molock, NASA/GSFC, Code 534

[jphickey]

Can we add some commentary about why this change is needed? This file is just for testing (a real target would presumably have a real eeprom) and its not clear to me in this PR or in the original ticket what was wrong that prompted this change

[dmolock-NASA]

Can we add some commentary about why this change is needed? This file is just for testing (a real target would presumably have a real eeprom) and its not clear to me in this PR or in the original ticket what was wrong that prompted this change

@jphickey I noticed this issue on QNX and it depends on how/where the cFS processes are started. On QNX the cFS process was started from the root directory which doesn't have permissions to write/create files. This also happens when cFS is started by another process and cFS doesn't have write permissions for the launching directory. This change will ensure that the EEPROM.DAT file is always located in the CF directory which the cFS process should have full read/write access.

[jphickey]

Can we add some commentary about why this change is needed? This file is just for testing (a real target would presumably have a real eeprom) and its not clear to me in this PR or in the original ticket what was wrong that prompted this change

@jphickey I noticed this issue on QNX and it depends on how/where the cFS processes are started. On QNX the cFS process was started from the root directory which doesn't have permissions to write/create files. This also happens when cFS is started by another process and cFS doesn't have write permissions for the launching directory. This change will ensure that the EEPROM.DAT file is always located in the CF directory which the cFS process should have full read/write access.

I'm not so sure about that actually -- there are some deployments where /cf is also mounted read-only. What if we simply gave the user more control over where the file is created? Such as making a CONFIG option with the full pathname to the file?

[dmolock-NASA]

Can we add some commentary about why this change is needed? This file is just for testing (a real target would presumably have a real eeprom) and its not clear to me in this PR or in the original ticket what was wrong that prompted this change

@jphickey I noticed this issue on QNX and it depends on how/where the cFS processes are started. On QNX the cFS process was started from the root directory which doesn't have permissions to write/create files. This also happens when cFS is started by another process and cFS doesn't have write permissions for the launching directory. This change will ensure that the EEPROM.DAT file is always located in the CF directory which the cFS process should have full read/write access.

I'm not so sure about that actually -- there are some deployments where /cf is also mounted read-only. What if we simply gave the user more control over where the file is created? Such as making a CONFIG option with the full pathname to the file?

@jphickey I updated simulated EEPROM to use a new PSP CONFIG parameter for file path.

[jphickey]

I like this solution