Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Hector Palacios, On 09/19/2013 06:07 PM, Marek Vasut wrote: Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please disregards my previous message. You actually just saved me a lot of annoyance, thank you ;-) btw feel free to run into me on IRC (#u-boot on freenode) or jabber so we can work on the backporting-to-uboot part ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Marek Vasut,
On 09/19/2013 06:07 PM, Marek Vasut wrote:
btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm
trying to backport patches from -next and apply the GPMI NAND patchset, without
much luck yet.
If it helps, to make it work on v3.10 I had to apply lots of commits (listed in
reverse order, from most recent to oldest):
53a9abf27213154d1ebaa54d111533f1e69d8ef3 mtd: mtd-abi: add a helper to detect the nand
type
44aabd5fe3423f5b2071379bd55e708d523a1b4c mtd: add a helper to detect the nand
type
2a2d49314b6a36eca80947ad021d01f7e6294291 mtd: add MTD_MLCNANDFLASH case for
mtd_type_show()
576c9744f0f62d0b8d207d74b9066f00f4bdd347 jffs2: do not support the MLC nand
654b09629a50fd1680afcce46514e9ffc6723418 mtd: fix the wrong mtd-type for nand
chip
95bc60491c394174cdbd1b24b0940fa61b6f2aec mtd: add more comment for
MTD_NANDFLASH/MTD_MLCNANDFLASH
b9032012d68cf881e48237336e79d783b69f2a1b mtd: gpmi: rewrite the gpmi_ecc_write_oob()
to support the jffs2
2c92e6f5e6a61020443ec3dbb7d51c6a84170f36 mtd: print out the cell information
for nand chip
01e1b2c398952ead5d8b3eb370dc7a31560e9c00 mtd: set the cell information for ONFI
nand
2dcd73d5c96067342fafeb088cc08872f68558d5 mtd: nand: rename the cellinfo to
bits_per_cell
40f5c3f65f9f2151ae5cdd9293af6d62f551d51a mtd: add a new field to mtd_info{}
a0181739d881f3e973ebfbe29769f0d4f08b26a4 mtd: add ECC info for nand_flash_dev{}
247db5b42147d0b764c6096e1b55c7f01439b9a5 mtd: add a helper to get the supported
features for ONFI nand
0db74df18a1dbd9814637ba891cc123f3b7a4bba mtd: add data structures for Extended
Parameter Page
f4ead19a666581c78a7f9d27379e4ee4850d38ae mtd: add datasheet's ECC information to
nand_chip{}
b47e2aa8f044092ea63a2b28d1ead0ff6bc54ac3 mtd: nand: remove NAND_BBT_SCANEMPTY
91eae06eb963ad7f5faf8f585f21d34921cb7830 mtd: nand: hide in-memory BBT implementation
details
4b8c49529b49e84a9472e52ffa2b452b48779563 mtd: nand_base: Only use GET/SET FEATURES
command on chips that support them.
8babb2385cfcd9ee24b62e2dd1577a1e05ef2f1f mtd: nand: fsmc: update of OF support
34b182c94acfc08e851af3500d8f3fa8b1d073e5 mtd: increase max OOB size to 744
b726168414d1ce3cff143e4bdc3f944459894388 mtd: nand: reword nand_chip bad block
interface comments
36b46f044704df158078beaa368284fdc435f34a mtd: mpc5121_nfc: cleanup clock API use
5afbc047077a88c38181b9d4de6bea70a140b5a0 mtd cs553x_nand: use kzalloc() instead
of memset
247f500f0903c084fa04f96e41aed049a3ec0709 mtd: atmel_nand: fix error return code in
atmel_nand_probe()
573f505290ac60920d2e4d4c39323acb14b7b0c4 mtd: remove alauda driver
240ca8e6f0f5689bc34130c5843fc7df40fc994a mtd: nand: mxc_nand: mark 'const'
properly
fdd0ddf7fac3ae18b8cbaf64a60a3f9591e124ac mtd: r852: Staticize local symbols
e979054e90b480bb62ac8ac2d69bbe13418f6514 mtd: nandsim: Staticize local symbols
cfa8de169b47502e0ce8b30b9a79b615b68af6b1 mtd: MTD_NAND_DENALI should depend on
HAS_DMA
d322e0477e11fdd9bdec1040a7c8d4e14ec3e188 mtd: fsmc_nand: simplify
platform_get_resource_byname/devm_ioremap_resource
f09f9d2061572d858856085d57d2f580fb60db0d mtd: atmel_nand: pmecc: fix bug fail to
correct bit error in 1024-bytes sector
8a7f3dbd96350bc1d3f012c14da682049eb89530 mtd: nand: fixup kerneldoc, rename
parameter
69d75957804c0cc214b705fee8c618bcca6c1671 mtd: gpmi: remove the nand_scan()
6aa28d55ddaf7ce5e245f835bfd0871ef3db492c mtd: set ONFI nand's default hooks in
nand_set_defaults()
3320916b8845e06d04cea7b492920829ce49ac0e mtd: set the ecc step size for master/slave
mtd_info
8d6a288d8b950b08a150f96781d365f770669898 mtd: nand: silence some shift wrap
warnings
38cd6478fb2b38b12525fbede22cf549e1581a3e mtd: simplify use of
devm_ioremap_resource
7b900eb9f497da080c3a46a50fe33ffa14e093aa mtd: nand: Allow to build pxa3xx_nand on
Orion platforms
2cd4ce5d72919da4a5eb48f63d50ccbb38d96b19 mtd: nand: pxa3xx: Allow devices with no dma
resources
383b9edf4a14193c819cb5f1cf841206da064095 mtd: nand: pxa3xx: Add __maybe_unused keyword
to enable_int()
4552440a0c279fac04e4a7216c36a537956a2acc mtd: nand: pxa3xx: Make dma code dependent on
dma capable platforms
475e1ad93c4bc100ad8ed82013669f8569471a96 mtd: nand: pxa3xx: Move cached registers to
info structure
8270cfd39ae136c10082287f612f825414a01950 mtd: nand: pxa3xx: Remove uneeded
internal cmdset
234f82f9269e2a96c4b6f3802121d8e307d29580 mtd: nand: pxa3xx: Remove hardcoded
mtd name
afa5a8a3750f428fe4c9f9a5840dfddfe4f7d503 mtd: nand: pxa3xx: Add a local loop
variable
dc33d8fcfc245dab443ef1a5172864bb6d3d2c94 mtd: nand: pxa3xx: Use 'length override' in
ONFI paramater page read
1b3334cf50d40eb1ef7f39d6e3396b30d5d085f0 mtd: nand: pxa3xx: Support command
buffer #3
33275c59dab511acd0fbb988519bd8dba670b7ff mtd: nand: pxa3xx: Allow to set/clear the
'spare enable' field
08f509aac14a0c7120f2885ac543c9758b00a518 mtd: nand: pxa3xx: Handle ECC and DMA
enable/disable properly
00187c3a76b6e3da79ef495ce2a6c68fe96ee0de mtd: nand: pxa3xx: Introduce
'marvell,armada370-nand'
Re: [U-Boot] gpmi-nand driver and jffs2 support
On 09/19/2013 06:07 PM, Marek Vasut wrote: Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please disregards my previous message. Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Hector Palacios, On 09/19/2013 06:07 PM, Marek Vasut wrote: Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please disregards my previous message. After applying the batch of patches, this is what I get. Interestingly enough, this JFFS2 was written from FSL 2.6.35 kernel. [ 24.118091] jffs2: mtd-read(0x100 bytes from 0x0) returned ECC error [ 24.164458] jffs2: mtd-read(0x1fa34 bytes from 0x5cc) returned ECC error [ 24.171377] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05cc: 0x7953 i nstead [ 24.180969] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05d0: 0xe837 i nstead [ 24.190675] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05d8: 0x85ff i nstead [ 24.200274] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05dc: 0xcde0 i nstead [ 24.209853] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05e0: 0x7000 i nstead [ 24.219428] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05e4: 0x020f i nstead [ 24.229000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05e8: 0x0200 i nstead [ 24.238570] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05ec: 0x2400 i nstead [ 24.248142] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x05f4: 0xa400 i nstead [ 24.257645] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0608: 0xacc8 i nstead [ 24.267191] jffs2: Further such events for this erase block will not be printed [ 24.275419] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x21c8: Read 0x, cal culated 0xd5be0e0f [ 24.287221] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x49d4: Read 0xd1f0, cal culated 0x34cb9a56 [ 24.300900] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0xb9c0: Read 0x7fd74190, cal culated 0xfdbc37a5 [ 24.312171] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0xd1f4: Read 0x1660, cal culated 0x00cb3014 [ 24.326509] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000161d4: Read 0x9a50, cal culated 0xcd68c7e3 [ 24.338761] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0001a1e4: Read 0x1450, cal culated 0xa3e78a6c [ 24.352739] jffs2: mtd-read(0xc28 bytes from 0x1f3d8) returned ECC error [ 24.359661] jffs2: Empty flash at 0x0001f3d4 ends at 0x0001f400 [ 24.366953] jffs2: mtd-read(0xbec bytes from 0x1f414) returned ECC error [ 24.374053] jffs2: Empty flash at 0x0001f410 ends at 0x0001f604 [ 24.381408] jffs2: mtd-read(0x9e8 bytes from 0x1f618) returned ECC error [ 24.388450] jffs2: Empty flash at 0x0001f614 ends at 0x0001fa00 [ 24.395141] jffs2: mtd-read(0x5f4 bytes from 0x1fa0c) returned ECC error [ 24.402059] jffs2: Empty flash at 0x0001fa08 ends at 0x0001fc00 [ 24.408794] jffs2:
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月15日 22:18, Marek Vasut 写道:
Dear Huang Shijie,
于 2013年09月04日 23:46, Hector Palacios 写道:
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged
all the commits done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or
linux v3.10.
We have abandoned the old gpmi driver, and we use the same gpmi code in
current FSL kernel.
Since we swtich to the upstream gpmi code, and it could not support the
jffs2,
and that's why you mount always failed.
With the patchset, mounting the jffs should work again, no? If mounting the jffs
If the jffs2 image is written by the uboot, the mounting should not works.
works with the patchset AND it only works with jffs written using the new
driver, you will need to introduce soem compatibility option or something along
that.
do you mean i should a new dt property for the jffs2 support ?
[1]
http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm
doing anything wrong in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs
fixing,
otherwise it's impossible to do a drop-in replacement for the ancient
FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to
know what
exactly is missing.
92a2645 mtd: add 4 Toshiba nand chips for the full-id case
ec6e87e mtd: add the support to parse out the full-id nand type
Do these really have any impact?
yes. the full-id nand is not supported by the old mtd code.
f22d5f6 mtd: add new fields to nand_flash_dev{}
2febcdf mtd: gpmi: set the BCH's geometry with the ecc info
d1048aa mtd: add the ecc info for some full-id nand chips
5721934 mtd: parse out the ECC info for the full-id nand chips
2dc0bdd mtd: add ECC info for nand_flash_dev{}
e2985fc mtd: replace the hardcode with the onfi_feature()
6dcbe0c mtd: get the ECC info from the Extended Parameter Page
5b40db6 mtd: add a helper to get the supported features for ONFI nand
5138a98 mtd: add data structures for Extended Parameter Page
10c86ba mtd: get the ECC info from the parameter page for ONFI nand
4cfeca2 mtd: add datasheet's ECC information to nand_chip{}
Hector, can you inspect those patches ?
Yes, please, we need more details. This seems to be related with how
the MTD drivers (in Linux and in U-Boot) access the OOB area to store
the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Before apply the patches above, the gpmi will use all the oob, so
oinfo-oobavail == 0 becomes true.
After apply the patches, the gpmi will not use all the oob for the ONFI
SLC nand or the full-id nand,
and it can supports the jffs2 when you apply the other SLC/MLC patchset.
So the patches you listed above are not enough?
It should be enough.
thanks
Huang Shijie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Hector Palacios, Dear Marek, On 09/04/2013 04:38 PM, Marek Vasut wrote: Dear Huang Shijie, On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: Dear Huang Shijie, How come hector was then able to write his JFFS2 partition ? If he uses the gpmi, he should not write the JFFS2, since the gpmi does not support the jffs2. He will get the failure in the end. Hector, can you comment on this? I don't think I'm following these comments. The facts are: 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0) a) does not mount on kernel v3.10 b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from Huang (actually I didn't use linux-next but instead a v3.10 where I merged all the commits done to MTD in linux-next, which are a lot). 2) A JFFS2 filesystem image written with U-Boot v2013.01 a) mounts OK on old FSL kernel 2.6.35 b) does not mount on kernel v3.10 (neither on v3.8, I believe). c) does not mount on linux-next with the patchset [1] [1] http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html Marek, could you please confirm 2b on your side, just in case I'm doing anything wrong in my custom U-Boot? Sorry for the late reply. I cannot test it, since I don't have such a setup. I still believe it'd be worth figuring out what the heck is going on in here. There is obviously a bug which breaks compatibility and that must not happen. [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie,
于 2013年09月04日 23:46, Hector Palacios 写道:
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged
all the commits done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or
linux v3.10.
We have abandoned the old gpmi driver, and we use the same gpmi code in
current FSL kernel.
Since we swtich to the upstream gpmi code, and it could not support the
jffs2,
and that's why you mount always failed.
With the patchset, mounting the jffs should work again, no? If mounting the
jffs
works with the patchset AND it only works with jffs written using the new
driver, you will need to introduce soem compatibility option or something along
that.
[1]
http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm
doing anything wrong in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs
fixing,
otherwise it's impossible to do a drop-in replacement for the ancient
FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to
know what
exactly is missing.
92a2645 mtd: add 4 Toshiba nand chips for the full-id case
ec6e87e mtd: add the support to parse out the full-id nand type
Do these really have any impact?
f22d5f6 mtd: add new fields to nand_flash_dev{}
2febcdf mtd: gpmi: set the BCH's geometry with the ecc info
d1048aa mtd: add the ecc info for some full-id nand chips
5721934 mtd: parse out the ECC info for the full-id nand chips
2dc0bdd mtd: add ECC info for nand_flash_dev{}
e2985fc mtd: replace the hardcode with the onfi_feature()
6dcbe0c mtd: get the ECC info from the Extended Parameter Page
5b40db6 mtd: add a helper to get the supported features for ONFI nand
5138a98 mtd: add data structures for Extended Parameter Page
10c86ba mtd: get the ECC info from the parameter page for ONFI nand
4cfeca2 mtd: add datasheet's ECC information to nand_chip{}
Hector, can you inspect those patches ?
Yes, please, we need more details. This seems to be related with how
the MTD drivers (in Linux and in U-Boot) access the OOB area to store
the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Before apply the patches above, the gpmi will use all the oob, so
oinfo-oobavail == 0 becomes true.
After apply the patches, the gpmi will not use all the oob for the ONFI
SLC nand or the full-id nand,
and it can supports the jffs2 when you apply the other SLC/MLC patchset.
So the patches you listed above are not enough?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月04日 23:46, Hector Palacios 写道:
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged
all the commits done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or
linux v3.10.
We have abandoned the old gpmi driver, and we use the same gpmi code in
current FSL kernel.
Since we swtich to the upstream gpmi code, and it could not support the
jffs2,
and that's why you mount always failed.
[1]
http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm
doing anything wrong in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs
fixing,
otherwise it's impossible to do a drop-in replacement for the ancient
FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to
know what
exactly is missing.
92a2645 mtd: add 4 Toshiba nand chips for the full-id case
ec6e87e mtd: add the support to parse out the full-id nand type
f22d5f6 mtd: add new fields to nand_flash_dev{}
2febcdf mtd: gpmi: set the BCH's geometry with the ecc info
d1048aa mtd: add the ecc info for some full-id nand chips
5721934 mtd: parse out the ECC info for the full-id nand chips
2dc0bdd mtd: add ECC info for nand_flash_dev{}
e2985fc mtd: replace the hardcode with the onfi_feature()
6dcbe0c mtd: get the ECC info from the Extended Parameter Page
5b40db6 mtd: add a helper to get the supported features for ONFI nand
5138a98 mtd: add data structures for Extended Parameter Page
10c86ba mtd: get the ECC info from the parameter page for ONFI nand
4cfeca2 mtd: add datasheet's ECC information to nand_chip{}
Yes, please, we need more details. This seems to be related with how
the MTD drivers (in Linux and in U-Boot) access the OOB area to store
the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Before apply the patches above, the gpmi will use all the oob, so
oinfo-oobavail == 0 becomes true.
After apply the patches, the gpmi will not use all the oob for the ONFI
SLC nand or the full-id nand,
and it can supports the jffs2 when you apply the other SLC/MLC patchset.
thanks
Huang Shijie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, 于 2013年09月03日 19:53, Marek Vasut 写道: questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next The jffs2 does not changed since the linux 3.7. All the changes happened in the drivers and mtd code. OK, JFFS2 aside then, let's focus on MTD core code. The gpmi does not support the jffs2 all the time. Only apply the slc/mlc patch set, the gpmi can support the jffs2. How come hector was then able to write his JFFS2 partition ? So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: Dear Huang Shijie, How come hector was then able to write his JFFS2 partition ? If he uses the gpmi, he should not write the JFFS2, since the gpmi does not support the jffs2. He will get the failure in the end. So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? Not compatible. This patch set is still underreview. that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Besides this patchset, the u-boot needs more patches to sync with the kernel mtd code. Such as the full-id features. thanks Huang Shijie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged all the commits
done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
[1] http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm doing anything wrong
in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs fixing,
otherwise it's impossible to do a drop-in replacement for the ancient FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to know what
exactly is missing.
Yes, please, we need more details. This seems to be related with how the MTD drivers
(in Linux and in U-Boot) access the OOB area to store the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: Dear Huang Shijie, How come hector was then able to write his JFFS2 partition ? If he uses the gpmi, he should not write the JFFS2, since the gpmi does not support the jffs2. He will get the failure in the end. Hector, can you comment on this? So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? Not compatible. This patch set is still underreview. So this patch breaks compatiblity with FSL kernel release? This needs fixing, otherwise it's impossible to do a drop-in replacement for the ancient FSL kernel. that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Besides this patchset, the u-boot needs more patches to sync with the kernel mtd code. Such as the full-id features. Can you elaborate on this more? This is very vague, I would like to know what exactly is missing. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, 于 2013年09月02日 19:32, Marek Vasut 写道: This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot and Linux would be incompatible for all MTD drivers. This would also mean that The jffs2 in uboot and linux is compatible now. But the mtd base code, such as nand_base.c /nand_bbt.c has changed. Ok, based on this claim AND U-Boot being last synced with Linux 3.7, the obvious questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next that I could mount with Linux 3.7 and earlier? And the gpmi for kernel has be changed too. All these changes are not sync with the uboot yet. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月03日 19:53, Marek Vasut 写道: questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next The jffs2 does not changed since the linux 3.7. All the changes happened in the drivers and mtd code. The gpmi does not support the jffs2 all the time. Only apply the slc/mlc patch set, the gpmi can support the jffs2. So the jffs2 support is compatiable all the time. that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. thanks Huang Shijie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang, On 09/02/2013 10:50 AM, Huang Shijie wrote: 于 2013年09月02日 16:42, Hector Palacios 写道: I am writing the JFFS2 partition from my custom U-Boot. Do you mean that they way it writes it could not be compatible with what the new driver expects? That sounds really bad. The mtd code(as well as the gpmi driver) has merge many patch to the kernel, BUT, the relative patches are not submitted to uboot maillist. So the code is not aligned between the uboot and the kernel. Ok, I just rewrote the JFFS2 partition using the mtd-utils and now it mounts correctly and without any error. So does this mean that U-Boot is now unable to properly write a JFFS2 partition for it to be understood by the linux-next kernel? What is exactly the difference? Does it only affect Freescale NAND controllers? I'm including the U-Boot mailing list in CC. The complete thread for reference: http://patchwork.ozlabs.org/patch/271322/ Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月02日 18:10, Hector Palacios 写道: So does this mean that U-Boot is now unable to properly write a JFFS2 partition for it to be understood by the linux-next For the gpmi nand controller, the uboot is not proper to write a jffs2 now. kernel? What is exactly the difference? Does it only affect Freescale NAND controllers? I think there are many difference. Just diff the nand_base.c, you can see there are many patches merged in the kernel's mtd code, but not exit in the uboot's mtd code. AFAIK, only the gpmi is affected now. thanks Huang Shijie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, 于 2013年09月02日 18:10, Hector Palacios 写道: So does this mean that U-Boot is now unable to properly write a JFFS2 partition for it to be understood by the linux-next For the gpmi nand controller, the uboot is not proper to write a jffs2 now. kernel? What is exactly the difference? Does it only affect Freescale NAND controllers? I think there are many difference. Just diff the nand_base.c, you can see there are many patches merged in the kernel's mtd code, but not exit in the uboot's mtd code. This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot and Linux would be incompatible for all MTD drivers. This would also mean that JFFS2 in Linux 3.7 is incompatible with Linux-next (since 3.7 was the last sync point between U-Boot and Linux MTD). Is that really the case? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月02日 19:32, Marek Vasut 写道: This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot and Linux would be incompatible for all MTD drivers. This would also mean that The jffs2 in uboot and linux is compatible now. But the mtd base code, such as nand_base.c /nand_bbt.c has changed. And the gpmi for kernel has be changed too. All these changes are not sync with the uboot yet. thanks Huang Shijie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
