Ingo Jürgensmann dixit: >Or even easier: we know that memory on accelerator cards will be >located at 0x08000000 (didn't count the zeros ;) and should have the
Oh, please not… Geert Uytterhoeven dixit: >On Sun, Dec 8, 2013 at 10:58 PM, Michael Schmitz >> It already is (has to be, due to lack of sparse mem support). And the kernel >> lives in ST-RAM pretty much always. > >I know it is, but TT-RAM should be faster, right? The kernel can also be loaded to TT-RAM by some of the bootloader versions, IIRC… but AFAIR then it could not use the ST-RAM because it assumed that the first chunk was the lowest, or something. All of these (plus the sheer amount of m68k variants – there are the VME, Q40/Q60, and even more, still) just cry for flexible memory layouts, in priority, order of allocation, speed, physical layout etc. (and hardware‐ specific allocation rules like framebuffer must reside in ST-RAM). >>> Alternatively, it could be done automatically, by the kernel >>> measuring read (and/or write) performance of the different memory >>> chunks in a loop similar to the delay loop calibration. >As long as you read enough data, it should be OK. Sounds interesting, as long as someone defines “enough” ☺ bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312092051210.25...@herc.mirbsd.org
