Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Saturday, February 12, 2011 02:08:00 am Albert ARIBAUD wrote: > Le 12/02/2011 09:54, Aaron Williams a écrit : > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > > Octeon ebb6300(ram)# md.b 0x1f400020 20 > > 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 > > QQRRYY@@ 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 > > 07..''66.. > > This, according to the CFI spec, gives us the proof that the Spansion > chip is a x16 device in x8 mode. > > Can you now please, based on the knowledge that the device is x16 in x8 > mode, go through the CFI detection sequence agin and determine which > line exactly fails to work as expected? > > > -Aaron > > Amicalement, I'll take a look at this next week. The problem with the current code is that it detects the chip width of 8 but a port width of 16 which results in 16-bit writes. This fails for obtaining the manufacturer ID. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Le 12/02/2011 09:54, Aaron Williams a écrit : > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > Octeon ebb6300(ram)# md.b 0x1f400020 20 > 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00QQRRYY@@ > 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07..''66.. This, according to the CFI spec, gives us the proof that the Spansion chip is a x16 device in x8 mode. Can you now please, based on the knowledge that the device is x16 in x8 mode, go through the CFI detection sequence agin and determine which line exactly fails to work as expected? > -Aaron Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Saturday, February 12, 2011 12:49:24 am Albert ARIBAUD wrote: > Le 12/02/2011 08:57, Aaron Williams a écrit : > >> The CFI query is normal for a x16 device: byte address 0xAA is word > >> address 0x55, which is what is expected from a x16 device in x8 mode as > >> in x16 mode. > >> > >> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode? > >> > >> Amicalement, > > > > You mean like this? > > > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa > > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 > > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 > > Octeon ebb6300(ram)# md.b 0x1f40 0 > > Octeon ebb6300(ram)# md.b 0x1f40 1 > > 1f40: 01. > > Octeon ebb6300(ram)# md.b 0x1f42 1 > > 1f42: 7e~ > > Octeon ebb6300(ram)# md.b 0x1f44 1 > > 1f44: 00. > > Octeon ebb6300(ram)# md.b 0x1f45 1 > > 1f45: 00. > > Octeon ebb6300(ram)# md.b 0x1f46 1 > > 1f46: 1a. > > Octeon ebb6300(ram)# md.b 0x1f48 1 > > 1f48: 00. > > Octeon ebb6300(ram)# md.b 0x1f4a 1 > > 1f4a: 00. > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > > Octeon ebb6300(ram)# md.b 0x1f400020 > > 1f400020: 51Q > > Octeon ebb6300(ram)# md.b 0x1f400022 > > 1f400022: 52R > > Octeon ebb6300(ram)# md.b 0x1f400024 > > 1f400024: 59Y > > Octeon ebb6300(ram)# md.b 0x1f400026 > > 1f400026: 02. > > Octeon ebb6300(ram)# md.b 0x1f400028 > > 1f400028: 00. > > > > -Aaron > > No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20' > once in CFI QRY mode, that is: > > mw.b 0x1f40 0xf0 > mw.b 0x1f4000AA 0x98 > md.b 0x1f400020 20 > > Amicalement, Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 20 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00QQRRYY@@ 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07..''66.. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Le 12/02/2011 08:57, Aaron Williams a écrit : >> The CFI query is normal for a x16 device: byte address 0xAA is word >> address 0x55, which is what is expected from a x16 device in x8 mode as >> in x16 mode. >> >> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode? >> >> Amicalement, > You mean like this? > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 > Octeon ebb6300(ram)# md.b 0x1f40 0 > Octeon ebb6300(ram)# md.b 0x1f40 1 > 1f40: 01. > Octeon ebb6300(ram)# md.b 0x1f42 1 > 1f42: 7e~ > Octeon ebb6300(ram)# md.b 0x1f44 1 > 1f44: 00. > Octeon ebb6300(ram)# md.b 0x1f45 1 > 1f45: 00. > Octeon ebb6300(ram)# md.b 0x1f46 1 > 1f46: 1a. > Octeon ebb6300(ram)# md.b 0x1f48 1 > 1f48: 00. > Octeon ebb6300(ram)# md.b 0x1f4a 1 > 1f4a: 00. > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > Octeon ebb6300(ram)# md.b 0x1f400020 > 1f400020: 51Q > Octeon ebb6300(ram)# md.b 0x1f400022 > 1f400022: 52R > Octeon ebb6300(ram)# md.b 0x1f400024 > 1f400024: 59Y > Octeon ebb6300(ram)# md.b 0x1f400026 > 1f400026: 02. > Octeon ebb6300(ram)# md.b 0x1f400028 > 1f400028: 00. > > -Aaron No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20' once in CFI QRY mode, that is: mw.b 0x1f40 0xf0 mw.b 0x1f4000AA 0x98 md.b 0x1f400020 20 Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Friday, February 11, 2011 11:51:24 pm Albert ARIBAUD wrote: > Le 12/02/2011 08:14, Aaron Williams a écrit : > > On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote: > >> Le 12/02/2011 07:42, Aaron Williams a écrit : > >>> I've placed the results of the scan below. > >>> > >>> The problem is that in 8-bit mode the code that scans the CFI does not > >>> follow the specification. > >>> > >>> In the specification to read the CFI data you write 0x98 to address > >>> 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is > >>> set to 0x55 which in this case is wrong and won't work. When it tries > >>> 16-bit mode then it writes to address 0xAA which causes it to work. > >> > >> Let us see the specs, then. The specs I have (admittedly not necessarily > >> the latest: I use JESD 68.01, september 1999) state the following: > >> > >> "Nonvolatile memory devices are assumed to power up in a read-only > >> state. Independent of that assumption, the Query structure contents must > >> be able to be read at the specific address locations following a single > >> system write cycle where: 1) a 98h Query command code is written to 55h > >> address location within the device’s address space (in maximum device > >> buswidth), and 2) the device is in any valid read state, such as “Read > >> Array” or “Read ID Data”. > >> > >> I read "55h address location within the device’s address space (in > >> maximum device buswidth" as implying that 0x55 is the only address to > >> use but is in device bus terms, and that may mean different CPU > >> addresses for different devices types: for x8 devices, one should access > >> the byte address 0x55 because the device bus is in bytes, whereas for > >> x8/x16 and x16 devices, one should access byte address 0xAA because it > >> translates to x16 device bus address 0x55 -- regardless of actual x8 or > >> x16 mode. > >> > >> Are we in sync here? > > > > This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 > > mode according to the data sheet. > > Yes, but the 0xAA address is a byte address and the 0x55 address is a > word address, translating to byte address 0xAA as well. > > On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte > location for a pure x8 device is 0x55, and 0xAA for a x16 device, both > in x16 or x8 mode (the difference is that byte mode will expect a byte > write of 0x98 where x16 mode will expect a word write of 0x0098). > > This is in sync with my Macronix MX29LV400CB/CT spec. > > >> Now it's been a long time since I last looked at my ED Mini V2 Flash, > >> but I should be able to dig it up and do a test within one or two hours. > >> > >>> -Aaron > >> > >>> Here's the results of the scan: > >> Yes, that's what U-boot *CFI code* does, but I'd like to see what very > >> basic writes and reads give without any detection logic involved. > >> > >> Amicalement, > > > > When I use the addresses and data shown in the datasheet, everything > > responds as it should using mw.b and md.b. > > > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa > > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 > > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 > > Octeon ebb6300(ram)# md.b 0x1f40 1 > > 1f40: 01. > > Octeon ebb6300(ram)# md.b 0x1f42 1 > > 1f42: 7e~ > > Octeon ebb6300(ram)# md.b 0x1f44 1 > > 1f44: 00. > > > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > > Octeon ebb6300(ram)# md.b 0x1f400020 > > 1f400020: 51Q > > Octeon ebb6300(ram)# md.b 0x1f400022 > > 1f400022: 52R > > Octeon ebb6300(ram)# md.b 0x1f400024 > > 1f400024: 59Y > > Octeon ebb6300(ram)# md.b 0x1f400026 > > 1f400026: 02. > > Octeon ebb6300(ram)# md.b 0x1f400028 > > 1f400028: 00. > > > > -Aaron > > The CFI query is normal for a x16 device: byte address 0xAA is word > address 0x55, which is what is expected from a x16 device in x8 mode as > in x16 mode. > > Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode? > > Amicalement, You mean like this? Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f40 0 Octeon ebb6300(ram)# md.b 0x1f40 1 1f40: 01. Octeon ebb6300(ram)# md.b 0x1f42 1 1f42: 7e~
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Le 12/02/2011 08:14, Aaron Williams a écrit : > On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote: >> Le 12/02/2011 07:42, Aaron Williams a écrit : >>> I've placed the results of the scan below. >>> >>> The problem is that in 8-bit mode the code that scans the CFI does not >>> follow the specification. >>> >>> In the specification to read the CFI data you write 0x98 to address 0xAA, >>> not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to >>> 0x55 which in this case is wrong and won't work. When it tries 16-bit >>> mode then it writes to address 0xAA which causes it to work. >> >> Let us see the specs, then. The specs I have (admittedly not necessarily >> the latest: I use JESD 68.01, september 1999) state the following: >> >> "Nonvolatile memory devices are assumed to power up in a read-only >> state. Independent of that assumption, the Query structure contents must >> be able to be read at the specific address locations following a single >> system write cycle where: 1) a 98h Query command code is written to 55h >> address location within the device’s address space (in maximum device >> buswidth), and 2) the device is in any valid read state, such as “Read >> Array” or “Read ID Data”. >> >> I read "55h address location within the device’s address space (in >> maximum device buswidth" as implying that 0x55 is the only address to >> use but is in device bus terms, and that may mean different CPU >> addresses for different devices types: for x8 devices, one should access >> the byte address 0x55 because the device bus is in bytes, whereas for >> x8/x16 and x16 devices, one should access byte address 0xAA because it >> translates to x16 device bus address 0x55 -- regardless of actual x8 or >> x16 mode. >> >> Are we in sync here? > > This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode > according to the data sheet. Yes, but the 0xAA address is a byte address and the 0x55 address is a word address, translating to byte address 0xAA as well. On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte location for a pure x8 device is 0x55, and 0xAA for a x16 device, both in x16 or x8 mode (the difference is that byte mode will expect a byte write of 0x98 where x16 mode will expect a word write of 0x0098). This is in sync with my Macronix MX29LV400CB/CT spec. >> Now it's been a long time since I last looked at my ED Mini V2 Flash, >> but I should be able to dig it up and do a test within one or two hours. >> >>> -Aaron >> >>> Here's the results of the scan: >> Yes, that's what U-boot *CFI code* does, but I'd like to see what very >> basic writes and reads give without any detection logic involved. >> >> Amicalement, > > When I use the addresses and data shown in the datasheet, everything responds > as it should using mw.b and md.b. > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 > Octeon ebb6300(ram)# md.b 0x1f40 1 > 1f40: 01. > Octeon ebb6300(ram)# md.b 0x1f42 1 > 1f42: 7e~ > Octeon ebb6300(ram)# md.b 0x1f44 1 > 1f44: 00. > > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > Octeon ebb6300(ram)# md.b 0x1f400020 > 1f400020: 51Q > Octeon ebb6300(ram)# md.b 0x1f400022 > 1f400022: 52R > Octeon ebb6300(ram)# md.b 0x1f400024 > 1f400024: 59Y > Octeon ebb6300(ram)# md.b 0x1f400026 > 1f400026: 02. > Octeon ebb6300(ram)# md.b 0x1f400028 > 1f400028: 00. > > -Aaron The CFI query is normal for a x16 device: byte address 0xAA is word address 0x55, which is what is expected from a x16 device in x8 mode as in x16 mode. Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote: > Le 12/02/2011 07:42, Aaron Williams a écrit : > > I've placed the results of the scan below. > > > > The problem is that in 8-bit mode the code that scans the CFI does not > > follow the specification. > > > > In the specification to read the CFI data you write 0x98 to address 0xAA, > > not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to > > 0x55 which in this case is wrong and won't work. When it tries 16-bit > > mode then it writes to address 0xAA which causes it to work. > > Let us see the specs, then. The specs I have (admittedly not necessarily > the latest: I use JESD 68.01, september 1999) state the following: > > "Nonvolatile memory devices are assumed to power up in a read-only > state. Independent of that assumption, the Query structure contents must > be able to be read at the specific address locations following a single > system write cycle where: 1) a 98h Query command code is written to 55h > address location within the device’s address space (in maximum device > buswidth), and 2) the device is in any valid read state, such as “Read > Array” or “Read ID Data”. > > I read "55h address location within the device’s address space (in > maximum device buswidth" as implying that 0x55 is the only address to > use but is in device bus terms, and that may mean different CPU > addresses for different devices types: for x8 devices, one should access > the byte address 0x55 because the device bus is in bytes, whereas for > x8/x16 and x16 devices, one should access byte address 0xAA because it > translates to x16 device bus address 0x55 -- regardless of actual x8 or > x16 mode. > > Are we in sync here? This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode according to the data sheet. > > Now it's been a long time since I last looked at my ED Mini V2 Flash, > but I should be able to dig it up and do a test within one or two hours. > > > -Aaron > > > Here's the results of the scan: > Yes, that's what U-boot *CFI code* does, but I'd like to see what very > basic writes and reads give without any detection logic involved. > > Amicalement, When I use the addresses and data shown in the datasheet, everything responds as it should using mw.b and md.b. Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f40 1 1f40: 01. Octeon ebb6300(ram)# md.b 0x1f42 1 1f42: 7e~ Octeon ebb6300(ram)# md.b 0x1f44 1 1f44: 00. Octeon ebb6300(ram)# mw.b 0x1f40 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02. Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote: > Le 12/02/2011 07:42, Aaron Williams a écrit : > > I've placed the results of the scan below. > > > > The problem is that in 8-bit mode the code that scans the CFI does not > > follow the specification. > > > > In the specification to read the CFI data you write 0x98 to address 0xAA, > > not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to > > 0x55 which in this case is wrong and won't work. When it tries 16-bit > > mode then it writes to address 0xAA which causes it to work. > > Let us see the specs, then. The specs I have (admittedly not necessarily > the latest: I use JESD 68.01, september 1999) state the following: > > "Nonvolatile memory devices are assumed to power up in a read-only > state. Independent of that assumption, the Query structure contents must > be able to be read at the specific address locations following a single > system write cycle where: 1) a 98h Query command code is written to 55h > address location within the device’s address space (in maximum device > buswidth), and 2) the device is in any valid read state, such as “Read > Array” or “Read ID Data”. > > I read "55h address location within the device’s address space (in > maximum device buswidth" as implying that 0x55 is the only address to > use but is in device bus terms, and that may mean different CPU > addresses for different devices types: for x8 devices, one should access > the byte address 0x55 because the device bus is in bytes, whereas for > x8/x16 and x16 devices, one should access byte address 0xAA because it > translates to x16 device bus address 0x55 -- regardless of actual x8 or > x16 mode. > > Are we in sync here? > > Now it's been a long time since I last looked at my ED Mini V2 Flash, > but I should be able to dig it up and do a test within one or two hours. > > > -Aaron > > > Here's the results of the scan: > Yes, that's what U-boot *CFI code* does, but I'd like to see what very > basic writes and reads give without any detection logic involved. > > Amicalement, I'm looking at the Spansion S29GL-N datasheet from 2008. Look at table 10.3 on page 53. http://www.spansion.com/Support/Datasheets/S29GL-N_01_12_e.pdf -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Le 12/02/2011 07:42, Aaron Williams a écrit : > I've placed the results of the scan below. > > The problem is that in 8-bit mode the code that scans the CFI does not follow > the specification. > > In the specification to read the CFI data you write 0x98 to address 0xAA, not > address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which > in this case is wrong and won't work. When it tries 16-bit mode then it writes > to address 0xAA which causes it to work. Let us see the specs, then. The specs I have (admittedly not necessarily the latest: I use JESD 68.01, september 1999) state the following: "Nonvolatile memory devices are assumed to power up in a read-only state. Independent of that assumption, the Query structure contents must be able to be read at the specific address locations following a single system write cycle where: 1) a 98h Query command code is written to 55h address location within the device’s address space (in maximum device buswidth), and 2) the device is in any valid read state, such as “Read Array” or “Read ID Data”. I read "55h address location within the device’s address space (in maximum device buswidth" as implying that 0x55 is the only address to use but is in device bus terms, and that may mean different CPU addresses for different devices types: for x8 devices, one should access the byte address 0x55 because the device bus is in bytes, whereas for x8/x16 and x16 devices, one should access byte address 0xAA because it translates to x16 device bus address 0x55 -- regardless of actual x8 or x16 mode. Are we in sync here? Now it's been a long time since I last looked at my ED Mini V2 Flash, but I should be able to dig it up and do a test within one or two hours. > -Aaron > > Here's the results of the scan: Yes, that's what U-boot *CFI code* does, but I'd like to see what very basic writes and reads give without any detection logic involved. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Friday, February 11, 2011 10:25:46 pm Albert ARIBAUD wrote: > Le 12/02/2011 01:15, Aaron Williams a écrit : > > I think I found the problem. The cfi code does not work properly in x8 > > mode. > > > > In x8 mode, according to the datasheet, the addresses should be doubled > > for all of the commands. Additionally, according to my correspondence > > with Spansion, there needs to be at least a 500ns delay after a reset > > command. > > > > The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT > > when it is actually 8-bits. Currently things just happen to work because > > the bus is being incorrectly detected as 16-bits, > > > > The 16-bit bus detection, however, breaks in x8 mode when it issues the > > commands for the manufacturer ID. > > > > In this case, the following takes place: > > > > In cmdset_amd_read_jedec_ids > > fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit > > flash_write16: Wrote 0xf0f0 to address 1f40 > > funlock writing 0xaa to address 0xaaa > > fwc addr 1f401554 cmd aa 16bit x 8 bit > > flash_write16: Wrote 0x to address 1f401554 > > funlock writing 0xaa to address 0x555 > > fwc addr 1f400aaa cmd 55 16bit x 8 bit > > flash_write16: Wrote 0x to address 1f400aaa > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit > > flash_write16: Wrote 0x9090 to address 1f401554 > > flash_read8: Read 0x0 from address 1f41 > > flash_read8: Read 0x3f from address 1f43 > > > > This does not work. > > > > If the proper sequence is written, then it works fine. > > > > The proper sequence, according to the datasheet, is to do the following: > > > > write 0xf0 to address 0x > > write 0xaa to address 0xaaa > > write 0x55 to address 0x555 > > write 0x90 to address 0xaaa > > read address 0 (returns 1 as expected) > > read address 2 (returns 0x7e as expected) > > ... > > > > So the cfi code is broken in the x8 case. > > Hmm... It would be surprising that the x8 CFI code be broken -- not > impossible, mind you -- because it was intensively used with a variety > of chips, and thus extensively checked for brokenness. > > What *might* be at stake is the result of the width detection, because > many reputedly CFI compliant Flash devices are actually not compliant, > especially among the dual-width, x8/x16, ones. On my ED Mini V2, there > is a Macronix x8/x16 part which presents its CFI QRY response as a pure > x16 even though it is a x8/x16, thus tricking the width detection > mechanism into taking the wrong decision; I had to resort to using the > LEGACY feature of manually defining the widths. > > Did you check the Flash part against the CFI specs, including the QRY > location and layout? > > Can you boot into a RAM-baed u-boot and use its memory write and read > commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device? > > Amicalement, I've placed the results of the scan below. The problem is that in 8-bit mode the code that scans the CFI does not follow the specification. In the specification to read the CFI data you write 0x98 to address 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work. -Aaron Here's the results of the scan: flash detect cfi fwc addr 1f40 cmd f0 f0 8bit x 8 bit flash_write8: Wrote 0xf0 to address 1f40 fwc addr 1f400055 cmd 98 98 8bit x 8 bit flash_write8: Wrote 0x98 to address 1f400055 is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010 is= 0 51 flash_read8: Read 0x0 from address 1f400010 fwc addr 1f40 cmd f0 f0 8bit x 8 bit flash_write8: Wrote 0xf0 to address 1f40 fwc addr 1f400555 cmd 98 98 8bit x 8 bit flash_write8: Wrote 0x98 to address 1f400555 is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010 is= 0 51 flash_read8: Read 0x0 from address 1f400010 fwc addr 1f40 cmd f0 f0 8bit x 8 bit
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Le 12/02/2011 01:15, Aaron Williams a écrit : > I think I found the problem. The cfi code does not work properly in x8 mode. > > In x8 mode, according to the datasheet, the addresses should be doubled for > all of the commands. Additionally, according to my correspondence with > Spansion, there needs to be at least a 500ns delay after a reset command. > > The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when > it is actually 8-bits. Currently things just happen to work because the bus is > being incorrectly detected as 16-bits, > > The 16-bit bus detection, however, breaks in x8 mode when it issues the > commands for the manufacturer ID. > > In this case, the following takes place: > > In cmdset_amd_read_jedec_ids > fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit > flash_write16: Wrote 0xf0f0 to address 1f40 > funlock writing 0xaa to address 0xaaa > fwc addr 1f401554 cmd aa 16bit x 8 bit > flash_write16: Wrote 0x to address 1f401554 > funlock writing 0xaa to address 0x555 > fwc addr 1f400aaa cmd 55 16bit x 8 bit > flash_write16: Wrote 0x to address 1f400aaa > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit > flash_write16: Wrote 0x9090 to address 1f401554 > flash_read8: Read 0x0 from address 1f41 > flash_read8: Read 0x3f from address 1f43 > > This does not work. > > If the proper sequence is written, then it works fine. > > The proper sequence, according to the datasheet, is to do the following: > > write 0xf0 to address 0x > write 0xaa to address 0xaaa > write 0x55 to address 0x555 > write 0x90 to address 0xaaa > read address 0 (returns 1 as expected) > read address 2 (returns 0x7e as expected) > ... > > So the cfi code is broken in the x8 case. Hmm... It would be surprising that the x8 CFI code be broken -- not impossible, mind you -- because it was intensively used with a variety of chips, and thus extensively checked for brokenness. What *might* be at stake is the result of the width detection, because many reputedly CFI compliant Flash devices are actually not compliant, especially among the dual-width, x8/x16, ones. On my ED Mini V2, there is a Macronix x8/x16 part which presents its CFI QRY response as a pure x16 even though it is a x8/x16, thus tricking the width detection mechanism into taking the wrong decision; I had to resort to using the LEGACY feature of manually defining the widths. Did you check the Flash part against the CFI specs, including the QRY location and layout? Can you boot into a RAM-baed u-boot and use its memory write and read commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
I think I found the problem. The cfi code does not work properly in x8 mode.
In x8 mode, according to the datasheet, the addresses should be doubled for
all of the commands. Additionally, according to my correspondence with
Spansion, there needs to be at least a 500ns delay after a reset command.
The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when
it is actually 8-bits. Currently things just happen to work because the bus is
being incorrectly detected as 16-bits,
The 16-bit bus detection, however, breaks in x8 mode when it issues the
commands for the manufacturer ID.
In this case, the following takes place:
In cmdset_amd_read_jedec_ids
fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
flash_write16: Wrote 0xf0f0 to address 1f40
funlock writing 0xaa to address 0xaaa
fwc addr 1f401554 cmd aa 16bit x 8 bit
flash_write16: Wrote 0x to address 1f401554
funlock writing 0xaa to address 0x555
fwc addr 1f400aaa cmd 55 16bit x 8 bit
flash_write16: Wrote 0x to address 1f400aaa
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_write16: Wrote 0x9090 to address 1f401554
flash_read8: Read 0x0 from address 1f41
flash_read8: Read 0x3f from address 1f43
This does not work.
If the proper sequence is written, then it works fine.
The proper sequence, according to the datasheet, is to do the following:
write 0xf0 to address 0x
write 0xaa to address 0xaaa
write 0x55 to address 0x555
write 0x90 to address 0xaaa
read address 0 (returns 1 as expected)
read address 2 (returns 0x7e as expected)
...
So the cfi code is broken in the x8 case.
-Aaron Williams
On Thursday, February 10, 2011 08:05:37 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > > > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> > > >
> > > > wrote:
> > > > >> I would suggest to make sure any caching/prefetching stuff is off,
> > > > >> hardware is doing one flash bus access per CPU read/write.
> > > > >>
> > > > >> In cmdset_amd_read_jedec_ids() after this line:
> > > > >>
> > > > >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> > > > >>
> > > > >> add something like
> > > > >>
> > > > >> printf("test manf id word = %04x\n", *(volatile uint16_t
> > > > >> *)0x1f40); printf("test device id word = %04x\n", *(volatile
> > > > >> uint16_t
> > > > >> *)0x1f42); printf("test device id word = %04x\n", *(volatile
> > > > >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> > > > >> *(volatile uint16_t *)0x1f40001e);
> > > > >>
> > > > >> and see what you get.
> > > > >
> > > > > fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
> > > > > flash_write16: address: 1f40, value: 0xf0f0
> > > > > fwc addr 1f401554 cmd aa 16bit x 8 bit
> > > > > flash_write16: address: 1f401554, value: 0x
> > > > > fwc addr 1f400aaa cmd 55 16bit x 8 bit
> > > > > flash_write16: address: 1f400aaa, value: 0x
> > > > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > > > flash_write16: address: 1f401554, value: 0x9090
> > > > > flash_read8: address: 1f41, value: 0x0
> > > > > test manf id word = 1000
> > > > > test device id word = 013f
> > > > > test device id word = da6c
> > > > > test device id word = 2926
> > > >
> > > > looks like garbage :-( What's in the flash at those addresses?
> > > > Maybe something is happening to mess up the unlock sequence and
> > > > you're reading the memory data instead of the device codes.
> > > >
> > > > It's odd that earlier in the sequence when the CFI query data is read
> > > > the byte data is mirrored across both bytes of the response, here the
> > > > two bytes are different.
> > >
> > > I received an email back from Spansion about this problem. They
> > > suggested that instead of the following:
> > >
> > > fwc addr 1f401554 cmd aa 16bit x 8 bit
> > > flash_write16: Wrote 0x to address 1f401554
> > > funlock writing 0xaa to address 0x555
> > > fwc addr 1f400aaa cmd 55 16bit x 8 bit
> > > flash_write16: Wrote 0x to address 1f400aaa
> > > fwc addr 1f401
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> > >
> > > wrote:
> > > >> I would suggest to make sure any caching/prefetching stuff is off,
> > > >> hardware is doing one flash bus access per CPU read/write.
> > > >>
> > > >> In cmdset_amd_read_jedec_ids() after this line:
> > > >>
> > > >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> > > >>
> > > >> add something like
> > > >>
> > > >> printf("test manf id word = %04x\n", *(volatile uint16_t
> > > >> *)0x1f40); printf("test device id word = %04x\n", *(volatile
> > > >> uint16_t
> > > >> *)0x1f42); printf("test device id word = %04x\n", *(volatile
> > > >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> > > >> *(volatile uint16_t *)0x1f40001e);
> > > >>
> > > >> and see what you get.
> > > >
> > > > fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
> > > > flash_write16: address: 1f40, value: 0xf0f0
> > > > fwc addr 1f401554 cmd aa 16bit x 8 bit
> > > > flash_write16: address: 1f401554, value: 0x
> > > > fwc addr 1f400aaa cmd 55 16bit x 8 bit
> > > > flash_write16: address: 1f400aaa, value: 0x
> > > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > > flash_write16: address: 1f401554, value: 0x9090
> > > > flash_read8: address: 1f41, value: 0x0
> > > > test manf id word = 1000
> > > > test device id word = 013f
> > > > test device id word = da6c
> > > > test device id word = 2926
> > >
> > > looks like garbage :-( What's in the flash at those addresses? Maybe
> > > something is happening to mess up the unlock sequence and you're
> > > reading the memory data instead of the device codes.
> > >
> > > It's odd that earlier in the sequence when the CFI query data is read
> > > the byte data is mirrored across both bytes of the response, here the
> > > two bytes are different.
> >
> > I received an email back from Spansion about this problem. They suggested
> > that instead of the following:
> >
> > fwc addr 1f401554 cmd aa 16bit x 8 bit
> > flash_write16: Wrote 0x to address 1f401554
> > funlock writing 0xaa to address 0x555
> > fwc addr 1f400aaa cmd 55 16bit x 8 bit
> > flash_write16: Wrote 0x to address 1f400aaa
> > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > flash_write16: Wrote 0x9090 to address 1f401554
> >
> > to instead do the following:
> > write 0xAA to 0x1F400AAA
> > write 0x55 to 0x1F400555
> > write 0x90 to 0x1F400AAA
> >
> > read 0x1F41 returns 0x01
> > read 0x1F43 returns 0x7e
> >
> > This looks correct.
> >
> > I found two things I need to do to work around the problem. First, in
> > flash_write_cmd I use info->chipwidth instead of info->portwidth for the
> > write commands, and second, in __flash_detect_cfi I don't modify the
> > address in compatibility mode. This works. If either of those steps are
> > left out then reading the manufacturer ID fails.
> >
> > -Aaron
>
> It looks like I spoke too soon. It fixes the manufacturer problem but
> everything else is now broken.
>
> -Aaron
It works now, but I had to hard-code cmdset_amd_read_jedec_ids for some
reason.
static void cmdset_amd_read_jedec_ids(flash_info_t *info)
{
ushort bankId = 0;
uchar manuId;
debug("In %s\n", __func__);
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_write_cmd(info, 0, 0x555, AMD_CMD_UNLOCK_START);
flash_write_cmd(info, 0, 0x2AA, AMD_CMD_UNLOCK_ACK);
flash_write_cmd(info, 0, 0x555, FLASH_CMD_READ_ID);
/*flash_unlock_seq(info, 0); */
/*flash_write_cmd(info, 0, info->addr_unlock1, FLASH_CMD_READ_ID);*/
With this, everything works with my mod to flash_write_cmd to use chipwidth
instead of portwidth.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> >
> > wrote:
> > >> I would suggest to make sure any caching/prefetching stuff is off,
> > >> hardware is doing one flash bus access per CPU read/write.
> > >>
> > >> In cmdset_amd_read_jedec_ids() after this line:
> > >>
> > >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> > >>
> > >> add something like
> > >>
> > >> printf("test manf id word = %04x\n", *(volatile uint16_t
> > >> *)0x1f40); printf("test device id word = %04x\n", *(volatile
> > >> uint16_t
> > >> *)0x1f42); printf("test device id word = %04x\n", *(volatile
> > >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> > >> *(volatile uint16_t *)0x1f40001e);
> > >>
> > >> and see what you get.
> > >
> > > fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
> > > flash_write16: address: 1f40, value: 0xf0f0
> > > fwc addr 1f401554 cmd aa 16bit x 8 bit
> > > flash_write16: address: 1f401554, value: 0x
> > > fwc addr 1f400aaa cmd 55 16bit x 8 bit
> > > flash_write16: address: 1f400aaa, value: 0x
> > > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > > flash_write16: address: 1f401554, value: 0x9090
> > > flash_read8: address: 1f41, value: 0x0
> > > test manf id word = 1000
> > > test device id word = 013f
> > > test device id word = da6c
> > > test device id word = 2926
> >
> > looks like garbage :-( What's in the flash at those addresses? Maybe
> > something is happening to mess up the unlock sequence and you're
> > reading the memory data instead of the device codes.
> >
> > It's odd that earlier in the sequence when the CFI query data is read
> > the byte data is mirrored across both bytes of the response, here the
> > two bytes are different.
>
> I received an email back from Spansion about this problem. They suggested
> that instead of the following:
>
> fwc addr 1f401554 cmd aa 16bit x 8 bit
> flash_write16: Wrote 0x to address 1f401554
> funlock writing 0xaa to address 0x555
> fwc addr 1f400aaa cmd 55 16bit x 8 bit
> flash_write16: Wrote 0x to address 1f400aaa
> fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> flash_write16: Wrote 0x9090 to address 1f401554
>
> to instead do the following:
> write 0xAA to 0x1F400AAA
> write 0x55 to 0x1F400555
> write 0x90 to 0x1F400AAA
>
> read 0x1F41 returns 0x01
> read 0x1F43 returns 0x7e
>
> This looks correct.
>
> I found two things I need to do to work around the problem. First, in
> flash_write_cmd I use info->chipwidth instead of info->portwidth for the
> write commands, and second, in __flash_detect_cfi I don't modify the
> address in compatibility mode. This works. If either of those steps are
> left out then reading the manufacturer ID fails.
>
> -Aaron
It looks like I spoke too soon. It fixes the manufacturer problem but
everything else is now broken.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> On Thu, Feb 10, 2011 at 00:28, Aaron Williams
>
> wrote:
> >> I would suggest to make sure any caching/prefetching stuff is off,
> >> hardware is doing one flash bus access per CPU read/write.
> >>
> >> In cmdset_amd_read_jedec_ids() after this line:
> >>
> >> manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
> >>
> >> add something like
> >>
> >> printf("test manf id word = %04x\n", *(volatile uint16_t *)0x1f40);
> >> printf("test device id word = %04x\n", *(volatile uint16_t
> >> *)0x1f42); printf("test device id word = %04x\n", *(volatile
> >> uint16_t *)0x1f40001c); printf("test device id word = %04x\n",
> >> *(volatile uint16_t *)0x1f40001e);
> >>
> >> and see what you get.
> >
> > fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
> > flash_write16: address: 1f40, value: 0xf0f0
> > fwc addr 1f401554 cmd aa 16bit x 8 bit
> > flash_write16: address: 1f401554, value: 0x
> > fwc addr 1f400aaa cmd 55 16bit x 8 bit
> > flash_write16: address: 1f400aaa, value: 0x
> > fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> > flash_write16: address: 1f401554, value: 0x9090
> > flash_read8: address: 1f41, value: 0x0
> > test manf id word = 1000
> > test device id word = 013f
> > test device id word = da6c
> > test device id word = 2926
>
> looks like garbage :-( What's in the flash at those addresses? Maybe
> something is happening to mess up the unlock sequence and you're
> reading the memory data instead of the device codes.
>
> It's odd that earlier in the sequence when the CFI query data is read
> the byte data is mirrored across both bytes of the response, here the
> two bytes are different.
I received an email back from Spansion about this problem. They suggested that
instead of the following:
fwc addr 1f401554 cmd aa 16bit x 8 bit
flash_write16: Wrote 0x to address 1f401554
funlock writing 0xaa to address 0x555
fwc addr 1f400aaa cmd 55 16bit x 8 bit
flash_write16: Wrote 0x to address 1f400aaa
fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
flash_write16: Wrote 0x9090 to address 1f401554
to instead do the following:
write 0xAA to 0x1F400AAA
write 0x55 to 0x1F400555
write 0x90 to 0x1F400AAA
read 0x1F41 returns 0x01
read 0x1F43 returns 0x7e
This looks correct.
I found two things I need to do to work around the problem. First, in
flash_write_cmd I use info->chipwidth instead of info->portwidth for the write
commands, and second, in __flash_detect_cfi I don't modify the address in
compatibility mode. This works. If either of those steps are left out then
reading the manufacturer ID fails.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Tuesday, February 08, 2011 03:11:54 pm Aaron Williams wrote:
> On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> > On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> > > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> > >> Trying again submitting the patch.
> > >>
> > >> /* Do manufacturer-specific fixups */
> > >> switch (info->manufacturer_id) {
> > >>
> > >> + case 0x:
> > >> case 0x0001:
> > >> flash_fixup_amd(info, &qry);
> > >> break;
> > >
> > > This seems unrelated.
> > >
> > > Otherwise, the patch looks good. Whose tree should it go through?
> > > It's not really a NAND patch, though NAND is the reason for it.
> >
> > NAK
> >
> > This is not only unrelated (which the OP was told to fix on the
> > previous post of this patch), but wrong. The S29GL series chips don't
> > return 0x for the manufacturer ID. AMD (later Spansion) have
> > always had mfg. ID 0x0001.
> >
> > I have various boards with S29GL064, S29GL128N, and S29GL256P, and
> > they all return the correct value (0x0001) for the mfg. ID. I looked
> > up the latest datasheet and they have not changed that section.
>
> I always get 0x for the mfg ID and cannot explain it. The full part
> number is S29GL064N90TF103 010FF058. That is why it was added. Without it,
> the proper fixup doesn't happen with this chip.
>
> -Aaron
Note that in our case the port width is 16-bits and the chip width is 8 bits.
I added some printf statements for all read accesses to help.
Here's the output when I enable debugging:
flash detect cfi
fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit
fwc addr 1f40 cmd ff 16bit x 8 bit
fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr 1f400020 flash_read16: address 1f400020, value 0x5151
is= 5151 5151
flash_read16: address 1f400020, value 0x5151
is= cmd 52(R) addr 1f400022 flash_read16: address 1f400022, value 0x5252
is= 5252 5252
flash_read16: address 1f400022, value 0x5252
is= cmd 59(Y) addr 1f400024 flash_read16: address 1f400024, value 0x5959
is= 5959 5959
flash_read16: address 1f400024, value 0x5959
flash_read8: address 1f400021, value 0x51
flash_read8: address 1f400023, value 0x52
flash_read8: address 1f400025, value 0x59
flash_read8: address 1f400027, value 0x2
flash_read8: address 1f400029, value 0x0
flash_read8: address 1f40002b, value 0x40
flash_read8: address 1f40002d, value 0x0
flash_read8: address 1f40002f, value 0x0
flash_read8: address 1f400031, value 0x0
flash_read8: address 1f400033, value 0x0
flash_read8: address 1f400035, value 0x0
flash_read8: address 1f400037, value 0x27
flash_read8: address 1f400039, value 0x36
flash_read8: address 1f40003b, value 0x0
flash_read8: address 1f40003d, value 0x0
flash_read8: address 1f40003f, value 0x7
flash_read8: address 1f400041, value 0x7
flash_read8: address 1f400043, value 0xa
flash_read8: address 1f400045,
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> >> Trying again submitting the patch.
> >>
> >> /* Do manufacturer-specific fixups */
> >> switch (info->manufacturer_id) {
> >> + case 0x:
> >> case 0x0001:
> >> flash_fixup_amd(info, &qry);
> >> break;
> >
> > This seems unrelated.
> >
> > Otherwise, the patch looks good. Whose tree should it go through?
> > It's not really a NAND patch, though NAND is the reason for it.
>
> NAK
>
> This is not only unrelated (which the OP was told to fix on the
> previous post of this patch), but wrong. The S29GL series chips don't
> return 0x for the manufacturer ID. AMD (later Spansion) have
> always had mfg. ID 0x0001.
>
> I have various boards with S29GL064, S29GL128N, and S29GL256P, and
> they all return the correct value (0x0001) for the mfg. ID. I looked
> up the latest datasheet and they have not changed that section.
I always get 0x for the mfg ID and cannot explain it. The full part number
is S29GL064N90TF103 010FF058. That is why it was added. Without it, the proper
fixup doesn't happen with this chip.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
>> Trying again submitting the patch.
>>
>> /* Do manufacturer-specific fixups */
>> switch (info->manufacturer_id) {
>> + case 0x:
>> case 0x0001:
>> flash_fixup_amd(info, &qry);
>> break;
>
> This seems unrelated.
>
> Otherwise, the patch looks good. Whose tree should it go through?
> It's not really a NAND patch, though NAND is the reason for it.
NAK
This is not only unrelated (which the OP was told to fix on the
previous post of this patch), but wrong. The S29GL series chips don't
return 0x for the manufacturer ID. AMD (later Spansion) have
always had mfg. ID 0x0001.
I have various boards with S29GL064, S29GL128N, and S29GL256P, and
they all return the correct value (0x0001) for the mfg. ID. I looked
up the latest datasheet and they have not changed that section.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> Trying again submitting the patch.
>
> Adds support for NAND flash chips that are 4GiB and larger.
>
> Signed-off-by: Aaron Williams
>
> diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
> index 5481c88..26d24b0 100644
> --- a/common/cmd_mtdparts.c
> +++ b/common/cmd_mtdparts.c
> @@ -21,6 +21,11 @@
> * $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
> * Copyright 2002 SYSGO Real-Time Solutions GmbH
> *
> + * (C) Copyright 2011
> + * Aaron Williams, Cavium Networks, Inc.
> + *
> + * Added support for partitions and flash greater than or equal to 4GiB.
> + *
> * See file CREDITS for list of people who contributed to this
> * project.
> *
Changelogs go in git, not at the top of the file.
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index dd394a8..105eb3f 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1162,10 +1162,10 @@ void flash_print_info (flash_info_t * info)
> info->name,
> (info->portwidth << 3), (info->chipwidth << 3));
> if (info->size < 1024*1024)
> - printf (" Size: %ld kB in %d Sectors\n",
> + printf (" Size: %ld KiB in %d Sectors\n",
> info->size >> 10, info->sector_count);
> else
> - printf (" Size: %ld MB in %d Sectors\n",
> + printf (" Size: %ld MiB in %d Sectors\n",
> info->size >> 20, info->sector_count);
> printf (" ");
> switch (info->vendor) {
> @@ -1924,6 +1924,7 @@ ulong flash_get_size (phys_addr_t base, int banknum)
>
> /* Do manufacturer-specific fixups */
> switch (info->manufacturer_id) {
> + case 0x:
> case 0x0001:
> flash_fixup_amd(info, &qry);
> break;
This seems unrelated.
Otherwise, the patch looks good. Whose tree should it go through?
It's not really a NAND patch, though NAND is the reason for it.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
