Does anyone have experience with the PINE64 SBCs?

pine64.org/?page_id=46823

They seem to offer Gigabit Ethernet compared to the Raspberry Pi3 or is this purely theoretical? I also note FreeBSD support in 12.0-CURRENT.

@cynicalsecurity I have a pinebook at home.

afaik, the pine64 does do gige link, and can even get into 300-400Mbps range. I don't know if it can do higher.

@phessler does it mean it does OpenBSD? :) I notice on the forum they say HardenedBSD is available for the PINE64-LTS (Is it true @lattera ? I thought HardenedBSD was amd64-only).

I am working hard on removing my machines from hosting because $$ and setting up an el-cheapo hosting at home on ARM-based machines.

My biggest load is e-mail to my private domains and the PoC||GTFO mirror..

@cynicalsecurity @lattera yes, I have on the pinebook. the biggest problem is getting a functional u-boot, especially since not enough of it has been upstreamed :/.

pine64 itself is in u-boot and in openbsd.

@phessler @lattera not sure what that means about u-boot but I'd be happy to learn :) Where can I document myself?

@cynicalsecurity @lattera linux-sunxi.org/Pine64 is a decent start to it. linux-sunxi.org/Mainline_U-boo has some background information, but is more useful for 32bit arm machines.
the u-boot patches for the pinebook are spread over too many places for me to quickly find now :/.

@phessler @lattera Oh, OK, so I should not assume this is as trivial as burning an image on to a microSD card… I am trying to decide what to do in the sense that the Pi 3 with Raspbian is a nice toy but for my servers I would prefer *BSD.

My plan is to use the WD external disk for Raspberry Pi 3 (or the PINE64 eMMC) for server stuff but if it is a nightmare then perhaps not.

@cynicalsecurity @lattera for pine64, just burn to a card. pinebook requires building shit, then burning to a specific set of blocks on the card :)

@lattera @cynicalsecurity I'm not sure if we can use the emmc on the pine64 yet or not; the twisty maze of devices is hard to figure out.

worst case, boot off of a uSD, then have the disk for everything else.

@phessler @lattera USB disk, I assume, as I don't see a SATA connector (like the Raspberry).

@cynicalsecurity

I did not get to the point of digging into OpenBSD (beyond occasionally polling @phessler over beers re: ARM64) support, but the ODROID-C2 might be a better choice than raspi3 for your intended purposes.

other ODROID boards have a mix of big.LITTLE endian ARM cores and it is unsurprisingly an inefficient mess.

hardkernel.com/main/products/p

@aag @phessler that is an incredibly useful comment: I was recently digging into the ARM architecture and big.LITTLE sounded like something I really didn't need.

Note that I have nothing against the Raspberry Pi 3, just that I'd like Gbit Ethernet since I am getting Gbit fibre...

@cynicalsecurity @aag i like the concept of BIG.little, but it sounds like a mess to actually implement and use.

@phessler @aag conceptually big.LITTLE is not a bad idea and I can see it being brilliant in servers where you offload network processing to the big-endian cores and run an x86 emulator in the little-endian cores… I have a plan™ ;)

@cynicalsecurity @aag I don't think big.LITTLE refers to the endianness of the cores, but to how fast/power-hungry they are.

How would you even handle mixing endianness of memory(!) or device access?

@phessler @aag oh, that is a lot less sexy then :( I thought it allowed you to mix endianness… but no, it is just boring power…

@cynicalsecurity @aag I certainly want my devices to use less power, but indeed it is a far less tempting prospect than what you were thinking of.

@phessler @cynicalsecurity @aag Yeah, that's exactly what it is - big (fast, power-hungry) and little (small, power-efficient) cores.

Mixed-endian systems do exist, though, but would be completely pointless to intentionally create one, especially given that ARM cores have supported bi-endian operation for ages.

(Let's not talk about how ARM FPA stored things in a middle-endian format, because it never was widely adopted AFAIK.)

@aag @cynicalsecurity @phessler (Generally the only cases I can think of, of where mixed-endianness is used, would be things like a big-endian architecture emulating a little-endian one, or a little-endian architecture interacting with data formats that were designed on big-endian machines?)

@phessler @aag @cynicalsecurity Yeah, network packets were the example of a data format designed on a big-endian machine that I could think of.

But, with ARM, I'm pretty sure you could just switch the core into big-endian mode to handle packets, then back into little-endian, if you really needed to optimize that.

@bhtooefr @phessler @aag I am thinking more of a processor with efficient x86 emulation… you could dedicate certain cores to emulating x86 in little-endian mode, certain cores to networking tasks (see it as a µkernel design where "networking" is a task) in big-endian mode and so on… there is a certain beauty to it.

@phessler @cynicalsecurity yes now I am wondering where I got that crazy idea. I could've sworn the different cores were different endianness -- making the small ones effectively useless.

@aag @phessler @cynicalsecurity I saw discussion about how many (most? all?) of the BIG.little implementations have different size cache lines for big versus little and that means things break horribly.

@kurtm @aag @cynicalsecurity well, different sized cache lines isn't a problem as long as you flush the caches when switching cores.

and don't switch between them *too* often.

@cynicalsecurity @phessler

the C2 has repeatedly been clocked at over 900Mbps w/ iperf (on Linux of course) which means it wipes the floor with raspi 3 on network throughput.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!