Jump to content

Recommended Posts

Posted

I don't know if this the right place to post this question. I am looking for a board that fits what I need. I have been looking and could not find everything I need in one board. I thought of asking here maybe someone can suggest something. So here are the specifications I am looking for:

1- CPU: has a crypto engine/ Security system. Almost all Allwinner Axx and Hx have crypto engines. 

2-  wireless connectivity Has all or most of the following: WiFi 2.4G, 5GHz and 3G/4G Module if possible.

3- Network connectivity: Has 1000 Mbps Ethernet.

4- USB : At least one A-type USB.

 

Thanks

 

Posted
2 hours ago, mido said:

crypto engine/ Security system

 

Are you aware that Allwinner's crypto engine is nothing you want to use? Did you already have a look at ARMv8 crypto extensions (almost all 64-bit ARM SoCs support with two known exceptions: the Broadcom thing in the Raspberries and Amlogic S905 on ODROID-C2)?

 

WiFi can be USB or PCIe attached, with 3G/4G it's always USB2 even if the modules fit into a mPCIe slot. Onboard WiFi is usually crap since limited to 2.4GHz and if 5GHz is possible limited to a single antenna.

 

So you better explain your use case first and other constraints (e.g. space) to get any reasonable advise...

Posted

Thanks a lot for your reply.

I am trying to find something that is small, in the size of 90mmx13mm at max. I could not find any boards that have LTE support. 

Posted
6 hours ago, mido said:

I could not find any boards that have LTE support. 


I am not sure if it exists, but it would be cool. There are some older boards which are ready that you can plug in LTE mPCI modem - Clearfog and Hummingboard ...  none is small. There is also an Orange 4G IOT but with questionable software support.

@Stanislav Sinyagin https://txlab.wordpress.com/ is playing with 3G/4G connectivity and had a similar wish some time ago. Perhaps he  made some progress?

Posted
7 hours ago, mido said:

I could not find any boards that have LTE support.

 

Every board has LTE support since all available external modems are USB based. Even if they appear as mPCIe card. They always rely on USB2 signals present on pins 36 and 38 of the mPCIe connector. On some boards the mPCIe slot is not standards compliant (eg. Banana Pi R2, there the board maker 'forgot' to route USB2 to the mPCI connector) and also some mPCIe cards are not standards compliant (Sierra Wireless MC74 for example uses a proprietary USB3 pin out).

 

Since all mPCIe modems are USB based these things here work. But they always rely on an USB connection to the mPCIe slot. So simply save a lot of money and use an LTE USB dongle directly.

 

If you're fine using an Android phone without phone enclosure and display then Orange Pi 4G-IoT might be something for you...

Posted

Thanks for your replies.

 

Essentially, am trying to build a travel router. So the crypto engine shall be indeed usable with OpenVPN & Snort for example. What boards are there with usable crypto engines then? 

 

Regarding the 3g/4g/lte thing, I was advised to just forget about it and use a usb modem for that since it differs from a region to the other (bandwidth restrictions). So we can put that aside. 

 

What is hard to find is a board that has 

- 1 usb  port (for usb modem)

- crypto engine

- 1 gb ram 

- Onboard storage emmc or nand

- 1gb Ethernet 

- 2on board wifi modules - or 1 and 1 extra usb (for usb wifi) 

- PMU (for battery management) (and charge port)

- On/OFF power switch 

- very small board 90mmx13mm at max 

- Cost should be under 30usd 

 

 

Posted
11 hours ago, mido said:

PMU (for battery management) (and charge port)


Guess which is the only Allwinner A64 board around where engineers 'forgot' to include charging capabilities? The one that is on sale of course ;) 

 

11 hours ago, mido said:

What boards are there with usable crypto engines then?

 

All 64-bit SoCs that support ARMv8 Crypto Extensions (this is something different than SoC vendor proprietary 'crypto engines'). So every Cortex-A53 or A72 (except Raspberry Pi, ODROID-C2 and NanoPi K2): https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829

 

Posted
2 hours ago, guidol said:

 

A micro-USB powered board sounds like a bad idea when you have 2x wifi + 4g modem... 

 

14 hours ago, mido said:

- very small board 90mmx13mm at max 

I guess that won't be possible... 

 

14 hours ago, mido said:

- Cost should be under 30usd 

sounds also a bit hard with your needs..

 

The only board which somehow comes to my mind is the pine64. But the wifi chip you can buy with it is a RTL8723BS where BS stands for... :lol: 

Posted
3 minutes ago, chwe said:

A micro-USB powered board sounds like a bad idea when you have 2x wifi + 4g modem...  

you can always use Pin 2 or 4 for 5V and Pin 6 for GND ;)

Posted
1 minute ago, guidol said:

you can always use Pin 2 or 4 for 5V and Pin 6 for GND ;)

or, you go for a pine64 where you can use a barrel plug for 5V powering or the battery connector for a (hopefully) proper powering with a battery (can't say cause I never used it). ;) 

 

IMO pine64 boards sounds like a good idea for everything which has to be UPS capable (never realized that before, the first time I'm interested in pines AW boards, these guys actually have a nice product spectrum).

Posted
1 hour ago, chwe said:

A micro-USB powered board sounds like a bad idea when you have 2x wifi + 4g modem... 

 

All FriendlyELEC boards have a 4-pin header for serial console and to be powered with. But as already mentioned their A64 board is the only one around with this SoC not able to deal with batteries since lacking connector/circuitry (ok, the other exception is BPi-M64 with the super sophisticated battery connector you can attach nothing too). IMO battery support is the only reason to look at A64 at all.

 

1 hour ago, chwe said:

the wifi chip you can buy with it is a RTL8723BS where BS stands for...

 

Nope, I don't agree. RTL8723 is the same as any of those other '2.4 GHz 1T1R' Wi-Fi thingies. They all perform more or less the same and environmental conditions (count of 'adversary' wireless networks around) matters more than anything else. I referenced the relevant thread already.

 

If it's about battery support in the past I always chose Olimex since they sell matching batteries on their own (for which the relevant parameters were available). Just came accross this here so maybe situation with Pine64 has improved in the meantime (only remember some weird discussions over in their forum long time ago).

Posted (edited)
9 hours ago, tkaiser said:

Would be interesting to see 'iwconfig' output...

Sorry, moved to the wifi thread..

wifi.png

Edited by @lex
moved to wifi thread
Posted

Thanks all, that was a very helpful discussion. I got the Pine64 and I am trying to use it. However, it has only two USB ports and I need at least 3 ports. Is there a way I can add a USB port on the Pi-2 Or Euler Buses on the board?

Posted
5 hours ago, mido said:

Pine64 ... Is there a way I can add a USB port on the Pi-2 Or Euler Buses on the board?

 

Of course not. The A64 SoC is pretty limited wrt fast external interfaces (Gigabit Ethernet is the fastest). Only way to add more USB ports is adding an internal USB hub like it's done on BPi M64 (ports having to share bandwidth so not exactly an improvement).

Posted

I need to connect three USB Wifi modules. That is all I need. I tried to find a solution for that but the only one I could think of is to add an extra USB port. It seems this idea will not work.  Is it possible to add a WiFi module on the Pi-2 or Eurler Buses on the board directly? Can we use a USB to UART convert to connect another USB port?

Posted
1 hour ago, tkaiser said:

much better Ampak AP6359S based module should also work with Pine64 and PineH64.

Should.. Did someone ever test this? I was also curious due to 2x2 mimo together with the pine64-LTS seems to be what I look for my UPS capable IoT 'master node' thingie which doesn't need that much CPU power. But the fact that pine wrote 'only for Rock' was a bit annoying. 

Posted
2 hours ago, chwe said:

Did someone ever test this? I was also curious due to 2x2 mimo together with the pine64-LTS

 

No one tested so far since no one ported the driver (this and firmware for Ampak AP6359SA are contained in Rockchip's 4.4 BSP but with Allwinner A64 we still deal with a smelly 3.10 kernel... that's most probably the reason why there's mentioned 'only available for RockPro64')

Posted

So, I already tried to use the WiFi module.  The problem is that I am trying to use openwrt with the board. I did a mix between Armbian and openwrt and used with the board which worked fine, but still can not recognize the WiFi module.  I am trying to make the Armbian the main and openwrt on it instead to see what will happen. 

Posted

both should run mainline (with some limitations) so at least there, a test 'should' be possible. 

 

41 minutes ago, tkaiser said:

Allwinner A64 we still deal with a smelly 3.10 kernel...

The only reason I don't like my Pine64 PSU idea. His board would run in a 'larger' nertwork, guess how happy a network admin will be to have an untrusted device in his network.. :P Since @wtarreau 'decided' to let 3.10 go EOL this doesn't look sane to rely on an EOL kernel for a new project (besides the fact that I don't like BSP kernels that much anymore).

 

4 minutes ago, mido said:

I did a mix between Armbian and openwrt and used with the board which worked fine, but still can not recognize the WiFi module. 

don't sound sane to me.. :P Where do you start to mix things? There are so many possibilities that things can go wrong and support might be a nightmare if you don't describe exactly what you did..

 

2 minutes ago, mido said:
4 hours ago, chwe said:

Why do you need 3 USB wifis? :blink: Is it still the 2x w-lan 1x 3g/4g setup? Then you might go for the SDIO wifi which is possible with the pine64 (https://www.pine64.org/?product=wifi-802-11bgn-bluetooth-4-0-module).

Wait, is it possible to use another WiFi instead the one they sell in their store? I am confused.

For the RockPro64 there's a 2x2 mimo wifi (also from pine folks). which 'could' also work (same 'connector'). But it seems that nobody tested it ever, for 3.10 kernel it would need probably a back-port and mainline might have some other drawbacks (from what I know or better from what I heard from @tkaiser, the pmic doesn't work fully for charging batteries etc.).

 

Is there a reason for openwrt? What does debian/ubuntu miss that you find in openwrt? (not meant offensive, more in a 'maybe we find something similar in debian' manner..)

Posted
27 minutes ago, chwe said:

don't sound sane to me.. :P Where do you start to mix things? There are so many possibilities that things can go wrong and support might be a nightmare if you don't describe exactly what you did..

 

Well, for example, the openwrt current version for pine 64 does not support hdmi. What I did is similar to what is explained in this link
https://gist.github.com/praveenbm5/3c81692e6b2b651bb450fb7fc45dff4d

When I did that, I now can use openwrt on the board and still use the screen instead of the serial console.  Openwrt has a lot of advanced networking packages that I need to use. The point is that I started the software development part before choosing the hardware. Now I am stuck :(

Posted
33 minutes ago, mido said:

Well, for example, the openwrt current version for pine 64 does not support hdmi. What I did is similar to what is explained in this link

Does a 'router like' board need HDMI? Well different people, different opinions on that. Problem is when you start to mix up those things, openwrt may have some needs to for a kernel which 'we' don't care (I'm not really familiar with openWRT). How do you ensure that your device gets regular updates (kernel and userspace side) when you've a combination whit doesn't fit to both distributions? This may need additional work to keep your device updated. For me, such router/network boards should run with a (patched) mainline/vanilla kernel or at least with a kernel which isn't EOL (the only device which doesn't get regular updates in my home is the outdated iPad and the android phone, sony decided that my phone isn't worth to get updates a few months after I bought it :angry:). 

53 minutes ago, mido said:

The point is that I started the software development part before choosing the hardware. Now I am stuck :(

Is your software so close tied to openWRT so that a switch to debian isn't possible? I don't know how the whole kernel-update procedure in openWRT world works to keep your device up to date but IMO it's worth to keep an eye on this (the last time I used a openWRT device is years ago in a time when I didn't care much about it, now my ISP is in charge :rolleyes::rolleyes: but hey, I'm sure they'll do a decent job :lol::lol:).

Posted
50 minutes ago, chwe said:
2 hours ago, mido said:

Well, for example, the openwrt current version for pine 64 does not support hdmi. What I did is similar to what is explained in this link

Does a 'router like' board need HDMI? Well different people, different opinions on that. Problem is when you start to mix up those things, openwrt may have some needs to for a kernel which 'we' don't care (I'm not really familiar with openWRT). How do you ensure that your device gets regular updates (kernel and userspace side) when you've a combination whit doesn't fit to both distributions? This may need additional work to keep your device updated. For me, such router/network boards should run with a (patched) mainline/vanilla kernel or at least with a kernel which isn't EOL (the only device which doesn't get regular updates in my home is the outdated iPad and the android phone, sony decided that my phone isn't worth to get updates a few months after I bought it :angry:). 

I am just giving an example, of how when I mixed them something that did not work is now working. Also, I could find the battery level which was not available when I used pure openwrt. The main kernel is openwrt now, so when I write on the terminal is appears as openwrt. 
And yes, my software is built on openwrt.  Another advantage is that they have the LUCI interface ready which is a GUI of configuring the router. That is a problem. I agree mixing between two different OS is not a good idea. But I will try and see if I did the opposite,

Posted
1 minute ago, mido said:

The main kernel is openwrt now, so when I write on the terminal is appears as openwrt. 

kernelnaming doesn't mean anything.. :lol: Change this one:

https://github.com/armbian/build/blob/2d92ef44ca0d0d8e1ff3d7a344cb85fdd36ff0ca/config/kernel/linux-sunxi-next.config#L34 and you can call your kernel: 4.17.5-super-mega-deadpool :P (not recommended for armbian due to kernel package script won't work properly). That your userspace terminal looks like openWRT looks like is clear (cause you use a openWRT rootfs). If your stuff is tied so close that a change doesn't make sense you might have a look what's needed in openWRT to bring up the stuff which doesn't work (e.g. HDMI). Maybe it's only a kernelconfig issue, maybe a patch is missing (for the 3.10 kernel, you find all our patches here: https://github.com/armbian/build/tree/master/patch/kernel/pine64-default, for the kernelconfig you find this stuff here: https://github.com/armbian/build/blob/master/config/kernel/linux-pine64-default.config). 

Maybe you can implement *needed feature* for openWRT on the pine and send then the patches to their structure to improve openWRT (I've no idea how they organize patches/contributions but for sure they're also grateful for all improvements :) - openWRT is a big 'blackbox' for me in terms of update and contribution). It's not that I don't like openWRT, it's only that I don't understand their processes good enough to give you some guidance but compare kernelconfig and patches to nail down the problem should be possible when you're patient enough (for the same reason I prefer mainline over bsp kernels cause they act more predictable and documentation is often also better).. 

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines