Re: Atari TT (next)

[Alan Hourihane <alanh@fairlite.co.uk>]

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.