arnd

No, it only means that Rockchips (or one of their customers) ships a kernel with a a driver for a Marvell wireless devices (presumably now made by NXP), for which Marvell claims to own the copyright and gives permission under GPL.

Assuming that the license text is correct, Marvell or NXP would have been in their full rights to provide the same source code to some users under the GPLv2 for use in a Linux driver, and to other users under a different license.

Another possibility is that Marvell themselves licensed the supplicant code from someone else and replaced the copyright information when publishing it together with their driver.

M1 is Armv8.5-A, which is almost the same as Armv9.0-A, except that it lacks SVE2 vector instructions. Apple's CPUs tend to move to the latest architecture revision that is available at the time the instruction set gets nailed down, so the next generation (M2 and A15) would be Armv8.6-A if it lacks SVE2, or Armv9.1-A if it includes it.

Most likely the M2/A15 will include SVE2 but won't be available for another six months, while the M1+ in the coming Macbook Pro would still be Armv8.5-A.

Some of the Apple M1 changes went into the tty/serial driver tree that GregKH maintains. The actual platform code requires those changes, so we based the branch on top of that, and the top-level merge commit contains all of these.

https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/... is the better commit to look at for the stuff that I just merged that was not already part of linux-next.

MIPSr6, aarch64 and riscv are siblings born from MIPSr5 plus the best of other RISC architectures.

ppc64le and 32-bit Arm are part of the wider family, but have some notable differences that make them slightly less RISC-like. Both include e.g. more complex condition code handling and instructions that operate on more than three registers.

They are using risc-v for their 64-bit cores now.

Mips R6 (Warrior m62xx/i6400/i6500/p6600) was already somewhat incompatible with R5 and earlier, the seventh generation nanomips i7200 was incompatible with that again.

The next "loongarch" generation was already announced to move away from mips as the underlying ISA but instead allow running mips, arm64, risc-v, and x86 code in hardware assisted emulation.

I double-checked the numbers reported by the driver against doing actual writes to the file system and the numbers reported by the OS, and they match exactly when there is no other activity: writing a 1GB file increases the number by 1GB and a few kilobytes of metadata.

Once the memory is full, it starts swapping a lot and then things go bad.

For the record, here are the numbers from this box: 900GB written in 20 power-on hours, on a 256GB driver.

Critical Warning: 0x00 Temperature: 26 Celsius Available Spare: 100% Available Spare Threshold: 99% Percentage Used: 0% Data Units Read: 15,019,377 [7.68 TB] Data Units Written: 1,759,297 [900 GB] Host Read Commands: 101,021,092 Host Write Commands: 14,010,727 Controller Busy Time: 0 Power Cycles: 75 Power On Hours: 20

It was apparently built for a very specific use case (doing CI for some application) so I guess it has to be ARM Linux. You can run Linux in a VM guest on Mac mini, but some limitations remain:

- The project was obviously started before the Mac mini was available

- Linux guests are still rather experimental and might not behave the same way as a real machine.

- 32-bit Arm applications do not run on the M1, it is a 64-bit-only CPU

- Nested virtualization is said to not work yet under MacOS, so you cannot run KVM guests inside of the Linux guest

- If you need to spin up lots OS instances simultaneously to test various setups and each of them need 8GB, you can have at most 2 instances on a Mac.

For most use cases, none of those apply, so you would be better off with a Mac, a Graviton instance or an off-the-shelf PC.

User space doesn't generally deal well with time going backwards, but the main problem is that setting an absolute timeout in a program is broken when the target time is less than the current time. An example of this is 32-bit systemd, which just hangs at boot when the RTC points to a time after 2038, as it tries to figure out of timers work.

https://www.adelielinux.org/ is an example of a Linux distro built on musl-1.2, so you can use that beyond 2038 on 32-bit hardware.

I think you get into practical problems at some point. WikiChip lists a 28nm Cortex-A7 core at 0.48mm², with every node shrink (20nm, 14nm, 10nm, 7nm, ...) you can halve that, but adding 64-bit support to a core might only add about 10%.

You can't make chips arbitrarily small, because you end up wasting more of your wafer for the area between the dies and for the wire bond pads. If the chip size stays the same but the CPU gets smaller, most of the chip is for off-core components and the CPU has less impact on the total cost and power consumption.

You could use more complex CPU cores, or simply more cores, for better performance, but then you also need a faster memory interface (wider buses, LD-DDR4+ instead of DDR3, ...) to make actually use of the performance. These lead to higher memory capacity as well, but then you can't actually use the available memory as you run into 32-bit addressing limits.

I wouldn't rule out shrinks of existing 32-bit SoC families to 22nm or below to lower cost once those processes get cheap enough and there is still demand for compatibility, but there is a good chance that 28nm SoCs is where 32-bit ends. (note that I'm not talking about the dozen or so additional ARC/Xtensa/RV32/Cortex-M/... microcontroller cores on high-end SoCs, as those are not the ones running Linux).

That sweet spot for cost has already moved from 40nm to 28nm for most of the market. The new SAM9X60 I mentioned is still on 40nm, but it's a tiny chip and all new Cortex-A7 SoCs and things like the Ingenic X2000 are on 28nm because of overall cost for that design point.

The sweet spot for power efficiency has apparently moved from 28nm to 22nm, which uses less energy than either 28nm HKMG or 14nm FinFET and is also closing in on 28nm on cost.

There no mainstream 32-bit cores on 22nm or below (yet), so there is a good chance that the coming generation of low-cost 64-bit SoCs on 22nm will beat all 32-bit chips on performance, power consumption and cost.

I tried not to talk too much about 64-bit architectures, but that's a good point. Indeed not just Alpha but also MIPS R4000, UltraSPARC, PA-8000 were already around in the 1990s when the 32-bit kernel support got merged, while ppc64, s390x and TileGX hardware came a little later than the corresponding 32-bit ports.

For time_t, I remember it first getting discussed seriously among kernel developers around 2010 as it became clearer that we had misjudged how long 32-bit systems would be around for, how much work it would be to fix it, and how long before 2038 things would fall apart from bugs. Before then, the general thinking was we could either delay dealing with it until the 2030s or 32-bit Linux would just not be there any more.

I would consider the LFS transition a user space failure, as glibc never made that the default and Debian still builds some packages with 32-bit off_t to avoid breaking the interface between libraries. As late as 2018, glibc was still merging architecture ports (csky) that default to a 32-bit off_t, despite the kernel having 64-bit off_t since 1994 (linux-1.1.46) before any non-i386 ports were added, and all new architectures in the kernel only supporting 64-bit off_t since 2011.

musl has completed the move with version 1.2, and embedded distros are moving to that.

glibc time64 support is still work in progress, as I wrote in the article

32-bit Arm has some features that make it less RISC-like than others:

- Predication as a major architectural feature -- every instruction can be conditionally executed - Complex load-store instructions: ldm/stm can operate on a large set of registers in a single instruction, including performing a branch by loading into the instruction pointer - 16-bit Thumb instruction format (also optionally present in RISC-V and newer MIPS)

64-bit Arm mostly drops all of the above and is basically a traditional RISC implementation.

I find the latest architecture versions are all remarkably similar as they have all adapted to the same environment:

The old 32-bit Arm (now called Aarch32) was quite different and only somewhat RISC-like. Arm's Aarch64 however is mostly derived from MIPS64 with a lot of modernization plus some parts (exception levels) from 32-bit Arm.

MIPSr6 was an attempt of modernizing MIPSr5 by removing all the ugly bits (delay slots!) but the incompatible instruction encoding prevented it from being widely adopted. You cannot buy a single MIPSr6 machine that a mainline Linux runs on.

RISC-V's design looked at all RISC architectures (Berkely RISC, MIPS, SPARC, Power, Arm, ...) for inspiration and took the best parts of each. Leaving out all the historic baggage means it's simpler (the manual is a fraction of the size), but most of the important decisions are the same as in MIPSr6 and Armv8/Aarch64.

One notable difference is the handling of compressed (16-bit) instructions: ARMv8/Aarch64 doesn't have them at all (like RISC-I/RISC-II, ARMv3 and MIPS-V), MIPSr6/microMIPS needs to switch between formats (like ARMv4T through ARMv6) and in RISC-V they are optional but can be freely mixed (somewhat like ARMv7 and nanoMIPS).

Ingenic an Loongson both have architecture licenses and so far have kept releasing new chips with their own cores on a regular basis, including (in Loongson's case) some interesting enhancements. Both are also members in the RISC-V foundation already though, so it seems likely they would in the long run pivot their instruction sets to that, like others have done before them: Andes, C-Sky, Cortus, Cobham-Gaisler, NVIDIA, and presumably many more all keep supporting old products based on their previous designs while doing new development on RISC-V.

CIP-United still promises to provide enhanced versions of the both the architecture and the MIPS Warrior cores for the Chinese market, regardless of what happens to MIPS Technologies. This may seem utterly futile now, but it is also the very thing that the US Committee on Foreign Investment was trying to prevent when it required MIPS to be spun out of Imagination Technologies when that got sold to Chinese investors.