[HN Gopher] VoCore - Coin-sized Linux Computer
       ___________________________________________________________________
        
       VoCore - Coin-sized Linux Computer
        
       Author : vinnyglennon
       Score  : 93 points
       Date   : 2023-09-13 12:18 UTC (10 hours ago)
        
 (HTM) web link (vocore.io)
 (TXT) w3m dump (vocore.io)
        
       | MrBuddyCasino wrote:
       | The NanoPi Air can be had with Wifi and BT:
       | https://www.friendlyelec.com/index.php?route=product/product...
        
       | synergy20 wrote:
       | Size looks great, pricing not so. Orange Pi Zero LTS, RPI zero
       | etc might be better. ESP32 also good and cheaper but it does not
       | run Linux well.
        
       | dark-star wrote:
       | This guy is amazing. This started out as a Kickstarter, for
       | something like 25EUR, and for that price point, it was
       | unbeatable. Especially if size was important. Heck, even at the
       | current price point it's not too shabby (if size matters).
       | 
       | And where most other Kickstarters abandon their projects once
       | they released it, moving on to something different, this guy on
       | the other hand still provides updates (new hardware, updated
       | drivers, etc.), to a point where even big companies could really
       | learn from.
       | 
       | Sure, the VoCore might not compete with a fancy ASUS router or
       | FritzBox, but that was never the intended target.
        
       | rbanffy wrote:
       | This is a bit larger but a lot faster.\
       | 
       | https://octavosystems.com/2019/04/12/osd335x-c-sip-dead-bug/
        
       | iancmceachern wrote:
       | The other thing folks haven't mentioned is that things like the
       | esp32 have support from thr Arduino IDE and a bunch of other
       | software stacks that make it way easier, and significantly lower
       | the barrier of entry to use these things for non-professionals.
       | 
       | Professionals choose chips/modules based on an entirely different
       | set of needs/requirements and wouldn't use this module for say, a
       | new embedded product.
       | 
       | It's cool, but kind of sits between 2 niches....
        
       | CameronNemo wrote:
       | Maybe this fits the bill?
       | 
       | https://www.cnx-software.com/2023/06/13/compulab-ucm-imx93-m...
        
         | sudobash1 wrote:
         | That requires a carrier board though.
        
       | swsieber wrote:
       | So, something I've really wanted to do, but don't have the chops
       | for is this:
       | 
       | Make a small dongle that plugs into an ethernet jack and sets up
       | an wifi access point that is run over a VPN. e.g. I could give
       | one to my friend and any device they connect would connect to my
       | VPN.
       | 
       | a) Is that possible?
       | 
       | b) Would that get around Nintendo Switch NAT issues?
       | 
       | The last time this chip came up I got the idea, but I'm not sure
       | how doable it is.
       | 
       | Edit: I forgot that a stretch goal would be to change the setup.
       | You could have the VoCore connect to a wifi network, and then
       | plug the USB side into a device (nintendo switch doc or computer)
       | to emulate a USB ethernet adapter, but of course send the traffic
       | over wifi through the VPN.
        
         | axytol wrote:
         | I've been doing just that with a Raspberry Pi Zero W and a USB
         | ethernet adapter. The eth adapter is set to dhcp, and the wifi
         | sets a hotspot. The wireguard adapter is routed/from to wifi
         | with firewall rules. I even tested the Pi plugged to a
         | powerbank and it still works.
        
         | yjftsjthsd-h wrote:
         | I dunno about a dongle, but yes that's fundamentally reasonable
         | sounding. I would do it by taking a Raspberry Pi equivalent and
         | setting it up with automatic Ethernet configuration, wireguard
         | for the VPN, and hostapd+dnsmasq for the WiFi. I've never
         | actually done the step of bridging the Wi-Fi access point to a
         | VPN, but I can't imagine that it's terribly hard.
        
         | pdpi wrote:
         | IIRC Facebook used to provide a small wifi router that you'd
         | plug into your home network and it would connect itself to the
         | office VPN, then just provided office wifi at home. Sounds
         | fairly similar to what you're suggesting.
        
         | peddling-brink wrote:
         | Sounds like you are looking for a travel router. GLinet makes
         | some good ones. I have one of these: https://a.co/d/gbWTmjS I
         | use it to connect to hotel WiFi then provide its own WiFi (or
         | Ethernet) connection to my devices. It can connect to vpn to
         | route the traffic like you mention.
         | 
         | Edit: I should also mention that it's very doable to DIY this
         | using OpenWRT, and some compatible SBC that has WiFi and
         | Ethernet.
         | 
         | You don't want something crazy underpowered like VoCore for
         | this.
        
           | swsieber wrote:
           | Hmm... that's a reasonably priced prepackaged solution.
           | Thanks for pointing that out.
           | 
           | I am tempted to still use VoCore since it appears to run
           | OpenWRT out of the box and I'm really only aiming to support
           | a single device. Hmm..
        
             | luma wrote:
             | Your challenge will be throughput, without hardware
             | acceleration every packet needs to be handled by the CPU
             | and you're going to pretty quickly bump up against
             | throughput limits. Travel routers will generally offer
             | hardware acceleration and have everything ready to go in
             | one package, so great news - the thing you're looking for
             | exists today!
        
             | sisk wrote:
             | Many of the gl.inet routers can run vanilla OpenWRT out of
             | the box--the linked router above (Beryl) included[1]. Be
             | mindful that not every one of their routers can as some run
             | unsupported chipsets that require a custom build, but many
             | do. Can always check for support on the OpenWRT page for
             | gl.inet routers[2].
             | 
             | Just here to second the recommendation. I'm in no way
             | affiliated, I've just happily used several generations of
             | their routers for this exact purpose.
             | 
             | EDIT: Wanted to point out that their newest and most
             | powerful travel router with (upcoming--in the latest v23
             | release candidate[3]) support from mainline OpenWRT is the
             | Beryl AX (GL-MT3000)[4].
             | 
             | [1]: https://openwrt.org/toh/gl.inet/gl-mt1300_v1
             | 
             | [2]: https://openwrt.org/toh/hwdata/gl.inet/start
             | 
             | [3]: https://firmware-
             | selector.openwrt.org/?version=23.05.0-rc3&t...
             | 
             | [4]: https://www.gl-inet.com/products/gl-mt3000/
        
         | shrubble wrote:
         | The ESP32 chips have the ability to drive both Ethernet and
         | Wifi. There is some onboard hardware accelerated encryption
         | also. So in that case you could make the physical device easily
         | enough. VPN can often do proxy-arp so that the NAT issue would
         | not appear. Whether it would give you enough performance,
         | unknown.
        
           | swsieber wrote:
           | Thank you!! I hadn't hear of proxy-arp, but it seems like
           | from cursory google searches that reading up on it will lead
           | me down a promising path.
        
         | swsieber wrote:
         | For those wanting to do similar things, I found
         | https://www.thinq.ai/RPi_Ethernet_USB_OpenWRT.html to be a
         | pretty good page on how to do usb over ethernet in both
         | directions with open wrt, which was a big chunk of the mystery
         | for me.
        
         | mschuster91 wrote:
         | > b) Would that get around Nintendo Switch NAT issues?
         | 
         | Depends on the game. Animal Crossing is particularly bad in
         | that regard - say you have two kids and they want to be able to
         | play with one remote friend each as the host, it's _impossible_
         | : it will not work without the hosting Switch being completely
         | exposed to the Internet, and there can only be one "catch all"
         | device configured on your router at the same time.
         | 
         | I get that Nintendo doesn't wish to run a STUN/TURN setup but
         | JFC, that's penny pinching on the wrong end.
        
           | swsieber wrote:
           | Interesting. I did not know that about Animal Crossing. It
           | sounds like that's because the last person is remote? I'd
           | ideally be trying to resolve that quirk by using VPN (plus
           | proxy-arp?) to put all the switches on the same VPN despite
           | being geographically distant.
        
           | Tijdreiziger wrote:
           | Doesn't it have UPnP?
        
         | numpad0 wrote:
         | A USB powered Linux device with a USB-Ethernet gadget driver
         | and Wi-Fi hardware should be possible, but that can't be
         | powered by a power-over-laptop-Ethernet-jack if that's what
         | you're after; Ethernet is either isolated or well filtered and
         | can't provide current.
        
           | swsieber wrote:
           | Oh that's a bummer about the isolated or filtered. Thanks for
           | the heads up!
        
       | oneplane wrote:
       | This has been reposted many times over the last ~10 years:
       | https://hn.algolia.com/?q=vocore
       | 
       | While it's not useless, it's also so underpowered, you might as
       | well stick to the ESP32 family. MIPS 24k is not great, even if
       | you run the smallest linux distro ever. It's essentially WRT54G
       | tech from 2002.
       | 
       | As with all hardware like this, it's the ecosystem that makes or
       | breaks it, not the product on its own. That said, it's survived
       | this long so it must be a good fit for some people out there.
        
         | dragontamer wrote:
         | Linux is still Linux though.
         | 
         | Having the proper Linux full-sized TCP stack, however slow it
         | is, is probably more robust in more corner-cases (and possibly
         | has more features, like TCP_CORK, that could lead to better
         | performance anyway).
         | 
         | Honestly? I think a microcomputer of 1980s or 1990s level is
         | still important for hobbyists. Rasp. Pi is taking the bulk of
         | it but Rasp. Pi still uses too much power for a lot of tasks
         | IMO.
         | 
         | BeagleBone is good to play with in my experience (1/2 the power
         | usage of Rasp. Pi, and more realtime features like PRUs or even
         | Cortex M4 cores on the more recent ones). So that actually
         | matches my use cases more.
         | 
         | But finding even smaller chips that are proper full sized
         | microprocessors, with a proper application environment / user-
         | mode and applications is still intriguing to me.
         | 
         | ----------
         | 
         | You're right. This is very similar to ESP32 on a specs
         | perspective. But... "Proper Linux" is a huge difference and
         | well worth the... what? $15 difference?
        
           | helpfulContrib wrote:
           | Think scales of magnitude. For a one-/few- off project, okay,
           | you might not notice the difference of a hundred bucks.
           | 
           | But if you do things at scale, every single penny counts.
           | Yes, penny.
           | 
           | And one thing about the embedded Linux aspect - yes, this is
           | a path for Linux hackers to get into embedded, and perfectly
           | valid.
           | 
           | BUT. ESP32 _also_ has many things going for it. Other
           | operating systems, for example, equally fun and friendly to
           | code for, as Linux. FreeRTOS is fun. So many other things,
           | too .. endless great bits of community software components
           | that can be picked and placed into your project, which will
           | absolutely allow you to build a great product.
           | 
           | The point is, if you can do Linux, you can do the ESP32
           | ecosystem too.
           | 
           | They are approximately relevant to each other.
           | 
           | Disclaimer: I have done multiple projects in both realms, for
           | many, many years (minix-list) and am quite comfortable with
           | the cyclomatic complexity of writing code for either Linux or
           | ESP32. They are, to me, flat. YMMV.
        
             | dragontamer wrote:
             | Hobbyists and even professionals are looking at 1000 SKUs
             | to maybe 10,000 SKU projects.
             | 
             | Knowing how to code and design at the 10,000 unit level is
             | important. At this level, paying $3 per oscillator module
             | for 2% higher reliability is more important than paying for
             | a $0.50 XTAL and trying to save $2.50 per SKU.
             | 
             | Because the bulk of the costs are development, and because
             | you are likely building a reputation as an elite artisan
             | selling highly custom goods for a niche audience.
             | 
             | The $20,000 difference of a $2.50 module with slightly
             | better reliability is absolutely the right choice to make.
        
               | helpfulContrib wrote:
               | Higher reliability? Sorry, that is a fallacy .. you're
               | not paying for reliability at scale in either the ESP32
               | or Embedded Linux scales.
               | 
               | You're paying for what functionality you can attain.. in
               | the ESP32 case, its mighty limited - but as all embedded
               | devs know, challenge accepted - and in the Linux case its
               | mighty complex/hefty and you have to pay to play, in the
               | BOM costs anyway ..
               | 
               | Either way, the 'reliability' factor is misguided, in my
               | opinion. This is not at all why you choose either path.
               | 
               | Both platforms are functionally equivalent. The only
               | difference is capacity.
        
               | dragontamer wrote:
               | > At this level, paying $3 per oscillator module for 2%
               | higher reliability is more important than paying for a
               | $0.50 XTAL and trying to save $2.50 per SKU.
               | 
               | I'm talking about oscillators and XTALs in this sentence.
               | Not about Linux.
               | 
               | Anyone making relatively small run items (10,000 or less
               | SKUs) knows what I'm talking about. Saving every penny is
               | counterproductive at this level of production. The main
               | goal is to cut development costs actually.
               | 
               | $2 more on the BOM? Whatever, did that save $10,000 on
               | tooling and software? Definitely worth it. I'm bringing
               | up oscillators and XTALs because XTAL is notoriously
               | difficult to debug with standard lab tools. Its a
               | physical device that changes with just 2pf and might only
               | be running a few microwatts, so you need very low
               | capacitance test equipment to directly debug XTAL issues.
               | 
               | Different tools and methodologies exist at different
               | levels of production. That's all I'm saying. You do _NOT_
               | pinch every penny at this level, you just buy the more
               | reliable Oscillator-module and avoid XTAL testing all
               | together (saving a ton of money on development tools and
               | development time).
        
           | LeifCarrotson wrote:
           | > But finding even smaller chips that are proper full sized
           | microprocessors, with a proper application environment /
           | user-mode and applications is still intriguing to me.
           | 
           | For what use cases, though?
           | 
           | I find having a full Linux stack with all its complexity
           | introduces a lot more corner cases to test, while something
           | like lwIP [1] if you need TCP and an 'application' running
           | under either FreeRTOS or similar, the timer tick ISR, or a
           | bare while(1) loop can be enormously less complicated, more
           | reliable, and enormously smaller/lower power.
           | 
           | It's possible to solve a lot of problems with literally 6
           | orders of magnitude less RAM, and about that much reduction
           | in power usage/increase in battery life.
           | 
           | I get that overkill is underrated, if you can throw $50 at a
           | problem or $20 and make it easier to use than a $2
           | microcontroller that doesn't really matter if you place any
           | value on your time, but it's just wasteful.
           | 
           | [1]: https://www.nongnu.org/lwip/2_1_x/index.html
        
             | dragontamer wrote:
             | Anything where your users could build a codebase of their
             | own and extend your functionality.
             | 
             | Sure, maybe you create a JavaScript system inside of some
             | ESP32 interpreter and allow code extensions.
             | 
             | But is it really easier than saying: I got a mkfifo and
             | daemon in this device at /custom/LEDs that controls the
             | color output of my doohickey?
        
               | janoc wrote:
               | You certainly aren't going to run any Javascript on an
               | ancient 580 MHz MIPS CPU with 128MB of RAM.
               | 
               | So that is a completely bogus argument.
        
               | rkeene2 wrote:
               | That's significantly more powerful than workstations I
               | used for a long time, where I ran Linux, Solaris, HP-UX,
               | DOS, OS/2, and Windows.
               | 
               | Excluding really small machines that didn't do well with
               | multitasking, I used a 486 DX2 50MHz with 8MiB of RAM
               | (this was a Packard-Bell) to my day-to-day work until
               | around 2002, this includes running browsers that
               | supported JavaScript. It could even decode and play MP3s
               | if that's the only thing it was dedicated to doing.
               | 
               | After that I upgraded to an HP Visualize C3000 (400MHz,
               | 512MiB RAM) desktop running HP-UX and an HP Pavilion 6350
               | (475MHz, 128MiB RAM) laptop running Linux. Both of these
               | supported a GUI much better than the 50MHz, and also
               | could run more intensive JavaScript workloads.
               | 
               | I have a few screenshots [0] from the HP Pavilion, you
               | can see it's running several browsers and decoding an MP3
               | at the same time.
               | 
               | [0] https://rkeene.org/personal/screenshot/Image_fvwm2-06
               | Jul02-3...
        
               | helf wrote:
               | [dead]
        
               | dragontamer wrote:
               | I've literally run Javascript on smaller processors than
               | that on college projects. Smaller scale Javascript
               | (probably not the latest DOM or EMCAscript), but... yeah.
               | Its not actually that large of a language. Especially
               | older versions. It helps that I did this back in 2008 as
               | part of my college education when processors were smaller
               | (and Javascript was smaller), but Javascript goes back to
               | the early 90s in practice. There's surely some version
               | applicable for this use case.
               | 
               | You know that OSes and extendable, multi-process systems
               | were around in the 80s right? On 640kB of RAM and 20MHz
               | processors right?
               | 
               | -----------
               | 
               | Anyway, my point is that code-extensibility is absolutely
               | a thing. Some devices do deserve 3rd party code. I admit,
               | none of my projects right now, though I'm hobby level.
               | But I can _imagine_ a use of a standard OS with
               | extendable 3rd party code modules where an API with the
               | hardware would be helpful.
               | 
               | If you wanna implement Forth, VxWorks, custom Javascript
               | or whatever... there's plenty of valid solutions. But you
               | know what else is a perfectly fine, and probably the
               | easiest, solution?
               | 
               | Straight Linux.
               | 
               | Maybe FreeDOS or Dr. DOS as well.
        
           | janoc wrote:
           | "But... "Proper Linux" is a huge difference and well worth
           | the... "
           | 
           | Proper Linux is only worth the difference if you can actually
           | fit the OS and your application in the available RAM (good
           | luck) and the part has mainstream kernel support and
           | available documentation. Otherwise you are buying into a
           | literally throwaway platform that will become a useless piece
           | of e-junk the moment the vendor stops updating their copy of
           | Linux with patched in various binary blobs necessary to make
           | the thing work.
           | 
           | The VoCore website only links to binaries, no source code
           | (only some patch files) for their kernels and OpenWRT builds
           | (GPL?), the wifi driver Github has "This feed enable using
           | MTK/Ralink official wifi driver for the latest linux kernel
           | 4.14/openwrt." in the description - current mainline is at
           | 6.5.3 ...
           | 
           | Their OpenWRT binaries are also ancient - the latest they
           | offer for download is 19.07.03 which is 3 years old. Not
           | great, given what this is meant to be used for. I guess
           | security is not high on their priority list.
           | 
           | Also the amount of chinglish on the website ("note: normally,
           | we upgrade or fix brick are using Firmware. Flash Image is a
           | clone of the full flash, for professional usage only. ")
           | doesn't exactly bode well for good quality English
           | documentation availability.
           | 
           | Ship an ancient, outdated Linux or Android image, no or
           | incomplete sources, poor or no English documentation - and
           | good luck to anyone trying to make such board work.
           | 
           | The hardware could be the best in the world - but this poor
           | ecosystem support is the bane of most Chinese SBC and the
           | reason why almost everyone uses Raspberry Pi, despite it
           | certainly not being neither the cheapest, most powerful or
           | having lowest power consumption.
        
             | duozerk wrote:
             | Mostly I agree but mind you:
             | 
             | > Proper Linux is only worth the difference if you can
             | actually fit the OS and your application in the available
             | RAM (good luck)
             | 
             | This says it has 128MB RAM. This is _more_ than sufficient
             | to run the very latest Linux and several useful
             | applications. You just can 't install systemd.
        
             | dragontamer wrote:
             | I literally ran a Linux VPS for years on 256MB of RAM.
             | 
             | 128MB is plenty. Throw down Busybox and cut some corners,
             | run uClib rather than glibc, etc. etc. You'll be surprised
             | what fits in there.
             | 
             | My 256MB Linux VPS was Apache + Bash, full scale Linux.
             | There's plenty of room there. 128MB is small for a
             | "mainstream" Linux / Ubuntu install, but 128MB isn't even
             | "Linux from Scratch" levels of size.
             | 
             | Linux from Scratch is probably like 32MB or so RAM needed.
             | And that's still "kit" Linux (IE: a prebaked "kit" where
             | the OSS community already made a bunch of optimizations for
             | you, but no application-specific optimization decisions
             | yet), not even going into difficult levels of optimization
             | yet.
             | 
             | > The hardware could be the best in the world - but this
             | poor ecosystem support is the bane of most Chinese SBC and
             | the reason why almost everyone uses Raspberry Pi, despite
             | it certainly not being neither the cheapest, most powerful
             | or having lowest power consumption.
             | 
             | EDIT: I think you have a fine point on this front. I know
             | that MIPS chips are still available from some manufacturers
             | (like Microchip's PIC-line), and I think they're Linux
             | compatible. That might be a better way to go. But this
             | ~128MB "sized" Linux instance seems perfectly usable to me.
             | Good softare/Linux support would be preferred of course.
        
             | sitzkrieg wrote:
             | i replaced a 200 mhz 512k ram mips mpu with one of these
             | same chips to great effect and at reduced cost.
             | 
             | thinking everyone uses raspberry pis (while mostly true in
             | hobby) ignores a very large segment of very real and very
             | active embedded dev getting to the point MPUs are at cost
             | in design bumps etc
        
         | password4321 wrote:
         | Specifically https://news.ycombinator.com/item?id=31395379 1.5
         | years ago with 68 comments.
         | 
         | > _performance lower than a Pi 1_
        
           | Narishma wrote:
           | Physical size and power requirements are also lower than a Pi
           | 1.
        
       | 1-6 wrote:
       | At this point, the interfaces are larger than the compute unit.
        
         | dragontamer wrote:
         | The thing that pisses me off at this level is how much power
         | interfaces draw.
         | 
         | The chip here probably draws 50mA.
         | 
         | The WiFi draws 200mA, while wired Ethernet probably draws like
         | 100mA.
         | 
         | There are specifically low powered communications like
         | Bluetooth, ZigBee, or the new SPE Ethernet standards. But they
         | are niche and more expensive to work with.
         | 
         | So you're pretty much paying for lower power (and lower
         | performance) on a rather consistent basis.
        
       ___________________________________________________________________
       (page generated 2023-09-13 23:01 UTC)