Re: Atari TT (next)

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

On 07/01/12 06:47, Michael Schmitz wrote:
> Hi Guys,
>> O.k. I'm passed the unexpected interrupt problem.
>>
>> Now the next problem is that the console is all corrupted because atafb
>> initializes and shows this...
>>
>> atafb_init: start
>> atafb_init: initializing TT hw
>> atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
>> Determined 640x480, depth 4
>>    virtual 640x972
>>
>> Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
> 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 ?


>> 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.



> 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.

Alan.