Problem with developing Samsung K9F1G08U0A MTD driver

Problem with developing Samsung K9F1G08U0A MTD driver

[z l]

We have ARM (Cirrus Logic EP93XX) based systems
running Linux 2.6.8.1.  We are trying to add NAND
driver for Samsung K9F1G08U0A chip on the board.  We
are able to have the driver read the MTD and register
the device.  However writing to the chip using
nandwrite seem to write some bytes in the OOB area and
mark the block bad.  Checking with mtd_debug program,
the information returned as following,

mtd.type = NAND FLASH
mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB |
MTD_ECC
mtd.size = 134217728 (128M)
mtd.erasesize = 131072 (128K)
mtd.oobblock = 2048 (2K)
mtd.oobsize = 64 
mtd.ecctype = MTD_ECC_NONE
regions = 0

The mtd.flags shows the MTD_ECC is set but the
mtd.ecctype is set to MTD_ECC_NONE.  We have the
following line in the driver code,

this->eccmode = NAND_ECC_SOFT;

Does this set the mtd.flags or set the mtd.ecctype?

What should be the right setting for the Samsung chip?

Thanks in advance.

ZL

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[Thomas Gleixner]

On Thu, 2006-10-05 at 11:35 -0700, z l wrote:
> We have ARM (Cirrus Logic EP93XX) based systems
> running Linux 2.6.8.1.

You omitted: ", based on Cirrus Logic release 1.0.7."

Do not try to trick me! 

http://www.linux-mtd.infradead.org/source.html#kernelversions

still applies.

Pester Cirrus with problems about their kernel.

Use an up to date kernel from the community and you get community
support.

	tglx

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[z l]

> You omitted: ", based on Cirrus Logic release
> 1.0.7."
> 
> Do not try to trick me! 
> 
Maybe it is an important piece of information, but it
was not intentionally left out.


http://www.linux-mtd.infradead.org/source.html#kernelversions
> 
> still applies.
> 
> Pester Cirrus with problems about their kernel.
> 
> Use an up to date kernel from the community and you
> get community
> support.
> 
We would love to have the latest kernel, but this is
the one we can find that has all the device drivers
working for our board.  If there is a later version
available that has all the drivers we would jump in
without any hesitation.

Now onto our NAND FLASH problems.  The problems seem
not to be the kernel, at least so far we don't think
they are.  We found this post in the mailing list,
http://lists.infradead.org/pipermail/linux-mtd/2006-July/016159.html.
and interesting enough it fixed one of our problems. 
So it was the nandwriite that was doing the bad thing
by writing things where "not suppose to" and made good
blocks into "bad".  After applying the fix, at least
we can write to the NAND without making lots of new
"bad" blocks.  And the JFFS2 copied over is somewhat
working.  Still got lot's of "nand_read_ecc: Failed
ECC read, page 0xXXXXXXXXX" when doing normal file
access.  So we are looking into that to see what is
the cause of this problem.

Any idea what it might be?

Thanks

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[Thomas Gleixner]

On Thu, 2006-10-05 at 15:08 -0700, z l wrote:
> > You omitted: ", based on Cirrus Logic release
> > 1.0.7."
> > 
> > Do not try to trick me! 
> > 
> Maybe it is an important piece of information, but it
> was not intentionally left out.

It _IS_ an important piece of information. Go, read and _UNDERSTAND_
http://www.linux-mtd.infradead.org/source.html#kernelversions

It was in your previous offlist mail to my _BUSINESS_ mail address, when
you tried to get _FREE_ help from me. I pointed you to that URL in my
answer:

> Please use a community supported up to date kernel. See also
> 
> http://www.linux-mtd.infradead.org/source.html#kernelversions
> 
>         tglx
> 

It was not longer there in your mail to the mailing list. And I'm not
believing for a second that it was not intentional.

> > Use an up to date kernel from the community and you
> > get community
> > support.
> > 
> We would love to have the latest kernel, but this is
> the one we can find that has all the device drivers
> working for our board.  If there is a later version
> available that has all the drivers we would jump in
> without any hesitation.

Ah, if the community is ready to please your expectations you are
willing to use a community kernel.

Go and blame Cirrus for their unwillingness to work with the community.

Guess who put support for their CPU's into mainline: community people
without _ANY_ help from Cirrus.

This code was written by people with a trust in the "Do ut des" basics
of Open Source and you sit there and wait until we have done all the
work, so you can have your benefit ?

Should I really take your "unintentional" excuse serious ? No way, you
just disguised yourself.

If the commmunity supported kernel lacks support of device drivers you
are interested in, then you can add it. You are welcome and you will get
all the help we can provide.

If you are more pleased by the Cirrus kernel hackery, use it and seek
help from them.

Open Source is not a self service store without a cashpoint. 

> Now onto our NAND FLASH problems.

I don't care at all.

> Any idea what it might be?

You use code, which I can not look into and I'm not interested to give
witchcraft debugging aid.

	tglx

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[z l]

> It was in your previous offlist mail to my
> _BUSINESS_ mail address, when
> you tried to get _FREE_ help from me. I pointed you
> to that URL in my
> answer:
> 
If I was able to subsribe to the mailing list I would
never write to you directly.  I already explained to
you about it in my e-mail.  My main objective in that
e-mail was to find out how I can subsrible with the
web page not available and my previous attempts of
subsribing by e-mail all failed.

> Ah, if the community is ready to please your
> expectations you are
> willing to use a community kernel.
It has nothing to do with pleasing or not.  Would you
use something that is broken?

> 
> Go and blame Cirrus for their unwillingness to work
> with the community.
Maybe they are not actively involved in the
development of latest kernel, but their code is open
and available for anyone to pick and use.

> Guess who put support for their CPU's into mainline:
> community people
> without _ANY_ help from Cirrus.
I have great respect for people putting their effort
to make this happen.

> This code was written by people with a trust in the
> "Do ut des" basics
> of Open Source and you sit there and wait until we
> have done all the
> work, so you can have your benefit ?
If there is something I can contribute I would love
to. If I know half of what you know about Linux, I
would be here coding day and night.  

> Should I really take your "unintentional" excuse
> serious ? No way, you
> just disguised yourself.
I do not need to disguise anything.

> If the commmunity supported kernel lacks support of
> device drivers you
> are interested in, then you can add it. You are
> welcome and you will get
> all the help we can provide.
Again, if I can of any help, I would.

> You use code, which I can not look into and I'm not
> interested to give
> witchcraft debugging aid.
The Cirrus Logic release is open source.  You can
download it from arm.cirrus.com if you care to take a
look.

zl

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[Nishanth Menon]

z l stated on 10/5/2006 1:35 PM:
> driver for Samsung K9F1G08U0A chip on the board.  We
<snip>
>
> mtd.type = NAND FLASH
> mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB |
> MTD_ECC
> mtd.size = 134217728 (128M)
> mtd.erasesize = 131072 (128K)
> mtd.oobblock = 2048 (2K)
> mtd.oobsize = 64
> mtd.ecctype = MTD_ECC_NONE
> regions = 0
>
z l stated on 10/5/2006 5:08 PM:
<snip>
> http://lists.infradead.org/pipermail/linux-mtd/2006-July/016159.html.
> and interesting enough it fixed one of our problems. 
> So it was the nandwriite that was doing the bad thing
> by writing things where "not suppose to" and made good
> blocks into "bad".  After applying the fix, at least
> we can write to the NAND without making lots of new
I have hardly looked at the nand mtd code, but maybe the data sheet
(http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_LargeBlock/1Gbit/K9F1G08U0A/ds_k9f1g08x0a_rev10.pdf#search=%22K9F1G08U0A%20%20data%20sheet%22)
might help, on the R1 device is 128M, the U device is 256M(so am not too
sure abt ur mtd.size param), on this device, page1,page2 offset 0 had
badblock info, so am not sure if mtd is putting ecc over there..

> "bad" blocks.  And the JFFS2 copied over is somewhat
> working.  Still got lot's of "nand_read_ecc: Failed
> ECC read, page 0xXXXXXXXXX" when doing normal file
> access.  So we are looking into that to see what is
> the cause of this problem.
mebbe u can try this: (dunno if it works): flash_eraseall mtd and mount
and umount the same, let jffs2 maintain the bad blocks - remount should
not show any jffs2 errors.
another issue is possibly that ur host based mkfs.jffs2 might not have
been given the right params..

Just my guesses.. but then.. I can be completely wrong...

Regards,
Nishanth Menon

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[Lennert Buytenhek]

On Thu, Oct 05, 2006 at 04:28:15PM -0700, z l wrote:

> > Ah, if the community is ready to please your expectations you
> > are willing to use a community kernel.
> 
> It has nothing to do with pleasing or not.  Would you
> use something that is broken?

It does.

You are using a car from vendor A because vendor B's cars don't appeal
to you (which is fine), but then you come to a vendor B mechanic and
expect him to fix the problems with your vendor A car, for free.

When the vendor B mechanic tells you that he can only help you with
problems with your vendor B car, and asks you why you aren't driving
a vendor B car, you simply tell him that vendor B cars are broken, and
after that you believe:
- that he is still willing to help you with fixing a competitor's car
  after you've insulted his own employer's cars; and
- that he agrees with you that vendor B cars not appealing to you is a
  perfect reason for expecting vendor B mechanics to fix your vendor A
  car for you for free instead.


> > Go and blame Cirrus for their unwillingness to work with the
> > community.
>
> Maybe they are not actively involved in the
> development of latest kernel, but their code is open
> and available for anyone to pick and use.

That's like insisting that your vendor B garage should help you fix
your vendor A car for free even though you didn't buy it from them,
because "vendor A cars are readily available everywhere and everyone
can figure out how they work, including you."


> > This code was written by people with a trust in the
> > "Do ut des" basics
> > of Open Source and you sit there and wait until we
> > have done all the
> > work, so you can have your benefit ?
> 
> If there is something I can contribute I would love to.

If you want the 2.6 community kernel to improve, tell Cirrus that
their upstream support is crap and put pressure on them to fix it.
They know what they have to do.

If you prefer to use the Cirrus kernel instead, please go to Cirrus
with your bug reports -- that's all we ask.


cheers,
Lennert

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[Thomas Gleixner]

On Thu, 2006-10-05 at 16:28 -0700, z l wrote: 
> If I was able to subsribe to the mailing list I would
> never write to you directly.  I already explained to
> you about it in my e-mail.  My main objective in that
> e-mail was to find out how I can subsrible with the
> web page not available and my previous attempts of
> subsribing by e-mail all failed.

I know that you apologized upfront for writing offlist, and that's the
only reason why I even bothered to answer you, but please go back to
your "Sent" folder and check the mail subject.

It reads: "MTD NAND FLASH & mailing list"

Simply your main concern was your NAND problem and nothing else.

I gave you advise how to subscribe to the mailing list and I gave you
the answer to your NAND question:

> Please use a community supported up to date kernel. See also
> 
> http://www.linux-mtd.infradead.org/source.html#kernelversions
> 
>         tglx

So you were able to subscribe and after you read this URL you go ahead,
omit the information about your vendor kernel intentionally and expect
that I would not notice.

> > Ah, if the community is ready to please your
> > expectations you are
> > willing to use a community kernel.
> It has nothing to do with pleasing or not.  Would you
> use something that is broken?

You start to annoy me.

1. The code in mainline is not broken at all. It works perfectly fine
and you insult really competent developers, who took the task to put it
there. Do you expect that the people, who you insult, will help you in
return for your obnoxiouness ?

2. incomplete != broken. You suffer from severe perceptual disturbance.

3. If it is broken for you, point it out and help to fix it.

4. If you are happy with the Cirrus code, use it and seek the help from
Cirrus. The paragraph about kernel versions on the mtd website makes
this entirely clear and we are not changing the terms for you.

5. Will Microsoft help you with problems you experience when using a
pirated copy of Windows ? The only difference is that Cirrus is allowed
to use our code and make whatever modifications they want, but this
right to copy, modify an redistribute does neither transfer our
responsibility for that code nor the right to abuse us as their unpaid
support team.

> > Go and blame Cirrus for their unwillingness to work
> > with the community.
> Maybe they are not actively involved in the
> development of latest kernel, but their code is open
> and available for anyone to pick and use.

Cirrus has _NEVER_ been involved with the community in any way, except
for unloading the problems with their shit^Hny code to us.

Are you expecting that I'm obliged to figure out what their pretious
"Cirrus Logic release 1.0.7" contains ?

Thats simply not the way it works. I wrote and maintain code which is in
the community codebase. I'm helping users with that code.

You decided to use Cirrus code for whatever reason. Go and get help from
Cirrus or pressure them to work with us.

> > You use code, which I can not look into and I'm not
> > interested to give
> > witchcraft debugging aid.
> The Cirrus Logic release is open source.  You can
> download it from arm.cirrus.com if you care to take a
> look.

I don't care and I'm not going to figure out where this "open source
Cirrus Logic release" is. Even if you give me a real download URL, I'm
not going to look at it. Have you the faintest idea how many of those
vendor kernels are out there ?

I care about the code which is in Linus' tree and the development code
in the mtd repository and I'm helping users to fix problems with said
code.

You have not the foggiest notion how Open Source works, but you think
you have a god given right to get our help.

All you get for your obnoxious behaviour is an entry in my killfile. 

	tglx

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[z l]

I really had no intention of causing any problem and
wasting other people's time.  Please let me explain my
point of view, maybe it's wrong but this is how I see
it.

1. The reason of choosing which version is purely
based on which one had more complete solution for a
particular application.  If I can get mainline version
to work with all the drivers available I would use it.
 However as an average user and just some basic
knowledge about kernel internal I have to choose which
ever one that gives me the least problems.  Here I
apologize for using the wrong word "broken" in my
previous e-mail, incomplete!=broken.
It could well be that the main line is complete and it
was just my incompetence that prevented me from
getting it to work.  Again there is very little
distinction for me wheher the kernel source is from a
commercial company or someone's own edition, I merely
picked one that presented least problem for me.  I had
no idea that it would cause so much trouble.

2. Maybe I did not phrase my question right.  With no
knowledge of how MTD works at all and very limited
understanding of Linux kernel, I just tried to explain
the problem the best way I can and hoping maybe
someone had encountered similar issue and had a
solution for it.  Any help is greatly appreciated. 
Maybe I'm just so used to Alan Stern at
[linux-usb-users].


Best regards, zl

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[z l]

> might help, on the R1 device is 128M, the U device
is 256M(so am not too
> sure abt ur mtd.size param), on this device,
page1,page2 offset 0 had
> badblock info, so am not sure if mtd is putting ecc
over there..
I doubled checked the datasheet, R is 1.8v device, U
is 3.3v.

> mebbe u can try this: (dunno if it works):
flash_eraseall mtd and mount
> and umount the same, let jffs2 maintain the bad
blocks - remount should
> not show any jffs2 errors.
Is it possible to mount a bare MTD device?

> Just my guesses.. but then.. I can be completely
wrong...
Thanks for the help.

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[Nicolas Pitre]

On Fri, 6 Oct 2006, z l wrote:

> 1. The reason of choosing which version is purely
> based on which one had more complete solution for a
> particular application.

You forgot to buy a support contract to go with it.

> If I can get mainline version to work with all the drivers available I 
> would use it.

If you want free support from the community that is your only option.

> However as an average user and just some basic
> knowledge about kernel internal I have to choose which
> ever one that gives me the least problems.

If you choose to go with Cirus kernel version, you have to go to Cirus 
for questions and support.  It is that simple.


Nicolas

Bug in edb7312.c ?

[z l]

Come across this code and it looks it's broken


/*
 *      hardware specific access to control-lines
 *
 *      NAND_NCE: bit 0 -> bit 7
 *      NAND_CLE: bit 1 -> bit 4
 *      NAND_ALE: bit 2 -> bit 5
 */
static void ep7312_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int ctrl)
{
        struct nand_chip *chip = mtd->priv;

        if (ctrl & NAND_CTRL_CHANGE) {
                unsigned char bits;

                bits = (ctrl & (NAND_CLE | NAND_ALE))
<< 3;
                bits = (ctrl & NAND_NCE) << 7;

                clps_writeb((clps_readb(ep7312_pxdr) 
& 0xB0) | 0x10,
                            ep7312_pxdr);
        }
        if (cmd != NAND_CMD_NONE)
                writeb(cmd, chip->IO_ADDR_W);
}

Re: Problem with developing Samsung K9F1G08U0A MTD driver

[nishanth menon]

On 10/6/06, z l <zql@glomationinc.com> wrote:
> > might help, on the R1 device is 128M, the U device
> is 256M(so am not too
> > sure abt ur mtd.size param), on this device,
> page1,page2 offset 0 had
> > badblock info, so am not sure if mtd is putting ecc
> over there..
> I doubled checked the datasheet, R is 1.8v device, U
> is 3.3v.
check page 13 again, table on top, K9K2G08U1A NVB 2008 - 2048 Blocks
(2048*64*2048 = 256M), R1 is 1024blocks.

Regards,
Nishanth Menon