Hi again!
>
> Hmmm. So I did slightly misunderstand how things were being done.
>
Doesn't matter :-)
> : Hmmm. That would work, but actually I don't like this unnecessary
> : memory fragmentation. But if the other's agree...
>
> I think that it wouldn't matter much at all. I believe that we could
> reduce the amount of fragmentation if we loaded the data and, if
> possible, the bss below the 640K mark. Also, as things start up, I
> would imagine that they would use up at least 1M of memory (and
> certainly 640K) so that wouldn't be a huge deal, I don't think. We
> have plenty of time to get to know this problem. There are a few
> places in the kernel that are #ifdef'd based on the machine type that
> is configured, which means we can't have a single, unified kernel for
> ARCBIOS machines at this stage anyway. For the moment, I'll just hack
> MILO to move the kernel to different places based on the machine type
> and to perform a basic sanity check to make sure that the kernel is
> LD'd to that address, etc.
>
Ok. If you're ready with that, can you send me patches again?
Meanwhile I'll try to build in your latest changes, and together
with the above changes we could release Milo 0.26. Agreed ?
Regarding kernel load address: The best way would of course
be a PIC kernel, but I don't know how reliable PIC currently is.
I would say, leave the "standard" kernel 0x80000000 for know,
just load the RPC44 kernel to a different place. It doesn't hurt
that much not to have a unified kernel for the moment. It's more
important to have a unified loader :-)
Cheers,
Andy
|