tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
Did you plug in an Ethernet dongle or is this the 'onboard' Ethernet: AX88179?
-
Today I was able to add a 3rd disk (since another UAS capable enclosure arrived using an ASMedia ASM1153E USB-to-SATA bridge that is not UAS blacklisted). Again only read tests since one of the disks contains important data):
116 MB in 3.02 seconds = 38.44 MB/sec 116 MB in 3.02 seconds = 38.43 MB/sec 114 MB in 3.04 seconds = 37.44 MB/sec 106 MB in 3.00 seconds = 35.30 MB/sec 116 MB in 3.02 seconds = 38.45 MB/sec 116 MB in 3.02 seconds = 38.36 MB/sec 116 MB in 3.02 seconds = 38.45 MB/sec 116 MB in 3.02 seconds = 38.44 MB/sec 114 MB in 3.04 seconds = 37.44 MB/sec 116 MB in 3.02 seconds = 38.45 MB/sec 116 MB in 3.02 seconds = 38.45 MB/sec 116 MB in 3.04 seconds = 38.10 MB/sec 116 MB in 3.02 seconds = 38.43 MB/sec 116 MB in 3.02 seconds = 38.43 MB/sec 114 MB in 3.04 seconds = 37.47 MB/sec
That's +114 MB/s sequential read throughput with just one single CPU core running at 1008 MHz and the kernel being able to utilise UASP
This looks really promising using H3 based devices for NAS purposes with mainline kernel since when SMP is working and we're able to adjust clockspeeds up to 1296 MHz again there's enough horsepower left even with 4 disks connected to use btrfs compression and stuff like that. -
I got my USB/UART for odroid XU4 from Hardkernel/South Korea, for testing.
It would be great if you could've a look at those 2 threads:
http://forum.odroid.com/viewtopic.php?f=97&t=17349
http://forum.odroid.com/viewtopic.php?f=93&t=15727#p113236
I'm especially interested in the GL3321G being UAS capable:
dmesg | egrep -i "usb|uas"
shortly after connecting a disk. And whether performance further increases or not. Unfortunately the SSD and disk used by the hardkernel folks might already be the bottleneck (SSDs with just 120GB capacity are most of the times performance limited due to lack of parallelism when writing/reading)
-
I had disconnected the attached hard drive and it seems that Debian Jessie won't boot if there's an entry in /etc/fstab referencing a non-existent device.
Unless you provide the "nofail" option this is now the case. And this change in jessie is intended: have a look at eg. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797039
-
What means???
At least not related to Samba. Can you elaborate a bit on your network setup? Did you exchanged cabling and/or switch ports already? The performance numbers you posted are really low...
-
And another small update. Still running Igor's 1st test OS image with kernel 4.4.0-rc4 and 2 disks in JMS567 equipped enclosures. Both UAS enabled (according to dmesg):
[ 4.208848] scsi host0: uas [ 4.216324] scsi host1: uas
A rather primitive hdparm test (only testing read speeds since on /dev/sdb is important data):
/dev/sda: Timing buffered disk reads: 120 MB in 3.03 seconds = 39.56 MB/sec /dev/sdb: Timing buffered disk reads: 116 MB in 3.02 seconds = 38.38 MB/sec /dev/sda: Timing buffered disk reads: 120 MB in 3.04 seconds = 39.50 MB/sec /dev/sdb: Timing buffered disk reads: 116 MB in 3.01 seconds = 38.49 MB/sec /dev/sda: Timing buffered disk reads: 120 MB in 3.04 seconds = 39.45 MB/sec /dev/sdb: Timing buffered disk reads: 114 MB in 3.03 seconds = 37.58 MB/sec
Great results since both disks were tested in parallel: /dev/sda is a fast SSD and /dev/sdb just a slow 2.5" disk. But this is still an Orange Pi PC with just a single active CPU core since SMP stuff isn't ready in mainline kernel now. And CPU utilisation looks like it's possible to saturate even another USB bus with one CPU core.
EDIT: Nope, not true. As soon as a filesystem is involved and also write speed the single CPU core becomes a bottleneck. I repeated the tests using a btrfs raid-0 between the two disks. When reading sequential throughput is ~79 MB/s (great!) while writing the throughput decreases to 57/65 MB/s (with 4K and 1M record size). I hope that we'll get SMP support rather sooner than later and then post a follow-up with an in-depth comparison of BOT vs. UAS when using the H3.
-
Regarding USB power the RPi (and most sunxi boards) and H3 based boards are totally different. On the RPi you can control how much USB peripherals are allowed to draw (see here for example) which is not possible with Orange Pi PC since the H3 has no PMU support.
DC-IN is directly used to provide power to the USB ports and HDMI. As far as I understand you might be able to draw 2A from a type A connector if you insert 3A on DC-IN (but I might be wrong). I will report back in the next few days when I try to use 3 bus-powered 2.5" disks clearly exceeding 2A peak current while spinning up.
I tried to explain the overvolting stuff already (15th Dec). In short: The higher you clock a chip the more voltage it needs. Usually you want the lowest voltage (with some safety headroom) since that helps with consumption, temperatures and longevity. To fulfil both needs dvfs will be used, adjusting the Vcore voltage depending on the clockspeed and the clockspeed will be adjusted dynamically also (cpufreq scaling based on load).
Normally the PMU/PMIC is responsible for the Vcore adjustments but since the H3 lacks PMU support, the cheap SY8106A programmable voltage regulator is used by Xunlong. The voltage will be set using I2C and this way it's possible to overvolt the CPU cores (Vcore above 1.4V) even while the board itself is undervolted due to bad cables or a bad PSU (DC-IN voltage below 4.7V). All the voltage regulators used on Orange Pi PC are able to be fed with 4.5-5.5V. But since DC-IN is directly used for USB and HDMI you might get in trouble with connected USB peripherals and/or a display when you exceed the 'safe range': 4.8V - 5.25V (USB: 4.75V-5.25V, HDMI: 4.8V-5.3V)
-
they still do not activate 1-Wire. That's the only company on this planet selling an SBC that is not able to use 1-Wire sensors since they don't give a sh*t about software at all.
Another funny update on the M3 (and the M2 as well, this SBC also suffers from lack of support). The reason you can not use 1-Wire sensors on both Banana Pi M2 and M3 is that the vendor has no clue how to setup settings correctly. Banana Pi M2 and M3 are the only SBCs on this planet where you can't use popular thermal sensors like DS18B20 since the vendor's software support sucks.
So what to do? You've to fix the problem yourself (it's easy, all that's missing is CONFIG_W1 and also CONFIG_W1_SUNXI + the driver but 'Team BPi' simply forgot to include this driver).
Now a user created a patch https://github.com/BPI-SINOVOIP/BPI-M2-bsp/pull/5 ( based on earlier work for the A20) for the M2 that will work also with the M3. And what is 'Team BPi' doing? Instead of merging the pull request and immediately providing a fix to their customers, they simply ignore it. As usual. They don't give a sh*t whether you can use an SBC as an SBC or as a paperweight. But since their customers also don't care it's just another example for a great business model.
-
The only feature that's interesting on the Raspberry Pi is that one can use the VPU correctly now (after a few years). We use RPi B+ as IP camera (even when the CPU core is clocked with just 200 MHz the VPU is able to provide a 1080p@30 fps h.264 encoded video stream) or for digital signage, often combined. In the meantime also lightweight distros exist like http://dietpi.com
For everything else the RPi is always the worst choice due to its one single USB 2.0 connection to the outside.
Supporting the RPi would mean Armbian either focuses on a completely new use case (desktop stuff -- VPU) or on a completely new user base (clueless people).
-
Another small update. I took Igor's test image with kernel 4.4.0-rc4 again ("Nothing is working, only USB/UART"), plugged in an USB-Ethernet dongle, connected a disk in an JMS567 enclosure and compiled Netatalk (fileserver for OS X) to get results that can be compared easily:
The results are not that good compared to the recommended sunxi boards (all featuring SATA and GbE) but that's due to my USB-Ethernet adapter being cheap crap [1]. But given that I used the very first test image Igor created, that I just had to exchange the device tree contents to get USB running on my Orange Pi PC (Igor built the image for the 'Plus'), that only cpu0 is running since SMP is not working yet, this is simply AWESOME!
Really looking forward to see mainline u-boot/kernel improve in 2016. Thank you all you linux-sunxi devs (and Igor of course -- providing the image makes testing convenient)
[1] Ethernet adapter used:
root@orangepipc:/mnt/sda1/data# modinfo smsc75xx filename: /lib/modules/4.4.0-rc4-sunxi/kernel/drivers/net/usb/smsc75xx.ko license: GPL description: SMSC75XX USB 2.0 Gigabit Ethernet Devices author: Steve Glendinning <steve.glendinning@shawell.net> author: Nancy Lin alias: usb:v0424p7505d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0424p7500d*dc*dsc*dp*ic*isc*ip*in* depends: usbnet intree: Y vermagic: 4.4.0-rc4-sunxi SMP mod_unload ARMv7 p2v8 parm: turbo_mode:Enable multiple frames per Rx transaction (bool) root@orangepipc:/mnt/sda1/data# lsusb -v -d 0424:7500 Bus 003 Device 002: ID 0424:7500 Standard Microsystems Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0424 Standard Microsystems Corp. idProduct 0x7500 bcdDevice 1.00 iManufacturer 1 WS iProduct 2 USB Gigabit LAN iSerial 3 0000000814 bNumConfigurations 1
-
I don't see any reason to buy a Guitar.
Me too unless they provide a few more baseboards that would make use of the SoM concept. But they're not able to answer even most basic questions, therefore... forget about the Guitar...
BTW: LeMaker's competitors (Steed Technology, Allo and Roseapple Pi) at least accepted the S500's thermal challenges: you need large heatsinks for both SoC (and PMIC) otherwise throttling/power-off will occur under load. And both Allo Sparky and Roseapple Pi provide an USB 3.0 type A receptacle so USB 3.0 is useable there (which is still not the case with LeMaker's guitar)
-
Another update. The 'Team BPi' seems to also monitor this thread. At least they started to adopt changes I made to the sources and published a few days ago above: http://pastebin.com/xvJ04Pi2
Everything from Dec 15 is just partially adopting the aforementioned stuff: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master
And while this is good news (they're at least able to learn a little bit) their customers can't benefit since 'Team BPi' has no online update mechanism and all these changes do not affect the rootfs but kernel/initrd living in the first sectors of SD card or eMMC. Every OS image they provided so far can't be upgraded and users are forced to reflash their media when (if?) they release new OS images containing all these fixes.
Their 'development style' still sucks and they still do not activate 1-Wire. That's the only company on this planet selling an SBC that is not able to use 1-Wire sensors since they don't give a sh*t about software at all. They even set CONFIG_DEFAULT_MMAP_MIN_ADDR to a value that leads to all sorts of problems when trying to use the Banana Pi M3 with a normal user account (not root) but since they neither test the crappy software they release nor care this is a problem the unfortunate customers have to deal with.
Since I stumbled across the most weird combination of two devices ever today (Raspberry Pi 2 with its limited I/O and network bandwidth and WD's "PiDrive" as an ownCloud self-hosting device) I had a short look on this PiDrive today (since it could've been a nice addition for an ODROID-C1+ for example -- unfortunately not true): https://community.wdc.com/t/technical-questions-regarding-pidrive/142658/1
To be able to compare the miserable throughput of this PiDrive (being marketed as a native USB drive by WD -- LOL!) I recompiled the RPi 4.1.5 kernel with enabled UASP (to no avail since it doesn't work) and used my usual test SSD and also the usual UASP/SAT capable enclosure with JMS567 bridge: Thanks to mainline kernel and btrfs I'm able to reach 34.5/37 MB/s (write/read) on a Raspberry Pi! Compare this with the lousy 15/30 MB/s you get with the 'SATA implementation' the Banana Pi M3 ships with.
And I doubt we'll ever be able to use btrfs with the M3 since mainlining efforts for u-boot/kernel are still in early stage. It's just unbelievable: Even a single core 700 MHz SBC using only one single USB port on its SoC is able to outperform the expensive Banana Pi M3 easily when it's about I/O bandwidth.
-
Did I understand it right, that the OrangePI PC has its seperate LAN-Controller (and doesn't it by USB like e.g. Raspberry) ?
Yes, the H3 has the ability to provide both Fast and GBit Ethernet (EMAC/GMAC) and to either use an external GBit Ethernet PHY through RGMII (as it's the case with nearly all Allwinner SoCs starting with A20) or to rely on an internal PHY that is 100 Mbits/sec capable (that's new with the H3 --> the ability to use Fast Ethernet without any external 'active' components)
So when you design a device with the H3 you can either save the few Cents for the RTL8211D/E and route 4 traces from SoC to the Ethernet jack (Fast Ethernet uses only 2 cable pairs) or you choose an external GBit PHY and interconnect SoC and PHY with RGMII. No USB involved.
BTW: On Raspberry Pi everything except of access to the SD/TF card has to happen through USB since the SoC only has 1 single USB connection to the outside. Therefore choosing any of the RPi models for anything that needs I/O and network bandwidth is just weird.
If Steven Zhao from Xunlong could be convinced to produce an upgraded version of the OPi PC (using RTL8211 for GBit Ethernet and with 2 GB RAM and all available 4 USB ports as type A receptacle) then this could be the basis of a really great low-end NAS for 4 drives even if the H3 doesn't feature SATA.
With mainline kernel we've the ability to use UASP (responsible for drive access maxing out at +40 MB/s) and we can also use btrfs with advanced options one of them being transparent filesystem compression which trades in CPU cycles for more throughput.
Also an 'Orange Pi NAS' would be possible/great. A board with H3, 2 GB RAM, GBit Ethernet and 3 onboard UASP capable USB-to-SATA bridges where 3 of the available USB ports are directly wired to bridge chips, eg. JMS567/568: http://linux-sunxi.org/USB/UAS#UASP_capable_chipsets_in_disk_enclosures
With btrfs you can then setup a RAID-0 or RAID-1 over all 3 connected disks and since btrfs handles RAID-1 differently than md-raid you can even use 3 disks of different sizes in RAID-1 and end up with the whole capacity of all three divided by 2 (btrfs always storing 2 copies of data blocks on two disks and balancing the accesses between disks so the whole capacity will be used)
Btrfs is also able to combine RAID-0 for performance with RAID-1 to detect data corruption (striped data and mirrored metadata). Such a setup with activated btrfs compression would easily exceed 80 MB/s locally and this way you would've a NAS that is able to provide +70 MB/s through the network.
-
Now I took your image, put it to sd-card, started and -oh wonder- nothing happens.
Unless you use a serial console you won't realise that the board boots. There's no LED activity and no HDMI output available at the moment. UART and USB -- that's it.
-
I doubt I can just enter a MicroUSB charger on that USB part so I can pick the $23 one for that. I guess that works out.
Nope, the H3 has no PMU therefore only DC-IN works (available at the barrel plug or on the GPIO pins -- just re-read the review above).
-
Looks too small. But it would fit for an ODROID-C1+ (also a good choice, you can clock the S805 with up to 1.7 GHz and no need for a fan -- see the LeMaker review for comparisons).
Regarding Allwinner's A64 everything is speculation right now. But it's clear that this chip is probably the definition of 'low-end 64 bit'. The upcoming Amlogic S912 looks a lot more interesting (also only Cortex-A53 but up to 4 GB RAM and USB 3.0). But for most use cases an H3 board with GBit Ethernet and optional 2GB RAM would also suffice.
-
The A64 might be a bit faster than the H3 (slow Cortex-A7 vs. slow Cortex-A53, both made in an inexpensive 28nm process) but you would need to run an OS on it that makes use of the ARMv8 instruction set (arm64 architecture and not armhf in 'Armbian terms'). The whole '64 bit' thing is more or less marketing since with 64 bit you might be able to address a huge virtual address space but are limited to 2 GB physical RAM with the A64 anyway (same with H3).
And by looking into preliminary material from the Pine64 people I would suspect the A64 is prone to overheating. We will see, they shipped a board to me that's still on its way. Regarding kernel and OS support: I don't think any of the linux-sunxi developers will happily spend much time for free on the project to fulfill the Pine64 promise to be able to use a more recent kernel anytime soon (in their FAQ they said they will later support 3.18 and then 4.2 which is a clear sign that they have no idea what 'mainlining' means. Or maybe they think they can apply the 'few' patches from kernel.org to the 3.10.65 kernel they got from Allwinner to reach 3.18 or 4.x in 2016?)
-
Do most or all of these developments apply to the OPi Plus 2 as well since it is also using the H3?
They do. The best place to look regarding new boards is here: http://linux-sunxi.org/Mainlining_Effort#Planned_for_4.5
Supporting a new SBC happens at several layers: Drivers have to be written and the hardware has to be described correctly (in so called 'device tree files'). Igor's preliminary image contained support for the 'Plus' (the 'Plus 2' is exactly the same just with 2 GB RAM) and the 'PC'. You should be aware that the PC is most likely the better choice (no crappy USB-to-SATA bridge, no internal USB hub, all 4 USB ports useable) but it lacks GBit Ethernet and the 2GB RAM.
Now that Orange Pi customers start to realise how they've been fooled by the manufacturer ("up to 1.6 GHz", no real software development and relying solely on community, crazy overvolting), maybe Steven changes his business model and instead of advertising only useless feature sets targeted at uneducated customers he concentrates on the H3's strengths: He could do an "Orange Pi PC Plus" (to further confuse his customers with naming schemes
) that is like the PC with 4 useable USB ports, but GBit Ethernet using an external RTL8211 PHY and 2 GByte RAM. This would be the perfect H3 device for less than $20.And for the 'I need at least 64 bits' morons his next model with the H64 is the board of choice (If I remember correctly this is called "Orange Pi 3 Plus Turbo" or something like that).
-
HAH good one.
Please do it. Ask in the forum at banana-pi.org so others can learn what to expect from this vendor. Again and again. At least others are warned that there's no support available.
-
I think working on CSI is still "work in progress" in mainline kernel. And regarding the OV5460 it's not worth the efforts. This is a "5MP" camera and I've never seen anyone being able to get more than 640x480 pixels with questionable quality out.
I tried to get an idea why and stumbled across a freescale forum (IIRC) where one engineer said that it's hard to write a driver for this module without loading/using BLOBs with tables for conversion (or something like that) on the camera first. In short words: If you don't sign an NDA with Omnivision you won't be able to write a driver for this module that doesn't suck.
We still use the RPi (B+) for this purpose. And the difference are just the drivers (for both the VPU -- HW accelerated h.264/1080p@30fps -- and OV5647 -- image quality)
Today I stumbled across these links: http://www.arducam.com/camera-modules/raspberrypi-camera/ and http://www.arducam.com/camera-modules/5mp-ov5640/
No idea how to deal with currently (maybe they've drivers that work better, but this still won't help with mainline kernel)
-
-
Is it possible that only the ferrite bead burnt and nothing else? I think I can replace it... but even then, the schematics sinovoip posted doesn't have the values listed on the components...
Ask the vendor. In case they care about customer support they should answer soon.
-
I was hoping the R1 would fill a need I have for some serious work, and clearly they are not even near there.
Apart from the many issues we had with the R1 (vendor 'forgot' to define SATA power definition, faulty power design, crappy OS support in the beginning and so on), there's one thing most people interested into this device always overlook: It's not suitable to be used as a router without an additional USB-to-Ethernet dongle.
The so called 'WAN port' is connected with the 'LAN ports' through an el cheapo switch IC. When the board boots or you're able to attack it from the outside to provoke a reboot then it simply acts as a switch unless the b53 driver tries to change that behaviour. But before any interface has been brought up by the kernel and VLAN rules are applied it acts as a dumb switch connecting all available Ethernet ports.
You can use the R1 as 'router' only as long as you're happy with the situation that 'WAN' and 'LAN' are interconnected through a switch (while rebooting the R1 or while being under a 'Denial of Service' attack) or use something else for the 'WAN' interface. And if you do so then still Ethernet performance sucks.
-
Did anyone got this to work with 4.x-kernel?
http://linux-sunxi.org/Mainlining_Effort#Major_drivers
BTW: How does quality look like with OV5640? What's the highest resolution possible?
Banana Pi M3
in Reviews, Tutorials, Hardware hacks
Posted
The A83T used on the M3 has an internal temperature sensor and I provide RPi-Monitor templates to monitor this stuff (see above).
Regarding useable OS images from 'them': well, they suck more or less and you won't see Armbian support anytime soon for any device based on A83T. Why don't you try to get support from the vendor? Why don't you push them to provide something more useable? Why do all the M3 users accept that they bought an expensive paperweight and do not complain publicly so others could learn to avoid the so called 'Banana Pi' M2/M3?