Intermediate merge of Banana Pi updates

[akuker]

This is an interim merge of the Banana Pi updates to make things a little easier later. Some notes on the current state of things:

• A bunch of tests added for raspberry pi gpio functionality... more to come
• Raspberry Pi works for RaSCSI (and probably scsidump, but I haven't tried yet)
• A "virtual" gpio bus should be created when running on x86. Some of the gpiobus_raspberry.cpp functionality was re-enabled on x86 so that it can be tested. When running the rascsi service on x86, it should create a "virtual" gpio bus.
• scsimon doesn't work
• banana pi functionality is incomplete
• longer term: the virtual gpio bus will create a shared memory point. In theory, we should be able to have rascsi and scsidump run together on the same host (to test each other)

TODOs (before PR):

• Fix scsimon FOR RASPBERRY PI ONLY (working on BPi is going to take a lot more work)
• Double-check formatting
• Double-check sonarcloud issues
• Do more testing on Raspberry Pi
• Capture performance metrics
• scsiloop doesn't properly handle the SEL interrupt on Banana Pi
• Add manpage for scsiloop

Defer until next PR:

• Finish BPi functionality for RaSCSI
• Test out scsidump on bpi

Defer to new issues to deal with later:

• Make scsimon work with bpi. (this is going to take significant updates, since the gpio registers do not fit in a single variable on bpi)
• Implement shared memory interface for the virtual gpiobus

[uweseimet]

@akuker Not that many comments from my side, BUT:

• Please at least fix those SonarQube issues that are trivial, e.g. missing/wrong override/final declarations or mismatching integer data types. There are already too many tickets where something was promised to be done soon, but has not been done for months.
• Before approving the PR I need to run some tests, but there are compile-time errors on my Linux PC because of warnings and hard errors, e.g.

./monitor/sm_vcd_report.cpp:132:14: warning: variable 'i' set but not used [-Wunused-but-set-variable]
    uint32_t i = 0;
./monitor/sm_core.cpp:245:23: error: invalid operands to binary expression ('uint32_t' (aka 'unsigned int') and 'shared_ptr<DataSample>')
            high_bits |= this_sample;

Mixing pointer operations with integer operations looks very wrong in general, but especially when you have 64 bit pointers but 32 bit integers.

As soon as everything is fixed (compiling) I will review again and then I will also run tests on the Pi.

The scsiloop tool is a good idea, by the way.

[uweseimet]

Pleas see my comments, not that many.

[akuker]

Pleas see my comments, not that many.

Thanks for taking a look! I think I addressed your comments.

[uweseimet]

@akuker I'm afraid there are more compile-time issues. The unit tests do not compile on Bullseye anymore (neither on the Raspberry nor on the Banana Pi):

In file included from ./test/gpiobus_raspberry_test.cpp:11:
./test/linux_os_stubs.h:13:10: fatal error: boost/filesystem.hpp: No such file or directory
   13 | #include <boost/filesystem.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~

I strongly recommend not to use the boost library. Not just because it is not installed by default (at least not on Bullseye), but also because a dependency on boost is introduced. This is similar to having a dependency on a particular compiler version. Depending on the OS version the installable boost version can vary, and code using boost may not compile.
Since there was never any need for boost I am quite sure there is also no need for using boost in the tests. When I look at linux_os_stubs.h on first sight I don't see anything that is not supported by the standard C++ filesystem library or other means.

// create a file with the specified data
void test_fs_create_file_in_temp_dir(string filename, vector<uint8_t> &data);

void test_fs_delete_file_in_temp_dir(string filename);
// Call this at the end of every test case to make sure things are cleaned up
void test_fs_cleanup_temp_files();

If it is about temporary files, the existing unit tests already make use of them without boost, see test_shared.cpp. The convenience methods in test_shared.cpp might be just what you need.

// This header file should ONLY be used in test procedures. It bypasses the
// linker wrap functionality. DO NOT USE THIS IN PRODUCTION CODE.

What is the "linker wrap functionality"? Only the new tests are affected by this?

One more issue: rascsi and rasdump on the Raspberry Pi (but not on the Banana Pi) now segfault when not being run as root. On the develop branch there is no crash.

[2022-12-01 12:49:15.652] [error] Error: Unable to open /dev/mem. Are you running as root?
Segmentation fault

When creating #1013 I wondered why the platform appears to be detected at runtime. I did not dig deeper into this, but that's how it is, isn't it? The platform can only be either a Raspberry or a Banana Pi, i.e. code that is not needed should not be compiled/executed. This will make the binaries leaner, reduces compilation times and avoids issues during runtime detection. The more platforms are supported (e.g. other Pi flavors) the more problems will arise otherwise and the binaries will grow because of unused code. #1013 is probably the most elegant solution, but even conditional compilation based on #ifdefs would help.
But maybe I am missing something and these problems do not exist?

On the Raspberry Pi I did not find any issues except the ones just mentioned. On the Banana Pi things were not looking so good. Booting from an image did not work at all. Launching the hard disk driver from floppy disk sometimes worked, but often the attached drives were not detected. Reading sectors sometimes worked, and sometimes failed, cause unknown. Sometimes the rascsi process was frozen and could not even be killed anymore and I had to reboot the Banana Pi. Sometimes I was able to launch an application, but this was very slow, which might have been caused by the excessive logging.
I placed a logfile on trace level on https://www.rascsi.de/banana.log.gz. It's too big to attach it. The log covers several unsuccessful boot attempts, then launching my driver software from floppy disk, then trying to send some SCSI commands and then trying to read sectors.

When testing with the Banana Pi, except for the Pi board my hardware and software setup was exactly the same as with the Raspberry Pi.

I guess you do it anyway, but in case you don't I suggest to test by connecting two RaSCSI boards. On one you can run rasdump, for instance, on the other rascsi. This will provide logs from both the initiator and target perspective.

[akuker]

@akuker I'm afraid there are more compile-time issues. The unit tests do not compile on Bullseye anymore (neither on the Raspberry nor on the Banana Pi):

In file included from ./test/gpiobus_raspberry_test.cpp:11:
./test/linux_os_stubs.h:13:10: fatal error: boost/filesystem.hpp: No such file or directory
   13 | #include <boost/filesystem.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~

I strongly recommend not to use the boost library. Not just because it is not installed by default (at least not on Bullseye), but also because a dependency on boost is introduced. This is similar to having a dependency on a particular compiler version. Depending on the OS version the installable boost version can vary, and code using boost may not compile. Since there was never any need for boost I am quite sure there is also no need for using boost in the tests. When I look at linux_os_stubs.h on first sight I don't see anything that is not supported by the standard C++ filesystem library or other means.

Agreed. I didn't realize that the std::filesystem functionality existed. I switched the code over to use this instead.

If it is about temporary files, the existing unit tests already make use of them without boost, see test_shared.cpp. The convenience methods in test_shared.cpp might be just what you need.

I moved my temp files to the test_shared.cpp files as well. I also updated the existing functions so that they put the process id in the file path.

// This header file should ONLY be used in test procedures. It bypasses the
// linker wrap functionality. DO NOT USE THIS IN PRODUCTION CODE.

What is the "linker wrap functionality"? Only the new tests are affected by this?

Linker wrap functionality allows you to command the linker to call a "__wrap" function instead of the real function. I've used this in several projects in the past for testing features that call lower level routines.

For now, I've used it to override fopen(). So, when the gpiobus_raspberry.cpp class calls fopen() to read the /proc file system, the __wrap() function will re-direct it to a test file. This is enabled using linker arguments about which function(s) you want to wrap. See TEST_WRAPS = -Wl,--wrap=fopen64 in the Makefile. Notice that the TEST_WRAPS option is only used for the test application.

One more issue: rascsi and rasdump on the Raspberry Pi (but not on the Banana Pi) now segfault when not being run as root. On the develop branch there is no crash.

[2022-12-01 12:49:15.652] [error] Error: Unable to open /dev/mem. Are you running as root?
Segmentation fault

Fixed.

When creating #1013 I wondered why the platform appears to be detected at runtime. I did not dig deeper into this, but that's how it is, isn't it? The platform can only be either a Raspberry or a Banana Pi, i.e. code that is not needed should not be compiled/executed. This will make the binaries leaner, reduces compilation times and avoids issues during runtime detection. The more platforms are supported (e.g. other Pi flavors) the more problems will arise otherwise and the binaries will grow because of unused code. #1013 is probably the most elegant solution, but even conditional compilation based on #ifdefs would help. But maybe I am missing something and these problems do not exist?

There is already a precedent where the rascsi service detects which Raspberry Pi its running on and adjusts its behavior accordingly. So, for now, I'd propose that we leave the detection in.

On the Raspberry Pi I did not find any issues except the ones just mentioned. On the Banana Pi things were not looking so good. Booting from an image did not work at all. Launching the hard disk driver from floppy disk sometimes worked, but often the attached drives were not detected. Reading sectors sometimes worked, and sometimes failed, cause unknown. Sometimes the rascsi process was frozen and could not even be killed anymore and I had to reboot the Banana Pi. Sometimes I was able to launch an application, but this was very slow, which might have been caused by the excessive logging. I placed a logfile on trace level on https://www.rascsi.de/banana.log.gz. It's too big to attach it. The log covers several unsuccessful boot attempts, then launching my driver software from floppy disk, then trying to send some SCSI commands and then trying to read sectors.

When testing with the Banana Pi, except for the Pi board my hardware and software setup was exactly the same as with the Raspberry Pi.

Thank you for testing it out. Your results align with what I was seeing. When the banana pi did work, it was incredibly slow. (but it rarely worked). Inquiry seemed to work semi-reliably. When trace logging was enabled, it would consistently lock up, so I'll need to reduce the amount of logging. Definitely more work to be done on the BPi side of things.

I guess you do it anyway, but in case you don't I suggest to test by connecting two RaSCSI boards. On one you can run rasdump, for instance, on the other rascsi. This will provide logs from both the initiator and target perspective.

I hadn't tried that before tonight. This is an awesome quick test to make sure things are working. I've been thinking about setting this up as a Self-hosted runner and have a couple dedicated Pi's just to do that test. But.... that's a "someday" task.

I think I have all of your concerns addressed. Thank you again for looking at this!

[uweseimet]

@akuker Thank you for addressing my comments. My main concern is that the Banana Pi code is not working, at least it is very instable. What are going to be the next steps?

[akuker]

@akuker Thank you for addressing my comments. My main concern is that the Banana Pi code is not working, at least it is very instable. What are going to be the next steps?

Agreed. The BPi functionality is unusable. My intention is that this PR should cover the larger "architectural" changes to support BPi. I'm assuming that any future updates will be much more localized and easier to merge.

By merging this in now, we can get started with the "re-branding" to PiSCSI in parallel to me finishing up the BPi functionality. This is still my highest priority task and I'm planning on getting it fixed asap.

Since the RPi functionality still works the same, the changes should not negatively affect any users. I understand/agree that it hurts our quality metrics for more untested code, but I'll be working on that as well.

[uweseimet]

@akuker I am going to approve the PR, because I understand your reasoning. Nevertheless, giving approval for code that does not work (even if it may not affect any existing functionlity) makes me feel uneasy.
I hope that the Banana Pi support is going to work soon, and that we do not end up with non-working code that nobody wants to remove ;-).

[uweseimet]

This is not directly related to this PR or RaSCSI, but I mention it here because it also deals with the Banana Pi, in a general way.
My first impression of this hardware platform is not a favorable one:

• Too many different models, with different features, very confusing. Looks as if they just want to produce as much hardware as possible, with any chip they can get at the time of release. I predict that one will end up soon with hardware that does not get any OS updates anymore.
• Poor user support, tools are missing. There is not even something like raspi-config.
• Lack of useful documentation. Whenever you are looking for something you end up with the required information for the Raspberry Pi, but not for any Banana Pi.

I don't know whether you ever tried, but I gave up trying to boot the Banana Pi with WLAN access only. There is hardly any information on it, and I had a hard time to get a working WLAN at all. Now its working (but I do not even know why) but the Pi only boots when it is connected to the LAN. Very inconvient when your computers are placed somewhere where only WLAN is available.
Maybe I should have spent even more time on this, but with the Raspberry Pi it essentially worked out of the box.