On Dec 14, 11:10am, Matthias Scheler wrote:
> In article <yam6919.1019.121173336@mail.shadow.net>,
> 	Rafael Munoz <zonum@shadow.net> writes:
> > utils/loadbsd-2.14: Can't copy downwards yet.:
> 
> There is not enough chip memory free to copy the kernel into it.

  No - this means that the kernel image loaded by loadbsd is lower in
memory than the final location of th kernel.  Loadbsd incorrectly checks
for an overlapping copy of the kernel image and displays this message.

  Normally the kernel image created by loadbsd will be at a higher address
than the start of fast memory (since the memory at the start of fast memory
would usually be in use by AmigaDOS and everything else at that time), and
loadbsd is able to copy the kernel image to the start of fastmem without
worrying about an overlapping copy.

  I'd guess in this case the memory is actually in two distinct segments,
which may or may not be contiguous.  The segment with the lower address
is smaller, and is where loadbsd will malloc() the kernel image.  Loadbsd
will detect the larger segment, at the higher address, and choose that as
the kernel location.  When loadbsd decides to not use chipmem for the kernel
image, it sees that the image address is below the final address and complain.

  Loadbsd needs to correctly check for and deal with overlapping copy.

  The easy workaround is to use the -Z option on loadbsd to force the use
of chipmem for loading the kernel (i.e. the kernel image is copied to
chipmem, and the kernel startup copies the kernel image back to fastmem).
This won't work if you don't have enough chip memory to hold the kernel
image though.

  Another workaround would be to allocate the memory in the smaller fastmem
segment, so that when loadbsd loads the image, it uses the largest fastmem
segment.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA