Ive been reading Linux Appliance Design by Bob Smith, and have a question about something that was mentioned, but not covered at all in the book.
It was talking about using a microcontroller to control something such as a front panel display so you can show the progress of your appliance while its booting.
This is all it says, "An alternative (to a microcontroller) is to carve out a piece of the main CPU to use as a microcontroller while Linux is starting. You can modify the boot leader to set up a timer interrupt and use the interrupt handler to provide a front panel UI. You'll need to modify Linux so that it does not touch the timer or interrupt handler while booting. Once Linux is running, it can take over the timer and interrupt, making the front panel hardware just another device that it manages. This technique describes a form of virtual machine; as they become more popular, you may find that a VM provides all the hooks necessary to be used as an I/O controller."

Obviously I don't know what to search for on google. The only things I have found are the book itself that Im reading, and lots of info about microcontrollers.
Has anyone done this before? Maybe they could point me to a few resources? Im not looking for a how-to on here :P Just where I need to go to learn it for myself.

Thanks!!

Haven't done it before, but the idea isn't complicated in nature, but would take a good deal of effort for the average person to implement. You'll need some good Linux internals knowledge, PC hardware (low-level programming & hardware control) knowledge, etc.

Effort, I've got plenty of that. Knowledge, maybe not so much. But as much as I want to do this, I think it will be a great chance for me to learn more about Linux in the process.
Back to the lack of knowledge... I just don't know where to start. The book was no use other than enticing me to want to try this.

Go grab some books about x86 assembly language, system internals (programming side), and linux internals. :-)

Why so complicated?

Write a controller program in Linux and run it. Linux is multitasking... so what?

It doesn't have guaranteed response times, but on an ordinary PC but delays are usually in the ms range, which makes it good enough for almost anything.

jlinkels

The OP states 'use as a microcontroller while Linux is staring'. That mean it must be code which is part of or run by the bootloader before the kernel is ready to do anything.

Yes, I read that. Why would one want to do that?

I agree that the idea is rather farfetched. I suppose that the writer of the book didn't give any examples of doing this for the same reason.

Hmm, maybe I understand it... it seems as if during boot-up of the "real" controller, a separate process is running during boot (so it is there almost instantaneously after power-on) which gives the user information about the appliance's state. After the "real" controller boot process is completed, the "real" controller would take over.

I still think it is very complicated.

jlinkels

hmm... didn't get any emails about the new posts.
Thanks for all the comments about it. No, there are no examples at all in the book. That quote was it. Just enough to tease but no references on where to go.
And yes, the purpose is just as jlinkels said, to give the user that comforting feeling that something is going on.
I have an LCD panel, a CrystalFontz CF-635 that I'm using as the front panel for an Asterisk box. Using PERL to show some basic system info, things like that.
It would be nice to have the LCD update with some boot info during the boot, and this just seemed like a really interesting, if not implausible way to go about doing it.
Maybe a better idea would be to write a driver for the display and redirect the boot messages to it? Not that I know how to do that :P
Suggestions?

If you are able to use perl to write text to it, there is already a driver for it. From a quick websearch, it seems to be a generic UART-over-usb driver. In that case, to send bootup messages to the display you would need to do a couple things:

1. Compile the driver into your kernel as built-in (not a loadable module).
2. Through your bootloader, load your kernel with the extra parameter “console=ttyUSB0”

You may have to adjust the number, and also the baud/parity as specified here.

On second thought, this may not be such a good idea. The text will most likely scroll by too fast to read. An 80-character console line will take up an entire screenful.

While what the author is talking about could certainly be done, there is a piece he didn't bother to mention.

Basically, to do this, you have to treat the CPU as a bare processor with no operating system in it. You then write an assembler routine that runs in the system along with the linux boot loader (and, after a few seconds, along with Linux). This assembler routine takes over a timer (and prevents Linux from getting it as part of the boot process), and does the UI things you want to do with your appliance front panel.

Keep in mind that this assembler routine cannot access any libraries because there are no libraries available to access (no OS, remember?). You have no SDK to help you. You have to set your own stack, you have to create your own low-level interrupt service routine to respond to the timer. You have to load your code someplace in RAM where Linux won't interfere with it, you have to know exactly where it is, and your interrupt service routine has to properly invoke it. Probably, this is where you modify grub so that it will start your routine before it starts Linux.

After Linux is up and running (and your assembler routine is checking for this, somehow), your routine exits and passes control to Linux which then uses its own driver (which you have also written, but this is the easy part) to handle your appliance.

This is certainly possible.

It would be a royal b*tch to do, and the utility would be very limited.

When were in this position, I would try to optimize the boot process as much as possible. Perhaps the boot device is solid state, which is much faster than disk. It must be possible to cut out every unnecessary action during booting, especially actions which require a lookup of something with an associated time-out. (hardware detection, DHCP, DNS lookup) If needed, those actions can be inserted later when the system is already running. Is the kernel stored in compressed form? Is that really needed (by kernel design?) There is nothing magic about booting which makes it so slow, as soon as the kernel is loaded and running it should be possible to display your messages using the normal screen driver. Would 5 seconds be realistic?

jlinkels

Thanks jiml8. Suddenly this sounds like a horrible idea :P

osor, I use the Device::SerialPort perl module to write to it. The only problem with that is you have to specify what line you want the text to display on. Plus you have to add a CRC to the data you send to the LCD.

At any rate, just redirecting the console to the LCD would be terribly messy I think, either having to truncate every line to 1/4 of the text, or fill the entire LCD with each line from the console.

jlinkels, optimization is where I am headed now. I was using trixbox for Asterisk, which is based on CentOS. I hope no one takes offense, but CentOS has a huge footprint (almost 2GB for a fresh install, the trixbox installer does not let you choose packages) and seems terribly cumbersome for the task. I am in the process of switching it over to Arch. I am already using a SSD for the drive, albeit a very slow one, but this is just for testing the setup at the moment. I would be happy with ~15 second boot. I read somewhere, I think it was that Appliance Design book I have, that talks about getting the system configured how you want it to be when its running, and make an image of it, then just load the image into RAM at boot.