Hi Alan,
You need to reserve ST-RAM for use by late initializing drivers -
stram_pool=512k would be a good start. Not sure this works with only
4MB of ST-RAM though.
I saw this option and I don't understand why it even exists. ST-RAM is
being sent by the bootloader with it's start (0) and size. ST-RAM always
starts at 0. So it's perfectly detectable, so why the need for an option
to specify the ST-RAM pool size ?
The stram_pool option is just to reserve ST-RAM (DMA-capable) that would
otherwise be used by the kernel for other purposes. Atari sets the DMA
memory barrier to the entire memory size, which is wrong in the strict
sense (but cannot be changed easily). Drivers like SCSI and atafb have
to resort to a special purpose memory allocator in order to
claim DMA capable memory.
For this option to work, ST-RAM first has to be accepted by memory init
(i.e. it has to be in the first chunk). We might have to resort to
reserving the entire ST-RAM for the kernel's use if the kernel is not
residing in ST-RAM (breaking the above assumption). Something similar is
done for Amiga chip RAM - exactly how does the chip RAM situation
differ, Geert? Is chip RAM being claimed by mem_init or is it being left
aside?
Come to think of it - does the TT video chipset actually require screen
memory to reside in ST-RAM? If it's fully 32 bit addressed we should not
have any problems with TT-RAM. The problems you see might be caused by a
fault in the TT codepath in atafb - I'm unsure this has been tested
since the last atafb rewrite.
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Fix your bootloader or use a memfile to make use of this area!
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and
hence TT-RAM is listed as the first memory chunk. I don't think
ataboot supports a memfile, so it remains the first chunk?
No, because I don't use "-s" on the bootloader. That means it loads the
kernel in TTRAM.
That's what I meant - the kernel residing in TT-RAM automatically will
map this chunk at kernel virtual address 0x0. Something in our mem_init
logic prevents using RAM with a lower physical address than was used by
the first chunk. I'm quoting from memory here - Roman Zippel might know
the exact answer to this.
Can you try to have the kernel placed in ST-RAM?
I've tried to play around with the MM init code to circumvent this in
the past, to no avail. I think memory chunks have to be listed in
strict order for MM init to work. I don't think reordering the memory
chunk list once the kernel has started will work, so implementing the
memfile option in ataboot may be necessary.
I think anyone with ARanyM should be able to see this problem, by
setting their STRAM to 4MB and removing the "-s" flag from the
bootstra.tos app, to load the kernel in TTRAM.
You're right, this should be possible to test with ARAnyM - the behavior
is not new though. Loading the kernel in TT-RAM has been problematic on
the Falcon for a long time now.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
