From: Greg Ungerer <gerg@snapgear.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
linux-mtd@lists.infradead.org,
Mike Frysinger <vapier.adi@gmail.com>,
kernel@pengutronix.de, Greg Ungerer <gerg@uclinux.org>
Subject: Re: [PATCH 1/2 RFC v2] mtd/uclinux: support ROM and allow passing the base address
Date: Mon, 15 Oct 2012 14:14:55 +1000 [thread overview]
Message-ID: <507B8DBF.2030104@snapgear.com> (raw)
In-Reply-To: <1350027693-19528-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On 12/10/12 17:41, Uwe Kleine-König wrote:
> This allows to put the filesystem at a defined address in ROM allowing
> to save more precious RAM.
>
> I think it's save to default to ROM because the intention of using the
^^^^
safe
> uclinux map is to use a romfs and so mtd-ram doesn't give you anything
> that mtd-rom doesn't.
>
> Signed-off-by: Uwe Kleine-K÷nig <u.kleine-koenig@pengutronix.de>
Unfortunately email to me goes through an exchange server and openchange,
and it manages to often mangle anything more than 7bit ascii. Not too
much I can do about it, sorry.
> Changed since (implicit) v1:
>
> - don't make uclinux_ram_map static as pointed out by Mike and Greg.
>
> drivers/mtd/maps/Kconfig | 2 +-
> drivers/mtd/maps/uclinux.c | 28 ++++++++++++++++++++++------
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> index 5ba2458..d945950 100644
> --- a/drivers/mtd/maps/Kconfig
> +++ b/drivers/mtd/maps/Kconfig
> @@ -443,7 +443,7 @@ config MTD_GPIO_ADDR
>
> config MTD_UCLINUX
> bool "Generic uClinux RAM/ROM filesystem support"
> - depends on MTD_RAM=y && !MMU
> + depends on (MTD_RAM=y || MTD_ROM=y) && !MMU
> help
> Map driver to support image based filesystems for uClinux.
>
> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
> index c3bb304..f5e8e9a 100644
> --- a/drivers/mtd/maps/uclinux.c
> +++ b/drivers/mtd/maps/uclinux.c
> @@ -24,11 +24,12 @@
> /****************************************************************************/
>
> struct map_info uclinux_ram_map = {
> - .name = "RAM",
> - .phys = (unsigned long)__bss_stop,
> .size = 0,
> };
>
> +static unsigned long physaddr = -1;
> +module_param(physaddr, ulong, S_IRUGO);
> +
> static struct mtd_info *uclinux_ram_mtdinfo;
>
> /****************************************************************************/
> @@ -60,11 +61,17 @@ static int __init uclinux_mtd_init(void)
> struct map_info *mapp;
>
> mapp = &uclinux_ram_map;
> +
> + if (physaddr == -1)
> + mapp->phys = (resource_size_t)__bss_stop;
> + else
> + mapp->phys = physaddr;
> +
> if (!mapp->size)
> mapp->size = PAGE_ALIGN(ntohl(*((unsigned long *)(mapp->phys + 8))));
> mapp->bankwidth = 4;
>
> - printk("uclinux[mtd]: RAM probe address=0x%x size=0x%x\n",
> + printk("uclinux[mtd]: RAM/ROM probe address=0x%x size=0x%x\n",
> (int) mapp->phys, (int) mapp->size);
Is there any value in saying "RAM/ROM"?
Why don't we just drop those chars altogether.
>
> mapp->virt = ioremap_nocache(mapp->phys, mapp->size);
> @@ -76,9 +83,18 @@ static int __init uclinux_mtd_init(void)
>
> simple_map_init(mapp);
>
> - mtd = do_map_probe("map_ram", mapp);
> + mapp->name = "ROM";
> + mtd = do_map_probe("map_rom", mapp);
> + if (!mtd) {
> + /* fall back to ram probing for compatibility reasons */
> + mapp->name = "RAM";
> + mtd = do_map_probe("map_ram", mapp);
> + if (mtd && IS_ENABLED(CONFIG_MTD_ROM))
> + pr_err("Failed to map rom, but ram succeeded. Please report this issue!\n");
Do we really want this message?
My predominate usage of this code is in RAM mappings. Network
loading kernel+filesystem images on bare boards. Anyone who wants
to know and is looking in the kernel boot messages will see
something like:
Creating 1 MTD partitions on "RAM":
0x000000000000-0x0000000d8000 : "ROMfs"
So they will know what type of mapping it was loaded from.
> + }
> +
> if (!mtd) {
> - printk("uclinux[mtd]: failed to find a mapping?\n");
> + printk("uclinux[mtd]: failed to find a rom/ram mapping?\n");
Again, is there any point in changing this message?
Adding "rom/ram" doesn't add any value here.
Regards
Greg
> iounmap(mapp->virt);
> return(-ENXIO);
> }
> @@ -115,6 +131,6 @@ module_exit(uclinux_mtd_cleanup);
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Greg Ungerer <gerg@snapgear.com>");
> -MODULE_DESCRIPTION("Generic RAM based MTD for uClinux");
> +MODULE_DESCRIPTION("Generic RAM/ROM based MTD for uClinux");
>
> /****************************************************************************/
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
next prev parent reply other threads:[~2012-10-15 4:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 15:25 [PATCH] [RFC] mtd/uclinux: support ROM and allow passing the base address Uwe Kleine-König
2012-10-09 3:29 ` Greg Ungerer
2012-10-09 8:44 ` Uwe Kleine-König
2012-10-09 10:37 ` Greg Ungerer
2012-10-10 7:58 ` Uwe Kleine-König
2012-10-12 4:46 ` Mike Frysinger
2012-10-12 5:57 ` Greg Ungerer
2012-10-12 7:22 ` Uwe Kleine-König
2012-10-12 16:09 ` Mike Frysinger
2012-10-12 16:22 ` Mike Frysinger
2012-10-15 14:00 ` Artem Bityutskiy
2012-10-11 4:21 ` Mike Frysinger
2012-10-11 6:13 ` Uwe Kleine-König
2012-10-12 7:41 ` Uwe Kleine-König
2012-10-12 16:18 ` Mike Frysinger
2012-10-12 7:41 ` [PATCH 1/2 RFC v2] " Uwe Kleine-König
2012-10-12 7:41 ` [PATCH 2/2] mtd/uclinux: add a comment about why uclinux_ram_map must not be static Uwe Kleine-König
2012-10-12 16:23 ` Mike Frysinger
2012-10-15 4:15 ` Greg Ungerer
2012-10-15 4:14 ` Greg Ungerer [this message]
2012-10-15 6:58 ` [PATCH 1/2 RFC v2] mtd/uclinux: support ROM and allow passing the base address Uwe Kleine-König
2012-10-16 1:13 ` Greg Ungerer
2012-10-16 6:56 ` Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=507B8DBF.2030104@snapgear.com \
--to=gerg@snapgear.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=gerg@uclinux.org \
--cc=kernel@pengutronix.de \
--cc=linux-mtd@lists.infradead.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vapier.adi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox