Porting LinuxBIOS to the AMD SC520
Well, let's see how it goes. We have a script for this part, to save some typing:
cd src/targets ./buildtarget digitallogic/msm586seg
This step works. It builds, but we get errors, which is expected. The version covered above, by the way, is:
if you want to see what goes wrong. With a few modifications, we get a working version, which is stored at:
It builds! The next step is to see if we can get any serial output. Make sure, of course, that you place the Flash part you want to burn into the Flash socket or you're going to be pretty unhappy. Better yet, before you start burning, make a backup of your factory BIOS to cover for mistakes:
flash_rom -r /tmp/backup
Put in a new Flash part:
and store the Flash part somewhere safe.
We're building on a laptop and using an SC520 running Linux as the burner node. So use:
scp linuxbios.rom root@burnnode: ssh root@burnnode flash_rom linuxbios.rom
Let's find out if it worked. Be sure to follow our progress on the Linux Journal Web site.
You can track our progress on the Web page or the LinuxBIOS Wiki (see the on-line Resources)—we have set up a status page there so you can see how it is going.
We have tried to show you a quick overview of how to do a LinuxBIOS port to a new system. If you really want to give it a go, join the mailing list and tell people what you are doing. There's a lot of expertise out there, and people are ready to help. For the record, it took one person totally unfamiliar with this system four hours to build a new BIOS port from scratch. That's not bad. Although it looks rather complex, once you see how to build a BIOS, you probably will find it to be pretty easy.
This research was funded in part by the Mathematical Information and Computer Sciences (MICS) Program of the DOE Office of Science and the Los Alamos Computer Science Institute (ASCI Institutes). Los Alamos National Laboratory is operated by the University of California for the National Nuclear Security Administration of the United States Department of Energy under contract W-7405-ENG-36. Los Alamos, NM 87545 LANL LA-UR-05-3336.
How to Set Up a LinuxBIOS Port System
We do not use Flash part burners at LANL, and most other places also do not. To burn a new Flash part, we actually pop the Flash part out of a running machine, put in a new part and run the flash_rom program to erase and rewrite the part. By far, the easiest way to set up a LinuxBIOS port station is to have one machine on which to build, one machine on which to burn and one machine on which to test.
The worst case is to have the burn, build and test machine be one and the same. In other words, the user has to boot the machine, build the LinuxBIOS, pop the Flash BIOS part out and put in a test part, burn it, reboot the machine to test and, in the likely event of failure—this is a new port, after all—put the factory BIOS back in and boot. The edit/compile/test cycle time can be long, as long as 3–5 minutes. In some cases, the burn and build machine can be the same.
For the SC520, we had a build machine, our x24 laptop; a burn machine, which is an MSM586SEG board; and a test machine, another MSM586SEG board. To simplify the situation further, we ran the two MSM586SEG boards as two bproc slave nodes using the Clustermatic software suite. Clustermatic lets us set up the two slave nodes with no local disk of any kind. All the state and control is managed from the laptop. We have been doing ports this way for five years now, and it is the easiest possible way we have found.
We've made a 64MB compact Flash image available at the LinuxBIOS Wiki, so you can make a slave machine with no effort. For more details, see the Clustermatic Web site for instructions on how to set up a laptop as a master node.
Resources for this article: /article/8327.
Ron Minnich is the team leader of the Cluster Research Team at Los Alamos National Laboratory. He has worked in cluster computing for longer than he would like to think about.
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!
- Home Automation with Raspberry Pi
- Hacking a Safe with Bash
- Django Models and Migrations
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Secure Server Deployments in Hostile Territory, Part II
- Embed Linux in Monitoring and Control Systems
- Shashlik - a Tasty New Android Simulator
- Purism Librem 13 Review
- Look Mom! I'm on the Internet!