From schmitz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Thu Jan 3 02:53:38 2008
Newsgroups:
Date: Thu, 3 Jan 2008 02:53:38 +0100 (CET)
From: Michael Schmitz <schmitz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
To: Petr Stehlik <pstehlik@xxxxxxxxxx>
cc: Michael Schmitz <schmitz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<debian-68k@xxxxxxxxxxxxxxxx>, <linux-m68k@xxxxxxxxxxxxxxx>
Subject: Re: aranym vs atafb
Fcc: sent-mail
In-Reply-To: <1199177610.3941.12.camel@xxxxxxxx>
Message-ID: <Pine.LNX.4.44.0801020514040.27430-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
X-Reply-UID: (2 > )(1 1178187818 6089)/home/opal/schmitz/mail/linux-m68k
X-Reply-Mbox: mail/linux-m68k
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
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 loading of either kernel and/or the
ramdisk to ST-RAM/FastRAM exist only because there is a hidden bug
somewhere in the kernel that prevents running it correctly in FastRAM
(the MFP timer goes crazy when its routine is in FastRAM).
Not sure it started out that way - IIRC on the TT you could run the kernel
in FastRAM OK. The timer issue surfaced with the Afterburner at first. So
ARAnyM loads to ST-RAM always, I guess.
In ARAnyM the bug does not manifest itself (mostly because the MFP
emulation is far from correct) so it actually doesn't matter where the
kernel and ramdisks are located. BTW, looking into
aranym/src/bootos_linux.cpp it seems that FastRAM is preferred for the
ramdisk:
/*--- Copy the ramdisk after kernel (and reserved bootinfo) ---*/
if (ramdisk && ramdisk_length) {
unsigned long rd_start;
unsigned long rd_len;
rd_len = ramdisk_length - RAMDISK_FS_START;
if (FastRAMSize>rd_len) {
/* Load in FastRAM */
rd_start = FastRAMBase;
memcpy(FastRAMBaseHost, ((unsigned char *)ramdisk) + RAMDISK_FS_START,
rd_len);
} else {
/* Load in ST-RAM */
rd_start = RAMSize - rd_len;
memcpy(RAMBaseHost+rd_start, ((unsigned char *)ramdisk) +
RAMDISK_FS_START, rd_len);
}
Right, that matches up with what I printed for initrd start and end
addresses. But the problem is, the ramdisk doesn't stay there, it is
copied to a different location early during boot. That location appears to
be in ST-RAM, and the space is only freed after uncompresing the ramdisk
to yet another location. By that time, it's too late, unless we try and
load the framebuffer as a module.
You could play with the ataboot if you want to load the kernel and
ramdisk to certain type of memory (if you have the latest version - I
remember fixing the loading there).
May do that if I need more rigorous testing.
As to your question regarding the most generic fix: if there really is not
enough ST-RAM (i.e. the available space is taken by the kernel and the
ramdisk, after 'unpacking' the ramdisk to the buffer cache) we'd need to
either make the ramdisk unpack go to non-DMA memory (no idea here;
ideally the buffer cache should not have a preference for DMA memory in
this case), or reserve a chunk of memory up front (tried that in a hackish
way).
Well, I was asking how to properly flag the type of memory, not how to
manage the loading and upacking. IMHO if the size and location of memory
is passed to kernel from the bootstrap then also the bootstrap should
tell the kernel which memory is of which type.
The kernel already has that hardwired: all memory up to 0xffffff is
considered DMA capable. That limit is set in the arch specific code, but
is not honored anywhere in the generic memory management code anymore. My
initial guess at how to set up memory chunks ('nodes' in kernel parlance)
didn't work out too well, though.
As for the loading and unpacking itself - the ST-RAM is 10x slower than
FastRAM (on a real machine) so it shouldn't be used at all. It should be
arranged somehow so that the ST-RAM is kind of last-resort, something
like a slightly faster disk swap.
Thar code was removed in 2.6 because I could not make it work with the
current VFS (swap hadn't required entries in the dentry cache whereas it
now does, or something to that effect). So short of rewriting that code to
the new interface (or claiming ST-RAM for some resizable RAMdisk device),
we would have to change memory allocation priorities to only allocate from
the FastRAM node, unless GFP_DMA is set explicitly. Can we change the
order of the memory nodes to achieve this? Roman? Anyone?
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
