Porting Linux to the DEC Alpha: The Kernel and Shell
Achieving the shell prompt was only the beginning of the trial, not the end. Now we had to get other utilities working so as to allow us to debug more of the system and to make it into a real, usable UNIX-like system.
I set Brian Nelson to the task of porting more utilities, starting with the “fileutils” and “shellutils” subsets of the MCC 1.0+ distribution. Meanwhile, I realized that better debugging tools would expedite the debug process, and I started thinking about implementing some kind of remote debugger support for gdb. My first implementation was under the ISP CPU simulator. The reason for this is that I could add code to ISP to examine and modify the state of the machine and communicate with a debugger without having to code a breakpoint handler into the kernel itself.
GDB has a remote debugging protocol built into it; all I needed to do was to add code to ISP to respond to gdb commands and to encode the simulated machine state for GDB's consumption. Getting this all working was only a few days' work.
While all this was happening we realized that Linux/Alpha was turning into a serious project and that we could use some help in the device driver space. While console callback drivers had served admirably to get us up and running, they were not equal to the task of supporting a production system. We recruited Jay Estabrook from the Digital UNIX group in this capacity, and he has proved to be an immensely valuable addition to our team. Within his first two weeks with the group he produced a native text-mode VGA driver and a native keyboard driver for Linux on the DEC 2000 AXP (“Jensen”) series.
Porting device drivers to Linux/Alpha presents some interesting challenges. Fortunately, many of the problems only needed to be solved once and the results would be applicable to many different drivers.
The Alpha CPU has no concept of I/O bus access; there is no Alpha equivalent of the Intel inb/outb instructions for communicating with the I/O bus. In order to implement a PCI- or EISA-based Alpha system, some sort of “glue” logic is needed to translate Alpha load/store accesses into I/O bus accesses. On systems based on the DECchip 21064 and 21164 CPUs, this glue logic is implemented in an external chipset (DECchip 21071 series). On systems based on the DECchip 21066, this glue logic is built into the CPU. This glue logic sets aside certain areas of the system physical address space for communicating with the I/O busses. To perform a bus access, one takes such information as the I/O port number and the size of the transfer and encodes it into a special memory address (This encoding is different for the different glue logic implementations). One may then load the data from or store the data to this address.
Interrupt handling is also different on Alpha systems. On most Intel-based systems, the mapping between bus IRQs and interrupt vectors is fixed and straightforward, and the hardware dispatches directly to the interrupt vector associated with a particular IRQ. On Alpha, all interrupts are dispatched by PALcode. The Digital UNIX PALcode vectors all device interrupts to a single routine. One of the arguments to this routine is a number (called the “SCB vector” for reasons I don't need to go into here) indicating which interrupt was received. Unfortunately, the mapping between bus IRQs and SCB offsets is not the same across all platforms. This means that we need extra code in the interrupt handling path to map the SCB vector back to an IRQ number. In fact, there are different versions of the mapping routine for the different platforms.
It turns out that many Intel Linux device drivers rely on the fact that the BIOS puts the device into a known state before the operating system even sees it. We discovered this when we were debugging the interrupt handling for the keyboard driver (and, later on, the SCSI driver). Apparently the interrupt controller on Intel boxes is initialized by the BIOS to trigger on the transition of an IRQ line (edge triggering) rather than on the state of an IRQ line (level triggering). We were having no end of problems with “spurious” interrupts until we added code to the CPU initialization routine to set the interrupt controller properly.
While our early decision to use the SRM console was good to get the project off the ground, it turns out that the SRM console is not the best choice for Linux. First of all, the SRM console is memory-hungry because it must implement numerous functions required by OpenVMS and Digital UNIX. Many of these functions are not needed by Linux. Second, and more serious, is the fact that the SRM console is not freely redistributable. Digital charges a substantial license fee to third parties for resale rights to the SRM firmware, as well as a per-unit charge for each copy of the SRM firmware sold by Digital or a third party. While the end-user typically never sees these charges, they do serve to raise the price of the hardware when it is sold in a Digital UNIX or OpenVMS configuration. In addition, requiring the SRM console for Linux/Alpha would present a significant burden to clone vendors who wished to build and sell Alpha systems for the Linux marketplace.
For these reasons, we decided to investigate the possibility of developing a freeware “miniloader” for Linux/Alpha. The miniloader could be much smaller than the SRM console because it needs to implement only the functionality necessary to initialize the system, load the PALcode, and load Linux. It could also be freely redistributable in source and binary form.
Unfortunately, developing a replacement for the console firmware is a non-trivial undertaking. Fortunately, however, we had help in the person of Dave Rusling from the Digital Semiconductor facility in Reading, England. Dave had much experience in low-level hardware support on the evaluation boards produced by Digital Semiconductor, and he had already done significant work for the Linux/Alpha project in the area of PCI support. He eagerly took on the task of developing the miniloader.
The miniloader consists of system initialization code, an OSF-compliant PALcode library, a bootstrap loader, and console callback routines. It presents to the bootloader and kernel an interface similar to that seen in the SRM console, with stripped-down functionality. The miniloader only implements those SRM features and callbacks that are used by Linux. As of this writing, the miniloader has succeeded in booting Linux on several models of Digital Semiconductor evaluation boards, as well as on the low-cost AXPpci/33 “NoName” motherboard and the high-performance “Cabriolet” motherboard.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- Purism Librem 13 Review