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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Interview with Patrick Volkerding
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide