On 08/01/12 04:13, Michael Schmitz wrote:
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.
Looking at atafb, we always allocate FB memory from STRAM unless it's an
external video card, i.e. VME, ISA etc.
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?
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
the TT is pretty rare as the only other option is 10MB using the onboard
2MB and an 8MB upgrade board.
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.
Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of
people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.
I'll dig in.
Alan.
--
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
