Flashing NAND from NAND

[Atilla Filiz]

Hello
I have a blank NOR and didn't have time to hack and flash it(don't want to buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new bootloader to NAND? Probably not a good idea.

--
---------------------------------------------------------
Atilla Filiz
Eindhoven University of Technology
Embedded Systems, Master's Programme
--------------------------------------------------------

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Timo Juhani Lindfors]

Atilla Filiz <[hidden email]> writes:
> buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new
> bootloader to NAND? Probably not a good idea.

I think you answered your own question :-)


_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Atilla Filiz]

Hmm, I just wanted to confirm that, seems confirmed.

On Sun, Oct 18, 2009 at 4:27 PM, Timo Juhani Lindfors <[hidden email]> wrote:

Atilla Filiz <[hidden email]> writes:
> buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new
> bootloader to NAND? Probably not a good idea.

I think you answered your own question :-)


_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

--
---------------------------------------------------------
Atilla Filiz
Eindhoven University of Technology
Embedded Systems, Master's Programme
--------------------------------------------------------

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Joachim Ott-2]

2009/10/18 Atilla Filiz <[hidden email]>:
> Hello
> I have a blank NOR and didn't have time to hack and flash it(don't want to
> buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new
> bootloader to NAND? Probably not a good idea.

To flash something via USB cable with dfu-util you have to be in the
NOR boot menu. But it's totally legal to reflash /dev/mtd1 (u-boot),
mtd2 (u-boot_env) or mtd3 (kernel) when you have booted into the
rootfs in NAND. When you've booted from sd-card, you can reflash mtd6
(rootfs) too. Use flash_eraseall and nand_write for this.

Writing to /dev/mtd0 (NOR boot) is possible without debug board too,
you need need to enable write access to it. See
http://wiki.openmoko.org/wiki/Flashing_NOR

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Atilla Filiz]

On IRC, I asked someone to
dd if=/dev/mtd0 of=nor.img
for me. Does that work? The link in the wiki page is dead.
I always flash my kernel and rootfs from NAND u-boot menu.

On Sun, Oct 18, 2009 at 5:25 PM, Joachim Ott <[hidden email]> wrote:

2009/10/18 Atilla Filiz <[hidden email]>:

> Hello
> I have a blank NOR and didn't have time to hack and flash it(don't want to
> buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new
> bootloader to NAND? Probably not a good idea.

To flash something via USB cable with dfu-util you have to be in the
NOR boot menu. But it's totally legal to reflash /dev/mtd1 (u-boot),
mtd2 (u-boot_env) or mtd3 (kernel) when you have booted into the
rootfs in NAND. When you've booted from sd-card, you can reflash mtd6
(rootfs) too. Use flash_eraseall and nand_write for this.

Writing to /dev/mtd0 (NOR boot) is possible without debug board too,
you need need to enable write access to it. See
http://wiki.openmoko.org/wiki/Flashing_NOR

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

--
---------------------------------------------------------
Atilla Filiz
Eindhoven University of Technology
Embedded Systems, Master's Programme
--------------------------------------------------------

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

i personally do my backups with "cp"

cp /dev/mtdblock6 /media/card/rootfs
and vice versa.

#blocksave.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp /dev/mtdblock$i ${i}_* ; cp /dev/mtdblock$i ${i}_* ; done

# blockrestore.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp ${i}_* /dev/mtdblock$i ; done

and in practice, this works for backup _and_ restore

Atilla Filiz schrieb:

On IRC, I asked someone to
dd if=/dev/mtd0 of=nor.img
for me. Does that work? The link in the wiki page is dead.
I always flash my kernel and rootfs from NAND u-boot menu.

On Sun, Oct 18, 2009 at 5:25 PM, Joachim Ott <[hidden email]> wrote:

2009/10/18 Atilla Filiz <[hidden email]>:

> Hello
> I have a blank NOR and didn't have time to hack and flash it(don't want to
> buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new
> bootloader to NAND? Probably not a good idea.

To flash something via USB cable with dfu-util you have to be in the
NOR boot menu. But it's totally legal to reflash /dev/mtd1 (u-boot),
mtd2 (u-boot_env) or mtd3 (kernel) when you have booted into the
rootfs in NAND. When you've booted from sd-card, you can reflash mtd6
(rootfs) too. Use flash_eraseall and nand_write for this.

Writing to /dev/mtd0 (NOR boot) is possible without debug board too,
you need need to enable write access to it. See
http://wiki.openmoko.org/wiki/Flashing_NOR

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

--
---------------------------------------------------------
Atilla Filiz
Eindhoven University of Technology
Embedded Systems, Master's Programme
--------------------------------------------------------

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support
  

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

Matthias Huber schrieb:

i personally do my backups with "cp"

cp /dev/mtdblock6 /media/card/rootfs
and vice versa.

#blocksave.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp /dev/mtdblock$i ${i}_* ; cp /dev/mtdblock$i ${i}_* ; done

# blockrestore.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp ${i}_* /dev/mtdblock$i ; done

and in practice, this works for backup _and_ restore

but the backup with the assumption, that there are the destination files already in the directory, like:

-rw-r--r--    1 root     root       262144 Sep 25 09:11 1_uboot
-rw-r--r--    1 root     root       262144 Sep 25 09:11 2_uboot-env
-rw-r--r--    1 root     root      8388608 Sep 25 09:11 3_kernel
-rw-r--r--    1 root     root       655360 Sep 25 09:11 4_splash
-rw-r--r--    1 root     root       262144 Sep 25 09:11 5_factory
-rw-r--r--    1 root     root    258605056 Sep 25 09:16 6_rootfs

Atilla Filiz schrieb:

On IRC, I asked someone to
dd if=/dev/mtd0 of=nor.img
for me. Does that work? The link in the wiki page is dead.
I always flash my kernel and rootfs from NAND u-boot menu.

On Sun, Oct 18, 2009 at 5:25 PM, Joachim Ott <[hidden email]> wrote:

2009/10/18 Atilla Filiz <[hidden email]>:

> Hello
> I have a blank NOR and didn't have time to hack and flash it(don't want to
> buy a debug board). Is it safe to boot into NAND u-boot menu and flash a new
> bootloader to NAND? Probably not a good idea.

To flash something via USB cable with dfu-util you have to be in the
NOR boot menu. But it's totally legal to reflash /dev/mtd1 (u-boot),
mtd2 (u-boot_env) or mtd3 (kernel) when you have booted into the
rootfs in NAND. When you've booted from sd-card, you can reflash mtd6
(rootfs) too. Use flash_eraseall and nand_write for this.

Writing to /dev/mtd0 (NOR boot) is possible without debug board too,
you need need to enable write access to it. See
http://wiki.openmoko.org/wiki/Flashing_NOR

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Joachim Ott-2]

2009/10/18 Atilla Filiz <[hidden email]>:
> On IRC, I asked someone to
> dd if=/dev/mtd0 of=nor.img
> for me. Does that work? The link in the wiki page is dead.

If the file is about 2 MB big (mine is 2.097.152 bytes), that should be it.

> I always flash my kernel and rootfs from NAND u-boot menu.

I never heard that you can flash from NAND boot menu. Can you take a
picture of the boot menu and put it somwhere on the web (like
imageshack.us or so)?

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Timo Juhani Lindfors]

Joachim Ott <[hidden email]> writes:
> I never heard that you can flash from NAND boot menu. Can you take a
> picture of the boot menu and put it somwhere on the web (like
> imageshack.us or so)?

You configure the u-boot menu to have any entries you like.



_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Joachim Ott-2]

2009/10/18 Timo Juhani Lindfors <[hidden email]>:
> Joachim Ott <[hidden email]> writes:
>> I never heard that you can flash from NAND boot menu. Can you take a
>> picture of the boot menu and put it somwhere on the web (like
>> imageshack.us or so)?
>
> You configure the u-boot menu to have any entries you like.

Yes, I can configure the menu. But I cannot change the menu title. So
show me how you're flashing the FR while you are in the NAND boot
menu.

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Werner Almesberger]

Matthias Huber wrote:
> ># blockrestore.sh
> >#!/bin/sh -x
> >for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp
> >${i}_* /dev/mtdblock$i ; done
> >
> >and in practice, this works for backup _and_ restore
> >
> but the backup with the assumption, that there are the destination
> files already in the directory, like:

Hmm, don't you also assume that the partition has been erased before
writing ? Also, what happens if you have any bad blocks ?

- Werner

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

Werner Almesberger schrieb:

Matthias Huber wrote:
  

# blockrestore.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp
${i}_* /dev/mtdblock$i ; done

and in practice, this works for backup _and_ restore

      

but the backup with the assumption, that there are the destination
files already in the directory, like:
    

Hmm, don't you also assume that the partition has been erased before
writing ? Also, what happens if you have any bad blocks ?

  

No, erasing seemed not to be necessary.
why should i erase it ?

Bad Blocks: No i didnt even thing of it.
the four times i did a backup and two or three times i did a restore, there was no problem.
but you are of course right, one has to have a look at it.



_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Werner Almesberger]

Matthias Huber wrote:
> No, erasing seemed not to be necessary.
> why should i erase it ?

Because a write to NAND normally only clears bits but never sets them:

# flash_eraseall /dev/mtd4
# hexdump -C /dev/mtd4
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
# echo -en '\x0f' | dd bs=1024 count=1 conv=sync >/dev/mtd4
# hexdump -C /dev/mtd4
00000000  0f 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |?...............|
# echo -en '\xff' | dd bs=1024 count=1 conv=sync >/dev/mtd4
dd: writing `standard output': Input/output error
# hexdump -C /dev/mtd4
00000000  0f 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |?...............|

Here's a little brain-twister: repeat the example from the beginning,
but instead of trying to write '\xff', do this:

# echo -en '\x17' | dd bs=1024 count=1 conv=sync >/dev/mtd4
dd: writing `standard output': Input/output error
# hexdump -C /dev/mtd4
00000000  17 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Can you tell why it worked ?

- Werner

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

Werner Almesberger schrieb:

Matthias Huber wrote:
  

No, erasing seemed not to be necessary.
why should i erase it ?
    

Because a write to NAND normally only clears bits but never sets them:

# flash_eraseall /dev/mtd4
# hexdump -C /dev/mtd4
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
# echo -en '\x0f' | dd bs=1024 count=1 conv=sync >/dev/mtd4
# hexdump -C /dev/mtd4
00000000  0f 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |?...............|
# echo -en '\xff' | dd bs=1024 count=1 conv=sync >/dev/mtd4
dd: writing `standard output': Input/output error
# hexdump -C /dev/mtd4
00000000  0f 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |?...............|

Here's a little brain-twister: repeat the example from the beginning,
but instead of trying to write '\xff', do this:

# echo -en '\x17' | dd bs=1024 count=1 conv=sync >/dev/mtd4
dd: writing `standard output': Input/output error
# hexdump -C /dev/mtd4
00000000  17 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Can you tell why it worked ?

- Werner
  

i can't. it is possible that i flashed my boot with dfu-util and the rootfs directly.
for the other partitions i cant tell. maybe because the contents didn't change i did'nt see any error.

just for clearness: is the boot - partition different from the rootfs ?
and how are the other partitions ?

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Joachim Ott-2]

2009/10/20 Matthias Huber <[hidden email]>:
> ...
> just for clearness: is the boot - partition different from the rootfs ?
> and how are the other partitions ?

/dev/mtd0 is the 2 MB NOR flash that contains the NOR bootloader

/dev/mtd1 - mtd6 are the 256 MB NAND flash, the names and sizes are
shown when the kernel boots (check "dmesg | more" after boot) and they
contain:

- u-boot or Qi
- u-boot environment
- kernel
- splash image shown directly after power on
- factory settings
- rootfs

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

Joachim Ott schrieb:

2009/10/20 Matthias Huber [hidden email]:
  

...
just for clearness: is the boot - partition different from the rootfs ?
and how are the other partitions ?
    

/dev/mtd0 is the 2 MB NOR flash that contains the NOR bootloader

/dev/mtd1 - mtd6 are the 256 MB NAND flash, the names and sizes are
shown when the kernel boots (check "dmesg | more" after boot) and they
contain:

- u-boot or Qi
- u-boot environment
- kernel
- splash image shown directly after power on
- factory settings
- rootfs

  

my question was thougt as: do the other partitions also have to be erased ?

on the mounted rootfs (/dev/mtdblock6) i am writing just normal without erasing, thats why i am stating this question.

and what is then the difference between /dev/mtd6 and /dev/mtdblock6 ?


_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Joachim Ott-2]

2009/10/20 Matthias Huber <[hidden email]>:

> Joachim Ott schrieb:
>
> 2009/10/20 Matthias Huber <[hidden email]>:
>
>
> ...
> just for clearness: is the boot - partition different from the rootfs ?
> and how are the other partitions ?
>
>
> /dev/mtd0 is the 2 MB NOR flash that contains the NOR bootloader
>
> /dev/mtd1 - mtd6 are the 256 MB NAND flash, the names and sizes are
> shown when the kernel boots (check "dmesg | more" after boot) and they
> contain:
>
> - u-boot or Qi
> - u-boot environment
> - kernel
> - splash image shown directly after power on
> - factory settings
> - rootfs
>
>
>
> my question was thougt as: do the other partitions also have to be erased ?
>
> on the mounted rootfs (/dev/mtdblock6) i am writing just normal without
> erasing, thats why i am stating this question.

There's a difference between flashing a partition and writing to a
mounted filesystem. When you edit a file and change only one byte, the
whole block containig this changed byte will be erased and newly
written. This happens transparent to you.

> and what is then the difference between /dev/mtd6 and /dev/mtdblock6 ?

/dev/mtd6 is accessed as char device, while /dev/mtdblock6 is accessed
as block device. See e.g.
http://en.wikipedia.org/wiki/Device_file_system#Devices

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

Joachim Ott schrieb:

2009/10/20 Matthias Huber [hidden email]:
  

Joachim Ott schrieb:

2009/10/20 Matthias Huber [hidden email]:


...
just for clearness: is the boot - partition different from the rootfs ?
and how are the other partitions ?


/dev/mtd0 is the 2 MB NOR flash that contains the NOR bootloader

/dev/mtd1 - mtd6 are the 256 MB NAND flash, the names and sizes are
shown when the kernel boots (check "dmesg | more" after boot) and they
contain:

- u-boot or Qi
- u-boot environment
- kernel
- splash image shown directly after power on
- factory settings
- rootfs



my question was thougt as: do the other partitions also have to be erased ?

on the mounted rootfs (/dev/mtdblock6) i am writing just normal without
erasing, thats why i am stating this question.
    

There's a difference between flashing a partition and writing to a
mounted filesystem. When you edit a file and change only one byte, the
whole block containig this changed byte will be erased and newly
written. This happens transparent to you.

  

and what is then the difference between /dev/mtd6 and /dev/mtdblock6 ?
    

/dev/mtd6 is accessed as char device, while /dev/mtdblock6 is accessed
as block device. See e.g.
http://en.wikipedia.org/wiki/Device_file_system#Devices

  

(... coming back to my method of restoring and saving)
so is then in the driver  a difference

between /dev/mtd1 and /dev/mtd6 ?

or between /dev/mtdblock1 and /dev/mtdblock6 ?

and between mtd0 and mtd6 ?





_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[Werner Almesberger]

Matthias Huber wrote:
> Werner Almesberger schrieb:
> ># echo -en '\x17' | dd bs=1024 count=1 conv=sync >/dev/mtd4
[...]
> >Can you tell why it worked ?

In the 0x17 case, we're trying to go from 0x0f to 0x17. That's
one bit set and one bit cleared. Clearing the 0x08 bit can be
done, and happend when trying to write the 0x17. However, the
0x10 bit can't be set (without invoking an erase cycle).

However, since NAND has an ECC, it can still correct a one-bit
error. As it happens, the ECC pattern that gets written, just
flips the 0x10 bit, so the byte in NAND is 0x07, but it gets
corrected to 0x17 - which just happens to be the value we want.

> i can't. it is possible that i flashed my boot with dfu-util and the
> rootfs directly.

Yes, DFU follows all the NAND erasing rituals properly. The rootfs
is very tricky, because there you also have JFFS2 that tries to
hide problems from you.

For your backup system, you should at least add flash_eraseall
to the restore procedure. To make things work also for systems
that have bad NAND blocks, you would have to use nanddump and
nandwrite. (And you still have to erase explicitly - nandwrite
won't do it for you.)

- Werner

_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support

[matzehuber]

Some javascript/style in this post has been disabled (why?)

Werner Almesberger schrieb:

Matthias Huber wrote:
  

Werner Almesberger schrieb:
    

# echo -en '\x17' | dd bs=1024 count=1 conv=sync >/dev/mtd4
      

[...]
  

Can you tell why it worked ?
      

In the 0x17 case, we're trying to go from 0x0f to 0x17. That's
one bit set and one bit cleared. Clearing the 0x08 bit can be
done, and happend when trying to write the 0x17. However, the
0x10 bit can't be set (without invoking an erase cycle).

However, since NAND has an ECC, it can still correct a one-bit
error. As it happens, the ECC pattern that gets written, just
flips the 0x10 bit, so the byte in NAND is 0x07, but it gets
corrected to 0x17 - which just happens to be the value we want.

  

i can't. it is possible that i flashed my boot with dfu-util and the
rootfs directly.
    

Yes, DFU follows all the NAND erasing rituals properly. The rootfs
is very tricky, because there you also have JFFS2 that tries to
hide problems from you.

For your backup system, you should at least add flash_eraseall
to the restore procedure. To make things work also for systems
that have bad NAND blocks, you would have to use nanddump and
nandwrite. (And you still have to erase explicitly - nandwrite
won't do it for you.)

- Werner
  

Thank you for this information about this nand* progs.

I think, this should go into the wiki, if it isn't already.


_______________________________________________
support mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/support