[HN Gopher] Tinker V: Single-board RISC-V computer
___________________________________________________________________
Tinker V: Single-board RISC-V computer
Author : nixcraft
Score : 81 points
Date : 2023-03-20 14:50 UTC (8 hours ago)
(HTM) web link (tinker-board.asus.com)
(TXT) w3m dump (tinker-board.asus.com)
| whitehexagon wrote:
| Did I miss the pricing? I quite fancy the "StarFive's VisionFive
| 2" that was mentioned here a while back (assuming software
| improves a bit), but once again not clear what this new board
| offers in terms of RISC-V extensions/level of support. btw I
| noticed today that Pine64 are also planning a cheap RISC-V board
| maybe next month.
| [deleted]
| CharlesW wrote:
| > _Did I miss the pricing?_
|
| If you follow the "Where to Buy" links for the United States,
| it's available from Amazon for $280.
| microtherion wrote:
| No, that link goes to the Tinker Edge, a board with a
| different CPU and a TPU. As far as I can tell, Amazon does
| not carry the Tinker V at all.
| metaphor wrote:
| Nope...the Amazon page that ASUS redirects to[1] is a
| different SBC[2].
|
| [1] https://www.amazon.com/ASUS-Tinker-1-5GHz-Graphics-
| Motherboa...
|
| [2] https://tinker-board.asus.com/product/tinker-edge-t.html
| whitehexagon wrote:
| Thanks, I only scanned Europe. But anyway that is quite a
| premium over the SV2 at around $70? And I got the impression
| Star64 will also be in that lower price bracket, but lets
| wait and see.
| FullyFunctional wrote:
| It adds a much slower CPU /s
|
| The VisionFive 2 is currently the best RISC-V SBC option, at
| least until TH1520 becomes available (next month?), depending
| on the price.
|
| I can vouch for the VF2 hardware - works well. Alas PCIe is
| oddly slow, but I'm hopeful that firmware will improve that.
|
| EDIT: The Pine Star64 is (should be) the exact same SOC, so it
| should be basically the same as VF2 (small differences like
| PCIe edge connector instead of an M.2 slot, etc).
| whitehexagon wrote:
| Thanks. I saw there is a pine64 EU store now, so fingers
| crossed they will stock it, although a working PCIe would
| also be very nice! I hadn't heard of TH1520 until now, 2.5GHz
| is going to give the Pi4 a better run for it's money.
| brucehoult wrote:
| It looks like they're going to be running the bare chip at
| 1.85 GHz stock. Will probably need to add a heatsink and
| maybe fan to get to the rated 2.5 GHz.
|
| And, yes, with its OoO CPU cores it should match a Pi 4 at
| the same MHz, but do more MHz.
| brucehoult wrote:
| People are getting around 250 MB/s from an SSD on the PCIe
| (M.2) on VisionFive 2. Ok, so you'd ideally like 400 MB/s
| from 1 lane, but it's still 10x better than SD card.
|
| It's probably being limited because the RAM to RAM copy speed
| isn't much more than that! I get 475 MB/s memcpy() speed for
| 64 MB copies on my VisionFive 2. The much slower CPU on the
| AllWinner D1 manages 1100 MB/s n the same code. Somehow the
| SiFive-based SoCs have never been good on RAM speed -- the
| HiFive Unleashed and Unmatched were even worse than this.
|
| Hopefully the Horse Creek SoC has some good Intel DDR IP in
| it.
| FullyFunctional wrote:
| I'm getting ~ 180 MB/s on a Samsung SM8?? which hits around
| 3 GB/s on a desktop. I'm using a 5.1V 3.5A supply so that
| ought not be the issue (but I'll try another PSU now).
|
| Horse Creek would be nice - should it ever become available
| for purchase.
| rektide wrote:
| Pretty cool seeing a RISC-V chip from a longstanding well known
| name in chipmaking, Renesas.
| chunk_waffle wrote:
| Wish the SuperH stuff would have panned out, the open source
| stuff seems to be dead on the vine :(
| rektide wrote:
| Agreed. The j3 & especially j4 cores would have been very
| interesting baselines to compare against. https://j-core.org/
| peoplearepeople wrote:
| The first RISC-V single-board computer.... from ASUS that is
| pinewurst wrote:
| The real title actually says that - HN submitter chose to chop
| there
| dang wrote:
| We've fixed it now. Thanks! (Submitted title was 'Tinker V: The
| first RISC-V single-board computer")
| jerrysievert wrote:
| (from Asus).
|
| there are other SBC's available, like the mango pi mq pro, which
| is in the form factor of a raspberry pi zero.
| Reitet00 wrote:
| Looks nice! Too bad it's not PoE powered. That'd be great for
| simplifying IoT provisioning.
| johnwalkr wrote:
| Would be nice but it's easy to add with an external adapter.
| chunk_waffle wrote:
| > The first RISC-V single-board computer
|
| > from ASUS
|
| The "from ASUS" part is pretty important to that headline IMHO...
| msla wrote:
| Hey, if Apple can be recognized as the inventor of the GUI...
| garbagecoder wrote:
| Apple didn't "invent" the GUI and Columbus didn't discover
| America, but they popularized it, at least among a certain
| set.
|
| No one was popularized RISC-V yet. Maybe Asus will be the
| one!
| rocket_surgeron wrote:
| Are they?
|
| As far as I'm aware, there are only categories of people when
| it comes to "the invention of the GUI":
|
| 1. People who know it was a long and involved development
| process involving many people starting in the 1960s.
|
| 2. People who don't care.
|
| edit: Lol y'all some bitches.
| uticus wrote:
| I'm confused. When I click on "Where to Buy" it sends me to an
| Amazon page with these specs:
|
| > CPU and GPU: Quad-core ARM Cortex-A53 and integrated GC7000
| Lite Graphics
|
| > CPU Socket Quad-core ARM Cortex-A53
|
| > Chipset Type Quad-core ARM
|
| ...am I right to expect something _not_ ARM?
|
| [edit] nm, apparently the SBC series also offers ARM
| st3fan wrote:
| Unobtainium? Doesn't actually seem to be for sale anywhere?
| fortysixdegrees wrote:
| In my work I have had to evaluate a whole bunch of SBCs, and the
| Asus Tinkerboard is a cut above all the others.
|
| I expect the quality of this board to be similar
| aacid wrote:
| > Micro-USB
|
| Honestly??
| tlavoie wrote:
| I see people complain about Micro-USB in various places, and am
| not quite sure what the problem is. You're connecting to some
| relatively small, low-power device, not powering a beefy
| laptop. Is it problematic to have too many cables in the drawer
| that fit?
| kube-system wrote:
| It's an older standard, and if nothing else, the
| reversibility of type-c is worth the 10 cents.
|
| And because one of the ports is USB OTG, one of the intended
| uses is for a micro B connector as the host connector. Which
| is a misuse of the originally intended function of that
| connector anyway.
| tlavoie wrote:
| Thanks, just seems like much ado about nothing, other than
| that last part.
|
| I know I've got a wealth of devices that have the various
| formats, mostly micro. Their functionality still seems
| fine, so the anguish that pops up from time to time seems a
| bit much.
| wolrah wrote:
| Amen to this. I wish the USB-IF would officially deprecate the
| entire mini and micro line, stating that they are not allowed
| to be used and will not be certified compliant in new hardware
| designs unless the new design is intended to be a physically
| identical drop-in replacement for an older design that used
| those ports.
|
| There is no good excuse for these ports' continued use in new
| designs, just penny pinching nonsense.
|
| Host-side ports can be full size A or C, device side ports can
| be full size B or C, anything else is just being cheap.
| kube-system wrote:
| USB-IF should be forced to use PCs equipped only with Micro A
| and Mini A ports. And to connect their peripherals, they must
| first dig through a large bag of Micro/Mini B cables to find
| a single Micro/Mini A cable.
|
| Although that might be so cruel that it violates the Geneva
| Convention.
| wyldfire wrote:
| Probably saved a good $0.45 using a cheaper header. :(
| thrown123098 wrote:
| Or it was the only one they clild get in volume. The last 3
| years have been merry he'll on supply chains.
| johnwalkr wrote:
| Connectors, especially ones made by multiple manufacturers
| in the same footprint (including usb-c)really weren't hit
| hard by this.
| bayindirh wrote:
| This is an enterprise/industrial IoT board with CANBus and
| RS232. These people carry RS232 over Ethernet and call it a
| revolution.
|
| I'm sure that finding MiniUSB is much more easier on that
| setting and ecosystem.
| wolrah wrote:
| > Or it was the only one they clild get in volume. The last
| 3 years have been merry he'll on supply chains.
|
| This is Asus. They make a phone that has two USB-C ports,
| plus a variety of mobile accessories that all have one.
| They also make laptops, desktops, and motherboards that
| generally have 2-4 of them.
|
| I'd be shocked if the sales of the entire Tinkerboard line
| added up to even the mobile products alone, much less the
| PC lines.
| unusual-name wrote:
| Apparently the CPU in this SBC violates the RISC-V ISA pretty
| badly. [1]
|
| [1]
| https://lore.kernel.org/all/CA++6G0Do001Bo+kxhUNz5T937TYU-K5...
| pclmulqdq wrote:
| Keep in mind the spec being violated is the privileged spec,
| not the core instruction set (which is what people think of
| when they think of an ISA violation). Personally, I think the
| privileged spec is a little too overzealous about the
| implementation-specific details that it specifies, and a little
| more should have been left to chip vendors.
| cdcarter wrote:
| On the other hand, the privileged spec is also designed to
| provide process isolation and other security features. It may
| not seem as drastic as if a core instruction were
| misinterpreted, but this is IMO not the layer you want
| unexpected deviations from spec in.
| Pet_Ant wrote:
| For the uninitiated, what kind of things? I mean are these
| things that are necessary for desktop operating systems, but
| overkill when used as a DSP or something like that? I mean
| these aren't dumb people working on this so I wonder what
| this trade-off is.
| pclmulqdq wrote:
| Exactly that - they specify things that you need for an OS
| on a desktop/server system but complete overkill for
| embedded applications. I think the goal was to have one
| version of "RISC-V Linux" without vendor-specific
| extensions, but the chip vendors are used to their
| extensions, and there are good reasons to allow them to
| have some more customization (to allow design tradeoffs).
|
| Also, in the ARM ecosystem, some of the things that the
| RISC-V spec specifies (like MMU details) are vendor-
| specific, leading to a minor headache for OS writers, but
| give chip manufacturers more freedom. Renesas may have
| assumed they had the same freedom.
| pm215 wrote:
| On the other hand, it sounds from the thread like the result
| of the deviation from the spec is "you can't run userspace
| binaries unless you built them with a binutils that's working
| around this", so it's not just a "weirdness the kernel has to
| deal with" kind of thing.
| brucehoult wrote:
| If everyone is understanding it correctly then that appears
| to be the case. Apparently user-space addresses from
| 0x20000 to 0x3ffff are not mapped by the MMU in the
| expected way, but are directly mapped to the same SRAM for
| every program.
|
| A statically linked "HelloWorld" on my VisionFive 2 starts
| from 0x10000 and runs up to 0x4ea8e, so smack through that
| whole memory region.
|
| The only way to make programs compiled with a standard
| binutils (or on another RISC-V machine, or a standard OS
| running in a VM) work would be for the kernel to memcpy()
| that 128k region in and out on every address space switch.
|
| It's really an awful bug (or design decision) if you want
| to run standard OSes and standard code on it.
___________________________________________________________________
(page generated 2023-03-20 23:01 UTC)