Sign in with
Sign up | Sign in
Your question

BIOS of Dell Latitude CsX Laptop

Last response: in Laptops & Notebooks
Share
Anonymous
a b D Laptop
September 26, 2004 6:29:05 AM

Archived from groups: comp.sys.laptops (More info?)

I'm trying to read the ROM BIOS of my Dell Latitude CsX laptop.
I'm running RedHat 7.1 Linux on it. I used nasm-0.98.38 to disassemble
the BIOS and now I'm going through it trying to make sense of the code.
This isn't something I'm trained to do. I have a copy of Frank van Gilluwe's
book, The Undocumented PC, 2nd ed., which has some useful information.

I don't insist on doing this entirely from scratch on my own. I'd
be perfectly happy to read someone else's listing and comments on
the ROM BIOS for this machine, especially if the information is
freely available.

Failing that, here is where I am presently stuck in my efforts to
do it on my own. Assuming that on startup the CPU will takes its
first instruction from FFFF0, it then jumps to another location
and then to a place where it runs through about 60 or so instructions
terminating in a HLT instruction. The 60 or so instructions involve
reads and writes to various ports, including ports 60h, 64h, e0h, e1h.
Just before the HLT instruction, a bit is set in port 92h, causing
a reset. I am under the impression that the reset causes it to start
all over again at FFFF0, and then follow the same sequence of instructions
leading to the reset, and therefore cause an infinite loop. So, my impression
must be wrong. If the reset actually causes it to jump somewhere else, how can
I figure out where that somewhere else is?

Useful as it seems to be, I'm also not sure how much of what is in Gilluwe's
book applies to my laptop and would be glad to know of another book that
will help me understand the conversation that the CPU is having with the
underlying hardware when the ROM BIOS is being executed.
--
Ignorantly,
Allan Adler <ara@zurich.csail.mit.edu>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.
Anonymous
a b D Laptop
September 26, 2004 3:38:26 PM

Archived from groups: comp.sys.laptops (More info?)

Allan Adler <ara@nestle.csail.mit.edu> wrote:
[bios]
> Failing that, here is where I am presently stuck in my efforts to
> do it on my own. Assuming that on startup the CPU will takes its
> first instruction from FFFF0, it then jumps to another location
> and then to a place where it runs through about 60 or so instructions
> terminating in a HLT instruction. The 60 or so instructions involve
> reads and writes to various ports, including ports 60h, 64h, e0h, e1h.
> Just before the HLT instruction, a bit is set in port 92h, causing
> a reset. I am under the impression that the reset causes it to start
> all over again at FFFF0, and then follow the same sequence of instructions
> leading to the reset, and therefore cause an infinite loop. So, my impression
> must be wrong. If the reset actually causes it to jump somewhere else, how can
> I figure out where that somewhere else is?

It probably set state on the first run, which causes something else to
happen second time through. Anyway, isn't ffff0 where the interrupt
vector should be loaded (he remembers vaguely ...).

Peter
Anonymous
a b D Laptop
September 26, 2004 7:32:12 PM

Archived from groups: comp.sys.laptops (More info?)

ptb@oboe.it.uc3m.es (P.T. Breuer) writes:

> It probably set state on the first run, which causes something else to
> happen second time through. Anyway, isn't ffff0 where the interrupt
> vector should be loaded (he remembers vaguely ...).

What do you mean by "set state", and what happens when "state" is "set"?

Also, what interrupt? I didn't see an explicit interrupt, just a write
to a certain port, which happens to have a reset as a side effect.
The book of Gilluwe has a section on the interrupt vector table
but I didn't see anything that seemed to govern the behavior of
the machine upon reset.

So, I don't see why ffff0 should be any different the second time around.
According to the /proc/iomem, ffff0 is part of system ROM (as in ROM BIOS)
and can't be rewritten.

On the other hand, maybe I'm misunderstanding your point. Maybe you
are saying that my initial assumption, that program execution begins
at location ffff0, is incorrect and that what one finds at ffff0 is
not the first instruction to execute but the beginning of the interrupt
vector table.

A book or website that actually has all this information for the Dell Latitude
CsX would be very helpful, since vague recollections can often be wrong.
--
Ignorantly,
Allan Adler <ara@zurich.csail.mit.edu>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.
Anonymous
a b D Laptop
September 27, 2004 1:43:16 AM

Archived from groups: comp.sys.laptops (More info?)

Allan Adler <ara@nestle.csail.mit.edu> wrote:
> ptb@oboe.it.uc3m.es (P.T. Breuer) writes:

> > It probably set state on the first run, which causes something else to
> > happen second time through. Anyway, isn't ffff0 where the interrupt
> > vector should be loaded (he remembers vaguely ...).

> What do you mean by "set state", and what happens when "state" is "set"?

I mean what I said, and if you do not understand it I suggest you get a
dictionary.

> Also, what interrupt? I didn't see an explicit interrupt, just a write

Ditto "interrupt vector".

Peter
!