* AW: [ECOS] cat zImage >/dev/mtd1 does not work
@ 2007-01-19 7:48 Neundorf, Alexander
2007-01-19 9:00 ` [ECOS] Ecos/redboot on Xscale pxa270 tejas pawaskar
2007-01-19 16:50 ` AW: [ECOS] cat zImage >/dev/mtd1 does not work Weiguang Shi
0 siblings, 2 replies; 15+ messages in thread
From: Neundorf, Alexander @ 2007-01-19 7:48 UTC (permalink / raw)
To: ecos-discuss
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Ecos/redboot on Xscale pxa270 2007-01-19 7:48 AW: [ECOS] cat zImage >/dev/mtd1 does not work Neundorf, Alexander @ 2007-01-19 9:00 ` tejas pawaskar 2007-01-19 16:50 ` AW: [ECOS] cat zImage >/dev/mtd1 does not work Weiguang Shi 1 sibling, 0 replies; 15+ messages in thread From: tejas pawaskar @ 2007-01-19 9:00 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 7:48 AW: [ECOS] cat zImage >/dev/mtd1 does not work Neundorf, Alexander 2007-01-19 9:00 ` [ECOS] Ecos/redboot on Xscale pxa270 tejas pawaskar @ 2007-01-19 16:50 ` Weiguang Shi 2007-01-19 16:53 ` Andrew Lunn 2007-01-19 17:50 ` Gary Thomas 1 sibling, 2 replies; 15+ messages in thread From: Weiguang Shi @ 2007-01-19 16:50 UTC (permalink / raw) To: Neundorf, Alexander, ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 16:50 ` AW: [ECOS] cat zImage >/dev/mtd1 does not work Weiguang Shi @ 2007-01-19 16:53 ` Andrew Lunn 2007-01-19 17:50 ` Gary Thomas 1 sibling, 0 replies; 15+ messages in thread From: Andrew Lunn @ 2007-01-19 16:53 UTC (permalink / raw) To: Weiguang Shi; +Cc: Neundorf, Alexander, ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 16:50 ` AW: [ECOS] cat zImage >/dev/mtd1 does not work Weiguang Shi 2007-01-19 16:53 ` Andrew Lunn @ 2007-01-19 17:50 ` Gary Thomas 2007-01-19 18:08 ` Weiguang Shi 1 sibling, 1 reply; 15+ messages in thread From: Gary Thomas @ 2007-01-19 17:50 UTC (permalink / raw) To: Weiguang Shi; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 17:50 ` Gary Thomas @ 2007-01-19 18:08 ` Weiguang Shi 2007-01-19 18:18 ` Gary Thomas 0 siblings, 1 reply; 15+ messages in thread From: Weiguang Shi @ 2007-01-19 18:08 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 18:08 ` Weiguang Shi @ 2007-01-19 18:18 ` Gary Thomas 2007-01-19 18:28 ` Weiguang Shi 2007-01-20 2:00 ` Weiguang Shi 0 siblings, 2 replies; 15+ messages in thread From: Gary Thomas @ 2007-01-19 18:18 UTC (permalink / raw) To: Weiguang Shi; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 18:18 ` Gary Thomas @ 2007-01-19 18:28 ` Weiguang Shi 2007-01-20 2:00 ` Weiguang Shi 1 sibling, 0 replies; 15+ messages in thread From: Weiguang Shi @ 2007-01-19 18:28 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-19 18:18 ` Gary Thomas 2007-01-19 18:28 ` Weiguang Shi @ 2007-01-20 2:00 ` Weiguang Shi 2007-01-20 13:46 ` Gary Thomas 1 sibling, 1 reply; 15+ messages in thread From: Weiguang Shi @ 2007-01-20 2:00 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-20 2:00 ` Weiguang Shi @ 2007-01-20 13:46 ` Gary Thomas 2007-01-23 2:08 ` Weiguang Shi 0 siblings, 1 reply; 15+ messages in thread From: Gary Thomas @ 2007-01-20 13:46 UTC (permalink / raw) To: Weiguang Shi; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-20 13:46 ` Gary Thomas @ 2007-01-23 2:08 ` Weiguang Shi 2007-01-23 8:42 ` Gary Thomas 0 siblings, 1 reply; 15+ messages in thread From: Weiguang Shi @ 2007-01-23 2:08 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-23 2:08 ` Weiguang Shi @ 2007-01-23 8:42 ` Gary Thomas 2007-01-23 19:34 ` Weiguang Shi 0 siblings, 1 reply; 15+ messages in thread From: Gary Thomas @ 2007-01-23 8:42 UTC (permalink / raw) To: Weiguang Shi; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-23 8:42 ` Gary Thomas @ 2007-01-23 19:34 ` Weiguang Shi 2007-01-23 20:11 ` Gary Thomas 0 siblings, 1 reply; 15+ messages in thread From: Weiguang Shi @ 2007-01-23 19:34 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-23 19:34 ` Weiguang Shi @ 2007-01-23 20:11 ` Gary Thomas 2007-01-28 21:26 ` Weiguang Shi 0 siblings, 1 reply; 15+ messages in thread From: Gary Thomas @ 2007-01-23 20:11 UTC (permalink / raw) To: Weiguang Shi; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AW: [ECOS] cat zImage >/dev/mtd1 does not work 2007-01-23 20:11 ` Gary Thomas @ 2007-01-28 21:26 ` Weiguang Shi 0 siblings, 0 replies; 15+ messages in thread From: Weiguang Shi @ 2007-01-28 21:26 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2007-01-28 21:26 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-19 7:48 AW: [ECOS] cat zImage >/dev/mtd1 does not work Neundorf, Alexander 2007-01-19 9:00 ` [ECOS] Ecos/redboot on Xscale pxa270 tejas pawaskar 2007-01-19 16:50 ` AW: [ECOS] cat zImage >/dev/mtd1 does not work Weiguang Shi 2007-01-19 16:53 ` Andrew Lunn 2007-01-19 17:50 ` Gary Thomas 2007-01-19 18:08 ` Weiguang Shi 2007-01-19 18:18 ` Gary Thomas 2007-01-19 18:28 ` Weiguang Shi 2007-01-20 2:00 ` Weiguang Shi 2007-01-20 13:46 ` Gary Thomas 2007-01-23 2:08 ` Weiguang Shi 2007-01-23 8:42 ` Gary Thomas 2007-01-23 19:34 ` Weiguang Shi 2007-01-23 20:11 ` Gary Thomas 2007-01-28 21:26 ` Weiguang Shi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).