Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update smi_stream_dev.c #176

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

unixpunk
Copy link
Contributor

This fixes building on DragonOS_Pi64 - not sure if it breaks other OSes or not, though.

/home/ubuntu/cariboulite/driver/build/smi_stream_dev.c:1319:28: error: too many arguments to function ‘class_create’
1319 | smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);

This fixes building on DragonOS_Pi64 - not sure if it breaks other OSes or not, though.

/home/ubuntu/cariboulite/driver/build/smi_stream_dev.c:1319:28: error: too many arguments to function ‘class_create’
 1319 |         smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
@alphafox02
Copy link

To confirm, this resolved the issue building CaribouLite on the latest DragonOS Pi64 (22.04 Ubuntu) after it switched to the 6.5 kernel for Pi5 support. I haven’t tested running the hat on a pi5 but it did run fine on the Pi4. I’ll add to DragonOS when I get a chance..

@unixpunk
Copy link
Contributor Author

i had run through this on my pi4, then i swapped the hat and sd card to the pi5 and it all worked just the same.

@unixpunk
Copy link
Contributor Author

hm but now im having an issue doing it from scratch on the pi 5, i can't get /dev/gpiomem to exist, there are only 0-4 variants, unlike my pi 4. will investigate/compare things later to see what's going on.

@alphafox02
Copy link

That’s strange so doing it from scratch on Pi4 is okay, transferring sd to pi5 is okay, but then you can’t do it from scratch? I swear in my case I did it from scratch on Pi5 but moved sd to the 4. I’ll do it all again asap.

@unixpunk
Copy link
Contributor Author

@alphafox02 so it looks like the gpiomem interface was changed and this will require a change above my head here to get it working. i found someone saying that the 40-pin header was part of /dev/gpiomem4, but creating a symlink from gpiomem to gpiomem4 and running SoapySDRUtil caused the system to freeze up instantly. that's the only quick guess i had on this. pi 5 support may not be here yet, but at least you can build with the new kernel on a pi 4.

@@ -1316,7 +1316,7 @@ static int smi_stream_dev_probe(struct platform_device *pdev)
}

// Create sysfs entries with "smi-stream-dev"
smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
smi_stream_class = class_create(DEVICE_NAME);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't compile. macro class_create requires two parameters

./cariboulite/driver/build/smi_stream_dev.c:1319:45: error: macro "class_create" requires 2 arguments, but only 1 given
 1319 |  smi_stream_class = class_create(DEVICE_NAME);
      |                                             ^
In file included from ./include/linux/platform_device.h:13,
                 ./cariboulite/driver/build/smi_stream_dev.c:44:
./include/linux/device.h:778: note: macro "class_create" defined here
  778 | #define class_create(owner, name)  \
      | 
./cariboulite/driver/build/smi_stream_dev.c:1319:21: error: ‘class_create’ undeclared (first use in this function); did you mean ‘vfs_create’?
 1319 |  smi_stream_class = class_create(DEVICE_NAME);

Copy link

@great9 great9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

macro class_create requires two params

@alphafox02
Copy link

Did you check out the patch-1 branch?

@unixpunk
Copy link
Contributor Author

all i know is it doesn't compile for me on ubuntu/dragonos unless i edit the file and remove "THIS_MODULE, ". Not sure if you're using latest 6.5 kernel yet or what you're working on there, but my experience is the opposite of yours...

@ImDroided
Copy link

ImDroided commented Jan 28, 2024

I can confirm that I was able to build with this mod on a Pi 5 with Ubuntu/DragonOS but get the same GPIOMEM error. Would not compile without.

@geerlingguy
Copy link

geerlingguy commented Jan 16, 2025

On a Pi 4 with the latest Bookworm (Pi OS 12):

$ uname -a
Linux pi4-sdr 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

When compiling the driver I get an error relating to the same function in this PR:

/home/pi/Downloads/cariboulite/driver/build/smi_stream_dev.c: In function ‘smi_stream_dev_probe’:
/usr/src/linux-headers-6.6.51+rpt-common-rpi/include/linux/export.h:29:22: error: passing argument 1 of ‘class_create’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   29 | #define THIS_MODULE (&__this_module)
      |                     ~^~~~~~~~~~~~~~~
      |                      |
      |                      struct module *
/home/pi/Downloads/cariboulite/driver/build/smi_stream_dev.c:1053:37: note: in expansion of macro ‘THIS_MODULE’
 1053 |     smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
      |                                     ^~~~~~~~~~~
In file included from /usr/src/linux-headers-6.6.51+rpt-common-rpi/include/linux/device.h:31,
                 from /usr/src/linux-headers-6.6.51+rpt-common-rpi/include/linux/platform_device.h:13,
                 from /home/pi/Downloads/cariboulite/driver/build/smi_stream_dev.c:51:
/usr/src/linux-headers-6.6.51+rpt-common-rpi/include/linux/device/class.h:230:54: note: expected ‘const char *’ but argument is of type ‘struct module *’
  230 | struct class * __must_check class_create(const char *name);
      |                                          ~~~~~~~~~~~~^~~~
/home/pi/Downloads/cariboulite/driver/build/smi_stream_dev.c:1053:24: error: too many arguments to function ‘class_create’
 1053 |     smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
      |                        ^~~~~~~~~~~~
...
make[5]: *** [/usr/src/linux-headers-6.6.51+rpt-common-rpi/scripts/Makefile.build:248: /home/pi/Downloads/cariboulite/driver/build/smi_stream_dev.o] Error 1
make[4]: *** [/usr/src/linux-headers-6.6.51+rpt-common-rpi/Makefile:1946: /home/pi/Downloads/cariboulite/driver/build] Error 2
make[3]: *** [/usr/src/linux-headers-6.6.51+rpt-common-rpi/Makefile:246: __sub-make] Error 2
make[2]: *** [CMakeFiles/smi_stream_dev.dir/build.make:79: smi_stream_dev] Error 2
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/smi_stream_dev.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
binary file doesn't exist: /home/pi/Downloads/cariboulite/driver/build/smi_stream_dev.ko

Applying the patch with curl -L https://github.com/cariboulabs/cariboulite/pull/176.patch | git apply -v I get:

Checking patch driver/smi_stream_dev.c...
error: while searching for:
	}

	// Create sysfs entries with "smi-stream-dev"
	smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
	ptr_err = smi_stream_class;
	if (IS_ERR(ptr_err))
	{

error: patch failed: driver/smi_stream_dev.c:1316
error: driver/smi_stream_dev.c: patch does not apply

So I applied the change manually, and here is my diff:

pi@pi4-sdr:~/Downloads/cariboulite $ git diff driver/smi_stream_dev.c
diff --git a/driver/smi_stream_dev.c b/driver/smi_stream_dev.c
index e0d6618..c7f3fba 100644
--- a/driver/smi_stream_dev.c
+++ b/driver/smi_stream_dev.c
@@ -1050,7 +1050,7 @@ static int smi_stream_dev_probe(struct platform_device *pdev)
     }
 
     // Create sysfs entries with "smi-stream-dev"
-    smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
+    smi_stream_class = class_create(DEVICE_NAME);
     ptr_err = smi_stream_class;
     if (IS_ERR(ptr_err))
     {

After re-running install.sh, it compiles now, but when it's installing the driver I see some errors like:

01-16 09:23:53.090  7491  7491 E CARIBOU_SMI caribou_smi_init@caribou_smi.c:539 couldn't open smi driver file '/dev/smi' (Permission denied)
01-16 09:23:53.090  7491  7491 E CARIBOULITE Setup cariboulite_init_submodules@cariboulite_setup.c:288 Error setting up smi submodule
01-16 09:23:53.090  7491  7491 E IO_UTILS_SPI io_utils_spi_remove_chip@io_utils_spi.c:487 the device is already empty
01-16 09:23:53.091  7491  7491 I CARIBOU_PROG caribou_prog_release@caribou_prog.c:122 device release completed
01-16 09:23:53.091  7491  7491 E FPGA caribou_fpga_close@caribou_fpga.c:247 caribou_fpga_close: dev not initialized
[ERROR] cariboulite_init_driver() failed
01-16 09:23:53.095  7491  7491 E FPGA caribou_fpga_close@caribou_fpga.c:247 caribou_fpga_close: dev not initialized
01-16 09:23:53.095  7491  7491 E CARIBOULITE Setup cariboulite_release_submodules@cariboulite_setup.c:465 FPGA communication release failed (-1)
01-16 09:23:53.095  7491  7491 E IO_UTILS_SPI io_utils_spi_close@io_utils_spi.c:340 closing uninitialized device

After a reboot, I launched SoapySDRServer (sudo systemctl start SoapySDRServer.service), and was able to connect to the H1F and S1G bands from GQRX on my Mac remotely.

@geerlingguy
Copy link

See also: myriadrf/xtrx_linux_pcie_drv@d218d3e

After installing CaribouLite's drivers, I'm getting an error for Setting up xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.2) every time I run apt upgrade/install now.

@alphafox02
Copy link

Jeff with some additional steps you should not have to use sudo to launch Soapy. When I get back to s computer I’ll review but check up under the ticket for how to get going with caribou and DragonOS Pi64.

@geerlingguy
Copy link

@alphafox02 - I wanted to be able to get everything running on a bare Pi OS install—my idea is to have a very lightweight/simple setup where it's running Pi OS Lite, with CaribouLite served over SoapySDR, at least for now.

DragonOS is a fairly heavyweight OS image that requires additional trust / lifecycle management, which is fine for many purposes/uses of course!

Regarding not using sudo... if I want to have the service run on system boot (sudo systemctl enable SoapySDRServer.service), I believe sudo would be a requirement regardless.

@alphafox02
Copy link

oh yeah, I’m in agreement with you. I was just saying that you could cherry pick some of the additional steps that I detailed in there that may or may not be of help to you. But yeah, starting the service on boot you need Sudo or potentially the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants