Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

Hi Brian,

Are you trying to use the device from user space with the spidev driver? If so, then you need to fix the device tree to use:

...
crospointsw@0 {
    compatible = "linux,spidev";
    reg = <000>;
    spi-max-frequency = <100000000>;
    enable-dma = <1>;
};

The device compatible you are using is for the host controller, which will confuse the device manager.

Also, the kernel might complain (give a warning message) about the SPIDEV being enabled directly, but that is OK and you can press on.

If you are using the altera QSYS SPI (fabric built) host core, then you'll need to make sure that spi-altera (CONFIG_SPI_ALTERA) driver is enabled in the kernel (and modprobed if it is built as a module driver).

For the chip level support, you need to make sure that whatever chip driver is enabled (e.g., CONFIG_SPI_SPIDEV for user level access).

-Mike

Thanks for the reply. I have updated the dts and I'm getting the following warnings:

Warning (reg_format): "reg" property in /soc/bus@0ff200000/spi@0x0060/device@0 has invalid length (4 bytes) (#address-cells 2, #size-cells 0)
Warning (reg_format): "reg" property in /soc/bus@0ff200000/spi@0x0040/amp1@0x0000 has invalid length (4 bytes) (#address-cells 2, #size-cells 0)
Warning (reg_format): "reg" property in /soc/bus@0ff200000/spi@0x0040/amp2@0x0001 has invalid length (4 bytes) (#address-cells 2, #size-cells 0)

I have uploaded my updated dts. If I remove the "reg" property the dts compiles without warnings but I get errors on boot up. Can I can access the altera spi master without the need for the slave nodes in the dts? If so do you have any examples?

Thanks,

Brian

I was able to comply the DTB using a tool chain from rocketboards and a spi device showed up under /dev/spidev. Writing to this device crashes Linux and gives me the following error:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 42 Comm: spi32766 Not tainted 3.16.0-gad2c40b #1
task: 9f72c900 ti: 9f730000 task.ti: 9f730000
PC is at 0x0
LR is at spi_bitbang_transfer_one+0x6c/0x268
pc : [<00000000>] lr : [<803724a4>] psr: 200f0013
sp : 9f731ea8 ip : 9f731ee8 fp : 9f731ee4
r10: 9f5b6554 r9 : 9efd9ebc r8 : 9f5b65e8
r7 : 807e5e78 r6 : 807bf590 r5 : 00000001 r4 : 9efd9eec
r3 : 00000000 r2 : 9f738c00 r1 : 9efd9eec r0 : 9f738c00
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 1ec4004a DAC: 00000015
Process spi32766 (pid: 42, stack limit = 0x9f730248)
Stack: (0x9f731ea8 to 0x9f732000)
1ea0: 80054b40 9f5b6400 ffffffff 9f738c00 9f691500 9f5b656c
1ec0: 9efd9ebc 9f5b6400 807e5e78 9f730028 9f5b6558 9f5b6554 9f731f24 9f731ee8
1ee0: 80370040 80372444 9f731f24 9f730000 9f730028 807ee638 00000001 9f730000
1f00: 9f730028 807ee638 00000001 9f730028 9f5b6558 9f5b6554 9f731f5c 9f731f28
1f20: 800469cc 8036fcf4 00000000 807ee638 80046954 9f7728c0 00000000 9f5b6554
1f40: 80046954 00000000 00000000 00000000 9f731fac 9f731f60 800467e0 80046960
1f60: 9f727290 00000000 8003c32c 9f5b6554 00000000 00000000 9f731f78 9f731f78
1f80: 00000000 00000000 9f731f88 9f731f88 9f7728c0 800466f8 00000000 00000000
1fa0: 00000000 9f731fb0 8000eab8 80046704 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<803724a4>] (spi_bitbang_transfer_one) from [<80370040>] (spi_pump_messages+0x358/0x4c8)
[<80370040>] (spi_pump_messages) from [<800469cc>] (kthread_worker_fn+0x78/0x19c)
[<800469cc>] (kthread_worker_fn) from [<800467e0>] (kthread+0xe8/0x100)
[<800467e0>] (kthread) from [<8000eab8>] (ret_from_fork+0x14/0x20)
Code: bad PC value
---[ end trace 4093233369f7bcfe ]---

I'm not sure why the tool chain from the critical link wiki will not comply the DTB properly. Any input into my error would be helpful.
Thanks,
Brian

Hi Brain,

Sorry for the delay. Looking at the warnings you're getting from the critical link toolchain you need to set the #address-cells to 1.

For example:

spi@0x0060 {                                                                                              
        compatible = "altr,spi-15.1", "altr,spi-1.0";                                             
        #address-cells = <0x1>;                                                                   
        #size-cells = <0x1>;                                                                      
        reg = <0x60 0x20>;                                                                        
        interrupts = <0x0 0x33 0x4>;                                                              
        num-chipselect = <0x1>;                                                                   
        status = "okay";                                                                          

        spidev@0x0 {                                                                              
            compatible = "spidev";                                                                
            #address-cells = <0x1>;                                                               
            #size-cells = <0x0>;                                                                  
            reg = <0x0>;                                                                          
            spi-max-frequency = <0x5f5e100>;                                                      
            enable-dma = <0x1>;                                                                   
        };                                                                                        
    }; 

I'm still getting the same error.

Hi Brian,

Sorry you'll also have to set #size-cells to 0x0 for the altera spi driver nodes, this info was taken from here: https://support.criticallink.com/gitweb/?p=linux-socfpga.git;a=blob;f=Documentation/devicetree/bindings/spi/spi-bus.txt;h=bbaa857dd68fd938612b8c137badc79faf2c9479;hb=refs/heads/socfpga-3.16.

I've tested you the dts you've sent with setting the #size-cells to 0x0 and the #address-cells to 1 with our toolchain and the dtb compiler returned no warnings or errors.

I've attached the changed dts

Dan

Thanks Dan,
This cleared up the errors on the DTB. I have tried to run the spi_test.c provided in a different post and still get the Unable to handle kernel NULL pointer dereference at virtual address 00000000. I'm not sure if it's a problem with the initialization of the spi. If I run the "transfer" function by it self it seem to work but I'm not seeing anything on the output. Any idea on what is wrong?

Brian

Brian,

Would you mind posting your updated spi_test.c? I'll see if I can recreate what you're seeing on my dev kit.

Thanks,

Dan

Dan,
Sorry for the delay. I've been out of town. Here is the c file that I was using to test the spi.
Thanks,
Brian

Brian,

I'm sorry for the delay. I've been able to recreate your issue and after looking around Altera's spi kernel driver it looks like its fairly bare on features. The NULL pointer is because the driver doesn't set the setup_transfer function for the bitbang device. I've tried to fix that but then ran into other issues. I've looked at the newer kernel versions from Altera and doesn't look like they have a fix for it.

For projects that require spi devices, instead of using a FPGA SPI core, I route one of the SPI masters from the HPS through the FPGA. I've used this design flow with spidevs on a few projects as well.

I've attached a project that has one of the SPI masters routed through the fabric and has it's MOSI looped back to it's MISO, just as an example on how to setup the project. For device tree, the spi devices are already in the top level socfpga.dtsi, they just need to be enabled in your dts.

Dan

Dan,

I got the Altera spi working on a DE0 nano board with the latest rt kernel form altera : rel_socfpga-4.1.33-ltsi-rt_17.05.01_pr. Is it possible to uses this kernel on the mitysom? If not the above solution is possible just will require a board re-spin and I'm trying to avoid that if I can.

Thanks,

Brian

Brian,

Trying to avoid a board spin is fully understandable. Yes, you should be able to use that kernel on the mitysom without too much pain. It looks like in the 4.1 kernel there were updates to spidev so that might be why that version works, where the 3.16 doesn't.

Dan

Dan,
I compiled the rel_socfpga-4.1.33-ltsi-rt_17.05.01_pr branch of the kernel form altera open source. I replaced the config file with the mitysom5csx_devkit_defconfig. I am having trouble with the DTS. When using the dts you provided me the kernel will not boot properly. I'm not sure what the problem is and not sure if i missed anything else along the way.

Thanks,

Brian

Brian,

Can you post your boot output?

I would recommend doing a diff of the DE0 nano board dts and that one. There could be some new additions or changes because of the differences in kernel versions.

Dan,
I have most of it working. The only problem I see now is the gpio not showing up. I'm getting the following errors:
altera_gpio ff200160.gpio: altr,interrupt-type value not set in device tree
/soc/bus@0ff200000/gpio@0160: registration failed with status -22
altera_gpio: probe of ff200160.gpio failed with error -22

I have posted my dtb and the full boot output

Thanks,

Brian

Brian,

I think this variable was changed to "altr,interrupt-trigger" in the newer kernel. Here is the documentation for the device-tree bindings of the Altera GPIO core: https://github.com/altera-opensource/linux-socfpga/blob/socfpga-4.1.33-ltsi-rt/Documentation/devicetree/bindings/gpio/gpio-altera.txt

Dan

Dan,

I just tried this and I'm getting the same error. I posted my updated dts.

Thanks,

Brian

Dan,

I just tried this and I'm getting the same error. I posted my updated dts.

Thanks,

Brian

Brian,

It looks like the Altera GPIO documentation is wrong, in the the driver it's looking for GPIO interrupts to be set with "altr,interrupt-type", not the documented "altr,interrupt-trigger". In the 3.16 kernel it was "altr,interrupt_type"

So in summary, for the 4.1 kernel you should be using "altr,interrupt-type"

Sorry for the confusion,

Dan

Dan,

Got it working. Thanks for all the help.

Brian

Brian,

Glad to hear it! You're welcome

Dan