Verifying key functionality with small focused test programs, part 3

VERIFYING THAT WE CAN SHUTDOWN LINUX AFTER POWER FAILS

In operation, the programs running under Linux spin off a process that watches the HPS_USER_KEY signal, which is my power good/fail indication. When that signal goes to logic high we have lost AC power and are running off our battery. This process will issue a command to a shell (shutdown -h now) which commands Linux to do an orderly shutdown. 

I may add a bit more delay to allow the user interface to command an unload of any data that was written or updated from the IBM 1130, which would also protect the integrity of the virtual 2315 cartridges, but initially I am only ensuring that the SD Card is not in a corrupt state. This implies that the cartridge image being used on the 1130 would be the contents of the file when we first selected it for operation with any changes lost if there is an abrupt power down. 

If the operator has switched off the disk drive first, the  signal will tell us to request an unload to update our file on the SD Card so that nothing is lost; this is an issue only if power unexpectedly drops without the operator having first spun down the disk drive. 

My test program is very simply, it establishes accessibility to the HPS_USER_KEY signal in a process we spun off. We start without touching the pushbutton to simulate good power state. The test code indicates that it sees this. When we press the pushbutton, the code should warn us that power has dropped and then issue the shutdown. We know this works if we see Linux shutdown if and only if we push the pushbutton. 

Indeed, the system immediately shuts down when the button is pressed. In the actual implementation there will be the short delay to let everything wrap up, but this is tested and the method proven to work. 

SMALL BUG IN COMMAND PROCESSING BEING INVESTIGATED

My communications over the bridge from the program executing under Linux in the Hard Processor System side to the logic in the Field Programmable Gate Array side seems to work well, with status being read and commands executed with only one exception. The command that should turn the drive_ram signal back off is not being processed. I can start an unload and turn on drive_ram properly.

I changed that logic to return a special status that would at least provide that my logic did get the command, but I only get the normal 0000 status back. Something is awry, more digging will be done.