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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
