Live data from Hacker News

ODROID-C1 – Quad Core ARM Linux computer

hardkernel.com

71–80 of 84 posts

Re: ODROID-C1 – Quad Core ARM Linux computer

#71
post #26

Earlier quoted context omitted.

and a 3D hardware acceleration... this thing is so cool. For $35 you can get a really decent computer. Makes it really viable for people to run a small unix dev machine or buy a bunch of these to run a miniature server farm.

I'm thinking of upgrading my Pi cluster ( http://github.com/rcarmo/raspi-cluster ) to a set of these boards. Mostly waiting for some benchmarks to come in and the holiday season to go away...

Check out page 15 of their Odroid magazine December issue [1]. It has a few Odroid-C1 vs Raspberry Pi B+ benchmarks.

[1]: http://magazine.odroid.com/assets/201412/pdf/ODROID-Magazine...

Re: ODROID-C1 – Quad Core ARM Linux computer

#72

Anybody make something similar with dual ethernet? I'd like to replace my aging Alix-based home router/vpn ( http://www.pcengines.ch/alix2d3.htm ) with something like this.

If 100M is enough for you, I'm developing a new board with 2 RJ45 for industrial ethernet, which has a 40 pin connector compatible to that of RPi B+, but the circuit is adapted from beaglebone black. It's scheduled for end of January 2015.

https://docs.google.com/document/d/1X9RrbkUpiTQ-S6Acken-5fv7...

Re: ODROID-C1 – Quad Core ARM Linux computer

#73
post #68
post #56

Earlier quoted context omitted.

You had a 150MB/s hard drive 5 years ago? What kind of a drive was that? I'm only getting 100-150MB/sec on rotating media today. Only 7.2K, but even 5 years ago, 10K didn't deliver that transfer speed from what I remember.

For example 1TB Samsung drives delivered 100 MB/s over 5 years ago. Most 3.5" disks delivered as much.

I was surprised by that, though I shouldn't have been:

I'm getting about 100MB/sec from 3.5" Samsungs, WDs and Seagates today - but you're right according to these 4 year old benchmarks: http://www.storagereview.com/western_digital_caviar_blue_1tb...

I guess the configuration I'm benchmarking with, and the type of load, which is basically streaming, but from a journaled-but-otherwise-standard ext4, slows me down a little. But the convenience and standardness of this setup is worth more to me than a factor of 2 in performance (that's not my bottleneck at the moment).

Re: ODROID-C1 – Quad Core ARM Linux computer

#74
post #63

This looks pretty cool. How well documented is its GPU? The Raspberry Pi folks managed to pry documentation out of Broadcom http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A... , with an FFT example included in the standard distro https://github.com/raspberrypi/userland/blob/master/host_app... , resulting in porting the Deep Belief image-recognition SDK to that GPU http://www.raspberrypi.org/more-qpu-magic…

A bit of link chasing lead me to http://petewarden.com/2014/08/07/how-to-optimize-raspberry-p... which opens with this extraordinary sentence:

"When I was at Apple, I spent five years trying to get source-code access to the Nvidia and ATI graphics drivers"

That's at one of the richest development partners in the world. The secrecy is crippling.

Re: ODROID-C1 – Quad Core ARM Linux computer

#75
post #43

Earlier quoted context omitted.

I've never dealt with an ARM core that needed some magic object-only blob to boot. They're almost all using Denx U-Boot. If the GPU needs an object loaded to boot, like the RPi, that's another story. But a decent SoC should be able to start without the GPU getting in the way.

IIRC, for the Raspberry Pi, the GPU controls the CPU (or, at least, it boots first), which makes the blob necessary.

Correct. But this is just the first stage bootloader; the GPU boot ROM loads a second stage loader from the SD card, which then loads the kernel and launches the ARM straight into it. None of this is encrypted or signed as is usual on Android devices.

http://raspberrypi.stackexchange.com/questions/10489/how-doe...

Re: ODROID-C1 – Quad Core ARM Linux computer

#77
post #66

Earlier quoted context omitted.

Really? Thanks for the warning. I avoid Broadcom parts anyway but that's just messed up.

While your avoidance is understandable, given Broadcom's thoroughly disreputable history with regard to free software, it's not justified in this case. The Pi GPU is apparently fully enough documented that you can write your own software for it.

I could care less about the state of the GPU driver source and the typical complaints of RPi developers. Open, closed, whatever.

I'm more skeptical of a SoC architecture that has the CPU dependent on the GPU for its startup sequence. Or is this a matter of the GPU controlling the ARM's clock tree?

Re: ODROID-C1 – Quad Core ARM Linux computer

#78

Anybody make something similar with dual ethernet? I'd like to replace my aging Alix-based home router/vpn ( http://www.pcengines.ch/alix2d3.htm ) with something like this.

If 100M is enough for you, I'm developing a new board with 2 RJ45 for industrial ethernet, which has a 40 pin connector compatible to that of RPi B+, but the circuit is adapted from beaglebone black. It's scheduled for end of January 2015. https://docs.google.com/document/d/1X9RrbkUpiTQ-S6Acken-5fv7...

I'm very interested in your board as it would probably make for a great *BSD firewall, do you have any contacts? as I cannot find any on that page.

Re: ODROID-C1 – Quad Core ARM Linux computer

#79
post #64

Earlier quoted context omitted.

Yes, it does. SD cards are not really designed for being used as a root file system. They are OK at streaming writes and reads, but once you start getting non sequential they slow down like you wouldn't believe. Which, yes, I know, is super weird for what should just be some glue logic around a NAND. I was investigating corruption and performance problems with our root filesystem on an SD card. The cards would be gre…

Most SD and μSD cards have embedded microcontrollers http://www.bunniestudios.com/blog/?p=3554 — I wonder how much of the corrupted-sector problems you were getting are really just bugs in their firmware? Or things that could be worked around with better firmware?

Yeah, it was almost certainly firmware bugs combined with already marginal NANDs. ie. the NANDs probably would have been fine if they were babysat a little better, but they were probably bottom of the barrel. That's kind of the SD card market in a nut shell any way.

That being said we tried many different SD cards from quality vendors and found pretty heavy bugs and performance related issues among all of the non "industrial" versions.

So, yes, the problems don't have to be intrinsic to the form factor, but empirically you're more likely than not to have issues with them.

Re: ODROID-C1 – Quad Core ARM Linux computer

#80
post #66

Earlier quoted context omitted.

While your avoidance is understandable, given Broadcom's thoroughly disreputable history with regard to free software, it's not justified in this case. The Pi GPU is apparently fully enough documented that you can write your own software for it.

I could care less about the state of the GPU driver source and the typical complaints of RPi developers. Open, closed, whatever. I'm more skeptical of a SoC architecture that has the CPU dependent on the GPU for its startup sequence. Or is this a matter of the GPU controlling the ARM's clock tree?

Most "bigger" SoCs have a secondary processor for SoC bringup/boot. (It's not uncommon to see a tiny ARM7 or something in this role). Since Broadcom succeeded in making a particularly general purpose core for their GPU (it seems that the GPU runs a full RTOS written in C), it only makes sense (well, to me at least) that it could take over that role as well to save on the transistor budget.
Post reply on HN