<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/mtd, branch v2010.09</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>Fix "ubi part" cmd re-entrancy</title>
<updated>2010-09-27T13:06:00+00:00</updated>
<author>
<name>Karl Beldan</name>
<email>karl.beldan@gmail.com</email>
</author>
<published>2010-09-23T08:46:31+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=86af10cac421e7156da4a5f154ab34026e35a2c3'/>
<id>86af10cac421e7156da4a5f154ab34026e35a2c3</id>
<content type='text'>
Commit 2ee951ba (UBI: Enable re-initializing of the "ubi part" command)
reset mtd_devs in ubi_exit() but missed ubi_init()'s failure path.

Signed-off-by: Karl Beldan &lt;karl.beldan@gmail.com&gt;
Cc: Stefan Roese &lt;sr@denx.de&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 2ee951ba (UBI: Enable re-initializing of the "ubi part" command)
reset mtd_devs in ubi_exit() but missed ubi_init()'s failure path.

Signed-off-by: Karl Beldan &lt;karl.beldan@gmail.com&gt;
Cc: Stefan Roese &lt;sr@denx.de&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nand/davinci: make sure ECC calculation has really started</title>
<updated>2010-09-13T19:43:05+00:00</updated>
<author>
<name>Wolfram Sang</name>
<email>w.sang@pengutronix.de</email>
</author>
<published>2010-09-09T11:54:41+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1075b07e2c67c1f504d9f3a6f1b9aaa8f81393b2'/>
<id>1075b07e2c67c1f504d9f3a6f1b9aaa8f81393b2</id>
<content type='text'>
Due to a register glitch (result code &lt;4 might show up right after the
start-calculation-bit was set), make sure the ECC has really started.

See 1c3275b656045aff9a75bb2c9f3251af1043ebb3 in the kernel.

Signed-off-by: Wolfram Sang &lt;w.sang@pengutronix.de&gt;
Cc: Sandeep Paulraj &lt;s-paulraj@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Due to a register glitch (result code &lt;4 might show up right after the
start-calculation-bit was set), make sure the ECC has really started.

See 1c3275b656045aff9a75bb2c9f3251af1043ebb3 in the kernel.

Signed-off-by: Wolfram Sang &lt;w.sang@pengutronix.de&gt;
Cc: Sandeep Paulraj &lt;s-paulraj@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-ti</title>
<updated>2010-09-09T17:55:02+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-09-09T17:55:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a78ded13111dde555ed5de99cff10f41ae674cb1'/>
<id>a78ded13111dde555ed5de99cff10f41ae674cb1</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: supress 'unknown NAND' warning if no nand is found</title>
<updated>2010-09-08T18:51:29+00:00</updated>
<author>
<name>Steve Sakoman</name>
<email>steve@sakoman.com</email>
</author>
<published>2010-08-20T03:14:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4c468397cf71f2ab613c9c8989ab56d4b306a67f'/>
<id>4c468397cf71f2ab613c9c8989ab56d4b306a67f</id>
<content type='text'>
This printk was added recently and results in ugly output on systems
with no NAND:

NAND:  nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00, Chip ID: 0x00 0 MiB

instead of:

NAND:  0 MiB

Signed-off-by: Steve Sakoman &lt;steve@sakoman.com&gt;
Acked-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Sandeep Paulraj &lt;s-paulraj@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This printk was added recently and results in ugly output on systems
with no NAND:

NAND:  nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00, Chip ID: 0x00 0 MiB

instead of:

NAND:  0 MiB

Signed-off-by: Steve Sakoman &lt;steve@sakoman.com&gt;
Acked-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Sandeep Paulraj &lt;s-paulraj@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-samsung</title>
<updated>2010-09-07T22:03:22+00:00</updated>
<author>
<name>Wolfgang Denk</name>
<email>wd@denx.de</email>
</author>
<published>2010-09-07T22:03:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=09b4a9cf4003599f2cd609587dfa5f0b754640ed'/>
<id>09b4a9cf4003599f2cd609587dfa5f0b754640ed</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ARMV7: S5P: rename from CONFIG_S5PC1XX to CONFIG_S5P</title>
<updated>2010-08-26T08:33:23+00:00</updated>
<author>
<name>Minkyu Kang</name>
<email>mk7.kang@samsung.com</email>
</author>
<published>2010-08-23T10:52:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=889a275d428be2790270f7280385207c1666eb4b'/>
<id>889a275d428be2790270f7280385207c1666eb4b</id>
<content type='text'>
Use the same configuration around S5P SoCs.
(s5pc100, s5pc110, s5pc210 and so on)

Signed-off-by: Minkyu Kang &lt;mk7.kang@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use the same configuration around S5P SoCs.
(s5pc100, s5pc110, s5pc210 and so on)

Signed-off-by: Minkyu Kang &lt;mk7.kang@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.</title>
<updated>2010-08-18T07:09:00+00:00</updated>
<author>
<name>Philippe De Muyter</name>
<email>phdm@macqel.be</email>
</author>
<published>2010-08-17T16:40:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=54652991caedc39b2ec2e5b49e750669bfcd1e2e'/>
<id>54652991caedc39b2ec2e5b49e750669bfcd1e2e</id>
<content type='text'>
I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.

After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
"Numonyx Axcell P33/P30 256-Mbit Specification Update"

It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.

A working workaround is given, which I have applied and tested with success :

Workaround:  If the interval between 60h and its subsequent command
	     can be guaranteed within 20us, Option I is recommended,
	     otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
	      Data bus           Address bus       Remarks
Sequence
  1              90h            Block Address
						   Read Lock Status
  2             Read         Block Address + 02h
 (2)(3)                                      (1)
3                60h           Block Address
 (2)(3)                                      (1)   Lock/Unlock/RCR Configuration
4           D0h/01h/03h        Block Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
    command sequence is used to set RCR register combined with 03h
    subsequent command.
(2) For the third and fourth command sequences, the Block Address must
    be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
    commands should be less than 20us.

And here is a log comparison of a simple (destructive) flash test without
and with the workaround.

 diff without-numonyx-workaround.log with-numonyx-workaround.log
 -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
 +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)

  CPU:   Freescale MCF5484
         CPU CLK 200 MHz BUS CLK 100 MHz
  Board: Macq Electronique ME2060
  I2C:   ready
  DRAM:  64 MiB
  FLASH: 32 MiB
  In:    serial
  Out:   serial
  Err:   serial
  Net:   FEC0, FEC1
  -&gt; flinfo

  Bank # 1: CFI conformant FLASH (16 x 16)  Size: 32 MB in 259 Sectors
    Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
    Erase timeout: 4096 ms, write timeout: 1 ms
    Buffer write timeout: 5 ms, buffer size: 1024 bytes

    Sector Start Addresses:
    FE000000 RO   FE008000 RO   FE010000 RO   FE018000 RO   FE020000 RO
    FE040000 RO   FE060000 RO   FE080000 RO   FE0A0000 RO   FE0C0000 RO
    ...
    FFF80000 RO   FFFA0000 RO   FFFC0000 RO   FFFE0000 RO
  -&gt; protect off all
  Un-Protect Flash Bank # 1
  ................... done
  -&gt; erase all
  Erase Flash Bank # 1
  ................... done
  -&gt; cp.b 1000000 fe000000 2000000
 -Copy to Flash... Flash not Erased
 +Copy to Flash... done
  -&gt;

Signed-off-by: Philippe De Muyter &lt;phdm@macqel.be&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.

After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
"Numonyx Axcell P33/P30 256-Mbit Specification Update"

It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.

A working workaround is given, which I have applied and tested with success :

Workaround:  If the interval between 60h and its subsequent command
	     can be guaranteed within 20us, Option I is recommended,
	     otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
	      Data bus           Address bus       Remarks
Sequence
  1              90h            Block Address
						   Read Lock Status
  2             Read         Block Address + 02h
 (2)(3)                                      (1)
3                60h           Block Address
 (2)(3)                                      (1)   Lock/Unlock/RCR Configuration
4           D0h/01h/03h        Block Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
    command sequence is used to set RCR register combined with 03h
    subsequent command.
(2) For the third and fourth command sequences, the Block Address must
    be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
    commands should be less than 20us.

And here is a log comparison of a simple (destructive) flash test without
and with the workaround.

 diff without-numonyx-workaround.log with-numonyx-workaround.log
 -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
 +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)

  CPU:   Freescale MCF5484
         CPU CLK 200 MHz BUS CLK 100 MHz
  Board: Macq Electronique ME2060
  I2C:   ready
  DRAM:  64 MiB
  FLASH: 32 MiB
  In:    serial
  Out:   serial
  Err:   serial
  Net:   FEC0, FEC1
  -&gt; flinfo

  Bank # 1: CFI conformant FLASH (16 x 16)  Size: 32 MB in 259 Sectors
    Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
    Erase timeout: 4096 ms, write timeout: 1 ms
    Buffer write timeout: 5 ms, buffer size: 1024 bytes

    Sector Start Addresses:
    FE000000 RO   FE008000 RO   FE010000 RO   FE018000 RO   FE020000 RO
    FE040000 RO   FE060000 RO   FE080000 RO   FE0A0000 RO   FE0C0000 RO
    ...
    FFF80000 RO   FFFA0000 RO   FFFC0000 RO   FFFE0000 RO
  -&gt; protect off all
  Un-Protect Flash Bank # 1
  ................... done
  -&gt; erase all
  Erase Flash Bank # 1
  ................... done
  -&gt; cp.b 1000000 fe000000 2000000
 -Copy to Flash... Flash not Erased
 +Copy to Flash... done
  -&gt;

Signed-off-by: Philippe De Muyter &lt;phdm@macqel.be&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfi_flash: Cleanup flash_print_info()</title>
<updated>2010-08-18T07:09:00+00:00</updated>
<author>
<name>Stefan Roese</name>
<email>sr@denx.de</email>
</author>
<published>2010-08-13T07:36:36+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=70084df7125a0b67de707b999982ec67adfdc35c'/>
<id>70084df7125a0b67de707b999982ec67adfdc35c</id>
<content type='text'>
This patch does the following:

- Extract code to detect if sector is erased into function
  sector_erased().
- Because of this, we don't have variable declarations inside the
  sector loop in flash_print_info()
- Change "return" to "break" in the "if (ctrlc()) statement:
  This fixes a problem with the resulting output. Before this
  patch the output was:

  Sector Start Addresses:
  FC000000        FC020000        FC040000   =&gt;

  With this patch it is now:

  Sector Start Addresses:
  FC000000        FC020000        FC040000
  =&gt;

Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
Cc: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Cc: Wolfgang Denk &lt;wd@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch does the following:

- Extract code to detect if sector is erased into function
  sector_erased().
- Because of this, we don't have variable declarations inside the
  sector loop in flash_print_info()
- Change "return" to "break" in the "if (ctrlc()) statement:
  This fixes a problem with the resulting output. Before this
  patch the output was:

  Sector Start Addresses:
  FC000000        FC020000        FC040000   =&gt;

  With this patch it is now:

  Sector Start Addresses:
  FC000000        FC020000        FC040000
  =&gt;

Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
Cc: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Cc: Wolfgang Denk &lt;wd@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix printing &amp; reading of 16-bit CFI device identifiers</title>
<updated>2010-08-18T07:09:00+00:00</updated>
<author>
<name>Philippe De Muyter</name>
<email>phdm@macqel.be</email>
</author>
<published>2010-08-10T14:54:52+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d77c7ac47e4ea750cc13c2f0ecc037ab7afa7964'/>
<id>d77c7ac47e4ea750cc13c2f0ecc037ab7afa7964</id>
<content type='text'>
Fix reading and printing of CFI flashes 16-bit devices identifiers

Nowadays CFI flashes have a 16-bit device identifier.  U-boot still
print them and read them as if they were only 8-bit wide.  Fix that.
Before:
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1B
After:
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x881B

Signed-off-by: Philippe De Muyter &lt;phdm@macqel.be&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix reading and printing of CFI flashes 16-bit devices identifiers

Nowadays CFI flashes have a 16-bit device identifier.  U-boot still
print them and read them as if they were only 8-bit wide.  Fix that.
Before:
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1B
After:
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x881B

Signed-off-by: Philippe De Muyter &lt;phdm@macqel.be&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfi_flash: flinfo: allow user interrupt in flash print info fn</title>
<updated>2010-08-18T07:09:00+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2010-07-26T23:35:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2e97394a6d07a36dfc139b7b98b12e452b5bd8dc'/>
<id>2e97394a6d07a36dfc139b7b98b12e452b5bd8dc</id>
<content type='text'>
flashes getting larger, users more impatient.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
flashes getting larger, users more impatient.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
