I agree with what you said but there could be another reason behind the Rockchip move : they probably are shifting toward a full China made HW architecture, after the ASIC for ADC and frontend sections the SOC was the most likely to be changed.
Using rockchip/Allwinner isn't a huge deal, but focus on 'platform development' The QT vs Android thing, that's years of development. Using zynq was 'cute' and I can understand why this is an attractive choice. They are FPGA-bros if you will. They have been doing a lot of FPGA work over the years, all their devices use them. So if you are 'less experienced' and have to pick a SoC, zynq is very attractive. Linux + FPGA. And to be fair, it does offer some opportunities. You can offload some specific features to the FPGA, and offer it 'in hardware'. But I think most of the gates went into the display stuff. I think they are also re-routing one of the serial ports via the FPGA logic to pins that are only available there. Don't think there's a lot of 'hardware features' on those zynq fpga fabrics, but there was potential. The Zynq's however are outrageously expensive. So migrating away from that makes a lot of sense. Could have better not picked a zynq though :p
Anyway, the sourcing of the parts, I get; them not grokking how to do proper long term software development, is the part that frustrates me. I'd happily go work for them if they'd be able to pay though
not trying to read too much into this but...
from a kernel support / hardware support and drivers perspective. The manufacturers of all these chinese ARM socs they all always only bother to write and release drivers for android operating system.
Yes and no. The allwinner/rockchip SDK's are indeed often based on some ancient kernel, but those chips also tend to be very well supported mainline.
More importantly, if you strip out the userspace bit, the kernel is just that, the kernel. It doesn't matter or care if you run GNU, QT-specific, or Android stuff. Lack of knowledge and expierence of course. But there's nothing 'Androidy' about drivers etc. Just that the kernel offers extra android needed features (wake-locks etc) but most of that is in mainline nowadays as well. You don't need many android patches anymore ...
That is to say: for all those dedicated IP blocks within the soc itself, including for the GPU hardware acceleration etc.
If they use OpenGL (they have no need, though it looks sexy of course) then there's a chance you get stuck with propriatery 'bionic' linked GPU drivers of course.
Maybe some vendors will "pretend" to care about porting over to linux kernel. However by the time that is done might be well after the SOC is anymore relevant in current production, that soc is usually discontinued from curent manufacture (by then) and replaced with a shiny newer soc for the next wave of products.
I just hold it up to lack of knowledge/experience. Vendor gives me this SDK, so I have to use it.
[quote author=dreamcat4 link=topic=346222.msg4617653#msg4617653 date=1672822439
So if i had to guess, this was the reason why Rigol felt going for android here. And I don't actually have any clear or satisfying answer what other good options they had. Once you realize that they aren't going to have much sway with rockchip, or money to pay rockchip for developing linux drivers (for said soc), or much money for soc, (or to change for other soc which isn't dirt cheap).
[/quote]
As I said, the drivers are just kernel drivers, nothing special android here. As a manager, you then have to think 're-write all of our user facing software, which is where most of their IP/special sauce is' or 'make the kernel work'. I'm sure the later is far less work
BUT, if you have no idea, and just 'SDK is android, so we now must use android' sure, there you go.
Maybe it's necessary to do some sort of a numbers calculation / estimations to determine which cost is greater. Paying for more expensive soc versus paying more money for software developers to redevelop on android platform. And be switching platforms. Which may also depends how they structured their software stack etc.
Sure, this is the hard part, but doing some basic napkin math will tell you, they went for the expensive choice, because they likely have no idea they could have just kept their QT UI, running ontop of the 'SDK android kernel'. Heck, you can even run QT on android :p (maybe they did that though ...)
But the other thing would be the relative SoC availability in china. If they cannot get any other decent socs due to supply chain shortages. Or guarantee supply. Then that would not work, you complete a product to ship a product without any cpu in it.
No argument there though
I do agree about their software being really bad however. It's just not good enough in its current state. And they have this long history of just moving on to next shiny new thing. And then just never fixing what was un-shippable to begin with on their previous product. Just not on.
Maybe other people here have better knowledge than me about the situation with those rockchip socs. And the hardware / drivers support for linux. I was just stating how it's always been with so many chinese arm socs (made primarily for android platform). Yes they might ship linux distro images for them. And then you fire it up, there's no GPU acceleration (that is the main thing).
Perhaps it's because the GPU hardware block is under seperate proprietary IP? Then rockchip would not be responsible for a linux driver for that part. (unlike some of other smaller fixed hardware ip blocks).
AFAIK the Rockchip use MALI, which is also decently supported nowadays, but they'd still ship the mali drivers from ARM for sure.
Home
Help
Search
Login
Register
