January-16th-2020, 10:33 AM
(This post was last modified: January-16th-2020, 10:37 AM by Armin@netPI.)
Hello Irina,
before you start to develop a NPIX extender you need to understand the principle of the standard Raspberry Pi system and the plug-on modules called HAT. https://www.raspberrypi.org/blog/introdu...y-pi-hats/
What HAT is for standard Raspberry Pi is NPIX for netPI to extend the basic hardware with extended hardware. So on a standard Pi you apply a HAT on the 40 pin header and with netPI you shift in NPIX modules. HAT 40 pin header is the same as netPI's internal mPCIe connector ... it is just a different form factor.
So since we use the same mechanism with netPI as known from standard PI also the software behaviour is the same. Since HAT/NPIX may provide any connectivity like SPI, I2C, UART etc. the module "tells" the Linux system about its supported interfaces. This is done with the ID EEPROM that is located on the HAT/NPIX at I2C0 bus. If there is no EEPROM Linux cannot detect the possibilities of the module and does not load the respective driver.
And this is your problem. Linux during the startup phase reads out the ID EEPROM ... which in your case is not there ... and will not load the SPI driver. This is why you do not see the SPI devices mappable at all.
Here is the spec how to generate an ID EEPROM binary file in general for HAT + the tools: https://github.com/raspberrypi/hats
We have for example made the NPIX-CAN module that uses the SPI1.0 interface provided by the NPIX slot to connect to the MCP2515 CAN chip. I could provide you the binary file for the ID EEPROM ... so that you in turn can burn your ID EEPROM to get fast to the missing SPI 1.0 device in Linux and finally in your container.
For burning ID EEPROMS you need to use EEPROM writer for series production or for tests you can also use netPI with a different SD card loaded with Raspbian OS.
Thx
Armin
before you start to develop a NPIX extender you need to understand the principle of the standard Raspberry Pi system and the plug-on modules called HAT. https://www.raspberrypi.org/blog/introdu...y-pi-hats/
What HAT is for standard Raspberry Pi is NPIX for netPI to extend the basic hardware with extended hardware. So on a standard Pi you apply a HAT on the 40 pin header and with netPI you shift in NPIX modules. HAT 40 pin header is the same as netPI's internal mPCIe connector ... it is just a different form factor.
So since we use the same mechanism with netPI as known from standard PI also the software behaviour is the same. Since HAT/NPIX may provide any connectivity like SPI, I2C, UART etc. the module "tells" the Linux system about its supported interfaces. This is done with the ID EEPROM that is located on the HAT/NPIX at I2C0 bus. If there is no EEPROM Linux cannot detect the possibilities of the module and does not load the respective driver.
And this is your problem. Linux during the startup phase reads out the ID EEPROM ... which in your case is not there ... and will not load the SPI driver. This is why you do not see the SPI devices mappable at all.
Here is the spec how to generate an ID EEPROM binary file in general for HAT + the tools: https://github.com/raspberrypi/hats
We have for example made the NPIX-CAN module that uses the SPI1.0 interface provided by the NPIX slot to connect to the MCP2515 CAN chip. I could provide you the binary file for the ID EEPROM ... so that you in turn can burn your ID EEPROM to get fast to the missing SPI 1.0 device in Linux and finally in your container.
For burning ID EEPROMS you need to use EEPROM writer for series production or for tests you can also use netPI with a different SD card loaded with Raspbian OS.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
