MétaCan
Menu
Back to cohort
Record W1498914360

How to port Linux when the hardware turns soft

2007· article· en· W1498914360 on OpenAlex

Why this work is in the frame

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

aboutThe title or abstract carries a Canadian signal from the geographic lexicon.
no affNo Canadian affiliation: this work is invisible to an affiliation-only frame.
No Canadian affiliation. An affiliation-only frame, the usual design, would never have seen this work. It is one of the works that make the case for inverting the frame.

Bibliographic record

VenueLinux journal · 2007
Typearticle
Languageen
FieldComputer Science
TopicDistributed and Parallel Computing Systems
Canadian institutionsnot available
Fundersnot available
KeywordsPortingOperating systemComputer scienceLinux kernelGNU/LinuxPowerPCEmbedded systemSoftwareLaptopCompilerCross-platformByte
DOInot available

Abstract

fetched live from OpenAlex

Porting Linux to run on the Pico E12 and beyond. In software development, possibly the most mystical and prestigious effort is taking dead hardware and breathing life into it -porting an operating system to a new platform -the mythical land of wizards and gurus, the software side of The Soul of a New Machine. I had performed almost every other software development task, and I wanted a chance to conquer this one. I had been working with Linux and open-source software for many years. I am a fairly competent software developer (with hardware experience), but prior to starting the E12 port, I had done little more than tweak a Linux driver and build custom configured kernels. I was fortunate to have a friend building a new company that was developing one of the smallest embedded systems available, the Pico E12. I practically begged for the opportunity to put Linux on the E12. “A man's reach should exceed his grasp, or what's a heaven for?” The E12 used a Xilinx Virtex 4 FX20 FPGA (Field Programmable Gate Array) that included a 300MHz PowerPC 405 processor, 128MB of memory and 64MB of Flash ROM. I bought a Macintosh Lombard PowerBook Laptop on eBay, as a sort of simulator for the E12. It also provided a way to write for the E12 without a cross compiler. While waiting for the E12 to progress far enough to start working with it, I scoured the Web for information about Linux porting and developed competence in PowerPC assembly language. Linux kernel programming is primarily in C, but small parts of the Linux kernel -parts critical to putting Linux on a new system are in assembler. I have programmed in many assemblers -once writing the standard C library in x86 assembler, but PPC assembler was new and took a day or two to learn. Linux had been ported to PowerPCs, even a different Xilinx FPGA, long ago. How to Port Linux When the Hardware Turns Soft http://0-delivery.acm.org.innopac.lib.ryerson.ca/10.1145/1200000/11... 2 of 8 8/27/2007 7:28 PM Figure 1. Pico E12 I have a reference library of software books that fills a three-car garage. With few exceptions, they gather dust. My primary research tool today is a broadband Internet connection and a search engine. There are vast resources available on the Web for Linux developers. The Linux Device Driver guide -the Linux bible for device drivers -and numerous mailing lists target all aspects of Linux systems development. Kernel-Newbies is a great place to start (see the on-line Resources). There are mailing lists for every Linux subsystem. And, there are several Linux PowerPC mailing lists -one specific to embedded PowerPC Linux. At the root of this tree is LKML, the Linux Kernel Mailing List. LKML is Mount Olympus -the home of Linus, and the other Linux gods and titans. There are Web pages documenting the experience of others porting Linux to specific boards. Finally, the ultimate reference -the Linux kernel source -is available on kernel.org. Finally, the E12 was far enough along to start work, and I received one via FedEx. I had documents and specifications, but actually holding one made it real and answered questions that could not be read from the specifications. The E12 The E12 is a Compact Flash card -exactly like those in many digital cameras. It has only two connectors: a CF bus connection on one end and a 15-pin miniature connector on the other. There are no other external connections. The E12 is based on an FPGA. There are a few additional components, and a few fixed elements, such as the PPC405 How to Port Linux When the Hardware Turns Soft http://0-delivery.acm.org.innopac.lib.ryerson.ca/10.1145/1200000/11... 3 of 8 8/27/2007 7:28 PM CPU on the FPGA. A large part of the hardware is programmable. Most external connections are through the FPGA. Almost none of the “hardware” has form or meaning until the FPGA is loaded. Changing the bit file on the fly drops in a completely new hardware design. Welcome to a new era -even the hardware is software. The BIT image -in essence the program for the FPGA -is created by an FPGA developer, programmed into the Flash ROM and automagically loaded into the FPGA on power-up. Once this BIT image “boots”, hardware is created in the FPGA. Now, the pins on the connectors have meaning. The 15-pin connector provides three external connections for internal devices. It supports Ethernet, serial and JTAG connections through custom cables. The CF connector provides a bidirectional interface to a host -in most instances using a CardBus or PCMCIA adapter. Most of the pins on either connector can be whatever the FPGA programmer chooses to make them. Fielded systems may be plugged in to a CF connector solely to get power. E12's are used in daughter cards in typical embedded applications, on bus boards in high-performance computers in clusters and for applications, such as image processing or code cracking. They also are being used in applications with no operating system or extremely minimal operating systems. Figure 2. E12 in PCMCIA Adapter Pico provided tools for hosted development. The standard E12 BIT file provided a CF interface with a simulated LPT3/JTAG port, a 512-word bidirectional communications FIFO called the keyhole, and host access to the Flash ROM. Pico also provided host-side Windows and Linux drivers that allowed reading and writing the Flash ROM. The normal FPGA BIT image contains a very small PPC monitor program that can perform a small number of tasks -most of which rely heavily on support from the host. One of those functions is the ability to load two types of files into the E12. It can load a new BIT image or load and execute binary ELF files -a simple bootloader. This saved me the difficulty of porting a bootloader, such as U-Boot. The Linux kernel was the most complex ELF file that the E12 monitor program had loaded to this point, and a few tweaks were needed to the loader.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.

Full frame distilled prediction

Teacher imitation

Not calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

metaresearch head score (Codex)0.002
metaresearch head score (Gemma)0.000
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesScholarly communication
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Not applicable · Consensus signal: Not applicable
GenreCandidate signal: Methods · Consensus signal: none
Teacher disagreement score0.965
Threshold uncertainty score1.000

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0020.000
Meta-epidemiology (narrow)0.0000.000
Meta-epidemiology (broad)0.0000.000
Bibliometrics0.0000.000
Science and technology studies0.0000.000
Scholarly communication0.0020.000
Open science0.0020.000
Research integrity0.0000.001
Insufficient payload (model declined to judge)0.0000.000

Machine scores (provisional)

The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.

Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.

Opus teacher head0.020
GPT teacher head0.248
Teacher spread0.228 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it