AW: [ECOS] cat zImage >/dev/mtd1 does not work
Gary Thomas
gary@mlbassoc.com
Tue Jan 23 20:11:00 GMT 2007
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
More information about the Ecos-discuss
mailing list