From: Robert P. J. Day <hidden> Date: 2004-07-01 14:45:41
looking a bit more into command-line flash partitioning, i noticed
the following, and i just want to make sure i understand the current
state of this feature.
first, there's a fair amount of support for CONFIG_MTD_CMDLINE_PARTS
in the current denx (2.4.25) ppc kernel; that is, in the source files
under drivers/mtd/maps. (not yet in rpxlite.c, where i want it, but
it certainly seems straightforward to add it, i'll try that shortly.)
however, in the current 2.6 kernel bk pull from ppc.bkbits.net,
none of those maps files support that feature yet. the kernel itself
clearly lets you select that feature, but none of the drivers yet take
advantage of it, if i read it correctly.
so how is this being added to the files? as in, who will add this
feature to the individual files, and get it pushed upstream, if that's
what's going to happen? just curious as to how this feature will
eventually end up in the mainstream.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: David Woodhouse <dwmw2@infradead.org> Date: 2004-07-01 15:28:18
On Thu, 2004-07-01 at 10:45 -0400, Robert P. J. Day wrote:
so how is this being added to the files? as in, who will add this
feature to the individual files, and get it pushed upstream, if that's
what's going to happen? just curious as to how this feature will
eventually end up in the mainstream.
The owner of each board support ('map') file is expected to make sure
that it's kept up to date in my CVS tree. Periodically I push updates to
Linus, although individuals are welcome to send their own changes to
Linus as soon as they're committed to CVS too.
--
dwmw2
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Robert P. J. Day <hidden> Date: 2004-07-01 16:48:30
On Thu, 1 Jul 2004, David Woodhouse wrote:
On Thu, 2004-07-01 at 10:45 -0400, Robert P. J. Day wrote:
quoted
so how is this being added to the files? as in, who will add this
feature to the individual files, and get it pushed upstream, if that's
what's going to happen? just curious as to how this feature will
eventually end up in the mainstream.
The owner of each board support ('map') file is expected to make sure
that it's kept up to date in my CVS tree. Periodically I push updates to
Linus, although individuals are welcome to send their own changes to
Linus as soon as they're committed to CVS too.
ok, i was just trying to figure out how the different versions of the
kernel i have have such differing levels of that CMDLINE support.
the original kernel tree i have from embedded planet (approx. 2.4.22)
has a small number of map files that make any reference to that
feature. the CVS tree from denx (2.4.25) has considerably more. and
neither the latest "bk pull" of the 2.5/2.6 kernel from bkbits.net, or
the standard 2.6 kernel on my fedora core system has *any* support for
that feature in the map files (even though the kernel has the internal
support).
i was just trying to figure out the logical flow of how that feature
worked its way in. thanks.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Robert P. J. Day <hidden> Date: 2004-07-01 18:17:46
On Thu, 1 Jul 2004, Sylvain Munaut wrote:
Robert P. J. Day wrote:
| and neither the latest "bk pull" of the 2.5/2.6 kernel from
| bkbits.net, or the standard 2.6 kernel on my fedora core system has
| *any* support for that feature in the map files (even though the
| kernel has the internal support).
|
Are you sure about that ?
tnt@246tNt-laptop maps $ grep cmdline *
ceiva.c:static const char *probes[] = { "cmdlinepart", "RedBoot", NULL };
dc21285.c:static const char *probes[] = { "RedBoot", "cmdlinepart",NULL };
edb7312.c:static const char *probes[] = { "RedBoot", "cmdlinepart",NULL };
h720x-flash.c:static const char *probes[] = { "cmdlinepart", NULL };
impa7.c:static const char *probes[] = { "cmdlinepart", NULL };
integrator-flash.c:static const char *probes[] = { "cmdlinepart","RedBoot",
"afs", NULL };
iq80310.c:static const char *probes[] = { "RedBoot", "cmdlinepart",NULL };
ixp4xx.c:static const char *probes[] = { "RedBoot", "cmdlinepart", NULL };
lubbock-flash.c:static const char *probes[] = { "RedBoot","cmdlinepart", NULL
};
physmap.c:const char *part_probes[] = {"cmdlinepart", "RedBoot", NULL};
sa1100-flash.c:const char *part_probes[] = { "cmdlinepart", "RedBoot",NULL };
solutionengine.c:static const char *probes[] = { "RedBoot","cmdlinepart",
NULL };
wr_sbc82xx_flash.c:static const char *part_probes[] __initdata
={"cmdlinepart", "RedBoot", NULL};
oops, i was working off the structure of the older kernel version
where the individual files explicitly checked the value of the config
variable CONFIG_MTD_CMDLINE_PARTS to decide what to do, and that's the
string i was grep'ing for. this clearly changed in the newer files.
mea culpa.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/