> 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 :-)