This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: Patch for x86 bootstrap
> This patch has been in CVS for a long time, and is in the version you're
> are working on. One comment you're deleting in your patch was introduced
> with the very patch i'm talking about.
>
> I just say that Back in November a patch to handle a problem from floppy
> loading, the one described by the comment I quoted, was incorporated
> into CVS.
Very fair.
> Your patch sure add something else, and is more genreic. But as you were
> deleting the comment from the code, I just wanted to be sure that you
> had not as the same time reintroduced the problem.
>
> Well to not confuse you and others more i should explain more precisely:
>
> The problem was that before November, the code would have tried,
> with one call to int 13h, to load a full track (18 sectors), across a
> 64k boundary. The BIOS would not handle that case, some kind of DMA
> problem, I think. By loading sector by sector the problem was solved.
>
> I've look at your patch a little more closely, and I don't think it
> reintroduce the problem since you are still loading sector by sector. So At
> least for loading to an adress aligned on sector size (512b) should be
> Okay.
>
> But, I'm not sure what would happen when your code try to load a sector
> across a 64Ko boundary, ie: not a Sector size aligned size, but anyway
> the loader has never been designed to handle such a case before.
I believe that I didn't reintroduce this error. If you look at the
int13 call to read the sector, you can see that I am computing the
load address there. Since we are in real-mode, I load the segment
register (es) with the destination_address>>4 and the offset (bx) with
the destination_address&0xf. I believe that this will always load
correctly.
Had I known the problem you were trying to solve, I might have
reimplemented the multi-sector read. I thought about it, but I wasn't
sure if it was due to potential BIOS problems. I'll make it an
option.
>
>
> A+
> --
> Fabrice Gautier <gautier@email.enstfr>