This is so frustrating- sometimes 6.2NC boots on my Thinkpad, and sometimes it hangs
after the row of dots print. I cant tell what magic causes it to boot, I just keep trying
over and
over until it does. Pressing escape to boot the version without DMA doesn’t help.
Perhaps some simple diagnostic printouts could be added at the very beginning of the
kernel loading/starting
sequence so that we could give QSSL a little more help in debugging this in the future?
This is so frustrating- sometimes 6.2NC boots on my Thinkpad, and
sometimes it hangs
after the row of dots print. I cant tell what magic causes it to boot, I
just keep trying
over and
over until it does. Pressing escape to boot the version without DMA
doesn’t help.
Perhaps some simple diagnostic printouts could be added at the very
beginning of the
kernel loading/starting
sequence so that we could give QSSL a little more help in debugging this
in the future?
My IBM laptop A31 also hangs “sometimes”.
After much fiddling it appears that the problem is very early in the loading
process.
I have added -v to startup-bios. When it is going to boot I get a two line
message about the system page etc. When it isn’t going to boot I get nothing
(except the loader dots).
Cold and Soft resetting doesn’t seem to make a difference.
My system is a partition install. I haven’t yet tried booting using win98
and loadqnx.sys.
What ever it is its very early in the process. Either the loader, bios.boot
or very early in startup-bios. IBM don’t allow a lot of access to the bios
settings so I cant try changing settings like fast/slow A20 gate.
Just a thought… does it make any difference if you turn off the thinkpad
rather than just re-booting again and again?
Rob Rutherford
“Art Hays” <> avhays@nih.gov> > wrote in message
news:ahbpdt$fi8$> 1@inn.qnx.com> …
This is so frustrating- sometimes 6.2NC boots on my Thinkpad, and
sometimes it hangs
after the row of dots print. I cant tell what magic causes it to boot,
I
just keep trying
over and
over until it does. Pressing escape to boot the version without DMA
doesn’t help.
Perhaps some simple diagnostic printouts could be added at the very
beginning of the
kernel loading/starting
sequence so that we could give QSSL a little more help in debugging this
in the future?
I experienced a similar problem with an embeded x86 system that was not
fitted with a keyboard controller. There is a wait loop in the bios.boot
code that looks for the keyboard, but there is no timeout, so it hangs if
the keyboard is not detected. I have e-mailed an experimental package to
Andy that contains a bios_nokbd.boot file that will timeout if it does not
find the keyboard.
My IBM laptop A31 also hangs “sometimes”.
After much fiddling it appears that the problem is very early in the
loading
process.
I have added -v to startup-bios. When it is going to boot I get a two line
message about the system page etc. When it isn’t going to boot I get
nothing
(except the loader dots).
Cold and Soft resetting doesn’t seem to make a difference.
My system is a partition install. I haven’t yet tried booting using win98
and loadqnx.sys.
What ever it is its very early in the process. Either the loader,
bios.boot
or very early in startup-bios. IBM don’t allow a lot of access to the bios
settings so I cant try changing settings like fast/slow A20 gate.
Any ideas?
Andy.
Robert Rutherford <> ruzz@NoSpamPlease.ruzz.com> > wrote in message
news:ahfjqp$7lf$> 1@inn.qnx.com> …
Just a thought… does it make any difference if you turn off the
thinkpad
rather than just re-booting again and again?
Rob Rutherford
“Art Hays” <> avhays@nih.gov> > wrote in message
news:ahbpdt$fi8$> 1@inn.qnx.com> …
This is so frustrating- sometimes 6.2NC boots on my Thinkpad, and
sometimes it hangs
after the row of dots print. I cant tell what magic causes it to
boot,
I
just keep trying
over and
over until it does. Pressing escape to boot the version without DMA
doesn’t help.
Perhaps some simple diagnostic printouts could be added at the very
beginning of the
kernel loading/starting
sequence so that we could give QSSL a little more help in debugging
this
in the future?
Andy,
The dots during boot are printed out by secondary (operation system) loader. OS loader (it lives in
boot sector of QNX partition and it obtains control from primary loader which lives in Master Boot
Record) is looking through QNX partition by using int 13h of BIOS in order to find the file .boot
(or .altboot if Esc was pressed). So, the dots are printed before than even OS startup image is
loaded into RAM. Don’t waste time with playing around of startup image because the problem is
before all stuff in image. I suggest you to check all BIOS settings concerning of IDE (LBA and/or
PIO/UDMA modes, set it manually not to “auto”) and to try another system loader (see ‘dloader’ or
‘dinit -b -r’, loaders are under /boot/sys/ they are ipl-diskpc2 and ipl-diskpc2-flop in
QNX 6.1). Please be very careful in playing with loader - you are able to lose partition and all
data on it (startup floppy or CD which gives you a chance of ‘dinit -r /dev/hd0t79’ is good thing
to have before experiments).
Some more information:
ipl-diskpc2-flop uses int 0x13 ah=0x02 BIOS call (read sector). It should work with floppy disk as
well as with hard drives. The only limitation is the maximum quantity of cylinders should be no
more than 1024. So, if your hard drive is 8 Gig or less and BIOS supports LBA translation,
shouldn’t be any problem with usage of this x86 IPL. If you’re happy owner of huge HD, then the
best solution for you (IMHO) is to move QNX bootable partition to the begin of drive.
ipl-diskpc2 uses int 0x13 ah=0x42 BIOS call (extended read). It can’t boot system from floppy. I’m
not sure all BIOSes are supporting this feature equally good. But it is “modern” way to read hard
drive by BIOS and I guess it’s good for big drives
Personally I’m using the ipl-diskpc2-flop, it was automaticly installed during installation, but my
drive is small one.
That is one of the best descriptions of the differences between boot loaders
that I have seen.
I tried them both. Still boots erratically. Luckily my partition is within
the 1024 cylinders.
I have changed bios.boot to see if 1) it is executed and 2) if it completes
… Yes to both, bios.boot runs to the point where it is supposed to transfer
control to startup-bios.
It could still be the loader not accurately transferring the image to
memory. I suppose I need to add my debug code to startup-bios to see if it’s
first lines are being executed.
The IBM doesn’t allow a great deal of access to bios settings. There may be
some utility or other, I will look.
Andy.
ed1k <ed1k@spamerstrap.com> wrote in message
news:01c232fc$ef602c40$106fa8c0@ED1K…
Some more information:
ipl-diskpc2-flop uses int 0x13 ah=0x02 BIOS call (read sector). It should
work with floppy disk as
well as with hard drives. The only limitation is the maximum quantity of
cylinders should be no
more than 1024. So, if your hard drive is 8 Gig or less and BIOS supports
LBA translation,
shouldn’t be any problem with usage of this x86 IPL. If you’re happy owner
of huge HD, then the
best solution for you (IMHO) is to move QNX bootable partition to the
begin of drive.
ipl-diskpc2 uses int 0x13 ah=0x42 BIOS call (extended read). It can’t boot
system from floppy. I’m
not sure all BIOSes are supporting this feature equally good. But it is
“modern” way to read hard
drive by BIOS and I guess it’s good for big drives >
Personally I’m using the ipl-diskpc2-flop, it was automaticly installed
during installation, but my
drive is small one.
BTW, did you see final D after dots?
No sorry no 'D’s at all.
That is one of the best descriptions of the differences between boot loaders
that I have seen.
I tried them both. Still boots erratically. Luckily my partition is within
the 1024 cylinders.
I have changed bios.boot to see if 1) it is executed and 2) if it completes
. Yes to both, bios.boot runs to the point where it is supposed to transfer
control to startup-bios.
So, you have no any problem with reading the drive
It could still be the loader not accurately transferring the image to
memory.
Both loaders use INT 15h AH=87 BIOS call in order to access high memory area in real mode. Seems
they both don’t check return status after this call, so there is probability for some inaccuracy
during transfering. Did you try to load image into other region (‘image=2m’, for example, in build
file)?
I suppose I need to add my debug code to startup-bios to see if it’s
first lines are being executed.
Also it’s possible the start up initialization misses something (or do something wrong) on IBM’s
laptops.
Good luck!
Eduard.
ed1k at ukr dot net
The IBM doesn’t allow a great deal of access to bios settings. There may be
some utility or other, I will look.
Turning the thinkpad off/on may make a difference. It’s so erratic it’s hard to pin down.
This machine also has a W2K partition. Sometimes W2K hangs unless the machine
is turned off after RTP has been running. And I think sometimes it helps to restart from W2K
directly into RTP without a power off. However, RTP has sometimes booted fine from powerup as well.
Just a thought… does it make any difference if you turn off the thinkpad
rather than just re-booting again and again?
Rob Rutherford
“Art Hays” <> avhays@nih.gov> > wrote in message
news:ahbpdt$fi8$> 1@inn.qnx.com> …
This is so frustrating- sometimes 6.2NC boots on my Thinkpad, and
sometimes it hangs
after the row of dots print. I cant tell what magic causes it to boot, I
just keep trying
over and
over until it does. Pressing escape to boot the version without DMA
doesn’t help.
Perhaps some simple diagnostic printouts could be added at the very
beginning of the
kernel loading/starting
sequence so that we could give QSSL a little more help in debugging this
in the future?
I have managed to put a little debug code at the start of main.c in
startup-bios. This code is run only when the box successfully boots. Whereas
similar code in the last lines of bios.boot always runs.
I haven’t had time to look but does startup-bios have code before main.c ?
More information :
… putting the image at 2M and 18M gives no improvement.
… Making the image uncompressed gives a huge improvement. 6 successful boots
out of 8 attempts. Interestingly the two failed boots gave an error message.
“Unable to find boot process 0 )inode 2163897376)”
Ok Shirlock over to you?
Andy.
ed1k <ed1k@spamerstrap.com> wrote in message
news:01c2348f$3a841ea0$106fa8c0@ED1K…
That is one of the best descriptions of the differences between boot
loaders
that I have seen.
I tried them both. Still boots erratically. Luckily my partition is
within
the 1024 cylinders.
I have changed bios.boot to see if 1) it is executed and 2) if it
completes
. Yes to both, bios.boot runs to the point where it is supposed to
transfer
control to startup-bios.
So, you have no any problem with reading the drive >
It could still be the loader not accurately transferring the image to
memory.
Both loaders use INT 15h AH=87 BIOS call in order to access high memory
area in real mode. Seems
they both don’t check return status after this call, so there is
probability for some inaccuracy
during transfering. Did you try to load image into other region
(‘image=2m’, for example, in build
file)?
I suppose I need to add my debug code to startup-bios to see if it’s
first lines are being executed.
Also it’s possible the start up initialization misses something (or do
something wrong) on IBM’s
laptops.
Good luck!
Eduard.
ed1k at ukr dot net
The IBM doesn’t allow a great deal of access to bios settings. There may
be
some utility or other, I will look.
Could you try the improved IPL (mipl is a little changed ipl-diskpc2-flop). Does it make any
difference for your problem system? Who is BIOS manufacturer and which revision number does it
have?
uuencoded mipl is attached.
Cheers,
Eduard.
ed1k at ukr dot net
begin 600 mipl
MZR60V@``````````````````2&ET($5S8R!F;W(@+F%L=&)O;W0Z```7H'N M*@.’[A@([,?^Y'SI0:X0P!0RPX?#A>\C[OA(KC=7H<0’K]K`
M!C’N1@\ZNX@"9OP$,=N]CHR`"Y)`"X’-%G42’C’CMB+%FP$.Q9L M!'3Z'^+GOH"/!MU!(’&0"+3#"]!QVXM$'(M4'J,!(D6@3&!@@$8’&
M%#K(X'&"#^#@@$=1FA2+%@($55.]HQV[!.AC%M=OA$BP2+5*+
M?3H4P!^('2I?`3!YPD!_8'3``"!?`0``'7AXK>[``)FNNM^_P"Y`"!F M.Q=T"H'#!`#B];!3ZQB+1R`!V`4`!HE'*,='*A$`N``!4#'`4,OHD`#K_E90 M45)3+0$`@=H,&!3%@8`]S8.`(C%B.'`R0*)T)GV-AB,8(X?[!OP$ MB?B[``B*%A$M+-$[!$<KOWQ?\_=06P+NA#%N^``;‘1!#\9$%9/'1!( M#L9$%#'1!C\9$‘9.);!J(7!R1!P1B?G!X0BTA\T5<LV^P%W!8A<’.L1
96EE87L-34+L’+0.S1!86\.TA\T5<N3KY_G!
end
I have managed to put a little debug code at the start of main.c in
startup-bios. This code is run only when the box successfully boots. Whereas
similar code in the last lines of bios.boot always runs.
I haven’t had time to look but does startup-bios have code before main.c ?
More information :
. putting the image at 2M and 18M gives no improvement.
. Making the image uncompressed gives a huge improvement. 6 successful boots
out of 8 attempts. Interestingly the two failed boots gave an error message.
“Unable to find boot process 0 )inode 2163897376)”
Turning the thinkpad off/on may make a difference. It’s so erratic it’s hard to pin down.
This machine also has a W2K partition. Sometimes W2K hangs unless the machine
I’m not expert, but it resembles IDE gone berserk,
due to overclocking, overheat, shabby IDE cable…
(NT kernels rarely locks up beside on hardware failures)
Did you have a surgery and inspected inside the machine?
Also having a decent power source (AC adapter?) may help.
Could you try the improved IPL (mipl is a little changed ipl-diskpc2-flop). Does it make any
difference for your problem system? Who is BIOS manufacturer and which revision number does it
have?
uuencoded mipl is attached.
Please rename “mipl” to “ipl-diskpc2-ed1k” after ‘uudecode’ of the news message. This naming scheme
is important for ‘dloader’ utility. I’m sorry about that.
P.S. This new IPL is working for me as good as ipl-diskpc2-flop, but I never had problems with
booting
Could you try the improved IPL (mipl is a little changed ipl-diskpc2-flop).
Well, some more details. “mipl” is actually ipl-diskpc2-flop from QNX 6.1 A (is it changed in 6.2?)
patched by debugger in order to check out the return status of fn AH=87 INT 15h (move memory block
into upper memory area). If return status is “unsuccessful moving” it just tries to repeat moving.
I’m still not sure the image is transfered correctly in your system (and behaviour of compessed and
uncompressed images lets me think so). Since there is no any check in standard loader, my guesses
are:
if memory moving fails for some reason in your system, next try of moving the same block could
improve the situation;
if next moving doesn’t improve the situation and system hangs (just like it is with standard
loader but on some step before), I will add the output of the some char, say ‘H’ (where is IPL guy
from QSS? I know they use ‘D’ to indicate problem with int 13, but know nothing about ‘H’, is it
free char for such usage?), in order to see it is exactly memory transfers problems, but something
is wrong (GDT is wrong??, BIOS doesn’t disable interrupts inside function 87 of int 15h?? or
something else )
if we will not discover any abnormalies by experiments above, it means the standard loaders are
great and problem is in exactly image (bios.boot, startup-bios, decompressing or something else).
“mipl” is five minutes patch of standard loader by command ‘debug’ in DOS, so I don’t suggest to
anyone to use this loader except of experiments discussed in this thread.
Let me know about the results of experiment please.
Best regards,
Eduard.
ed1k at ukr dot net
Does it make any
difference for your problem system? Who is BIOS manufacturer and which revision number does it
have?
uuencoded mipl is attached.
Cheers,
I have managed to put a little debug code at the start of main.c in
startup-bios. This code is run only when the box successfully boots. Whereas
similar code in the last lines of bios.boot always runs.
I haven’t had time to look but does startup-bios have code before main.c ?
More information :
. putting the image at 2M and 18M gives no improvement.
. Making the image uncompressed gives a huge improvement. 6 successful boots
out of 8 attempts. Interestingly the two failed boots gave an error message.
“Unable to find boot process 0 )inode 2163897376)”
Sorry about the delay in replying:
I have tried the “mipl” loader. Sorry it didn’t help. There was no
noticeable difference in the “not loaded” rate.
ed1k <ed1k@spamerstrap.com> wrote in message
news:01c23870$88340b80$106fa8c0@ED1K…
ed1k <> ed1k@spamerstrap.com> > wrote in article
01c237b8$3d08eb20$106fa8c0@ED1K>…
Andy:
Could you try the improved IPL (mipl is a little changed
ipl-diskpc2-flop).
Well, some more details. “mipl” is actually ipl-diskpc2-flop from QNX 6.1
A (is it changed in 6.2?)
patched by debugger in order to check out the return status of fn AH=87
INT 15h (move memory block
into upper memory area). If return status is “unsuccessful moving” it just
tries to repeat moving.
I’m still not sure the image is transfered correctly in your system (and
behaviour of compessed and
uncompressed images lets me think so). Since there is no any check in
standard loader, my guesses
are:
if memory moving fails for some reason in your system, next try of
moving the same block could
improve the situation;
if next moving doesn’t improve the situation and system hangs (just
like it is with standard
loader but on some step before), I will add the output of the some char,
say ‘H’ (where is IPL guy
from QSS? I know they use ‘D’ to indicate problem with int 13, but know
nothing about ‘H’, is it
free char for such usage?), in order to see it is exactly memory transfers
problems, but something
is wrong (GDT is wrong??, BIOS doesn’t disable interrupts inside function
87 of int 15h?? or
something else > > )
I still can’t say wether or not the image is sccessfully being loaded. Known
things are :
the bios.boot code always loads and runs. Even if the boot process
doesn’t complete successfully. It gets to the point where it transfers
execution to startup-bios.
Initially I had a startup-bios with debug code that appeared to execute
the debug code only when the boot was successful (obviously). NB It didn’t
appear to run that code when booting failed. I use the word appears because
now I can’t seem to verify the result.
Compressing the image greately increases the failure rate. This would
imply that the fault isn’t in the loader but near or after the decompression
code. The failure may be there but the cause could still be earlier.
Question: When is the checksun in the startup header checked? and What area
of the image is covered by the checksum ?
if we will not discover any abnormalies by experiments above, it means
the standard loaders are
great and problem is in exactly image (bios.boot, startup-bios,
decompressing or something else).
“mipl” is five minutes patch of standard loader by command ‘debug’ in DOS,
so I don’t suggest to
anyone to use this loader except of experiments discussed in this thread.
Understood. The effort is appreciated.
Andy.
Let me know about the results of experiment please.
Best regards,
Eduard.
ed1k at ukr dot net
Does it make any
difference for your problem system? Who is BIOS manufacturer and which
revision number does it
have?
uuencoded mipl is attached.
Cheers,
I have managed to put a little debug code at the start of main.c in
startup-bios. This code is run only when the box successfully boots.
Whereas
similar code in the last lines of bios.boot always runs.
I haven’t had time to look but does startup-bios have code before
main.c ?
More information :
. putting the image at 2M and 18M gives no improvement.
. Making the image uncompressed gives a huge improvement. 6 successful
boots
out of 8 attempts. Interestingly the two failed boots gave an error
message.
“Unable to find boot process 0 )inode 2163897376)”
I have tried the “mipl” loader. Sorry it didn’t help. There was no
noticeable difference in the “not loaded” rate.
I know it’s crazy question, but was there any difference in dots quantity during fault boot by
standard loader and by “mipl” loader? I know, it’s late question Seems there is no problem with
loader and problem appears after reading/loading of the image. Well, here is attached another
loader “ipl-diskpc2-tst2”, it has to print ‘H’ letter if will problems with int 15. This loader
works equally good for me as a standard one… but I’m repeating I never saw discussed problem. And
no one of my system is returning “error” after int 15 in order to check out the output of ‘H’
letter I believe, there is no mistake it that section of code
So, if you never will see ‘…H’ then there is problem with image, not with loader.
I still can’t say wether or not the image is sccessfully being loaded. Known
things are :
the bios.boot code always loads and runs. Even if the boot process
doesn’t complete successfully. It gets to the point where it transfers
execution to startup-bios.
Initially I had a startup-bios with debug code that appeared to execute
the debug code only when the boot was successful (obviously). NB It didn’t
appear to run that code when booting failed. I use the word appears because
now I can’t seem to verify the result.
Compressing the image greately increases the failure rate. This would
imply that the fault isn’t in the loader but near or after the decompression
code. The failure may be there but the cause could still be earlier.
Yes, you’re right. My thought was that the decompression code can fail on damaged archive (if
damages were occured during memory move manipulations). I want to exclude such possibility on early
stage of loading from consideration.
Question: When is the checksun in the startup header checked?
Good question I hope someone will clarify a matter I don’t know.
and What area of the image is covered by the checksum ?
AFAIK, there is 2 checksum: one for sturt-up (uncompressed) part and second for the rest of image
(this part of image could be compressed). So, answer should be the next: all area of image is
covered by checksum .
The only thing I discovered is that image is transfered by loader into some region of memory (I
have to look deeply into this), not into region pointed by image= . But finally image is executed
exactly from that pointed memory region. I don’t know now who is moving image across the high
memory area (perhaps it is done in protected mode), system is rebooted if this process fails. So
there is additional memory moving operation for fault (Reboot occurs if “outside of memory
error” but what occurs on other kind of errors I don’t know)
Eduard.
ed1k at ukr dot net
begin 600 ipl-diskpc2-tst2
MZR60V@``````````````````2&ET($5S8R!F;W(@+F%L=&)O;W0Z```7H'N M*@.’[A@([,?^Y'SI0:X0P!0RPX?#A>\C[OA(KC=7H<0’K]K`
M!C’N1@\ZNX@"9OP$,=N]CHR`"Y)`"X’-%G42’C’CMB+%FP$.Q9L M!'3Z'^+GOH"/!MU!(’&0"+3#"]!QVXM$'(M4'J,!(D6@3&!@@$8’&
M%#K(X'&"#^#@@$=1FA2+%@($55.]HQV[!.AC%M=OA$BP2+5*+
M?3H4P!^('2I?`3!YPD!_8'3``"!?`0``'7AXK>[``)FNNM^_P"Y`"!F M.Q=T"H'#!`#B];!3ZQB+1R`!V`4`!HE'*,='*A$`N``!4#'`4,OHD`#K_E90 M45)3+0$`@=H,&!3%@8`]S8.`(C%B.'`R0*)T)GV-AB,8(X?[!OP$ MB?B[``B*%A$M+-$[!$<KOWQ?\_=06P+NA#%N^``;'1!#\9$%9/'1!( M#L9$%#'1!C\9$'9.);!J(7!R1!P1B?G!X0BTA\T5L$AS^EW_X#[781 ?6EE87L-34+L'+0.S1!86.(7!RTA\T5L$ATY.E3_\T5
`
end
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.
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.
ed1k <ed1k@spamerstrap.com> wrote in message
news:01c23940$0ca7aa00$106fa8c0@ED1K…
Andy:
Andy <> andy@symmetry.com.au> > wrote in article <aiaagi$7hh$> 1@inn.qnx.com> >…
I have tried the “mipl” loader. Sorry it didn’t help. There was no
noticeable difference in the “not loaded” rate.
I know it’s crazy question, but was there any difference in dots quantity
during fault boot by
standard loader and by “mipl” loader? I know, it’s late question > > Seems
there is no problem with
loader and problem appears after reading/loading of the image. Well,
here is attached another
loader “ipl-diskpc2-tst2”, it has to print ‘H’ letter if will problems
with int 15. This loader
works equally good for me as a standard one… but I’m repeating I never
saw discussed problem. And
no one of my system is returning “error” after int 15 in order to check
out the output of ‘H’
letter > > I believe, there is no mistake it that section of code >
So, if you never will see ‘…H’ then there is problem with image,
not with loader.
I still can’t say wether or not the image is sccessfully being loaded.
Known
things are :
the bios.boot code always loads and runs. Even if the boot process
doesn’t complete successfully. It gets to the point where it transfers
execution to startup-bios.
Initially I had a startup-bios with debug code that appeared to
execute
the debug code only when the boot was successful (obviously). NB It
didn’t
appear to run that code when booting failed. I use the word appears
because
now I can’t seem to verify the result.
Compressing the image greately increases the failure rate. This would
imply that the fault isn’t in the loader but near or after the
decompression
code. The failure may be there but the cause could still be earlier.
Yes, you’re right. My thought was that the decompression code can fail on
damaged archive (if
damages were occured during memory move manipulations). I want to exclude
such possibility on early
stage of loading from consideration.
Question: When is the checksun in the startup header checked?
Good question > > I hope someone will clarify a matter > > I don’t know.
and What area of the image is covered by the checksum ?
AFAIK, there is 2 checksum: one for sturt-up (uncompressed) part and
second for the rest of image
(this part of image could be compressed). So, answer should be the next:
all area of image is
covered by checksum > > .
The only thing I discovered is that image is transfered by loader into
some region of memory (I
have to look deeply into this), not into region pointed by image= . But
finally image is executed
exactly from that pointed memory region. I don’t know now who is moving
image across the high
memory area (perhaps it is done in protected mode), system is rebooted if
this process fails. So
there is additional memory moving operation for fault > > (Reboot occurs if
“outside of memory
error” but what occurs on other kind of errors I don’t know)
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 ?
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). 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
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.
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 ?
Other code is executed first … take a look at the startup lib for X86
(specifically cstarts32.S).
