OpenMediaVault (PINE A64(+)) 4.13.10 [Nov 21] | OpenMediaVault (A64-LTS / SOPINE) 4.13.10 [Nov 21] | Q4OS (PINE A64(+)) 2.4-r1 [Nov 10] | Volumio (ROCK64) 2.299 [Oct 30] | Q4OS (Pinebook) 2.4-r1 [Oct 30] | DietPi (ROCK64) v156 [Oct 24] | Armbian - Xenial Desktop (Pinebook) 5.34 [Oct 24] | motionEyeOS (PINE A64(+)) 20171003 [Oct 23] | Android Images (ROCK64) 20171012 [Oct 23]

Getting Started | Visit the WIKI | IRC Logs | Forum Rules/Policy


gpio driver porting from an r-pi3b
#1
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
Reply
#2
(10-12-2017, 08:12 PM)gene83 Wrote: 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 !

Shy
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
Reply
#3
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
Reply
#4
(10-13-2017, 09:22 AM)gene83 Wrote: 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
Reply
#5
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
Reply
#6
>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.
Reply
#7
(10-13-2017, 04:06 AM)MarkHaysHarris777 Wrote:
(10-12-2017, 08:12 PM)gene83 Wrote: 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
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Configuring Python GPIO Pin Control Rock64 www139 1 150 11-03-2017, 07:30 PM
Last Post: MarkHaysHarris777
Brick Rock64 usb2.0 Power Control Floating GPIO Tutorial Files & Notes MarkHaysHarris777 5 523 08-28-2017, 07:06 AM
Last Post: ayufan

Forum Jump:


Users browsing this thread: 1 Guest(s)