Fix #1342, rename "Zero" union member field

[jphickey]

Describe the contribution
This field is just some generic bits. It is used when the CDS is cleared by zero-filling this data block and writing it to CDS repeatedly in a loop.

Renaming it to "GenericDataBlock" should be clearer as to its intent.

Fixes #1342

Testing performed
Build and sanity check CFE
Confirm all unit tests pass

Expected behavior changes
None

System(s) tested on
Ubuntu 20.04

Additional context
Just renames internal field to avoid confusion about the name Zero.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[skliper]

I still don't really follow as to why a clear wouldn't make more sense implemented by the PSP, or why it's sized as it is from the cFE level. Seems like the technique used to clear should be based on the hardware properties (page size, etc). Maybe we should convert this to a future work issue to do a more in-depth refactor? Clearing in arbitrary uint32[4] chunks just doesn't make sense to me whatever the variable is called.

[jphickey]

Yes, I completely agree that if the CDS is implemented by e.g. some flash memory sectors or something like that, writing zeros is a pretty terrible way to clear it. In fact the current design/assumptions of CDS might exclude certain classes of nonvolatile memory tech from being used to implement it.

The objective of this PR was not to improve the design, just to clarify why that union field was named "zero". This union field is just so ES can fill it with zeros, and this way it can at least write 16 bytes of zeros at a time instead of just 4 or 1. This is the same way that CDS has always been cleared in previous versions of CFE.

I totally agree that the CDS access interface needs improvement, but it shouldn't be done in a bugfix context, someone should really take a look at the various types of physical memory devices that might be used to implement it, and design a proper abstraction API to better support them. At a minimum, it likely needs a mechanism to align the CDS blocks to match the erase blocks of the underlying mem tech. Right now it seems to assume random read/write access is possible, which is not always the case.

[astrogeco]

CCB:2021-04-21 CONVERT FUTURE WORK

• Is it worth fixing this because it is "so broken:?
• This highlights that we need to move this to PSP
• One reason to keep this is because it forces developers to think about how the memory is architected

[skliper]

See #1404