Shrinking the kernel with a hammer

Posted Mar 5, 2018 20:17 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Shrinking the kernel with a hammer by flussence
Parent article: Shrinking the kernel with a hammer

The first commercial ARM desktops (Acorn Archimedes) had either 1 MiB (A310 and A410 models) or 4 MiB RAM (A440); the 512 KiB model (A305) was announced at the same time, but shipped later, and the 2 MiB RAM model (A420) also came along later.

Of course, they won't run Linux now, even if you did the soldering job needed to fit 16 MiB RAM - Linux does not support ARMv2 or ARMv2a CPUs (the ARM2 and ARM3 silicon that you can fit in these machines), and you can't fit an ARMv3 or later chip (the ARM6/7 silicon that the RiscPC used, on to modern AArch64 chips).

Shrinking the kernel with a hammer

Posted Mar 6, 2018 7:09 UTC (Tue) by epa (subscriber, #39769) [Link] (4 responses)

When was the support dropped? I know Russell King's original port was to these CPUs.

Shrinking the kernel with a hammer

Posted Mar 6, 2018 10:23 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

About 10 years ago, give or take - I don't have a git clone to hand to go spelunking, but you're looking for the removal of include/asm-arm26 to see when it was deleted.

Shrinking the kernel with a hammer

Posted Mar 6, 2018 12:51 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Found it:

commit 99eb8a550dbccc0e1f6c7e866fe421810e0585f6
Author: Adrian Bunk <bunk@stusta.de>
Date:   Tue Jul 31 00:38:19 2007 -0700

    Remove the arm26 port

    The arm26 port has been in a state where it was far from even compiling
    for quite some time.

    Ian Molton agreed with the removal.

Shrinking the kernel with a hammer

Posted Mar 7, 2018 21:43 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

Ah, yeah. I can understand nobody wanting to maintain a 26-bit(!) arch.

Shrinking the kernel with a hammer

Posted Mar 8, 2018 8:48 UTC (Thu) by epa (subscriber, #39769) [Link]

It's a full 32-bit CPU with 32-bit registers, 32-bit address space, and 32-bit data bus; just the program counter is 26 bits. So executable code needs to be in the lower 64 mebibytes of the address space. Data doesn't have that restriction (in the instruction set architecture; I don't think any machine was built using a CPU with this instruction set and more than 16 megs of RAM).

(The same register contained the 26-bit program counter and six flag bits. I believe this was to reduce the amount of saving and restoring needed for responding to interrupts: you could save the whole CPU state apart from the registers in a single 32-bit operation. With 64-bit CPUs I wonder whether the same technique could make a a comeback: I can see the need for a huge address space for data, but surely it wouldn't be much of a hardship if executable code had to be located in the bottom 281 terabytes...)