Re: aranym vs atafb

Hi, On Tuesday 1. January 2008, Michael Schmitz wrote: > I'm getting a bit confused - the good old mach_max_dma_address variable > does not seem to get used in the recent kernels anymore at all. Could a mm > expert please unravel this mystery? It suffered from bit rot, as atari was the only real

Re: aranym vs. atafb

>From [EMAIL PROTECTED] Thu Jan 3 02:53:38 2008 Newsgroups: Date: Thu, 3 Jan 2008 02:53:38 +0100 (CET) From: Michael Schmitz <[EMAIL PROTECTED]> To: Petr Stehlik <[EMAIL PROTECTED]> cc: Michael Schmitz <[EMAIL PROTECTED]>, , <[EMAIL PROTECTED]> Subject: Re: ara

Re: aranym vs. atafb

> > Sure, that's why we need to make sure the frame buffer is addressable by > > these 23 bits. > > Sure. I just didn't want to say that Fast RAM doesn't support DMA > generally - it might, for some chips, who knows :-) IIRC the ST-DMA only has 22 or 23 address lines, either. > > > > it should be

Re: aranym vs atafb

Michael Schmitz píše v Út 01. 01. 2008 v 04:58 +0100: > Regarding booter options: is there an option to load the kernel to FastRAM > as opposed to ST-RAM, Petr? What is the default here? ARAnyM LILO doesn't have any options, AFAIK. IMHO the various options of ataboot (bootstrap) that allow/force l

Re: aranym vs atafb

Hi all, > > Several fixes are possible; I'll try the most generic one next. > > I am curious what the fix will be (with regard to that Geert's remark). I'm getting a bit confused - the good old mach_max_dma_address variable does not seem to get used in the recent kernels anymore at all. Could a m

Re: aranym vs atafb

Michael Schmitz píše v So 29. 12. 2007 v 00:50 +0100: > > > If Fast RAM doesn't support DMA > > > > VIDEL has just 23 address wires... > > Sure, that's why we need to make sure the frame buffer is addressable by > these 23 bits. Sure. I just didn't want to say that Fast RAM doesn't support DMA ge

Re: aranym vs atafb

> > If Fast RAM doesn't support DMA > > VIDEL has just 23 address wires... Sure, that's why we need to make sure the frame buffer is addressable by these 23 bits. > > it should be added as non-DMA'ble memory. > > where can this be set? The bootstrap uses the following struct for > passing the ava

Re: aranym vs atafb

Hi, > > > So the question is how the atafb decides where to put the videoram and > > > why is it related to FastRAM size... Because __get_free_pages and friends allocate memory off the top of RAM? Would that explain the behavior? > > > > I have just 2.6.22 source and there the screen_base is set

Re: aranym vs atafb

Geert Uytterhoeven píše v Pá 28. 12. 2007 v 14:27 +0100: > If Fast RAM doesn't support DMA VIDEL has just 23 address wires... > it should be added as non-DMA'ble memory. where can this be set? The bootstrap uses the following struct for passing the available memory to kernel and it doesn't cont

Re: aranym vs atafb

On Fri, Dec 28, 2007 at 10:25:14AM +0100, Petr Stehlik wrote: > Stephen R Marenka píše v St 26. 12. 2007 v 15:40 -0600: > > > I've been trying to get d-i initrds to work with aranym without > > trashing the screen [0]. I noticed something interesting in my testing > > today. > > > > [0]

Re: aranym vs atafb

On Fri, 28 Dec 2007, Petr Stehlik wrote: > Petr Stehlik p��e v P� 28. 12. 2007 v 10:42 +0100: > > 128 MB: screen_base 00b0 > > 192 MB: screen_base 0170 > > 256 MB: screen_base 0160 > > > > So the question is how the atafb decides where to put the videoram and > > why is it related to F

Re: aranym vs atafb

Petr Stehlik píše v Pá 28. 12. 2007 v 10:42 +0100: > 128 MB: screen_base 00b0 > 192 MB: screen_base 0170 > 256 MB: screen_base 0160 > > So the question is how the atafb decides where to put the videoram and > why is it related to FastRAM size... I have just 2.6.22 source and there the

Re: aranym vs atafb

Michael Schmitz píše v Pá 28. 12. 2007 v 04:09 +0100: > That does probably steal our precious ST-RAM space. > > I guess I'll have to just allocate the required ST-RAM for atafb early Look at this: 64 MB of FastRAM: Memory: 68184k/68252k available (1956k kernel code, 9568k data, 100k init) a

Re: aranym vs atafb

Stephen R Marenka píše v St 26. 12. 2007 v 15:40 -0600: > I've been trying to get d-i initrds to work with aranym without > trashing the screen [0]. I noticed something interesting in my testing > today. > > [0] > > With the same kernel (2.6.18-4)

Re: aranym vs atafb

On Fri, Dec 28, 2007 at 12:19:18AM +0100, Michael Schmitz wrote: > OTOH, borked hardware design may well have been a hallmark of m68k > personal computers (look at the Mac for the real weird stuff). Whatever. What else is there to say? ;) Pushing the limits with underpowered hardware! Peace, S

Re: aranym vs atafb

On Fri, Dec 28, 2007 at 04:09:21AM +0100, Michael Schmitz wrote: > (found in arch/m68k/kernel/setup.c) > > That address is a virtual address, but (at least on my setup) the kernel > virtual addresses are identity mapped to physical. So the ramdisk > (compressed) resides in TT RAM or FastRAM. The

Re: aranym vs atafb

> > > The ramdisk load code needs to make sure a ramdisk is not loaded where it > > > might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce > > > buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the > > > kernel loaded in ST-RAM also? > > > > How do I find ou

Re: aranym vs atafb

> > IIRC any addresses in that range (i.e. above 0xff) are aliased down to > > fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL > > needs to use ST-RAM). Basically, you used up all available ST-RAM with the > > ramdisk and now force the framebuffer to use an invalid addres

Re: aranym vs atafb

On Thu, Dec 27, 2007 at 04:21:13AM +0100, Michael Schmitz wrote: > > I've been trying to get d-i initrds to work with aranym without > > trashing the screen [0]. I noticed something interesting in my testing > > today. > IIRC any addresses in that range (i.e. above 0xff) are aliased down to >

Re: aranym vs atafb

Hi, > I've been trying to get d-i initrds to work with aranym without > trashing the screen [0]. I noticed something interesting in my testing > today. > > [0] > > With the same kernel (2.6.18-4) and args ... > > Args = root=/dev/ram load_ramdisk=1

aranym vs atafb

Howdy, I've been trying to get d-i initrds to work with aranym without trashing the screen [0]. I noticed something interesting in my testing today. [0] With the same kernel (2.6.18-4) and args ... Args = root=/dev/ram load_ramdisk=1 ramdisk_size