piscsi should not try to initialize bus on aarch64 platform (and others without board)

[uweseimet]

develop branch as of 2023-01-05.

On all platforms without a PiSCSI board piscsi should run in client interface mode, just like it currently does on Intel PCs:

Note: No PiSCSI hardware support, only client interface calls are supported

On aarch64 platforms piscsi terminates with an error instead:

[2023-01-05 09:51:54.773] [error] Failed to open /proc/device-tree/model. Are you running as root?
[2023-01-05 09:51:54.773] [error] Exception while trying to initialize GPIO bus. Are you running as root?
Error: Can't initialize bus
>name -a
Linux ora1 5.15.0-1025-oracle #31-Ubuntu SMP Fri Nov 25 17:03:15 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

[akuker]

Do you have any proposals for how to differentiate between aarch64 on a Mac M1 vs 64-Bit raspberry pi?

[uweseimet]

The presence of the board should be detected dynamically (e.g by the GPIOBus factory), not based on preprocessor constants. A Pi without a board is not different from a non-Pi platform, i.e. relying on the preprocessor would not help in this case.

[akuker]

As part of this change, the logic should probably be updated to use something other than the model name from the device tree. User "Spike" on discord reported that his Raspberry Pi 4 reported this:

This article describes a reliable way to determine which version of Pi is being used: https://elinux.org/RPi_HardwareHistory#Board_Revision_History

I think we need to add a command line parameter to override this detection as well. It looks like the revision numbers change without new model numbers.

This would also allow for the "virtual" GPIO bus to be specified, even on a raspberry pi or banana pi.

[uweseimet]

1179 addresses this for the aarch64 platform based on the aarch64 preprocessor definition. This way piscsi now also runs on an aarch64 VM in the Oracle cloud (client interface support only), just like on an Intel PC, which is useful for testing.

[uweseimet]

In the final bookworm version for the Pi the preprocesser flags appear to have changed. The change mentioned in the previous comment had to be reverted.

[rdmark]

For the record, this is another example of making an assumption based on architecture:

https://github.com/PiSCSI/piscsi/blob/2de0aa090a95bdad0523cd3e9b90d757dc2367b7/cpp/devices/scsi_daynaport.cpp#L60

Not as critical as the bus initialization of course, but I just wanted to mention it.

[uweseimet]

@rdmark Yes, one would have to grep for 'x86' and update/verify all occurrences.

[uweseimet]

Fixed as port of https://github.com/PiSCSI/piscsi/issues/1295.

>uname -a
Linux ora1 5.15.0-1046-oracle #52-Ubuntu SMP Mon Oct 16 09:55:50 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
>./bin/fullspec/piscsi
SCSI Target Emulator PiSCSI (Backend Service)
Version 23.10 --DEVELOPMENT BUILD--  (Nov  5 2023 16:50:05)
Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Copyright (C) 2020-2023 Contributors to the PiSCSI project
Connection type: FULLSPEC
[2023-11-05 17:08:23.387] [info] Set log level to 'info'
[2023-11-05 17:08:23.387] [info] Detected unknown platform
[2023-11-05 17:08:23.387] [info] Cleared reserved ID(s)
[2023-11-05 17:08:23.387] [info] No devices currently attached.
No devices currently attached.
Note: No PiSCSI hardware support, only client interface calls are supported