January-16th-2020, 10:04 AM
Hi,
My name is Ira and I work at CoreTigo.
Currently working with the netPI I would like to test SPI functionality.
Using the extender it seems I can only access /dev/spidev1.0 and /dev/spidev1.1, but I can't add these interfaces when creating a new container.
Please advise on how can I access SPI interface using the extender.
Thanks,
Ira Grinberg.
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
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
January-16th-2020, 11:15 AM
Hi Armin,
Thank you for the fast reply.
Just to make sure we're on the same page, the extender (breakout) I'm referring to is attached as a file.
Also, I have an issue exposing /dev/ttyS0 using the container, which is usually accessible when using a regular Pi.
January-16th-2020, 12:14 PM
Hi there.
I do not see an attachment in your last post.
When I speak about the "NPIX module technique" I mean modules that fit in breakout at the bottom of a netPI device where module such das the CAN module
https://www.hilscher.com/products/produc...edge/3004/ can be shifted in.
The description of those modules you find at
https://www.netiot.com/netpi/industrial-raspberry-pi-3/ in the download section.
So do we speak about the same interface?
With the /dev/ttyS0 I disagree on a standard raspberry pi. All interfaces on a standard Pi can only be activated using the "raspi-config" tool. By default neither I2C, nor SPI, nor UART nor SSH is actviated. If you see /dev/ttyS0 active then you must have activated it with the raspi-config before.
Look here are the devices on my Raspberry Pi 3B:
Code:
autofs gpiochip1 loop7 ppp ram6 tty1 tty23 tty37 tty50 tty7 vcs3 vcsu3
block gpiochip2 loop-control ptmx ram7 tty10 tty24 tty38 tty51 tty8 vcs4 vcsu4
btrfs-control gpiomem mapper pts ram8 tty11 tty25 tty39 tty52 tty9 vcs5 vcsu5
bus hwrng media0 ram0 ram9 tty12 tty26 tty4 tty53 ttyAMA0 vcs6 vcsu6
cachefiles initctl mem ram1 random tty13 tty27 tty40 tty54 ttyprintk vcsa vga_arbiter
char input memory_bandwidth ram10 raw tty14 tty28 tty41 tty55 uhid vcsa1 vhci
console kmsg mmcblk0 ram11 rfkill tty15 tty29 tty42 tty56 uinput vcsa2 video10
cpu_dma_latency log mmcblk0p1 ram12 serial1 tty16 tty3 tty43 tty57 urandom vcsa3 video11
cuse loop0 mmcblk0p2 ram13 shm tty17 tty30 tty44 tty58 v4l vcsa4 video12
disk loop1 mqueue ram14 snd tty18 tty31 tty45 tty59 vchiq vcsa5 watchdog
fb0 loop2 net ram15 stderr tty19 tty32 tty46 tty6 vcio vcsa6 watchdog0
fd loop3 network_latency ram2 stdin tty2 tty33 tty47 tty60 vc-mem vcsm-cma zero
full loop4 network_throughput ram3 stdout tty20 tty34 tty48 tty61 vcs vcsu
fuse loop5 null ram4 tty tty21 tty35 tty49 tty62 vcs1 vcsu1
gpiochip0 loop6 port ram5 tty0 tty22 tty36 tty5 tty63 vcs2 vcsu2
there isn't any /dev/ttyS0 active.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
January-16th-2020, 12:27 PM
(This post was last modified: January-16th-2020, 12:52 PM by Armin@netPI.)
One remark: If you would use netPI during your first tests with the original Raspbian OS image (with antoher SD card you insert into netPI's SD card slot) instead of the secured netPI image then you have much more options to enable SPI, TTY and so on using netx to "raspi-config" tool also the config.txt file as described here
https://www.raspberrypi.org/documentatio...onfig-txt/
For example to enable the /ttyS0 interface you have to add the
entry in the confix.txt file.
The config.txt file serve to statically configure the Linux device tree ... while the ID EEPROM is made for flexible and dynamic use without the need to make edits in config.txt by any user. It is adjusting the Linux hardware device tree automatically.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
January-16th-2020, 01:19 PM
(This post was last modified: January-16th-2020, 01:32 PM by Armin@netPI.)
You are doing well.
The evalboard you are referencing "opens" you the NPIX slot's mPCIe socket signals to pin headers and of course you can use it for your tests.
But nevertheless you should not forget how the overall Raspberry chip/Linux OS behaviour is working in principle with this slot in accordance to the HAT specification.
I agree that netPI does not have an SD card slot you can access to immediately. This is because of security reasons that noone can remove the SD card during runtime.
You have to unscrew the 4 housing retaining screws. By removing the housing upper part you get access to the SD card slot.
Please keep the existing SD card safe and use your own SD card with Raspbian OS. And yes this netPI hardware uses 100% the same schematics as the RPi 3B. So any image/SD card made for original Pi will run in this device 1:1.
Thx
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
January-16th-2020, 02:51 PM
Hi Armin,
I opened the box and unfortunately there is no way to remove the existing SD card (it's glued completely in this version of the product).
Is there any way to enable SPI and UART in the constraints of the secured netPI image?
Thanks,
Irina.
January-16th-2020, 03:15 PM
Well Irina,
you have an "old" device. Since January 2019 the SD card is no longer sealed on netPI and open to everybody.
In the first stages of the netPI product year 2017/2018 we had the idea to make it as secure as possible which also covers also the physical removement of the SD card.
You see a barcode label on your product and in its lower right corner the value "1" which is #REVISION 1 of the hardware. You need a #REVISION 2 of hardware.
With #REV1 there is really no chance to make any edits via Linux, config.txt or any other method to enable SPI or UART manually other than ID EEPROM hooked to the extension board. This is the maximum secured Pi device you every can think of. The netPI image is a Linux secure-boot alike signed image that is also bound to the serial number of the Raspberry Pi CPU ... it cannot be changed or opened in terms of software.
You need #REV2.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)