ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Notebook BIOS build process Re: ant sandbox
Date Wed, 21 Nov 2001 18:04:43 GMT

----- Original Message -----
From: "Stefan Bodewig" <>
To: <>
Sent: Wednesday, November 21, 2001 00:16
Subject: Re: ant sandbox

> > (*) ask me about notebook bios build process NMAKE4 some time.
> Steve, can you tell me something about notebook bios build process

Its very scary.

I was making changes to the keyboard controller of a laptop, which is its
own 16 bit core that emulates a legacy KBC among other things, but also has
to do stuff like listen to messages from the batter "I'm getting warm now,
stop charging me" and act on them before Bad Things happen to the battery.

The source was written by some BIOS vendor, worked on in Taiwan by the ODM
(box maker) and by the vendor to "add value". So it has been hacked around a

But also, every notebook in the product family shares the same basic KBC
controller and bios, but all with different options, depending on buttons,
features, hardware to work with, etc. To keep memory down #ifdefs were used
to wrap everything, so that a notebook without a brightness control wouldnt
contain the hander code for brightness in the keyboard processor routine,

So the build process is

-take the 'core' code tree from taiwan
-copy it somewhere
-copy on top of that the code changes from the vendor
-copy on top of that any per-system changes
-create (in make) a makefile to build the new system using appropriate files
and ifdefs
-run it.
-flash it into memory; if you have a bug the notebook is toast unless you
have a notebook with a hole in the base and the bios memory unsoldered and
socketed so that it sticks out the bottom, then you can pull it out, erase
it and restore it.

So the last step in a build, if you call it on the wrong box, can render a
system toast.

To make life worse NMAKE4 is not the traditional "build the first target"
make, but a dumb sibling, the "build any target we come across" verson. Once
I worked out (two days into it), that that was why my later version of NMAKE
was not doing things, I had to migrate the whole setup to a later NMAKE

Before editing any files you had to just type garbage into the place you
were editing and run a build to see if that was the file in use.


Which is why I dont like copying source onto source, or even binary over
binary, it causes confusion. And why I dont work on notebook BIOSes.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message