Jump to content

RK3328 Kernel

Peba

By Peba
in Tinkerboard

 Share

Recommended Posts

chrisf

chrisf

Posted
Posted
13 hours ago, Frostbyte said:

I just happened to use it on the RPi3 simply because it was more accessible and easy to install. My sensor is a DHT22.
I could try the code in the last link you provided, but I'm afraid that it won't work as it's not designed for the tinkerboard.

I had a read on the available ASUS.GPIO code here and here, to see if I can get any hints on how I can modify the pdif2_DHTXXD to work with the tinkerboard, but I just can't understand anything.. :(

 

I had another look at DHTXXD and it uses another library called pigpiod, which in turn directly access the GPIO registers, so is probably not worth porting to another SoC.

I would go the route of using different sensors, like the BMP085 or BMP280, which offer a standard I2C interface instead of a proprietary one that requires bit-banging - which is always a bad idea to do on a non-real-time OS.

There is many libraries that work with those sensors and they all use the standard /dev/i2c interfaces. Here's one that supports the Tinkerboard: https://github.com/mattjlewis/diozero

1
Link to comment
Share on other sites
Frostbyte

Frostbyte

Posted
Posted
5 hours ago, chrisf said:

 

I had another look at DHTXXD and it uses another library called pigpiod, which in turn directly access the GPIO registers, so is probably not worth porting to another SoC.

I would go the route of using different sensors, like the BMP085 or BMP280, which offer a standard I2C interface instead of a proprietary one that requires bit-banging - which is always a bad idea to do on a non-real-time OS.

There is many libraries that work with those sensors and they all use the standard /dev/i2c interfaces. Here's one that supports the Tinkerboard: https://github.com/mattjlewis/diozero


Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then.

I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors):

  • Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that?
  • From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO)
    If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right?
  • In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin)
  • I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem?
  • Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them.

Thanks in advance. :)

1
Link to comment
Share on other sites
chrisf

chrisf

Posted
Posted
Just now, Frostbyte said:


Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then.

I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors):

  • Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that?
  • From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO)
    If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right?
  • In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin)
  • I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem?
  • Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them.

Thanks in advance. :)

I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI)

I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. 

I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400)

You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers.

 

For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver.

 

Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go

 

2
Link to comment
Share on other sites
Frostbyte

Frostbyte

Posted
Posted
1 hour ago, chrisf said:

I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI)

I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. 

I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400)

You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers.

 

For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver.

 

Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go

 


These two I2C buses on the Tinkerboard GPIO header that you're speaking about, are these dependent or independent of the CPU?
I plan on measuring values once every minute, so I guess I won't need to run it at high speed.

Thanks for all the info, it's really been helpful! :)

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

I have split 2 major support issues into their own threads, Bluetooth and Reboot.  I have gotten Bluetooth working on nightly builds of the default kernel, you need to use rtk_hciattach on every boot (add it to startup).  Next/dev kernels are still a work in progress.

1
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
On 12.6.2017 at 4:30 AM, TonyMac32 said:

I ran iperf3 just for kicks

Can you also provide numbers for the reverse direction please (-R) since all iperf3 results I found on the net are only Tinkerboard --> other device and never vice versa.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

Kernel 4.4.73 

Reverse mode, remote host 10.0.0.15 is sending
[  4] local 10.0.0.52 port 53276 connected to 10.0.0.15 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   109 MBytes   913 Mbits/sec
[  4]   1.00-2.00   sec   110 MBytes   925 Mbits/sec
[  4]   2.00-3.00   sec   109 MBytes   918 Mbits/sec
[  4]   3.00-4.00   sec   109 MBytes   918 Mbits/sec
[  4]   4.00-5.00   sec   110 MBytes   922 Mbits/sec
[  4]   5.00-6.00   sec   111 MBytes   930 Mbits/sec
[  4]   6.00-7.00   sec   111 MBytes   930 Mbits/sec
[  4]   7.00-8.00   sec   111 MBytes   933 Mbits/sec
[  4]   8.00-9.00   sec   111 MBytes   931 Mbits/sec
[  4]   9.00-10.00  sec   111 MBytes   931 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.08 GBytes   927 Mbits/sec    2             sender
[  4]   0.00-10.00  sec  1.08 GBytes   925 Mbits/sec                  receiver

Kernel 4.12 

Reverse mode, remote host 10.0.0.15 is sending
[  4] local 10.0.0.49 port 47608 connected to 10.0.0.15 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   108 MBytes   906 Mbits/sec
[  4]   1.00-2.00   sec   108 MBytes   907 Mbits/sec
[  4]   2.00-3.00   sec   108 MBytes   909 Mbits/sec
[  4]   3.00-4.00   sec   108 MBytes   910 Mbits/sec
[  4]   4.00-5.00   sec   109 MBytes   911 Mbits/sec
[  4]   5.00-6.00   sec   109 MBytes   911 Mbits/sec
[  4]   6.00-7.00   sec   109 MBytes   915 Mbits/sec
[  4]   7.00-8.00   sec   110 MBytes   920 Mbits/sec
[  4]   8.00-9.00   sec   109 MBytes   914 Mbits/sec
[  4]   9.00-10.00  sec   109 MBytes   912 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.06 GBytes   913 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.06 GBytes   912 Mbits/sec                  receiver

 

Link to comment
Share on other sites
Frostbyte

Frostbyte

Posted
Posted

So, until I get an I2C sensor to play around with; I decided to not let my existing DHT22 to go to waste.

I studied the wiringPi library a little bit and came up with my own DHT22 nagios plugin.
It can be found here for anyone else interested.

:beer:

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

As the NEXT image has moved to 4.12, I'll be moving the wireless patch over.  Sorry about not catching that sooner, the switch killed compilation due to the Mali driver.  There still won't be Bluetooth or reboot fix, I'm afraid...

Link to comment
Share on other sites
Myy

Myy

Posted
Posted

I'll take care of the patches this week. I thought that the rc1 would be released today, but it seems to have been released yesterday.

 

I'll incorporate the Mali r18p0 drivers this time, as they have incorporated various patches and are now directly usable with 4.11 kernels, lowering the number of patches required to integrate it with 4.13 kernels ! Yay !

 

For the reboot fixes, I'll wait until I get more logs from the Tinkering branch, in order to have a clearer understanding of the shutdown process.

For the bluetooth fixes, since nobody got it working with the weird Rockchip RFKill thingy, I'll try another way.

 

That said, the main focus with this release will be :

  • The hardware video decoder/encoder chip.
    RK3288 boards are mostly advertised for their abilities to play videos smoothly, and a lot of tinkerboard owners just want to watch movies on Netflix with it.
  • Trying to start pushing patches to arm-soc .
    The more patches are integrated into the arm-soc branch, the less we'll have to maintain in the future. And the less, the merrier, when it comes to maintaining patches.

Now, this might take a few days to get the first release coming, and the new releases will be done in a new repository that will be splitted in two. One of the kernel build scripts and patches, and one with the actual kernel files. That way, people looking for the builds won't have to download 100M of data and people looking for prebuilt kernels will have a clean repo and releases.

1
Link to comment
Share on other sites
lafalken

lafalken

Posted
Posted

Sounds great! Would like to see an clean version without desktop too.  

 

I would like to use this card as webb server, but is it stable enough for such use? For that I would use a usb-hdd, network cable and power. All other things like wireless is of no use for me. But a reboot that does not work is not very good ;(

Link to comment
Share on other sites
Myy

Myy

Posted
Posted

Well, the reboot issue will be a problem if you want some kind of unattended web server that you can upgrade through SSH.

If you can unplug / plug the cable back, it will be a hassle, but not a blocker though. Since servers don't reboot that often, and personal servers on personal networks, shielded from the outside, almost never reboot, you might not even face it.

 

Anyway, I don't see any problem in using that board for a test web server, though Tinkerboard owners might be aware of network issues that I don't.

 

Note that you can run :

 

systemctl set-default multi-user.target

 

To boot your system directly in text mode, instead of booting in desktop mode. From there, you might be able to delete desktop packages and keep only the server packages you need.

1
Link to comment
Share on other sites
Myy

Myy

Posted
Posted

Ok... turns out that the mainlined rk3288.dtsi references a "job" IRQ that is completely unknown and fail the Mali GPU detection...

 

However, I did it the same way before and it worked. So I don't know what they've added that could fail...

 

Anyway, I've started to do some prep work for my new repositories. The first one is here and contains my new patches :

https://github.com/Miouyouyou/RockMyy

 

EDIT :

Well my 4.12 DTB file works so it's clearly an issue generated by the new definition...

 

Oh... please...

/tmp/RockMyy/linux/drivers/gpu/arm/midgard/mali_kbase_core_linux.c 

		if (!strncmp(irq_res->name, "JOB", 4)) {
			irqtag = JOB_IRQ_TAG;
		} else if (!strncmp(irq_res->name, "MMU", 4)) {
			irqtag = MMU_IRQ_TAG;
		} else if (!strncmp(irq_res->name, "GPU", 4)) {
			irqtag = GPU_IRQ_TAG;
		} else {
			dev_err(&pdev->dev, "Invalid irq res name: '%s'\n",
				irq_res->name);
			return -EINVAL;
		}

 

I replaced the strncmp calls by strncasecmp and... it works...

 

Well, I'll reassemble the patches, and commit this.

1
Link to comment
Share on other sites
Frostbyte

Frostbyte

Posted
Posted

I am aware that this board has severe powering issues when using the USB power connector..
After struggling a lot to find a reliable PSU, I ended up buying the "official" RPi PSU that's supposed to provide 2.5 amps, however I still get a shutdown once every 2.5-3 weeks. (I suspect it's power)
Are these patches going to improve this by any chance, or will I forced to craft and use a 3A GPIO PSU?

I'm kind of reluctant, because I've heard that there are no fuses/protection in the GPIO and you can easily toast the board that way.
The reboot fix will be awesome, however.

PS: I'm also coding a nifty little Nagios check for the SHT31-D I2C sensors that just arrived, when my friend takes care soldering the pin headers and making the wires for me, I expect to get it on github soon.

1
Link to comment
Share on other sites
RickyTerzis

RickyTerzis

Posted
Posted

HI...i am a new user here. In my case my board idea is a little closer to my heat sink modification than I like, but if I make a proper board I want to include a USB charge port for powering external HDD's assuming they won't spin up on the USB alone.

Supply used:  Odroid XU4 5.0 V 4 Amp, I stuck a capacitor on there, will probably include an overvoltage protection diode as well.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

I've been playing with some board artwork to make a general "Pi-formfactor fixing Hat", I agree that a modified heatsink gets a bit close.  I have a 10mm heatsink and think an 8 would be maximum.  For a charge port, you'd ideally want to make it a colored port (red I think) so it's obviously for a singular purpose.

Link to comment
Share on other sites
bedalus

bedalus

Posted
Posted

There's something different about the 4.12.3 kernel, I can use my bluetooth keyboard with it. It's not using the native bluetooth, it's got it's own dedicated dongle. When I tried the stable versions (both legacy and mainline) I couldn't log in, I'm guessing because the drivers aren't enabled in these older kernels. Did the config change in the daily build? Are the commits in the source repo (sorry, this is a passing thought, and I'm at work, so shouldn't really be on here!)

 

Edit: Home from work. I think I found the commit: https://github.com/armbian/build/commit/ffb032449e1063d6f43862a9b2c430d99c54137d but I can't spot what might have been turned on that allowed the bluetooth dongle to function. 

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

I can't tell you for sure, to be honest, I haven't done anything with external peripheral drivers.  Can you drop me the link that running armbianmonitor -u gives you?  My guess is the USB dongle presents a 3-wire HCI device, which I enabled to begin work on the on-board bluetooth.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept