Enter Tinker: Asus pulls out RISC-V board it hopes trumps Raspberry PI Asus has unveiled a RISC-V model in its range of Tinker Board single board computer (SBC) systems, which up until now have all been Arm-based. However, it seems users should not expect too much in the way of performance from this first device. The Tinker Board has been around since 2017 as Asus’ answer to the Raspberry Pi, …
Yup. There's rather more to supporting an ecology than aping the GPIO pinouts.
On one hand it's good that one can plug in existing hardware (intended for the Pi) rather than needing new custom stuff.
But on the other hand it's a bit meaningless without the software/drivers and documentation to back it up.
And, of course, there's the price to consider.
Unless you want to actually buy an RPI, at which point the Pi Foundation fails miserably.
I've been on the waiting list with EVERY RPi retailer in the UK for over a year now. The Pi is a lie. It does not exist.
But if you don't want to actually buy the hardware and are fine with thier dubious hiring practices then yeah, they're great.
Due to, some might say massively flawed pandemic policies, supply chains are buggered. For chips this means that low volume, low margin chips like the Broadcoms used in the RPis that supply is severely constrained, especially if you are intending to sell at a fixed price, while car and consumer electronic manufacturers refill their inventories. Supplies are improving across the board but it probably won't be until the end of the year before things get more or less back to normal.
Probably true, who's going to pay for you to continue designing chips if your secret sauce isn't secret? It's not the greatest business model. I suppose some fabs with their own design labs could afford to do this. But it's difficult to see why they would want the overhead and what the benefit for them would be.
= The Raspberry Pi Foundation stands alone in this regard and will always trump its competition.
Except Raspberry PI computers have little to do with the Raspberry Pi Foundation these days. Having people buying them in the belief they are directly benefiting a charity has probably been very profitable for the multi-million dollar business and its well paid staff.
Bit of wishful thinking there perhaps?
Why? Foundation are an education charity. They do education including computing, not necessarily on Raspberry Pi. They are platform agnostic. They are funded by a number of supporting orgnaisations, including Raspberry Pi Limited.
They don't develop, make or sell Raspberry Pi hardware.
I noted the absence of any mention of OS platform compatibility.
Looking at Asus website, it seems it supports a version of Android and Debian (Tinker OS), although there are little details about the real openness etc. of these platforms.
I think if ASUS really want to play in the Raspberry space they either need to go full support environment or make their products fully compatible ie. run Rasbian (RISC-V).
That's no option for most Chinese sweatshops. They put together a board and slap some software together (probably done by some interns) and ship. They have no clue whatsoever.
Espressif, the Chinese company making titular boards is mostly hiring Western developers to develop software for it (I just recently read a blog by one of their developers on Rust support for their parts).
> and in the future
Starfive are upstreaming all their work for the VisionFive 2 to the 6.3 kernel. Looks to me like they planning future support.
>Starfive are upstreaming all their work for the VisionFive 2 to the 6.3 kernel. Looks to me like they planning future support.
Indeed so, but StarFive with their SiFive core based SoC are completely different to Asus with their Andes CPU core.
Also, I just yesterday learned that this Andes core has a major major flaw in not correctly implementing the RISC-V spec. It appears that virtual addresses between 0x30000 and 0x4FFFF do not (unlike all others) get mapped to physical addresses via the page table and TLB etc, but directly access the same PHYSICAL addresses, where some high speed SRAM is located.
This completely screws any OS which puts anything in those virtual addresses. Such as ... oh I don't know ... statically linked Linux binaries. I just checked a HelloWorld kind of program on my VisionFive 2 and the code starts at 0x103e0 and ends at 0x49bab ... so smack through that unmapped region.
It is completely normal to have a few KB of ITIM and/or DTIM on both ARM and RISC-V chips. Often (e.g. on all current SiFive cores) you can programatically decrease the size of the L1 cache and use the rest of it as scratchpad.
That's in physical address space.
What is wrong here on this Andes core is that this shows up in EVERY virtual address space too. That just completely breaks what a virtual address space is supposed to be. You're supposed to be able to map any virtual address to whatever physical address the OS wants. Not to have part of it (128K) mapped directly to physical.
On a normal ARM or RISC-V or x86 chip (or any other), you can always choose to map a certain part of multiple (or all) virtual address spaces to the same physical addresses. It's normal for this to be done for the OS kernel's RAM, for example. It is mapped the same in every process, but protected so only OS code can read/write it.
But that's a CHOICE.
This Andes core doesn't give you a choice, and furthermore, puts that area in a commonly-used address range.
Err, is it the same memory that shows up in every virtual address space? wouldn't that be a huge security/stability risk?
I.e. if a process makes use of the scratch memory then it can be read (and overwritten, intentionally or unintentionally) by other processes including those of other users?
Ok so as you say it's protected-mode, but that means all root-owned processes can read eachother's scratch buffers? Or is it only the kernel that can read it? (but even if so, that read/write could still be badly performed by system call - either the OS has good checks against misuse of scratch buffers and sacrifices the performance boost, or it doesn't)
> Err, is it the same memory that shows up in every virtual address space? wouldn't that be a huge security/stability risk?
Exactly! If this is actually correct (and it's being discussed on the Linux mailing list) then it's just an awful blunder on the part of Andes.
https://lore.kernel.org/all/CA+V-a8vT3AjnU1-s0k7ff0Y7WLofpHYnJPF+mKVnUspsrPvQtw@mail.gmail.com/
They want to change the address for statically-linked binaries, to start above this address hole.
OK, sure, that will work with things they compile themselves, or on their board, but not for any binary copied from another RISC-V system WHICH SHOULD WORK.
To solve this you'd need to have the OS copy that 128 KB of RAM in and out on every process switch (or address space switch), at least if either the from or the to process has that memory range in their page table. Slow, slow, slow.
Just an awful bug in that Andes CPU core, if this is all true and not some misunderstanding.
"It is completely normal to have a few KB of ITIM and/or DTIM on both ARM and RISC-V chips"
Yeah, true, very true. I experienced as much when I was playing with some RV silicon and also Qemu that correct emulates it.
The SRAM showing up in virtual space is very annoying, and demonstrates the part isn't for general purpose computing.
C.
True to a point. But for embedded applications like robot control, having CAN is a very nice feature, and we don't need the display port.
The price for a CAN 'hat' for a Raspberry Pi is shocking, and it's only an i2c/SPI-connected MCP25xx with very poor performance compared to a native CAN interface on the SoC.
Dual gigabit Ethernet ports is also a game changer. Then you can swap CAN for EtherCAT for -serious- robot control. Dedicated EtherCAT controllers cost thousands..
I hadn't thought of that but that's really neat. An EtherCAT driver for this would be awesome; one interface for networking, the other for control. It's curious, in a way, that it's running Linux and not FreeRTOS, which would be a more useful OS for robotics etc I think (although Yocto seems to have decent support for PREEMPT_RT, it's always still a pain to actually make something do what you want it to in RT).
I would love to see a Zephyr port for it actually.
If you're not familiar with Zephyr, it's kind of a halfway point between FreeRTOS and Linux. It's a fully real-time OS with bare-metal interrupt support, but it has a Linux-style device driver model, with DeviceTree and Kconfig.
RiscV is a supported architecture but the Tinker board is not on the list yet. It shouldn't be too much work to add it, though!
The closest board on there is the BeagleV StarLight JH7100
> The closest board on there is the BeagleV StarLight JH7100
300 of those were made and distributed for free to developers in April 2021. I was lucky enough to get one. No more have ever been made.
They were supposed to go into mass-production with a different SoC, the JH7110, in September 2021, but that didn't happen. Instead, a very very similar board, still with the JH7100, has been sold as the VisionFive v1 since December 2021, and the VisionFive 2 with JH7110 started to be delivered to people in January and February 2023.
Dual gigabit Ethernet ports is also a game changer. Then you can swap CAN for EtherCAT for -serious- robot control. Dedicated EtherCAT controllers cost thousands.I hadn't thought of that but that's really neat. An EtherCAT driver for this would be awesome; one interface for networking, the other for control.
An EtherCAT controller requires two interfaces, so you'd need to use both of them for control. If you want a "normal" network interface in addition to the EtherCAT master function, you'd have to add a USB dongle or something.
Yes, well, blame the article for the misleading comparison. Difficult to beat the R Pi for general tinkering devices. But for prototyping specific domains things might be different.
Most people won't care about the architecture, as long as it's well supported, and it won't affect the end price, either. ASUS has possibly switched archs purely because that's what is available at the moment in what is still a highly constrained market for low-end silicon.
With a 1 Ghz single core processor this does not come close to the Raspberry Pi 4 (or 3 or 3+). I have included a quick overview of its specs and add that it is priced close enough to the Raspberry Pi 4 to considered a real competitor. I recently bought one but have not yet begun to work with it as I have a long backlog of projects. I do plan to move it up on the project list and start using it soon.
Specifications listed for the VisionFive 2 SBC include:
Processor System:
StarFive JH7110 4 core 64-bit SoC w/ RV64GC (up to 1.5GHz)
Memory/Storage:
Up to 8GB LPDDR4
eMMC storage socket
1x M.2 M-Key for SSD
QSPI Flash
1x Micro SD card slot
Connectivity:
2x GbE RJ45 ports
Bluetooth V4.2 BR/EDR, Bluetooth LE
Display:
1x HDMI 2.0
1x 4-lane MIPI-DSI port (up to 2K@30fps)
1x 2-lane MIPI-DSI port
Camera:
MIPI CSI (up to 4K@30fps)
USB:
2x USB 2.0
2x USB 3.0
I/O Interfaces:
40-pin GPIO header
Other Features:
1x Reset button
Debug pin headers
Power:
5V (via USB Type-C with PD, up to 30W)
5V (via GPIO Power in)
PoE (supports Power over Ethernet)
Dimensions:
100 x 72mm
This post has been deleted by its author
I thought the consensus was that it was 80% performance of a Pi 4, with a better GPU... But anyway.
Look at the Sipeed Lichee Pi 4A come to that - 2000 of them will be shipping in a fortnight's time. It's got the T1520 SOM based around the open sourced T-Head C910, with the .7 Vector extension. Said to have the performance of a top flight 2016 smartphone - sufficient processing power to do lightweight computing.
I've no idea, but :
" the StarFive JH7110 processor has been released and answers some of those questions. It’s actually an SoC with six RISC-V cores, of which four 64-bit RISC-V cores run the main OS, plus a 64-bit RISC-V monitoring core, and a 32-bit RISC-V real-time core. " Jean-Luc Aufranc
https://riscv.org/news/2022/08/starfive-jh7110-risc-v-processor-specifications-released-jean-luc-aufranc-cnx-software/
> Can you expand on how this is done?
The RPi4 is made with a 28 nm process, say that the Asus chip is made with a 7nm process, could it possibly be faster if that is the case - yes it could!
I have no idea if that is the case. But yes slower can be faster if there is more logic.
> I don't see how a single core 1 GHz CPU can get close to 80% of the 4 core 1.5 GHz Raspberry Pi 4 CPU. Can you expand on how this is done?
It doesn't, obviously. That post is very badly phrased.
The Asus Tinker V has a 1 GHz single-issue core.
The StarFive VisionFive 2 has a 1.5 GHz quad core dual-issue in-order CPU, similar to an ARM A55 at 1.5 GHz, and about 80% of an A72 at 1.5 GHz -- except for lacking the NEON SIMD found in the ARM chips.
I don't know, it's not anything I have a need for at the present time. The data sheet for the processor is available for download. As an interesting aside, I understand it the Raspberry Pi can do 16 bit transfers into and out of a 100 MiB RAM buffer using DMA and the GPIO pins. It is not well documented but how to do it is out there on the web. From what I read it also requires the use of most the GPIO pins. I assume that is how a GPIO based VGA interface is done. I looked for the links I have for it and tried a Google search but haven't found the ones I have yet.
I didn't say it was. I said it was close. Last time I looked the retail price of the 8 GiB Raspberry Pi 4 was around $80 and I haven't seen one below $100 for over a year (?) now. I did read that they were supposed to be increasing production after they got some supply chain issues fixed but they are still not available in the US from the normal retailers. It is still well below the price of the Tinker 5 and has 4 times the number (and faster) cores and 8 times the amount of RAM.
Kernel 6.3 is where most of the upstream support is targeted (some will end up in 6.4) once that is the mainline kernel everything should be smooth sailing. And since a lot of the licensed IP used will be reused or upgraded in the upcoming (~a year away) JH8100 a lot of the code can reused or refactored to support both. Which will help to get mainline kernel support faster.
This post has been deleted by its author
Someone dug deep into the source code commits for the JH7110 and found that they could possibly do 1.75GHz, but you would probably need proper cooling.
> Someone dug deep into the source code commits for the JH7110 and found that they could possibly do 1.75GHz, but you would probably need proper cooling.
As it does 1.5 GHz without a heatsink of any kind, and a lot cooler than a Pi 4 -- I haven't been able to get mine over 68 C with a heavy make -j4 build taking over two hours -- it can probably do a good bit more than 1.75 GHz with "proper cooling".
A least as of late 2022, the StarFive support and knowledge base was abysmal. I have one, and gave up trying to get it setup (in favor of using some other computers that were new and shiny :)
Perhaps that's improved since then?
I like the StarFive, in principal, because it has a decent amount of RAM (8 GB), as opposed to the Asus's 1 GB.
What is the purpose of this?
It seems like they just wanted a competing product to RPi in their portfolio, without giving much thought what people actually need.
Apart from MCUs (that there are still shortages of), there is not much in the market that would offer a ton of I/O with DMA, timers and realtime capabilities.
RPi offers a lot of processing power, but it is usable in a very narrow scope. You can drive a few peripherals or connect something through USB, but that's boring.
There is no reason that a RISC-V system will be any less locked down than an ARM one. Either can be designed to have replaceable firmware, but mostly they're designed to be cheap and when some effort is put into it, it's almost always to make it harder to install your own. RISC-V has no licensing fees for the company that designs the chip, that's all. It has no intrinsic effect on what the user of hardware built around that chip will be able to do with the hardware, and just as ARM do, RISC-V have no standards that will make it any easier to solve the problem of porting between different chips, something that X86, for all its flaws, is better at doing.
This ^^^ x 1e6.
RISC V for the consumer will be no different to ARM or anything else - no more open, no cheaper and no utopia. The firmware will be the same old closed source, dodgy and unmaintained mess, and the manufacturer is going to pocket the couple of cent saving of the ARM licence fee. If anything it will be harder for 3rd parties to create replacement firmware if every vendors RISC V SOC uses a different variant of the instruction set.
Perhaps in the absence of display output, if the thing had a telco-pinned serial port and serial-friendly bios (ala what PC Engines have done with apu family) they might have some inroads in the server or network appliance (IDF closet or similar) sort of markets.
I say "bios" in a loose sense of the word, fwiw.
But otherwise, yeah it seems a bit off trying to market a headless gadget vs. rpi. I run my rpi4 as a headless server with the FreeBSD or Linux system console via serial hat, but I expect that's not a common config for most folks.
"The ASUS Tinker V, and any other platform based on the same AX45MP core IP configured with the ILM and/or DLM enabled, is unlikely to be supported on FreeBSD due to its SoC violating the RISC-V Sv39 specification, which would likely require intrusive patches to work around."
( ref: https://wiki.freebsd.org/riscv#Unsupported_Platforms )
And from the link off that:
"> > So now with the fix for statically compiled applications we can see its offsetted and entry point is 0x504e4 and load is at 0x0000000000050000. So with this we are for sure the MMU will always trigger a page fault.
> Well that’s just a blatant violation of the spec.
Right - this isn't a platform quirk; it's a violation of the ISA. Unless this behaviour is engaged by a custom mode bit, that is, in which case, it should just be disabled by default and none of this would be a problem. If the behaviour is unconditionally enabled, this should be treated as an erratum."
But maybe a new revision of the chip with a fully compliant RISC-V ISA will ship ? (After they fob these broken ones off on some unsuspecting idiots - *ponder*).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
