Boot hangs *sometimes* on Thinkpad A22p

[ed1k2]

ed1k <ed1k@spamerstrap.com> wrote in article 01c23a34$6d8469e0$106fa8c0@ED1K…

ed1k <> ed1k@spamerstrap.com> > wrote in article

I have no source codes for
bios.boot and sturtup-bios. Reverse engineering is not something easy or/and useful for
debugging
this stage. I will see what I can do.

Andy:

I looked through bios.boot code. It makes harware initialization and inspects hardware resources.
I
have question for you: is there any MRCI hardware-assist adaptor (compressor/decompressor) in
your
laptop? The only suspiciously place which I found is MRCI server check (AX=b001h, INT 1ah).

Oops, my fault Usually AX=b001h INT 1ah is check for PCI BIOS present. And it is handled in
quite adequate way by bios.boot. But in old documentation (1994) I found this BIOS call is also for
MRCI (microsoft real-time compression interface) hardware server check. I never have the computer
with such MRCI toy. Perhaps it’s some kind of feature which is available only in paper form. Anyway
I believe such services register and detected only thru INT 2fh and INT 1ah is extended only for
General PCI interrupt services nowadays . So, I have no any new ideas now. But I believe
discussed problem may be related to some BIOS function implementation on IBM’s laptops.

Eduard.
ed1k at ukr dot net

It’s done in some crazy way which I don’t understand. Might be my documentation is wrong, might
be it’s
well knowen hack (but not by me). Unfortunately I have no bios.boot from 6.2 release in order to
give you pleasure to try yet another patched module >

Cheers,

Eduard.
ed1k at ukr dot net

[ed1k2]

ed1k <ed1k@spamerstrap.com> wrote in article 01c23c65$7053d1a0$106fa8c0@ED1K…

Oops, my fault > > Usually AX=b001h INT 1ah is check for PCI BIOS present.

Seems I had no relaxation during weekend bios.boot makes ax=b101h int 1ah call, it’s really PCI
service. MRCI search is ax=b001h int 1ah call and it has nothing to do here. I’m sorry again.

Eduard.
ed1k at ukr dot net

[Andy1]

The saga continues:

Eduard: I have compared the 6.1 and 6.2 bios.s sources. The only difference
seems to be the return code from the subroutine that detects the type of
box. For an eide it return 2 instead of 3 (or vice versa). This difference
shouldn’t apply in this case. As yet I haven’t been able to try booting a
6.1 image. It will have to be done via a floppy and floppy booting on this
machine takes more than 5 minutes.

Thank you John Wall for the clue of where to look for the first code in
startup-bios.
I put the out8 debug code in cstart32 just before the call to _main : the
debug code runs every time ! The booting isn’t so reliable. For a while I
was linking startup-bios and not picking up the debug version of cstart.

The second last thing that cstart32 does is an “iret” , I assume that’s to
setup the processor state before the call to _main.

Andy


ed1k <ed1k@spamerstrap.com> wrote in message
news:01c23a19$844c9500$106fa8c0@ED1K…

Andy <> andy@symmetry.com.au> > wrote in article <aiddek$i1d$> 1@inn.qnx.com> >…
Eduard:

Bad news again. The tst2 loader works but doesn’t improve the booting.
Yes I
patched the “Hit Esc…” string to be “hit Esc” just to be sure that your
code was running. There were no 'D’s and no 'H’s . The number of ‘.’
were
the same if it booted or not.

Andy:

Bad result is not bad news > > We discovered that the secondary loader
reads and copies the image
correctly. It’s a good news > > We are closer to fault location now. I have
no source codes for
bios.boot and sturtup-bios. Reverse engineering is not something easy
or/and useful for debugging
this stage. I will see what I can do. I wonder who is decompressing and
transfering the imafe into
region which is pointed by image= option in build file. Strange we are
only both here, nobody else
want to jump into it.

BTW. Is this problem with 6.2 only? Or it was in 6.1 also? I found
ipl-diskpc2-flop in 6.2 is the
same as in 6.1, but perhaps there are differences in image built-in
components because 6.2NC
doesn’t allow to play around images, sadly.

Happy weekend,

Eduard.
ed1k at ukr dot net


Where is it halting?
I put the out8 (0x3f8,‘A’ ) (assembler equivalent) in the bios.s code,
just
before the jump to startup-bios. It hits this code every time.
I put the same code in the first line of startup-bios’s main.c (C
version) .
It only hits this when booting is ok.
I also put a kprintf (after the debug is enabled ) in startup-bios. I
thought that this fixed it (go figure). It booted correctly 8 times in a
row, then failed to boot for the next two.

Is there a way from bios.boot to examine and dump the code pointed to by
STARTUP_VADDR(%ebx) . I have started to incorporate the uart_init and
uart_hex32 code into bios.boot. Is this a sane thing to do ?

Is the main.c code in startup-bios the first to run or is there some
other
code that executes first ?

Andy.