gpio driver porting from an r-pi3b

[gene83]

I've an spi driver that runs on a pi3, writing (and reading from) 32 bit packets at nominally 42 megabaud, to a mesa 7i90HD cnc interfacing card, and reading back at 25 megabaud. But its full of code that checks to make sure its running on a pi. It also has an include file that describes the bcm2835 for all its offsets etc. I can excise the pi checks, but what else do I need to do to make it run on the rock64?  The spi port used is nominally the SPI1 address in the pi scheme of things.


Thanks & Cheers
gene83

[MarkHaysHarris777]

I can excise the pi checks, but what else do I need to do to make it run on the rock64?  

The most important thing you can do is to get the RPi.GPIO-PineA64 github package !

[gene83]

got it Mark, thank you. I might be back for clarification.

Never got away in fact. the setup.py didn't work And spit out pages of error/warnings. Hopefully what it did do is undoable. I'd post it, but its long and this software mucks up the formatting, and my ban on posting attachments hasn't expired.

Is this not available in the std "patch -p1 <patchfile" format so I can patch the 4.11.12-rt15 kernel src tree and rebuild?

Thanks Mark.

Cheers, gene83

[stacywebb]

got it Mark, thank you. I might be back for clarification.

Never got away in fact. the setup.py didn't work And spit out pages of error/warnings. Hopefully what it did do is undoable. I'd post it, but its long and this software mucks up the formatting, and my ban on posting attachments hasn't expired.

Is this not available in the std "patch -p1 <patchfile" format so I can patch the 4.11.12-rt15 kernel src tree and rebuild?

Thanks Mark.

Cheers, gene83

If setup.py didn't work, the following should fix the errors.

For python 2.x

Code:

sudo apt-get install python-dev

For python 3.x

Code:

sudo apt-get install python3-dev

[joseph]

gene83, if you're talking about porting hm2_rpspi.c to support the 7i90 you'll need to spend time with the technical reference manual, chapter 20, available here http://opensource.rock-chips.com/wiki_Main_Page - it's the RK3328 TRM link. The rpspi solution bitbangs the hardware directly and requires the standard "spidev" driver is unloaded.

The existing RPi3 hardware addresses and offsets will need to be updated to reflect the RK3328 layout.

Another option to consider is acquiring a 7i92 and connecting via wired ethernet, hm2_eth driver.

Is the 4.11.12-rt15 kernel build available?

All the best, Joe

[gene83]

>gene83, if you're talking about porting hm2_rpspi.c to support the 7i90 you'll need to spend time with the technical reference manual, chapter 20, available here >http://opensource.rock-chips.com/wiki_Main_Page - it's the RK3328 TRM link. The rpspi solution bitbangs the hardware directly and requires the standard "spidev" >driver is unloaded.

>The existing RPi3 hardware addresses and offsets will need to be updated to reflect the RK3328 layout.

That was assumed to be required. No biggie if I can get the headers. But I am under the impression that for a rock64, I need the RK3399 DATA?

>Another option to consider is acquiring a 7i92 and connecting via wired ethernet, hm2_eth driver.

>Is the 4.11.12-rt15 kernel build available?

>All the best, Joe

Thanks Joe. Nice to find someone who knows about this stuff. ;-)

That's because the spidev is terminally slow from what I've read. And using ethernet would tie up its only ethernet port, plus the latency in the much slower ethernet would make tuning the 7i92 a much bigger problem. The rpspi.ko driver can talk to the 7i90 at 41 megabaud, and read back at 25 megabaud on the pi. Doing it as I type in fact as I leave it running, with lcnc motion disabled which I've rigged to shut all motor power off.

And no, the rtai kernel I've built is 4.10.0-rc3. But its not been tested even for boot because I know zip about how to change kernels on what looks to be an efi boot system. Is there a make install command option to do more than just put the built stuffs in /boot? That's all I've done so far.

Or how is that done to a clone of a working ssd card? Made difficult by the fact that I've not found a piclone that will run on the rock64. ssd card reader/writers I have, but the working image needs constrained to valid data else something like dd fails because no two of these cards are the same size. It al blows up if the target card is 4k smaller than the source card, and the resultant image is not readable.

So the first thing I need is a piclone that runs on the rock64, so I can make the test boot on a different card.

I am extremely impressed with the rock64 speed, easily 10x the pi's speeds, and if I can get it all in one sock it would be a very welcome improvement.

A lot of questions, thanks for the link above. I'll pull all 3 TRM's to be sure I have the correct one. oh boy, 600 to 850 pages each. Obviously I'll only print the correct one. For a rock64/4G, which one is it?

Thanks Joe.

[gene83]

I can excise the pi checks, but what else do I need to do to make it run on the rock64?  

The most important thing you can do is to get the RPi.GPIO-PineA64 github package !

The driver I would be porting requires the native spi to be unloaded. Its part of LinuxCNC and bitbangs the pins directly, achieving 41 megabaud writes and 25 megabaud reads running on the pi, where a data packet is a 32 bit long word. Written in C, I doubt any python implementation can do half those speeds.
This package looks to be python based, but a 5 to 15 megabaud data rate would be essentially unusable because of the com lags.

I did pickup the 800 some page TRM, and have been told to consult chapter 20 by another poster more familiar with what I am attempting to do, but have a couple other irons in the fire, starting with a wife with COPD and the approaching event that implies.

Thank you Mark. When I can return to this, I'll likely have to further clarify what I need to do then.

Cheers, gene83

[joseph]

Hey Gene,

Sorry to hear about your wife's COPD. It's a hell of a challenge. I wish you both well.

Unless something changed on the Rock64, it uses the RK3328.

I am confused about your 7i92 speed concern. It's 100BaseT Ethernet and you can switch it so you avoid exclusive use of the Rock64's Ethernet port. I've used the 7i92 on x86 NUC-type solution.

For guidance on building Rock64 images I look to https://github.com/ayufan-rock64

Ever onward, Joe

[gene83]

Thanks Joe.

In re the rock64, the RK3328 seems to be the correct bit of smart sand. And I wasn't really concerned about the 7i92 as I expect it can have an ipv4 address assigned, and a smart switch used. What I would like to see happen is the rpspi.ko driver from linuxcnc ported to the rock64, as thats a much faster machine control interface. I have a pi writing 32 bit packets to a Mesa 7i90HD at 41 megabaud, and reading the 7i90HD's responses at 25 megabaud right now, But the pi's penchant for throwing away keyboard and mouse events absolutely kills any safety margin by leaving the machine jogging in which ever direction it was moving until it crashes into something, possibly breaking things.

The rock64 doesn't suffer from this design flaw, but its stock spi bus is the kernels version and that infamously very badly broken.
Nobody in media uses spi, so its not getting any TLC at all.

Heck, I've built 2 or 3 kernels, on the rock64, takes a bit over an hour. But I've found zero docs of how to make it boot a different kernel even if its been installed by the makefile. If I can make, install and boot one of the latest rt kernels, then I might take a swing at making this spi driver run on the rock64. It will take switching the header files out for the ones for the RK3328, AND the wholesale excising of a few paragraphs of code designed to keep it from running on anything but a pi-2 or pi-3.

But there's little use of working on the driver until I have a way worked out to make it run the realtime kernel.

Questions about that, which I've asked here over the last couple months, have simply been ignored, yet here is a tiny card that could put both the pi's and the best of the beagle bone blacks out to pasture for good.

Why the secrecy? Do they not want folks to develop anything but movie players on it?

Thanks Joe, and take care of you and yours.

[xalius]

Morning. The SPI devices seem to work OK for me.  A while back I enabled one of them to test the on-board 16MB SPI Flash for booting which worked fine after enabling the SPI node in the devicetree and adding a node for the Flash. I had to rebuild the kernel once with the necessary drivers which I did directly on the Rock64... as for installing, I just copied the resulting image and dtb directly to the /boot/.... folders and made backups of the old ones. Since the boot process uses extlinux and not grub, I think the normal make install doesnt work... but there should be another matching script...

As for general things GPIO and MCU buses, I would not try and port the RPi stuff, rather just use the normal Linux interfaces...

If you have any questions, maybe drop by in the #rock64 IRC channel where all the devs hang out