back to article 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, …

  1. StrangerHereMyself Silver badge

    Wrong

    People aren't interested in a board with a specific processor, but a platform which is well supported, now and in the future. The Raspberry Pi Foundation stands alone in this regard and will always trump its competition.

    1. MarcoV

      Re: Wrong

      Indeed, and riscv and its possibly lower license fees matter for producers, but for endusers that only factors if the price is really lower (and on small orders it probably won't matter)

      1. Yet Another Anonymous coward Silver badge

        Re: Wrong

        Might be useful as a dev board for people planning a RISC-V embedded system

    2. heyrick Silver badge

      Re: Wrong

      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.

    3. iron

      Re: Wrong

      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.

      1. Charlie Clark Silver badge

        Re: Wrong

        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.

        1. Doctor Syntax Silver badge
          Unhappy

          Re: Wrong

          "it probably won't be until the end of the year before things get more or less back to normal"

          Which year?

    4. ThomH

      Re: Wrong

      I think the Richard M Stallmans of the world are very interested. And possibly curious developers, especially those in the bare metal niche.

      But no, these are not substantial groups.

      1. MarcoV

        Re: Wrong

        The architecture definition of Risc V is open. The CPU design itself not necessarily.

        RMS probably will want a complete open design, but that will probably preclude the faster RISCV's.

        1. Charlie Clark Silver badge

          Re: Wrong

          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.

    5. Anonymous Coward
      Anonymous Coward

      Re: Wrong

      = 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.

      1. Anonymous Coward
        Anonymous Coward

        Re: Wrong

        @A/C

        "Except Raspberry PI computers have little to do with the Raspberry Pi Foundation these days."

        Bit of wishful thinking there perhaps?

        1. werdsmith Silver badge

          Re: Wrong

          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.

    6. Roland6 Silver badge

      Re: Wrong

      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).

      1. StrangerHereMyself Silver badge

        Re: Wrong

        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).

    7. Bartholomew
      Meh

      Re: Wrong

      > 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.

      1. Bruce Hoult

        Re: Wrong

        >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.

        1. diodesign (Written by Reg staff) Silver badge

          where some high speed SRAM is located

          Reminds me of some MIPS CPU implementations that had on-die high-speed scratch RAM in place of a cache, fixed in physical memory. Looking at you, PlayStation 1.

          C.

          1. Bruce Hoult

            Re: where some high speed SRAM is located

            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.

            1. cyberdemon Silver badge
              WTF?

              Re: where some high speed SRAM is located

              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)

              1. werdsmith Silver badge

                Re: where some high speed SRAM is located

                It’s early days yet, these things are for early adopters to mess about with. These things will feedback and improve the real implementations that will come in the future.

              2. Bruce Hoult

                Re: where some high speed SRAM is located

                > 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.

            2. diodesign (Written by Reg staff) Silver badge

              Scratch space, scratch that

              "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.

  2. IGotOut Silver badge

    Yikes.

    Having just seen the price of the Tinker boards, I don't think the Raspberry Pi has much to worry about.

    1. cyberdemon Silver badge
      Devil

      Re: Yikes.

      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..

      1. Tom7

        Re: Yikes.

        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).

        1. cyberdemon Silver badge
          Linux

          Re: Yikes.

          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

          1. Bruce Hoult

            Re: Yikes.

            > 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.

        2. Lipdorn

          Re: Yikes.

          Shouldn't have much trouble running FreeRTOS. Just need to port it to the particular processor. Shouldn't take too long. There is a generic port for RISC-V already.

        3. GBE

          Re: Yikes.

          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.

          1. cyberdemon Silver badge
            Devil

            Re: Yikes.

            Er, no it doesn't. You only need one interface. Two is required only if you need the ring-redundancy feature.

            1. GBE

              Re: Yikes.

              Er, no it doesn't. You only need one interface. Two is required only if you need the ring-redundancy feature.

              Yes, you're right -- all the installations I've seen were rings, so I assumed nobody used EtherCAT controllers in single-interface mode.

    2. Charlie Clark Silver badge

      Re: Yikes.

      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.

    3. ITMA Silver badge

      Re: Yikes.

      But, it doesn't matter how much cheaper Raspberry Pi boards are if you can't get them...

      1. Anonymous Coward
        Anonymous Coward

        Re: Yikes.

        There's a shortage of RPI?

        Quick, everybody order ten RPI4 8GBs just in case you might need one in a year ...

        Now where's that pasta... Ah yes in the spare room behind the mountain of toilet rolls.

        1. ITMA Silver badge
          Devil

          Re: Yikes.

          So you are the ****** hoarding them all!

          Quick everyone - this is the bugger who is causing the Pi shortage....

  3. Gary Stewart

    Look up StarFive 2

    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

    1. This post has been deleted by its author

    2. 3arn0wl

      Re: Look up StarFive 2

      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.

      1. Gary Stewart

        Re: Look up StarFive 2

        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?

        1. 3arn0wl

          Re: Look up StarFive 2

          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/

        2. Bartholomew

          Re: Look up StarFive 2

          > 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.

        3. Bruce Hoult

          Re: Look up StarFive 2

          > 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.

      2. Bruce Hoult

        Re: Look up StarFive 2

        > Said to have the performance of a top flight 2016 smartphone - sufficient processing power to do lightweight computing.

        The better comparison would be an SBC with RK3566 with quad A55.

    3. elsergiovolador Silver badge

      Re: Look up StarFive 2

      Can you bit bang all 40 GPIO pins using DMA at high frequency (say 100MHz) with a mechanism that prevents any interrupts being serviced during the DMA transfer?

      1. Gary Stewart

        Re: Look up StarFive 2

        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.

      2. cyberdemon Silver badge
        Devil

        Re: Look up StarFive 2

        > Can you bit bang all 40 GPIO pins using DMA at high frequency (say 100MHz) with a mechanism that prevents any interrupts being serviced during the DMA transfer?

        Er, why would you want that?

        If you really need that, I have an FPGA to sell you..

    4. A Non e-mouse Silver badge
      Flame

      Re: Look up StarFive 2

      And what about the price...?

      $100.

      Not quite the same as a RPI.

      1. Gary Stewart

        Re: Look up StarFive 2

        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.

        1. werdsmith Silver badge

          Re: Look up StarFive 2

          I have Starfive 2 8GB . It’s just slightly faster than à Pi 3 but the OS and software for it is all dogshit so far.

          1. Bartholomew

            Re: Look up StarFive 2

            > the OS and software for it is all dogshit so far.

            So armbian sucks ?

            https://www.armbian.com/visionfive2/

            1. werdsmith Silver badge

              Re: Look up StarFive 2

              Yes, on the StarFive. It's all a bit ropey.

              I use a headless Ubuntu, which was also not directly optimised for this board, but it's a bit better.

              The support and the linux ports will improve over time.

              1. Bartholomew

                Re: Look up StarFive 2

                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.

    5. This post has been deleted by its author

    6. Bartholomew

      Re: Look up StarFive 2

      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.

      1. Bruce Hoult

        Re: Look up StarFive 2

        > 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".

    7. ssieler

      Re: Look up StarFive 2

      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.

  4. elsergiovolador Silver badge

    Pointless

    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.

    1. diodesign (Written by Reg staff) Silver badge

      "What is the purpose of this?"

      Probably to test out manufacturing and distribution of RV SOCs and boards as well as fulfill any niche demand.

      C.

  5. Tubz Silver badge

    Looking forward to the first decent open RiscV routers, NAS and combos, hopefully keep costs down while leaving them open to community development, change radios, storage, whatever. ARMs still seem to be too locked down by the big boys. propriety hardware/code.

    1. elsergiovolador Silver badge

      It only has two 1gbps network ports - that is already a legacy technology. For a NAS even 10Gbps is a snail speed.

      1. Anonymous Coward
        Anonymous Coward

        Rubbish. For home/commodity uses 1GbE is fine for most purposes.

        For commercial/enterprise servers and infrastructure sure, 10GbE and up are typical, maybe even required. But little embedded gadgets like this and Rpi aren't in that category.

        1. A Non e-mouse Silver badge
          Joke

          Don't forget the gold connectors for maximum speed!

    2. doublelayer Silver badge

      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.

      1. druck Silver badge

        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.

  6. Mr Anonymous

    Tinker board 3 also announced

    RK3568 based, so will out perform the RPi4, so it's horses for courses and if you feel the need for speed then don't buy the RISC-V board.

  7. Groo The Wanderer Silver badge

    I don't see any appeal for an SBC with no video if they're trying to compete with the Pi. That is like delivering a car without wheels and claiming it is going to be "competitive."

    1. Anonymous Coward
      Anonymous Coward

      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.

  8. Bitbeisser

    $280? Sorry, but that isn't even remotely in the league of a RPi...

  9. David Alderman

    Single Core?

    I think single core may be a non-starter for many applications.

  10. Bartholomew
    Unhappy

    FreeBSD not supporting "ASUS Tinker V"

    "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*).

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like