AW: [ECOS] cat zImage >/dev/mtd1 does not work

AW: [ECOS] cat zImage >/dev/mtd1 does not work

[Neundorf, Alexander]

> Von: ecos-discuss-owner@ecos.sourceware.org
> 
> Hi, 
> 
> I'm running snapgear-3.4.0 on an IXDP425 board with RedBoot as 
> the bootloader and I want to
> be able to upgrade my kernel and filesystem, i.e., zImage and 
> ramdisk.gz on the flash, under Linux.
> 
> So I shipped the zImage and ramdisk.gz onto the running system
> and did
>     # cat zImage >/dev/mtd1
>     # cat ramdisk.gz >/dev/mtd2
> 
> after eraseall the two partitions. To my surprise, when I reboot,
> RedBoot gave 
>                         RedBoot> fis load ramdisk             
>                 
>                         ** Warning - checksum failure.  
> stored: 0x33dbe19b, computed:
>                         0xc9d7dfef                            
>                 
>                         RedBoot> fis load kernel              
>                 
>                         ** Warning - checksum failure.  
> stored: 0xfb99dd45, computed:
>                         0x788bb713                            
>                 
>                         RedBoot> exec -c 
> "console=ttyS0,115200 root=/dev/ram0 
>                         initrd=0x00800000,6M 
> mem=32M@0x00000000" 0x01600000   
>                         Can't execute Linux - invalid entry 
> address           
> and refused to boot.
> 
> I understand here the newly flashed images (as it was not 
> done in RedBoot but in the OS) may
> not have the same checksum as RedBoot calculated for the 
> earlier images. And this caused the problem.

When Redboot stores an image, it stores:
-the actual data length
-the size of the "partition"
-the calculated checksum

If the checksum doesn't match, it fails.
If the actual size of the kernel is bigger than what it stored in the FIS, it won't load everything and it probably will not work.

You could:
-disable the checksum in Redboot, I think this is possible via a cdl option
-when storing the kernel via Redboot, use the partition size also as data length, so it will always load everything as long as it fits in the partition.

Bye
Alex

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

[ECOS] Ecos/redboot on Xscale pxa270

[tejas pawaskar]

Greetings,

I am building redboot bootloader for xscale pxa270.
I have created templates and packages required for my
board.
Even i have made the necessary changes in
hal_platform_setup.h to initialize to my board.
I am using pxa270's FFUART as serial console.

My problem is after the initialization i can view
serial characters on terminal but at a point
particular when calling hal_hardware_init from
Vector.S. no further execution takes place.

When we debugged the code, we have observed that after
3 i.e LED 3 which is in Vector.S the execution is as
follows:-
   a. Calls /hal_hardware_init/ function which is in
/pxa2x0_misc.c/, entering the function it calls
/plf_hardware_init/ which is in /quantum_misc.c/,
entering the function it calls /hal_if_init /which is
in /hal_if.c
   /b. We have entered characters in each of the
function which can be seen on terminal so that we can
come to know the point where the execution gets halt.
   c. We have observed that in hal_if_init function it
calls
set_debug_comm(CYGNUM_CALL_IF_SET_COMM_ID_EMPTY);
       it enters in this function, but then it doesn't
returns from it.
We felt that either RAM or stack could be the cause
for it, but RAM is not an issue since we tested out by
writing and reading the RAM.
We have certain doubts over the stack, since we could
not locate the point where stack size is initialized
and where the stack pointer is pointing.
Before mmu init we printed the stack pointer value
which was 0xa0009a8c after the initialisation from the
plf_hardware_init function the stack pointer value was
0x00009a70.
From this we feel that the processor works on virtual
addresses after mmu init. Are we right about it? 

Has any one came across such problem?
Or does any one has better solution or process to
build the redboot for pxa270?

has any one succesfully ported redboot on pxa270 and
achieved the serial output thru FFUART on the
terminal.

Thanks with kind regards,
Tejas Pawaskar



		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

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

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

[Weiguang Shi]

Thanks very much Alex. That makes things clear.

Now for the CDL (please excuse me since I'm a newbie
to RedBoot), could you explain more? Do I need to build
Redboot with the correct options and store it in the
flash?

Thanks again.
Wei

--- "Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> wrote:

> > Von: ecos-discuss-owner@ecos.sourceware.org
> > 
> > Hi, 
> > 
> > I'm running snapgear-3.4.0 on an IXDP425 board with RedBoot as 
> > the bootloader and I want to
> > be able to upgrade my kernel and filesystem, i.e., zImage and 
> > ramdisk.gz on the flash, under Linux.
> > 
> > So I shipped the zImage and ramdisk.gz onto the running system
> > and did
> >     # cat zImage >/dev/mtd1
> >     # cat ramdisk.gz >/dev/mtd2
> > 
> > after eraseall the two partitions. To my surprise, when I reboot,
> > RedBoot gave 
> >                         RedBoot> fis load ramdisk             
> >                 
> >                         ** Warning - checksum failure.  
> > stored: 0x33dbe19b, computed:
> >                         0xc9d7dfef                            
> >                 
> >                         RedBoot> fis load kernel              
> >                 
> >                         ** Warning - checksum failure.  
> > stored: 0xfb99dd45, computed:
> >                         0x788bb713                            
> >                 
> >                         RedBoot> exec -c 
> > "console=ttyS0,115200 root=/dev/ram0 
> >                         initrd=0x00800000,6M 
> > mem=32M@0x00000000" 0x01600000   
> >                         Can't execute Linux - invalid entry 
> > address           
> > and refused to boot.
> > 
> > I understand here the newly flashed images (as it was not 
> > done in RedBoot but in the OS) may
> > not have the same checksum as RedBoot calculated for the 
> > earlier images. And this caused the problem.
> 
> When Redboot stores an image, it stores:
> -the actual data length
> -the size of the "partition"
> -the calculated checksum
> 
> If the checksum doesn't match, it fails.
> If the actual size of the kernel is bigger than what it stored in the FIS, it won't load
> everything and it probably will not work.
> 
> You could:
> -disable the checksum in Redboot, I think this is possible via a cdl option
> -when storing the kernel via Redboot, use the partition size also as data length, so it will
> always load everything as long as it fits in the partition.
> 
> Bye
> Alex
> 
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 



 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

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

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

[Andrew Lunn]

On Fri, Jan 19, 2007 at 08:50:31AM -0800, Weiguang Shi wrote:
> Thanks very much Alex. That makes things clear.
> 
> Now for the CDL (please excuse me since I'm a newbie
> to RedBoot), could you explain more? Do I need to build
> Redboot with the correct options and store it in the
> flash?

Yes.

Look at the redboot user manual which includes information about how
to build redboot.

   Andrew

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

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

[Gary Thomas]

Weiguang Shi wrote:
> Thanks very much Alex. That makes things clear.
> 
> Now for the CDL (please excuse me since I'm a newbie
> to RedBoot), could you explain more? Do I need to build
> Redboot with the correct options and store it in the
> flash?

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.

> 
> --- "Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> wrote:
> 
>>> Von: ecos-discuss-owner@ecos.sourceware.org
>>>
>>> Hi, 
>>>
>>> I'm running snapgear-3.4.0 on an IXDP425 board with RedBoot as 
>>> the bootloader and I want to
>>> be able to upgrade my kernel and filesystem, i.e., zImage and 
>>> ramdisk.gz on the flash, under Linux.
>>>
>>> So I shipped the zImage and ramdisk.gz onto the running system
>>> and did
>>>     # cat zImage >/dev/mtd1
>>>     # cat ramdisk.gz >/dev/mtd2
>>>
>>> after eraseall the two partitions. To my surprise, when I reboot,
>>> RedBoot gave 
>>>                         RedBoot> fis load ramdisk             
>>>                 
>>>                         ** Warning - checksum failure.  
>>> stored: 0x33dbe19b, computed:
>>>                         0xc9d7dfef                            
>>>                 
>>>                         RedBoot> fis load kernel              
>>>                 
>>>                         ** Warning - checksum failure.  
>>> stored: 0xfb99dd45, computed:
>>>                         0x788bb713                            
>>>                 
>>>                         RedBoot> exec -c 
>>> "console=ttyS0,115200 root=/dev/ram0 
>>>                         initrd=0x00800000,6M 
>>> mem=32M@0x00000000" 0x01600000   
>>>                         Can't execute Linux - invalid entry 
>>> address           
>>> and refused to boot.
>>>
>>> I understand here the newly flashed images (as it was not 
>>> done in RedBoot but in the OS) may
>>> not have the same checksum as RedBoot calculated for the 
>>> earlier images. And this caused the problem.
>> When Redboot stores an image, it stores:
>> -the actual data length
>> -the size of the "partition"
>> -the calculated checksum
>>
>> If the checksum doesn't match, it fails.
>> If the actual size of the kernel is bigger than what it stored in the FIS, it won't load
>> everything and it probably will not work.
>>
>> You could:
>> -disable the checksum in Redboot, I think this is possible via a cdl option
>> -when storing the kernel via Redboot, use the partition size also as data length, so it will
>> always load everything as long as it fits in the partition
> 

-- 
------------------------------------------------------------
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

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

[Weiguang Shi]

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?

Thanks!
Wei

--- 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.
> 



 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

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

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

[Gary Thomas]

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
------------------------------------------------------------

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

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

[Weiguang Shi]

That sounds great. Thanks!

Wei

--- 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
> ------------------------------------------------------------
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

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

[Weiguang Shi]

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?

Thanks very much again!
Wei


--- 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
> ------------------------------------------------------------
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

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

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

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

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
------------------------------------------------------------

[-- Attachment #2: mtd.patch --]
[-- Type: text/x-patch, Size: 1690 bytes --]

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;
 


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

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

[Weiguang Shi]

Thanks again.

My system is 2.4.x under snapgear-3.4.0 and I applied only the following part of the patch
since this only seems to be relevant.

   #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);
                    }
                }


When I tried to cat the modified ram image for the FIS partition back to /dev/mtd4
I still get 
      
    cat: Write Error: Read-only file system

Wei

--- 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;
>  
> 
> > -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

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

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

[Gary Thomas]

Weiguang Shi wrote:
> Thanks again.
> 
> My system is 2.4.x under snapgear-3.4.0 and I applied only the following part of the patch
> since this only seems to be relevant.
> 
>    #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);
>                     }
>                 }
> 
> 
> When I tried to cat the modified ram 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;
>>  
>>
>>> -- 
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 
>  
> ____________________________________________________________________________________
> It's here! Your new message!  
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/


-- 
------------------------------------------------------------
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

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

[Weiguang Shi]

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?


> 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;
> >>  
> >>
> >>> -- 
> >> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> >> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> > 
> > 
> > 
> >  
> > ____________________________________________________________________________________
> > It's here! Your new message!  
> > Get new email alerts with the free Yahoo! Toolbar.
> > http://tools.search.yahoo.com/toolbar/features/mail/
> 
> 
> -- 
> ------------------------------------------------------------
> 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
> 
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

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

[Gary Thomas]

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

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

[Weiguang Shi]

I was finally able to update the FIS directory which coexists with another 
partition on the same erase block.

- First, apply your patch to redboot.c
- Second, remove the code in mtdpart.c that marks partitions not 
  starting/ending on an erase block readonly
- Third, unlock (a utility in mtd-utils) the partition before 
  writing anything onto it.

Thanks and Cheers!
Wei

--- Gary Thomas <gary@mlbassoc.com> wrote:

> 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
> 
=== message truncated ===



 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

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