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 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 contain any flags
> > > like DMA:
> >
> > It does not matter where the bootstrap places the ramdisk data.
>
> I wasn't talking about ramdisk data but about the way the bootstrap
> reports to kernel the available memory.
OK - the bootstrap is supposed to fill in that struct with base address
and size for each chunk. The kernel is supposed to build a map of
available memory from that data (which works fine). It also sets the limit
for DMA-able RAM (which fails).
> > copied to a different (allocated) spot later by the kernel. It just so
> > happens that that spot falls into ST-RAM, and steals our precious ST-RAM.
>
> Do you think we ran out of ST-RAM by adding more Fast RAM? I doubt that.
Nope, rather a different allocation pattern took hold with less memory
available.
> > 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).
Fixing the DMA threshold, I guess.
Michael
Reply to: