chrisf

Members
  • Content count

    134
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chrisf got a reaction from WarHawk_AVG in gotop   
    You've bunged up the link somehow, there's a unicode byte order marker between i and / in cjbassi/gotop
    If you copy/paste into a url bar you'll get a 404 and scratch your head because it looks identical to a url with %EF%BB%BF in it
     
  2. Like
    chrisf got a reaction from jkljkl1197 in Tinkerboard Power It using a battery   
    5V with a 1R load is 5A, 25W
    5V with a 0.5R loan is 10A and 50W
     
    For a 2A load on 5.1V, the calculation is 5.1/2 = 2.55 ohms
  3. Like
    chrisf got a reaction from Set3 in CPU overload for minisatip using DVB-C, workaround by adding CPU load !   
    I can only assume the load is not enough to keep ondemand at a high enough frequency, so it keeps scaling up and down. Maybe the CPU needs to wait between interrupts and that's causing the scaling. Maybe the process that's doing the work is low priority.
    While the frequency changes, the CPU can do no work. You lose tens of microseconds each time it happens.
    You might be able to keep using ondemand if you tweak its settings, but if performance fixes your problems and works well, probably no need to change it.
  4. Like
    chrisf got a reaction from tom_i in Espressobin support development efforts   
    I had a quick look over the diff for 4.16-rc1 and it looks like there's progress on support for DVFS too
  5. Like
    chrisf got a reaction from jscax in How to control an infrared YS-IRTM module send/receive   
    Looks like that module has a UART (serial) interface, not I2C
     
    The aliexpress page doesn't say anything about how it communicates over the serial connection.
     
    There's a forum thread here about it: https://forum.arduino.cc/index.php?topic=359707.0
  6. Like
    chrisf got a reaction from Jens Bauer in RK3399 USB 3.0 peripheral mode data throughput?   
    Apparently yes
     
    Not sure if it's a matter of a simple PCIe cable or not (it implies that's the case for "local networking" between two PC's, a PCIe switch for a network of more than two) but if you scroll down just past half way here, it mentions it
    https://www.onestopsystems.com/blog-post/pcie-over-cable-goes-mainstream
     
    The PCI Express bus has direct access to system memory, I don't see why either side of the point-to-point connection can't be the initiator.
  7. Like
    chrisf got a reaction from Ruslan Dzanmahmudov in Asus Tinkerboard   
    Just connect your 5V to pins 2 and 4 and ground to pin 6 of the GPIO header.
     
    This goes straight to the power input of the RK808. It bypasses the input over voltage protection and current limit. Make sure you don't put in more than 5.5V
     
    Edit: Further reading of the schematic (providing it's accurate) shows you should be able to power it directly from a single lipo battery. Obviously this won't put 5V out to any USB devices you connect though.
  8. Like
    chrisf got a reaction from Igor_K in What would be a good board with 2 Gb RAM for a bitcoin node?   
    I haven't had any problems with my XU4 (or HC1)
     
    Tinkerboard has micro-usb power input, which would give stability issues.  Powering via GPIO headers bypasses its power input protections.
  9. Like
    chrisf got a reaction from Patrick in Espressobin support development efforts   
    I found all the firmware with 800mhz ram speed is dodgy. It must be a marginal board layout issue of the ram won't run stable at its rated speed.
     
    We just have to put up with lower memory bandwidth on a board that already wasn't all that fast (single channel 16 bit memory interface).
    Isn't it similar to the first ever DDR PC's 15 years ago? They had 64 bit bus width, 200mhz.
  10. Like
    chrisf got a reaction from tkaiser in ROCK64   
    Completely wrong it turns out.
    Turns out the RK805 PMIC needs the voltage increased in 12.5mV steps and the frequency needs to be specific values too, they're defined in drivers/clk/rockchip/clk-rk3328.c.
    They're defined up to 1.8GHz, but I didn't get any above 1.488 to work, cpufreq wouldn't load them.
    It does run stable at 1.488GHz though, if you increase the voltage. I'm using 1.4375V, haven't tested any lower.
    Done testing stability: Frequency: 1392000 Voltage: 1350000 Success: 1 Result: 0.0048034 Frequency: 1416000 Voltage: 1375000 Success: 1 Result: 0.0048034 Frequency: 1488000 Voltage: 1437500 Success: 1 Result: 0.0048034 I had to edit the script for min, max and cooldown freq as well as the Vcore regulator
    Peaks around 78 degrees, with idle @408MHz 40 to 45C
     
    minerd --benchmark reports 4.61khash/s (or 4.58 while armbianmonitor -M is running)
    after a few minutes it's sitting around 79C
  11. Like
    chrisf got a reaction from arm-push in Espressobin support development efforts   
    I've compared the kernel config for mainline and Marvell's 4.4 and one thing that stands out in regards to the SD card issue is:
    CONFIG_MMC_SDHCI_XENON
    In the linux-mvebu64-default.config it is set to y, in linux-mvebu64-next.config is it not set
     
    That could explain why it works to @umiddelb, his defconfig has it enabled too. I'll try it myself when I get the chance but that could be a few days away.
     
    Edit:
    I've just tried it on next and it works, just need to update fdt_name env var to point to the correct DTB
    # uname -a Linux ebin 4.14.0-mvebu64 #4 SMP PREEMPT Mon Nov 20 08:02:32 UTC 2017 aarch64 GNU/Linux # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 1.4T 0 disk └─sda1 8:1 1 1.4T 0 part mtdblock0 31:0 0 4M 0 disk mmcblk0 179:0 0 29.8G 0 disk └─mmcblk0p1 179:1 0 29.5G 0 part /  
  12. Like
    chrisf got a reaction from marcellom in How install RTC schield by Hardkernell in Odroid c2 with OMV Erasmus 3.0.92?   
    root@raspberrypi:~# modprobe i2c-dev root@raspberrypi:~# modprobe rtc-pcf8563 root@raspberrypi:~# echo pcf8563 0x51 > /sys/class/i2c-adapter/i2c-0/new_device the first command makes sure the i2c-dev driver is loaded
    the second command loads the pcf8563 driver
    the third one tells the kernel to use the pcf8563 driver for the device with addres 0x51 on i2c-0. You'll want to change i2c-0 to i2c-1 as that's the i2c port with your rtc device.
     
    This is from http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/
  13. Like
    chrisf got a reaction from chwe in Please recommend a chipset/board   
    I think it's going to be many years before you can find an SBC with both excellent IO bandwidth and a high performance GPU.
     
    You currently get to choose between the two.
     
    I guess the reason for this is there are only really three markets for the SoC's:
    Android tablets and phones. Needs decent GPU. Nothing more than SD/eMMC is required. TV box. Needs decent GPU, still doesn't need high IO bandwidth. Wifi runs over SDIO, still doesn't need a full 1GBe network connection. NAS/home server boxes. Goesn't needs a GPU at all. Needs decent SATA and NIC. High end soho expect 200MB/s with dual gbe. Mavell have this market pretty much covered. CPU doesn't need to be that great either, if they put in hardware acceleration for network/ssl/etc I'm also not aware of any mPCIe video cards, so you'd need to go down the route of an external PCI-E enclosure. Getting ARM drivers for an AMD or nVidia card would be interesting too. I was under the assumption that if you want proper drivers for these, they come as binary blobs.
  14. Like
    chrisf got a reaction from Frostbyte in Asus Tinkerboard   
    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
     
  15. Like
    chrisf got a reaction from Frostbyte in Asus Tinkerboard   
    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
     
  16. Like
    chrisf got a reaction from Frostbyte in Asus Tinkerboard   
    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
  17. Like
    chrisf reacted to zador.blood.stained in Asus Tinkerboard   
    I mean it shouldn't be too hard to add configfs support patches to these kernels, but you will still need to write overlays for each platform from scratch since base DT configuration will be different.
  18. Like
    chrisf got a reaction from Tido in Asus Tinkerboard   
    It's in the RK808 datasheet
    You can set shutdown to 140c or 170C
    You can set hot die to 85, 95, 105 or 115C
     
    The RK808 driver can then read the shutdown status or the hot die status
    http://rockchip.fr/RK808 datasheet V0.8.pdf
  19. Like
    chrisf got a reaction from Ruslan Dzanmahmudov in Asus Tinkerboard   
    Just connect your 5V to pins 2 and 4 and ground to pin 6 of the GPIO header.
     
    This goes straight to the power input of the RK808. It bypasses the input over voltage protection and current limit. Make sure you don't put in more than 5.5V
     
    Edit: Further reading of the schematic (providing it's accurate) shows you should be able to power it directly from a single lipo battery. Obviously this won't put 5V out to any USB devices you connect though.
  20. Like
    chrisf got a reaction from TonyMac32 in Asus Tinkerboard   
    Yes, with kernel 4.4.67, I built it from git two days ago. I could see it throttling fine for a few minutes on rpimonitor
     
    Edit: After replacing the heatsink it hasn't shut down. It may have been due to low thermal mass and slow temperature polling frequency. It's still throttling but the temperature is much more stable in the low 70's.
     
    Looking back over the rpimonitor stats, with the old heatsink it peaked at 85+ 3 times before the shutdown

  21. Like
    chrisf got a reaction from lafalken in Asus Tinker won't boot   
    I had this problem. I was using an SD card in an SD -> uSD adapter. Worked fine loading the image to the card from my laptop. Worked fine on a pine64 board. Worked fine on a RPi2. Did not work on a Tinkerboard. Bought a new SanDisk Ultra 16Gb and it works fine.