[oselas] Problem with new nand flash

[Carlos Leyva Guerrero]

Dear Juergen and all,

I am having problems with a new batch of mini2440 boards I have received
from the manufacturer, the chip for NAND in this boards is K9K8G08U0E SCB0.
I am able of writing data to the board (i.e. write the bootloader (busybox)
and our linux image) but, as soon as i start using the board and filling up
the space, more and more problems appear, making the boot time unusable
(>10 mins) due to MTD error messages.

Previously, I have been working with boards with chips SAMSUNG 131
K9K8G08UOB PIB0 and K9K8G08OUOD SCB0 with no problem, same image, same
bootloader.

I have been able to locate a note regarding differences in the chips:
http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf

Are you aware of this situation? Have been it solved in latest OSELAS
releases? If not, could you please give some guidance in the solution of
this issue?

I'm stuck with old kernels because we could say the boards are in
"production stage" so no big changes should be performed in order to avoid
further problems and because in later kernel versions, as far as I
remember, new issues arose as Sound not working.

Please let me know if any one can provide some light.

Best regards,

Carlos Leyva


--

[Juergen Borleis]

Hi Carlos,

On Tuesday 11 November 2014 12:37:59 Carlos Leyva Guerrero wrote:
> I am having problems with a new batch of mini2440 boards I have received
> from the manufacturer, the chip for NAND in this boards is K9K8G08U0E SCB0.
> I am able of writing data to the board (i.e. write the bootloader (busybox)
> and our linux image) but, as soon as i start using the board and filling up
> the space, more and more problems appear, making the boot time unusable
> (>10 mins) due to MTD error messages.
>
> Previously, I have been working with boards with chips SAMSUNG 131
> K9K8G08UOB PIB0 and K9K8G08OUOD SCB0 with no problem, same image, same
> bootloader.
>
> I have been able to locate a note regarding differences in the chips:
> http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf
>
> Are you aware of this situation?

No. My test systems are coming with 128 MiB and 256 MiB NANDs.

> Have been it solved in latest OSELAS releases?

Don't know, due to the lack of hardware.

> If not, could you please give some guidance in the solution of this issue?

Don't know yet. You are still using JFFS2? I didn't find a way to configure it
for a different sub page size yet.

> I'm stuck with old kernels because we could say the boards are in
> "production stage" so no big changes should be performed in order to avoid
> further problems and because in later kernel versions, as far as I
> remember, new issues arose as Sound not working.

Seems not a matter of the kernel. More a matter how you create your flash
image. But maybe also a matter of the kernel, to let it know the requirements
for the NAND memory have changed.

> Please let me know if any one can provide some light.

No system here to test it. Just guessed what could be done.

Regards,
Juergen

--
Pengutronix e.K.                              | Juergen Borleis             |
Industrial Linux Solutions      | http://www.pengutronix.de/ |

[Carlos Leyva Guerrero]

Dear Jurgen,

thanks for the quick reply.

Im using JFFS2. Do you seem a better alternative compatible with OSELAS and
busybox? If this issue could be solved easier with other format we could
study the possibility.

I am not sure if the problem, anyway, is related to the creation of the
image. The differences between both chips are in the Programming time
(tprog) parameter and in the number of Partial Program Cycles NOP. It seems
to me that this parameters should be embeded in the nand driver of both
kernel and busybox, but I have not enough knowledge of the secrets of both
drivers.

Do you remember any ocurrences of this parameters in any of the drivers?

Best regards,

Carlos



On 11 November 2014 14:44, Juergen Borleis <***@pengutronix.de> wrote:

> Hi Carlos,
>
> On Tuesday 11 November 2014 12:37:59 Carlos Leyva Guerrero wrote:
> > I am having problems with a new batch of mini2440 boards I have received
> > from the manufacturer, the chip for NAND in this boards is K9K8G08U0E
> SCB0.
> > I am able of writing data to the board (i.e. write the bootloader
> (busybox)
> > and our linux image) but, as soon as i start using the board and filling
> up
> > the space, more and more problems appear, making the boot time unusable
> > (>10 mins) due to MTD error messages.
> >
> > Previously, I have been working with boards with chips SAMSUNG 131
> > K9K8G08UOB PIB0 and K9K8G08OUOD SCB0 with no problem, same image, same
> > bootloader.
> >
> > I have been able to locate a note regarding differences in the chips:
> >
> http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf
> >
> > Are you aware of this situation?
>
> No. My test systems are coming with 128 MiB and 256 MiB NANDs.
>
> > Have been it solved in latest OSELAS releases?
>
> Don't know, due to the lack of hardware.
>
> > If not, could you please give some guidance in the solution of this
> issue?
>
> Don't know yet. You are still using JFFS2? I didn't find a way to
> configure it
> for a different sub page size yet.
>
> > I'm stuck with old kernels because we could say the boards are in
> > "production stage" so no big changes should be performed in order to
> avoid
> > further problems and because in later kernel versions, as far as I
> > remember, new issues arose as Sound not working.
>
> Seems not a matter of the kernel. More a matter how you create your flash
> image. But maybe also a matter of the kernel, to let it know the
> requirements
> for the NAND memory have changed.
>
> > Please let me know if any one can provide some light.
>
> No system here to test it. Just guessed what could be done.
>
> Regards,
> Juergen
>
> --
> Pengutronix e.K. | Juergen Borleis
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
>

[Carlos Leyva Guerrero]

Dear Juergen,

during this weekend I am going to try some new approaches, nand scrub and
createbbt have not solved anything. I'm going to try to modify nand drivers
for 2440. Meanwhile, I want to check if moving to another FS could be a
solution. I understand that ubifs is also supported in oselas bsp (both
barebox and image creation). Could you provide me some quick advice/guide
for this change?

In addition, I would like to ask you if you can provide me a current kernel
status, regarding device mal-functioning (i.e. sound problems? sync issues?
timers? ....)

Thanks in advance,

Best regards,

Carlos Leyva




--



On 11 November 2014 14:54, Carlos Leyva Guerrero <***@idener.es>
wrote:

> Dear Jurgen,
>
> thanks for the quick reply.
>
> Im using JFFS2. Do you seem a better alternative compatible with OSELAS
> and busybox? If this issue could be solved easier with other format we
> could study the possibility.
>
> I am not sure if the problem, anyway, is related to the creation of the
> image. The differences between both chips are in the Programming time
> (tprog) parameter and in the number of Partial Program Cycles NOP. It seems
> to me that this parameters should be embeded in the nand driver of both
> kernel and busybox, but I have not enough knowledge of the secrets of both
> drivers.
>
> Do you remember any ocurrences of this parameters in any of the drivers?
>
> Best regards,
>
> Carlos
>
>
>
> On 11 November 2014 14:44, Juergen Borleis <***@pengutronix.de> wrote:
>
>> Hi Carlos,
>>
>> On Tuesday 11 November 2014 12:37:59 Carlos Leyva Guerrero wrote:
>> > I am having problems with a new batch of mini2440 boards I have received
>> > from the manufacturer, the chip for NAND in this boards is K9K8G08U0E
>> SCB0.
>> > I am able of writing data to the board (i.e. write the bootloader
>> (busybox)
>> > and our linux image) but, as soon as i start using the board and
>> filling up
>> > the space, more and more problems appear, making the boot time unusable
>> > (>10 mins) due to MTD error messages.
>> >
>> > Previously, I have been working with boards with chips SAMSUNG 131
>> > K9K8G08UOB PIB0 and K9K8G08OUOD SCB0 with no problem, same image, same
>> > bootloader.
>> >
>> > I have been able to locate a note regarding differences in the chips:
>> >
>> http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf
>> >
>> > Are you aware of this situation?
>>
>> No. My test systems are coming with 128 MiB and 256 MiB NANDs.
>>
>> > Have been it solved in latest OSELAS releases?
>>
>> Don't know, due to the lack of hardware.
>>
>> > If not, could you please give some guidance in the solution of this
>> issue?
>>
>> Don't know yet. You are still using JFFS2? I didn't find a way to
>> configure it
>> for a different sub page size yet.
>>
>> > I'm stuck with old kernels because we could say the boards are in
>> > "production stage" so no big changes should be performed in order to
>> avoid
>> > further problems and because in later kernel versions, as far as I
>> > remember, new issues arose as Sound not working.
>>
>> Seems not a matter of the kernel. More a matter how you create your flash
>> image. But maybe also a matter of the kernel, to let it know the
>> requirements
>> for the NAND memory have changed.
>>
>> > Please let me know if any one can provide some light.
>>
>> No system here to test it. Just guessed what could be done.
>>
>> Regards,
>> Juergen
>>
>> --
>> Pengutronix e.K. | Juergen Borleis
>> |
>> Industrial Linux Solutions |
>> http://www.pengutronix.de/ |
>>
>
>

[Oliver Miranda]

Juergen Borleis <***@...> writes:

>
> Hi Carlos,
>
> On Tuesday 11 November 2014 12:37:59 Carlos Leyva Guerrero wrote:
> > I am having problems with a new batch of mini2440 boards I have received
> > from the manufacturer, the chip for NAND in this boards is K9K8G08U0E SCB0.
> > I am able of writing data to the board (i.e. write the bootloader (busybox)
> > and our linux image) but, as soon as i start using the board and filling up
> > the space, more and more problems appear, making the boot time unusable
> > (>10 mins) due to MTD error messages.
> >
> > Previously, I have been working with boards with chips SAMSUNG 131
> > K9K8G08UOB PIB0 and K9K8G08OUOD SCB0 with no problem, same image, same
> > bootloader.
> >
> > I have been able to locate a note regarding differences in the chips:
> > http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf
> >
> > Are you aware of this situation?
>
> No. My test systems are coming with 128 MiB and 256 MiB NANDs.
>
> > Have been it solved in latest OSELAS releases?
>
> Don't know, due to the lack of hardware.
>
> > If not, could you please give some guidance in the solution of this issue?
>
> Don't know yet. You are still using JFFS2? I didn't find a way to
configure it
> for a different sub page size yet.
>
> > I'm stuck with old kernels because we could say the boards are in
> > "production stage" so no big changes should be performed in order to avoid
> > further problems and because in later kernel versions, as far as I
> > remember, new issues arose as Sound not working.
>
> Seems not a matter of the kernel. More a matter how you create your flash
> image. But maybe also a matter of the kernel, to let it know the requirements
> for the NAND memory have changed.
>
> > Please let me know if any one can provide some light.
>
> No system here to test it. Just guessed what could be done.
>
> Regards,
> Juergen
>

Maybe this problem is already solved, but check below the solutions that I
founded.

The problem is that you can only write a page in the K9K8G08U0E memory
once. Check the K9K8G08U0E datasheet, the parameter NOP1 (Number of Partial
Program Cycles) . The old memory, K9K8G08U0B, is NOP4.
When you try to save the enviroment address in the first page of the
first block (this procedure behavior seems to be default in the u-boot
code), this page is corrupted and the board don't boot anymore.

FIRST ACTION - Create a patch to u-boot to set the environment address
hard-coded. Check below a patch that I apply:

->index d9b47f0..e5ffc94 100644
--- a/include/configs/mini2440.h
+++ b/include/configs/mini2440.h
@@ -236,12 +236,21 @@
#define CFG_MAX_FLASH_SECT 512 /* 512 * 4096 sectors, or 32 * 64k blocks
*/
#define CONFIG_FLASH_SHOW_PROGRESS 1

/*
* u-boot environmnet
*/
#ifndef CONFIG_MINI2440_NOR_ENV
#define CFG_ENV_IS_IN_NAND 1
-#define CFG_ENV_OFFSET_OOB 1 // dont define for CFG_ENV_IS_IN_FLASH
+//#define CFG_ENV_OFFSET_OOB 1 /* this version will use fix env offset
*/
+#define CFG_ENV_OFFSET 0x40000
+

[ian c]

Hi All,

I created a rule file to copy the compiled the kernel out of tree driver to rootFS home directory. I able to success copying the file using the command below.
@$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko)

when i run the image and do the insmod test.ko, it returns
"insmod: can't insert 'test.ko': invalid module format"

BUT if i copy the file manually using winscp to the running image, the insmod works perfectly.

Do you think i did wrong on using the install_copy?

Thanks in advance.

-ian



____________________________________________

[Marc Kleine-Budde]

On 11/17/2015 09:04 AM, ian c wrote:
> Hi All,
>
> I created a rule file to copy the compiled the kernel out of tree driver to rootFS home directory. I able to success copying the file using the command below.
> @$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko)
>
> when i run the image and do the insmod test.ko, it returns
> "insmod: can't insert 'test.ko': invalid module format"
>
> BUT if i copy the file manually using winscp to the running image, the insmod works perfectly.
>
> Do you think i did wrong on using the install_copy?

try:

@$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko, k)

instead.

regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: [phone] |
Vertretung West/Dortmund | Fax: [phone]-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |

[ian c]

Thank you Marc. It works!


-ian


----------------------------------------
To: ***@hotmail.com; ***@community.pengutronix.de
From: ***@pengutronix.de
Date: Tue, 17 Nov 2015 09:10:57 +0100
Subject: Re: [oselas] copying kernel out of tree driver using install_copy


On 11/17/2015 09:04 AM, ian c wrote:
> Hi All,
>
> I created a rule file to copy the compiled the kernel out of tree driver to rootFS home directory. I able to success copying the file using the command below.
> @$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko)
>
> when i run the image and do the insmod test.ko, it returns
> "insmod: can't insert 'test.ko': invalid module format"
>
> BUT if i copy the file manually using winscp to the running image, the insmod works perfectly.
>
> Do you think i did wrong on using the install_copy?

try:

@$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko, k)

instead.

regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: [phone] |
Vertretung West/Dortmund | Fax: [phone]-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |


_______________________________________________ oselas mailing list ***@community.pengutronix.de

[ian c]

Hi Marc,

Sorry I forgot to ask you
@$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko, k)
What is k stand for at the end ?

-ian


----------------------------------------
> From: ***@hotmail.com
> To: ***@pengutronix.de; ***@community.pengutronix.de
> Date: Tue, 17 Nov 2015 08:30:59 +0000
> Subject: Re: [oselas] copying kernel out of tree driver using install_copy
>
>
> Thank you Marc. It works!
>
>
> -ian
>
>
> ----------------------------------------
> To: ***@hotmail.com; ***@community.pengutronix.de
> From: ***@pengutronix.de
> Date: Tue, 17 Nov 2015 09:10:57 +0100
> Subject: Re: [oselas] copying kernel out of tree driver using install_copy
>
>
> On 11/17/2015 09:04 AM, ian c wrote:
>> Hi All,
>>
>> I created a rule file to copy the compiled the kernel out of tree driver to rootFS home directory. I able to success copying the file using the command below.
>> @$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko)
>>
>> when i run the image and do the insmod test.ko, it returns
>> "insmod: can't insert 'test.ko': invalid module format"
>>
>> BUT if i copy the file manually using winscp to the running image, the insmod works perfectly.
>>
>> Do you think i did wrong on using the install_copy?
>
> try:
>
> @$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko, k)
>
> instead.
>
> regards,
> Marc
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: [phone] |
> Vertretung West/Dortmund | Fax: [phone]-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
>
> _______________________________________________ oselas mailing list ***@community.pengutronix.de
>
> _______________________________________________
> oselas mailing list
> ***@community.pengutronix.de

____________________________________________

[Marc Kleine-Budde]

On 11/17/2015 10:02 AM, ian c wrote:
>
> Hi Marc,
>
> Sorry I forgot to ask you
> @$(call install_copy, test-modules, 0, 0, 0755, $(TEST_MODULES_DIR)/$(TEST_MODULES)/test.ko, /home/test.ko, k)
> What is k stand for at the end ?

The last parameter sets the stripping of debug symbols. Normal userspace
executables and libs can be stripped more then kernel modules.

y == strip
n == don't strip
k == kernel

Marc

--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: [phone] |
Vertretung West/Dortmund | Fax: [phone]-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |

[Juergen Borleis]

Hi Ian,

On Tuesday 17 November 2015 09:04:12 ian c wrote:
> [...]
> Do you think i did wrong on using the install_copy?

Section 5.2.4 in [1]:

"The <strip> is a complete optional parameter to prevent this macro from the
regular stripping process it does on files. Most of the cases stripping debug
information from files is intended. But some kind of files getting destroyed
when this stripping happens to them. One example is a Linux kernel module. If
it gets stripped, it can’t be loaded into the kernel anymore."

[...]

"partially strip
only strips real debug information from the file when this parameter is 'k'.
Useful to keep Linux kernel module loadable at run-time"

Regards,
Juergen

[1]
http://www.pengutronix.de/software/ptxdist/appnotes/OSELAS.BSP-Pengutronix-Generic-arm-Quickstart.pdf

--
Pengutronix e.K.                              | Juergen Borleis             |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |