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 ?
ed1k <email@example.com> wrote in message
Andy <> firstname.lastname@example.org> > wrote in article <aiaagi$7hh$> email@example.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.
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
the debug code only when the boot was successful (obviously). NB It
appear to run that code when booting failed. I use the word appears
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
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)
ed1k at ukr dot net