tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
The pcDuino3 Nano Lite features a SATA connector therefore using USB storage is weird. And while you can create a glusterfs consisting of 2 cheap nodes it's a really bad idea to run such a thing on inapproriate hardware (no ECC RAM --> no glusterfs)
-
Does the processor need a heat sink?
Normally not. And in case the SoC would overheat a heatsink won't help that much inside an enclosure without airflow. Which kernel version do you use? In case it's 3.4 it's easy to read out both the PMU's and the SoC's internal temperature: http://forum.armbian.com/index.php/topic/155-testers-wanted-sunxi-adjustments-for-rpi-monitor/
-
Which board are you using? How are drives connected and powered?
-
Sorry, I still don't get it. While you might be able to do some really weird VLAN stuff given all your devices are VLAN capable and you know what you're doing, using a 'layer 2 switch' as interconnect between the outside and the inside on an edge router (that is able to learn this VLAN stuff only after successfully booting when setup correctly) seems like a crazy idea.
The default state of a router should be "no packets get through", the default state of the R1 is "everything is bridged". That's plain wrong and there's no excuse for that. You simply can not use this device's so called 'WAN port' to be connected to the WAN. It doesn't work.
VLANs are a nice feature for internal networks to manage traffic flows and things like that. But that's not something you want to rely on to separate networks from a security point of view. Maybe that's not even the case here but most users of the Lamobo R1 trust in the false 'routerboard' marketing and fool themselves.
-
IMHO slapping cheap switch on a board with SoC originally designed for tablets, with single ethernet interface that doesn't support HW checksum offloading and calling it a "router" is not exactly a good concept
True
That's why I wrote 'The idea the R1 is based on is good'. But you're absolutely right: the SoC, the board and the single layer 2 switch for both WAN and LAN ports are wrong. The new Marvell ARMADAs with 2 or 3 independent GbE interfaces seem to be way more suited. 13 days left: https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-router#/
You get just the board for $99 + shipping -- given the state of R1's Wi-Fi (unuseable crap) it's simply a no-brainer to throw the R1 into the bin and pledge. I would believe the 500K stretch goal will also be reached so you get also a *good* metal case for this board for the same price.
Apart from that: Thanks for all the useful links. Will look through them (next year
) but not with the R1 in mind but more focused on A20's GMAC and SATA performance in general (still hoping for the quad-core A20 successor Olimex spread rumours about) -
setting his PC on a separate VLAN so the PC doesn't see the ISP DHCP @boot
But there are no VLANs defined when the board starts. At this stage the switch is a dumb one. Only after successfully booting the kernel and loading the b53 driver it can be configured through MDIO to be VLAN capable.
Did you try it out to simply remove the SD card and start the board? In this mode it's a layer 2 switch, isn't it?
-
ok, /etc/network/interface might be used to launch a pre/post script with "sleep 30; service dhcpd start" at least a small workaround for dhcpd
How should this help? The problem is if you power on the board all devices connected to the switch ports are in a bridged network segment since the BCM53125 then is just a dumb layer 2 switch. The default state is wrong.
-
And the Turris Omnia thing is not yet buyable, sadly. (April 2016, so we'll see in 4 months if the schedule will be kept, plus it will take probably some time before a regular Debian runs on it)
Well, the manufacturer is not a chinese vendor just trying to sell hardware without software/support but it's an open source targeted project from the very beginning. You should start reading from here: https://lists.debian.org/debian-arm/2015/11/threads.html#00071
-
And in Switzerland TK knows a company they make boards with low power X86 processor
If you look for something exactly like the Lamobo R1 then usually you're not willing to accept: "cheap/reliable/performant, choose 2"
The routerboards you refer to are well known: http://www.pcengines.ch/apu.htm (and if you do a web search for "alix apu alternative" you'll find http://soekris.com and others).
But since people are always looking for dirt-cheap and unreliable stuff simply combining a Banana Pi + USB/Ethernet adapter + cheap TP-Link switch + 3.5" HDD + 12V PSU + 2 step-down converters is worth a look IF you really want to combine router/firewall/NAS on a single device (not the best idea IMO)
-
Well, that still did not answer the question for a buyable product that is better.
Sorry, I don't know any alternative to a product that is defined as follows:
- product category: switch board (again: without a 2nd Ethernet interface this thing MUST not be used as a router)
- faulty power design
- most crappy onboard Wi-Fi ever
- no schematics available
- no support from the manufacturer available
- worst network performance of any GbE capable A20 device
- prone to overheating
If you find such an alternative I doubt it would be interesting at all.
You might be able to implement workarounds for some of the issues. But without a 2nd NIC it's simply not useable as router.
-
Just another update. The Foxconn/SinoVoip marketing staff is really convinced that M3 customers must be morons. It seems they produced a new camera module for the various Banana Pi variants and to showcase the capabilities they promote a video that is downscaled to 320x240 pixels and even then artefacts can be seen when trying out the camera in Android:
http://forum.banana-pi.org/t/banana-pi-bpi-m3-test-ov8865-camera-with-android-image/959
I would've never thought that it might be even worse than with the M2 but they prove me wrong
-
a game is not a benchmark
This is such a simple exercise: You are a marketing person. You want to show that your device draws just 2.5W while being used. In case that's true you can produce a short video showing the device being in use (playing a game, decoding a video, running a benchmark -- whatever) and at the same time the consumption. It's easy since the equipment is already there and you can show both the PSU's display and the PineA64 being busy.
They chose the opposite. The PSU's display can only be seen in the video while the PineA64 is totally idle. Simple question: What does this mean?
Apart from that: there was another kickstarter campaign for an A64 based device: https://www.kickstarter.com/projects/jidetech/remix-mini-the-worlds-first-true-android-pc?ref=nav_search
They're already shipping. These devices are intended to run Remix OS, that's simply Android optimised for desktop. And they ship with a 5V/3A PSU with barrel plug. For a reason. While the Pine people claim 5V/1A are enough: http://forum.pine64.org/showthread.php?tid=75&pid=407#pid407
-
Did you have a look at the schematics how the switch is powered? No, since you weren't able to do so. Lesson learned: Never ever buy a device again from a vendor not providing at least schematics. Better buy from vendors following the OSHW approach.
You care about a device being marketed as being capable of doing this and that and it's not the case? Lesson learned: Never ever buy a device again from such a vendor using lies as part of their product marketing.
It's that simple: Avoid any product from this vendor and you're done. We discussed some alternatives to the R1 in this thread: http://forum.armbian.com/index.php/topic/372-hardware-mod-bpi-r1/
The idea the R1 is based on is good. But implementation is simply crap. And on top of that the vendor actively prevented the community to jump in and fix his many software mistakes. Just have a look at the forums at bananapi.com -- we had to reverse engineer the power scheme to get a SATA disk working, they provided not a single working OS image and so on... this vendor's business model relies solely on producing hardware and let the community fix the software without being helpful at all.
Again: Please remember: It's just a dumb layer 2 switch connecting all ports that can be configured through MDIO when Linux is up and running and the driver is loaded and you configured everything correctly and no bugs in the driver exist. In case you brick your device (after a denial of service attack filling your SD card with log messages for example) or when it boots it's always just a dumb layer 2 switch.
If you want to use a router then the worst case scenario is defined as: WAN and LAN are disconnected. It always needs a running OS, an user-defined routing table and optionally appropriate firewall rules to allow packets to cross the border. With a switch board (yes, it's not a router board, it's a dumb switch board) like the R1 the worst case always means: WAN and LAN are connected on layer 2. To use this hardware as a router is moronic (applies to a whole bunch of cheap so called 'routers' as well)
-
BUT if you have a use for a headless linux box it is a bonanza!
I tend to disagree. It might be interesting if you're interested in A64 or Aarch64 in general (then you're either clueless and think '64 bit' is better/faster/higher/cooler because it's twice as 'much' as '32 bit' without having any clue what's going on... or you're a developer interested in Aarch64). In reality the '64 bit' the PineA64 is advertised with is just... marketing. You won't benefit from it as an end user at all with the A64 due to limited amount of accessible physical memory and the relatively bad performance the A64 shows (look at Remix Mini reviews -- A64 is maybe the slowest Cortex-A53 implementation available combined with one of the slowest GPUs -- the dual core Mali400MP2 from 2008)
In case you're interested in more available I/O bandwidth (or working HW accelerated video decoding in Linux and also working 2D/3D GPU acceleration in Linux) then choosing Allwinner's H3 might be the better choice. Since this SoC is older (read as 'longer available') and the community got all this stuff working in the meantime and mainlining efforts look also good (not to be expected to happen with the A64 anytime soon). You get boards with H3 currently for the same price as the Pine. And an 'Orange Pi One' is announced for less than $10 and to be available soon. But this SoC is just '32 bit' so definitely a no-go for the excited kickstarter crowd
Regarding the '64 bit' hype: I already ordered a 'Geekbox' and as soon as the ODROID-C2 can be ordered here I will get that device too. But in the long run A64/H64/R18 (and other upcoming members of the 64 bit sun50i family) might be the SoCs receiving the best Linux support due to the strong linux-sunxi community.
BTW: I'm still wondering how it's possible that thermal and consumption behaviour of the A64 used on the PineA64 can be that contradictory. The other Allwinner SoCs I'm familiar with idle at 16°C (A20), 19°C (H3) or 22°C (A83T) above ambient temperature when driven with sane dvfs settings. According to PineA64's marketing video the A64's idle consumption is higher compared to the aforementioned SoCs while the temperature after 30 minutes gaming is just a few degrees above 30°C (measured in an usual office with Miss Marketing sitting nearby the board and not a climate chamber). Really curious how Allwinner achieved this...
-
a game is not a benchmark TK. trapped
I'm getting tired of all that crap people believe without thinking just a second.
- Any 2D/3D game running in Android fully utilises the GPU core(s) therefore you won't see that much CPU activity. But GPU activity can lead to high consumption too (ARM just recently announced Mali-470 as being twice as energy efficient as the outdated Mali400 from 2008 used on the A64!)
- Any video playback running in Android fully utilises the VPU/CedarX therefore you won't see that much CPU activity. But VPU activity can lead to high consumption too
- Any marketing person producing a video to proof that while playing a game consumption does not exceed 2.5W, pausing a game and then showing the consumption ONLY while the SoC is totally idle (neither before pausing the game nor after the PSU's display is shown) showcases just the opposite: If consumption is just 2.5W while being idle the consumption MUST be higher while gaming. It's that simple: If consumption would not exceed 2.5W while playing Angry Birds they would've shown it in the video. But they prefered to show idle consumption only so the conclusion is simple
- Apart from that that's also an interesting statement regarding the target audience
BTW: Both A20 and H3 boards I've here idle at 1.5W-1.7W. Therefore either the A64 wastes energy when being idle (unlikely since Cortex-A53's strength compared to A7 is not more performance but just less consumption when using optimised software) or there's something wrong with the board or (cpufreq/dvfs) settings.
-
Basically it comes down to your engineering KNOW HOW. Means:
- how much can the board alone consume.
- how much can be consumed through the connectors your board comes with.
- plus some reserve.
And then it looks like this: http://wiki.pine64.org/index.php/Main_Page#Power_Usage
And at least Miss Marketing seems to believe in these numbers:
(0:15).Just kidding. There must be a reason that the clip only shows the PSU in detail when the game is paused. Marketing is so funny...
-
1.) the switch is active during boot, and it defaults to all ports on one VLAN.
Nope, unless the switch isn't configured through MDIO it's just a dumb switch connecting all ports on layer 2 (not a single VLAN existent). Simple conclusion: Don't try to use it as a router unless you waste the only available USB port to be used as the WAN port (USB-to-Ethernet adapter).
-
Thank you for "Hardware Reliability Tests" link. It can help me do stability tests now and in a future. [...]
I checked sys tree and I have only 2 temp here. One should be PMU and second is for battery (not connected). But system is on 100% load 24h/day because boinc-client is running on background.
You should immediately run cpuburn-a7 and the cpufreq-ljt-stress-test in parallel to sort undervoltage situations out. But since the PMU is getting that hot you might also run in overvoltage/overtemperature situations (the more Vcore you provide the hotter the PMU gets).
BTW: If you use my enhanced RPi-Monitor version available here http://forum.armbian.com/index.php/topic/155-testers-wanted-sunxi-adjustments-for-rpi-monitor/you can also read out the SoC's temperature with the included sunxi_tp_temp binary. By installing the sunxi additions everything should work automagically.
-
Too bad this device has the bottleneck of 100Mbps NIC
If Steven would produce a variant with an external PHY (RTL8211 -- not that expensive) and optional 2 GB RAM that would be the most interesting H3 based board -- at least for me. Since the only other board with these 2 features (the Orange Pi Plus 2) has less available I/O bandwidth (due to a wasted USB port for the ultra-slow GL830 USB-to-SATA bridge) and a useless WiFi module (maybe never supported by mainline kernel). I would believe Xunlong could sell such an OPi PC Plus without all the useless stuff and solely adding GBit Ethernet and an additional GB RAM for $20 if they're able to sell an upcoming Orange Pi One for less than $10 also.
BTW: Since a few days an SMP 'hack' is available for Orange Pi PC therefore all 4 CPU cores are already useable: http://pastebin.com/Vj9JYPTn(this is 'fritz' from the orangepi.org forums running his own kernel with Arch Linux)
-
BTW: Instead of trial&error you could also have a look whether the dvfs settings are stable: http://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings
Then you seem to confuse Vcore voltage (the voltage with which the CPU cores are being fed by the AXP209 PMU) with powering the board itself. It's possible to overvolt the CPU while running in undervoltage situations (voltage dropping below 4.6V from DC-IN).
On the cubietruck you should also be aware that a disk is not powered through the PMU but directly from DC-IN. And if you just use a 2.5" disk I fail to understand why you use the 12V/5V DC-DC converter?
BTW: What do you refer to regarding 'board temperature'? Is this PMU or SoC? Anyway: 63.4°C is way too high: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=7937&pid=37527&fromuid=33332
http://linux-sunxi.org/AXP209#Overview
AXP209 integrated over / under voltage (OVP / UVP), over temperature (OTP), overcurrent protection (OCP) circuit. -
What objection do you have to the OV5640?
That's an easy one: I've not seen anyone able to get something out of this camera with more than 640x480 resolution when running Linux (Android seems to be a different story). I've done some research since I thought about using a Banana Pi with this camera module (see here or here for example). But that's not important for the Pine64 since they chose a different module: http://wiki.pine64.org/index.php/Main_Page#Datasheet(we'll see what that means regarding drivers and the ability to use this camera in Linux).
Regarding recent Allwinner SoCs. I did some testing with both H3 and A83T (the former designed for OTT boxes, the latter a typical tablet SoC). Allwinner's kernel implements identical cooling strategies for both (throttling CPU/GPU cores and if that doesn't help shutting down CPU cores). By looking into the available A64 material it seems the same strategy applies to the A64. And the A83T for example isn't able to be clocked above 1.2 GHz without active cooling (or using the tablet's backcover as large heatsink). When reviewing the 'Banana Pi M3' I had to learn that using micro USB there is really crap since the board might easily draw 5V/3A current which is simply impossible when powering the board without a real DC-IN solution.
Apart from that: There are so many undervoltage/undercurrent problems associated with using micro USB for DC-IN (and the people aren't aware that 'not enough current' isn't the problem but voltage drops occuring under higher load) that I will not buy any device again that uses this crappy connector to be powered with.
We'll have to see how A64/AXP803 on the Pine64 behave. I would suspect that under full load with a connected USB disk spinning up the usual symptoms occur when choosing micro USB: Sudden power-off due to undervoltage.
-
It would be similar to the diet pi vm which autoboots into the qemu (I think) for the Raspberry Pi
Why should this image emulate a Raspberry Pi? It's a minimal x64 Jessie install containing the whole bunch of scripts that make DietPi somewhat special.
-
Either you start a fresh topic with your favorite image-name or continue with that one.
Better create new threads every day. Like @sinovoip does: This account floods the forums with outdated/useless crap he/she found somewhere else on the net just to let threads that contain criticism disappear...
This is the only way others could learn that there's something wrong with R1/M2/M3 and that people stop buying this unsupported hardware. And only if that happens Foxconn/SinoVoip would change their priorities.
-
I would try to push them, but I see you and a few other members trying to do that as well on their website, but it didn't seem to do anything. You guys have more credibility and more knowledge than I do, so I figured that it would be pointless for me to complain.
If users don't start to complain again and again publicly nothing will change. Foxconn/SinoVoip will happily advertise false features (they've no problems to spread lies as long as people are tricked into believing them and buy their hardware) and trust in the community to fix their mistakes over time.
The only useable OS distributions for everything they shipped after the M1 (Lamobo R1, Banana Pi M2 and now Banana Pi M3) are not provided by them but by community members. And since they're no team players and do not only refuse to cooperate but actively hold back necessary informations regarding their hardware again and again this has to stop. They know for example Armbian is the only OS image that really works on the M2 and the best Debian based for the M1(+) and R1. And what do they do? Instead of donating to the Armbian project they produce a shitty Armbian rip-off for the M3 to damage Armbian's image.
But since none of their customers really complains their business model (selling incompatible crap as 'Banana Pi') works perfectly.
Quick review of Orange Pi PC
in Reviews, Tutorials, Hardware hacks
Posted
Another update: Yesterday two new cheap H3 based Orange Pis were announced:
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=895
Both are smaller and are equipped with 512 MB RAM, CSI camera connector, 40 GPIO pins in the usual RPi style, TF card slot, HDMI and micro USB OTG port (DC-IN through the usual 1.7/4.1mm barrel plug)
Orange Pi One: One USB host port and 10/100 MB/s Ethernet for $10
Orange Pi Lite: no Ethernet but Wi-Fi (maybe again using the RTL8189ETV accessed through SDIO?) and two USB host ports for $12.
With the PCB layout only small heatsinks might fit on the H3 but fortunately we now know that it's matter of dvfs/thermal settings to prevent the H3 from overheating.