Some of the bloat is institutional, or maybe we should say, "civilisational"? Supporting TLS, modern hardware, media codecs, and so on - this puts a lower bound on the size of a "full" desktop OS, before you even consider a web browser. The next question is what kind of software do you need to get useful work done - not everyone writes code; if you want to edit audio, video, photos, do CAD, etc sometimes you simply need the horsepower.
I'm not sure how much horsepower or anything do TLS require but until very recently there were Win98 drivers capable of supporting almost-modern hardware. Codecs never were a problem on Windows 98 (thanks to the K-lite Codec Pack) and this CPU even has hardware h264 supposedly. Editing audio (besides ultra-professional many-channel ultra high fidelity) never was a problem on Windows 98 either (there was SoundForge). Editing video comfortably still requires highest-end PCs. AutoCAD worked nicely on Windows 98 too. Most of the people apparently only need Office (which was Okay since Windows 3.x), a messenger, a PDF&picture viewer, a media player and a browser. The browser running today websites probably is the heaviest thing of these. Chrome on my Raspberry PI 4 still struggles on many websites (YouTube is the worst, also the most needed there). When I say Windows 98 I generally imagine a 233-500 Mhz Pentium 1-2 CPU with 64-512 MB RAM generally (in fact the 64 MB of RAM in this title is exactly what caught my attention: I immediately recalled the days when I had a 64MB PC and was perfectly happy with it, and I still don't need anything it couldn't easily do those days).
Thank you for the link by the way.
> If you don't have an old computer, don't worry! You can still use your regularly computer and create a virtual machine with low specs, you would still be more comfortable with a good screen, disk access and a not too old CPU but you can participate.
Not really fair. Disk access always is a game changer. Migrating my Core 2 Duo laptop from 1 TB HDD to a 512 GB SSD made it feel like a totally new PC. I didn't try Windows 98 in a VM but Windows XP feels way faster in a VirtualBox than on bare hardware on the same PC (I believe that's because of caching, simple virtual hardware stack probably also contributes to lightning-fast booting).
I doubt it. They have been found to be in violation of the GPL for years, ranging from media codecs to bootloaders. Their response, even after joining the Linux foundation, was to obfuscate the code to make GPL violations hard to find.
Allwinner wants to sell as many SoCs as possible. Being open and having good Linux support is good business. The serve the low-end sector, which means they may not spend a lot of money for Linux support. But Linux support is good for business.
About a decade ago, Allwinner was providing an "SDK" to vendors to customize the Linux kernel for their devices. This "SDK" was a tarball of the compiled Linux kernel. In it, there were object files for drivers by third-parties for devices in the SoC that Allwinner sourced from other companies. Allwinner had the source code but obviously could not release it. They did not think better, and included those object files because it helps device integrators (mainly Android) to get the job done.
How do you deal with this issue with this blatant GPL violation? Obviously, you do not alienate the company. They fcked up but it's not the end of the world. They cannot release the source code of parts they do not own. You build a relationship and get them through to the right path.
But what happened in reality? A colossal fck-up. An attempt to "blackmail" the company to release the full source code and enforce the GPL. Listen to this, an attempt to enforce the GPL to a company "located in China". Not even on vendors that sell products in Europe or the US.
This alienated any attempts to get Allwinner's upper management to work with Linux. Allwinner made an effort and released some stuff (https://github.com/allwinner-zh) including the bootloader source and documentation (2015). The damage was done.
In 2016, Linus and other kernel developers posted their position on enforcing the GPL (https://lwn.net/Articles/698452/). Very pragmatic and should have been followed with Allwinner.
Well, that's pretty much what "providing SDK to vendors to customize their devices" means; if you're not planning to buy SOCs to make large quantities of custom devices, you're not a vendor for whom the manufacturer cares to provide an SDK.
Allwinner isn't the only vendor guilty of that. Ever try finding a datasheet for any Broadcom or Qualcomm part? I'm not defending the practice. I wish all SOC vendors would give full access to any/all documentation. They can still have a policy of "no support unless you sign a contract to buy X number of parts."
> an attempt to enforce the GPL to a company "located in China"
I'm not entirely sure what you mean by this. Companies in certain areas shouldnt have to follow the same rules as the rest of us? The GPL doesn't mention any geographical areas where it doesn't apply
Copyright law exists in China, and enforcement has dramatically ramped up over the last decade.
Since 2014, there have been specialized IP courts in major cities, and the volume of IP litigation in China is now similar to that in the US. China used to be the Wild West of IP, but that's been changing.
Giant company willfully violates the rules, and when someone tries to make them follow the rules, the poor, poor little giant company is "blackmailed" and it shouldn't have been done because they're "located in China". Or something.
Maybe but from the way they violate the GPL license and keep distributing binary blobs for their hardware I'd go out on a limb and say the money angle is more likely.
The amount of built-in 64MB RAM is equivalent to the typical RAM for 1995 - 97 PC era [1]. Someone actually offered me to buy his used PC for £400 back in 1997 and how dirt cheap this SoC would sell (£2) is really mind-boggling.
There are tons of SoCs that theoretically support Linux, but in practice rely on binary blobs or out-of-tree drivers. Getting them to work with anything other than the hand-picked, patched kernel versions provided by the manufacturer can be a nightmare.
Yes, but you can also look at it as a great way to start contributing to the upstream Linux kernel. Take the vendor's horrible drivers and clean them up, then submit them upstream.
You get to learn new things and contribute to Linux, which has varying amounts of value depending upon who you ask, but also you'll make the next person who buys one of these less likely to complain that mainline Linux doesn't support it.
Not a ton can easily be done about binary blobs, especially if those blobs have EULAs which prohibit reverse engineering. But there are always ways and doing so would be a great school or hobby project.
Upstreamed kernel drivers. A lot of companies just fork the kernel, throw in their modifications and then make you run their "official" image available in some random person's google drive.
This was particularly common with Allwinner but everyone with the proprietary ARM GPU drivers also had the problem that they only supported old kernel versions.
> Besides the built-in RAM, Allwinner D1s comes with many of the same features as D1 RISC-V SoC, but loses HDMI output and the HiFi 4 audio DSP, and Allwinner made some tweaks to the IOs with one less I2S audio interface, and general-purpose ADC.
Were the HDMI output and audio DSP licensed IP blocks from another company? On other Allwinner chips, the HDMI phy is from a different company than Allwinner.
Guess this is a super budget respin of this chip, where most licensed IP blocks have been removed.
Or even just that the chip was designed to fuse these blocks off for the low price options. It's not uncommon for those license agreements to allow disabled blocks without the licensing fees.
It saves millions of dollars to not have to do a different mask set, so quite likely. The downside is wasted silicon area and thus per-unit cost, but you've got to make a lot before that bites.
Likely a mistake in the spec list copied from the earlier intro article published in March. The chip has no DSP, HDMI or DVI blocks listed so it makes sense.
There's a bunch of reasons, here's a few I've heard or thought of myself:
* DDR2 is generally 1.8V. There's probably already a need for 1.8V logic within this SOC, so the power rail is "free." DDR3, DDR3L, and all the variants of DDR4 use a lower voltage. No one wants another power supply rail just to power some internal-to-the-SOC memory if they don't have to.
* DDR2 is easily available in single die x16 (data bus width) 64MB (512Mb) sizes. DDR3 may be available in this size, but DDR4 is almost certainly not available or would require buying dies which don't sell a lot so becomes risky.
* DDR2 in single-die configurations is super simple to hook up.
* DDR2 in this size die isn't going away any time soon and may likely be the cheapest way to get a smaller amount of RAM.
* SIP vendors often can negotiate very good and stable pricing for RAM, which is a big benefit to the PCB design integrator as they then don't have as crazy of price fluctuations which are common in the RAM market. This makes the SIP more attractive to some customers (the PCB designer, not the end user).
* DDR2 can likely keep this speed of CPU fed with data fast enough that the RAM won't be the bottleneck for many workloads.
DDR4 would require a significantly larger and more complex memory controller, and wouldn't improve performance. (This isn't exactly a high-performance SoC -- while no clock speed is listed, I suspect it's in the sub-GHz range.)
Offhand, one of the big issues that comes to mind is latency. DDR4 has a much higher latency than DDR2 between requesting and receiving, so could be potentially slower in a simpler core that doesn't have as big of a cache, and less aggressive cacheing/fetching algorithms.
By switching to RISC-V I guess Allwinner can save a few cents of Arm license fees.