This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: AW: cat zImage >/dev/mtd1 does not work

From: Gary Thomas <gary at mlbassoc dot com>
To: Weiguang Shi <wgshizz at yahoo dot com>
Cc: ecos-discuss <ecos-discuss at ecos dot sourceware dot org>
Date: Tue, 23 Jan 2007 13:11:13 -0700
Subject: Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work
References: <804814.62549.qm@web30410.mail.mud.yahoo.com>

Weiguang Shi wrote:

I have to make it work, old or new ;-) So I've been trying to apply your patch
to 2.6.18 in a way that makes sense in uClinux-2.4.x.

The patch consists three parts and, besides the one I tried, there are (I patched and diff'ed them)

   87a88,91
   >                 if (buf[i].name[0] == 0xff) {
   >                         i = numslots;
   >                         break;
   >                 }

and 127c131 < continue; --- > break;

It appears to me that 0xff is significant in both parts. What does it mean?
I haven't been able to figure out how either will enable writing.

As my node starts up, I saw in the sequence 0x003e0000-0x003ff000 : "FIS directory" mtd: partition "FIS directory" doesn't end on an erase block -- force read-only 0x003ff000-0x00400000 : "RedBoot config" mtd: partition "RedBoot config" doesn't start on an erase block boundary -- force read-only

can I remove the code that forced read-only (in mtdpart.c) at start up as an alternative to
applying your patch?

Thanks!
Wei


In addition, I found this piece of code in redboot.c confusing.
   #ifdef CONFIG_MTD_REDBOOT_PARTS_READONLY
                if (!memcmp(names, "RedBoot", 8) ||
                                !memcmp(names, "RedBoot config", 15) ||
                                !memcmp(names, "FIS directory", 14)) {
                        parts[i].mask_flags = MTD_WRITEABLE;
                }

That is, if CONFIG_MTD_REDBOOT_PARTS_READONLY is defined, the partitions, "RedBoot",
"RedBoot config", and "FIS directory", are set writeable! Can you shed some light?

It looks like a bug; I'm not interested in pursuing it at the moment.

Replace the section bounded by

#ifdef CONFIG_MTD_REDBOOT_PARTS_READONLY
#endif

with

#ifdef CONFIG_MTD_REDBOOT_PARTS_READONLY if (!memcmp(names, "RedBoot", 8) || !memcmp(names, "RedBoot config", 15) || !memcmp(names, "FIS directory", 14)) { parts[i].mask_flags = MTD_WRITEABLE; } #else if (!memcmp(names, "FIS directory", 14)) { // Special hack to let directory be read/write if ((fl->img->size & (master->erasesize - 1)) != 0) { parts[i].size = (fl->img->size + (master->erasesize - 1)) & ~(master->erasesize - 1); } } #endif

Make sure you disable MTD_REDBOOT_PARTS_READONLY in your configuration.

image for the FIS partition back to /dev/mtd4
I still get cat: Write Error: Read-only file system
You missed the part of the patch that allows the FIS directory to be
writable even if you have combined FIS & FCONFIG.  I don't have such an
old system, so you'll need to figure out how to get that code in.
--- Gary Thomas <gary@mlbassoc.com> wrote:
Weiguang Shi wrote:
Gary,
I'm at the point to flash the modified partition back but can't erase the
FIS partition /dev/mtd4
   # cat /proc/mtd
   dev:    size   erasesize  name
   mtd0: 00080000 00020000 "RedBoot"
   mtd1: 00100000 00020000 "kernel"
   mtd2: 00200000 00020000 "ramdisk"
   mtd3: 00020000 00020000 "kiyon_config"
   mtd4: 0001f000 00020000 "FIS directory"
   mtd5: 00001000 00020000 "RedBoot config"
   # eraseall /dev/mtd4
   eraseall: /dev/mtd4: Permission denied
I realized that I may need to "unlock" it but both my attempts to do that in RedBoot and Linux failed. In the former, "fis unlock" worked fine in Redboot but after Linux boots up I still get the same "Permission denied" error. In linux, my unlock resulted in # unlock /dev/mtd4 Could not open mtd device: /dev/mtd4 # unlock /dev/mtd5 Could not open mtd device: /dev/mtd5

Any ideas on how shall I proceed?
The problem is that if you use combined FIS directory and FCONFIG data
(which you are based on the map above), then the MTD layer makes both of
those images read only.  The attached patch can let you override this.
It's based on the public 2.6.18 kernel.
Note: you need to be careful doing these changes to your FLASH.  If you
simply erase the partition, RedBoot will lose everything.  MTD is pretty
cool and if you simply open /dev/mtd4 read/write, read the current contents,
update them and then rewrite them, the MTD layer will take care of erasing
and updating the appropriate portions.
--- Gary Thomas <gary@mlbassoc.com> wrote:
Weiguang Shi wrote:
That's even better and was the solution that I was looking for. The question is how, from the OS, can I update the FIS. Obviously I need to know the structure of the "FIS directory" partition and find the offset of that checksum and insert a '0' there by - reading the whole partition into ram, - changing the bit, erasing the partition on the flash, - and finally flashing the modified partition in the ram back.

Any suggestions as to where to start?
<redboot/fis.h>
Also, drivers/mtd has some RedBoot FIS parsing code in it.  You could
look at it for pointers.
--- Gary Thomas <gary@mlbassoc.com> wrote:
Note: you don't really need to change RedBoot.  Just update the
FIS [directory] entry for the image you are changing, either with
the corrected checksum, or the value 0.  RedBoot ignores the checksum
when the stored value is 0.
--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
diff -ubNr --exclude=.gitignore linux-2.6.18/drivers/mtd/redboot.c
/tmp/fc_base/opt/amltd/develop/linuxppc-2.6/drivers/mtd/redboot.c --- linux-2.6.18/drivers/mtd/redboot.c 2006-09-19 21:42:06.000000000 -0600 +++ /tmp/fc_base/opt/amltd/develop/linuxppc-2.6/drivers/mtd/redboot.c 2006-10-24 11:59:32.000000000 -0600 @@ -85,6 +85,10 @@ numslots = (master->erasesize / sizeof(struct fis_image_desc)); for (i = 0; i < numslots; i++) { + if (buf[i].name[0] == 0xff) { + i = numslots; + break; + } if (!memcmp(buf[i].name, "FIS directory", 14)) { /* This is apparently the FIS directory entry for the * FIS directory itself. The FIS directory size is @@ -124,7 +128,7 @@ struct fis_list *new_fl, **prev; if (buf[i].name[0] == 0xff) - continue; + break; if (!redboot_checksum(&buf[i])) break; @@ -196,14 +200,22 @@ parts[i].size = fl->img->size; parts[i].offset = fl->img->flash_base; parts[i].name = names; - strcpy(names, fl->img->name); + #ifdef CONFIG_MTD_REDBOOT_PARTS_READONLY if (!memcmp(names, "RedBoot", 8) || !memcmp(names, "RedBoot config", 15) || !memcmp(names, "FIS directory", 14)) { parts[i].mask_flags = MTD_WRITEABLE; } +#else + if (!memcmp(names, "FIS directory", 14)) { + // Special hack to let directory be read/write + if ((fl->img->size & (master->erasesize - 1)) != 0) { + parts[i].size = (fl->img->size + (master->erasesize - 1)) & ~(master->erasesize - 1); + } + } + #endif names += strlen(names)+1;


--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Follow-Ups:
- Re: AW: cat zImage >/dev/mtd1 does not work
  - From: Weiguang Shi

References:
- Re: AW: cat zImage >/dev/mtd1 does not work
  - From: Weiguang Shi

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]