topic Re: About HW_RTC_PERSISTENT1 register on i.MX28 in i.MX Processors

About HW_RTC_PERSISTENT1 register on i.MX28

hongyuplim — Wed, 28 May 2014 23:28:36 GMT

Hello All,

My system is consist of the NAND(K9F1G08U) boot on i.MX28.

I downloaded kernel boot and UBI Filesystem with Mfgtools.

Now I'm testing the NAND boot.

Most of NAND boot work well. But some NAND has a problem.

So I move the problem NAND to another linux platform(mini2440 Board + uboot + linux) then It works.

Here are 2 logs. one is OK log, another is Error log.

1. OK log

======================================================================

HTLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLFLC
hylim 0 _start : HW_RTC_PERSISTENT1_RD = [0x00000000]
.
PowerPrep start initialize power...
...
hylim 0 PowerPrep_ConfigurePowerSource : HW_RTC_PERSISTENT1_RD = [0x00000000]

hylim >> Configured for 5v only power source. Battery powered operation disabled.
..........
hylim 0-2 PowerPrep_ConfigurePowerSource : HW_RTC_PERSISTENT1_RD = [0x00000800]

hylim 1 PowerPrep_ConfigurePowerSource : HW_RTC_PERSISTENT1_RD = [0x00000800]
..LLLCMay 28 201416:16:17
FRAC 0x92925552
memory type is W9751G6JB DDR2
Wait for ddr ready 1power 0x00820710
Frac 0x92925552
start change cpu freq
hbus 0x00000003
cpu 0x00010001
LLLLLLLFLCLLJUncompressing Linux... done, booting the kernel.
Linux version 2.6.35.3-670-g914558e (hylim@hylim-virtual-machine) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1024 PREEMPT Tue May 13 12:08:09 KST 2014
============================================================================

2. Error log

============================================================================

0x80501003
HTLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLFLC
hylim 0 _start : HW_RTC_PERSISTENT1_RD = [0x00000002]
.
PowerPrep start initialize power...
...
hylim 0 PowerPrep_ConfigurePowerSource : HW_RTC_PERSISTENT1_RD = [0x00000002]

hylim >> Configured for 5v only power source. Battery powered operation disabled.
..........
hylim 0-2 PowerPrep_ConfigurePowerSource : HW_RTC_PERSISTENT1_RD = [0x00000802]

hylim 1 PowerPrep_ConfigurePowerSource : HW_RTC_PERSISTENT1_RD = [0x00000802]
..LLLCMay 28 201416:16:17
FRAC 0x92925552
memory type is W9751G6JB DDR2
Wait for ddr ready 1power 0x00820710
Frac 0x92925552
start change cpu freq
hbus 0x00000003
cpu 0x00010001
LLLLLLLFLCL0x8050100b

============================================================================

But both of them are different.

HW_RTC_PERSISTENT1 is

ERROR : 0x00000002

OK : 0x00000000

I read HW_RTC_PERSISTENT1_RD() in pwer_prep.c

============================================================================

pwer_prep.c

int _start( void )
{
int iRtn = SUCCESS;

printf("\r\n hylim 0 _start : HW_RTC_PERSISTENT1_RD = [0x%X]\x0d\x0a",HW_RTC_PERSISTENT1_RD());

#ifndef mx28
HW_DIGCTL_CTRL_SET(BM_DIGCTL_CTRL_USE_SERIAL_JTAG);
#else

#define SSP0_PIN_DRIVE_12mA 0x2

============================================================================

HW_RTC_PERSISTENT1_RD value is used in setup_cmdline_tag() function in /linux_prep/core/setup.c as " adding one to the rootfs partition number".

Could you please let me know about "HW_RTC_PERSISTENT1_RD = [0x00000002]" in details?

How can HW_RTC_PERSISTENT1 register is changed by H/W or S/W?

Thanks,

Hongyup

Re: About HW_RTC_PERSISTENT1 register on i.MX28

hongyuplim — Tue, 03 Jun 2014 00:50:33 GMT

Anybody help me please!

Re: About HW_RTC_PERSISTENT1 register on i.MX28

GraceH — Tue, 03 Jun 2014 02:54:45 GMT

In i.MX28 Reference Manual, you can see.

HW_RTC_PERSISTENT1:0x8005C070:1

ROM_SECONDARY_BOOT—When this bit is set, ROM attempts to boot

from the secondary image if the boot driver supports it. This bit is set by the

ROM boot driver and cleared by the SDK after repair.

In the error log, 0x80501003 means ROM can't successfully load boot image from NAND, so ROM_SECONDARY_BOOT of HW_RTC_PERSISTENT1 is set by ROM and ROM tries to load the secondary image, but also error occurs and error code 0x8050100b returned.

You can try to change the NANDTiming parameters of of Firmware Configuration Block which is set by kobs-ng.

For more information about FCB, reference 12.12.1.13 Firmware Configuration Block Structure and Definitions of i.MX28 Reference Manual

NANDTiming:

8 bytes of data for 8 NAND Timing Parameters from NAND datasheet. The 8 parameters are: data_setup, data_hold, address_setup, dsample_time,

and_timing_state, REA, RLOH, RHOH.

run "./ltib -p kobs-ng -m prep" to get kobs-ng source code.

Grace

Re: About HW_RTC_PERSISTENT1 register on i.MX28

hongyuplim — Tue, 03 Jun 2014 07:51:52 GMT

Hi Grace Si

Thank you very much.

Now I am modifying the below value base on k9f1g08u0d.pdf but it dosen't solve.

// kobs-ng-2.6.35.3-1.1.0/src/mtd.c

const struct mtd_config default_mtd_config = {

.data_setup_time = xx,

.data_hold_time = xx,

.address_setup_time = xx,

.data_sample_time = 6,

}

I don't know what is wrong.

please give me any advices and how can it get the ROM source code iMX28 cpu?

Thanks

Re: About HW_RTC_PERSISTENT1 register on i.MX28

igorpadykov — Tue, 03 Jun 2014 07:58:15 GMT

Hi hongyup,

probably reason of this misbehaviour is

poor soldering of components, for example capacitors.

You can try to change (resolder) processor and check more carefully power

supplies and NAND signals by oscilloscope.

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

Re: About HW_RTC_PERSISTENT1 register on i.MX28

igorpadykov — Wed, 04 Jun 2014 02:09:52 GMT

Hi hongyup,

ROM sources are closed for customers, also they will not help you

because they are much more complicated than this ubifs issue.

I would suggest to use and test NAND with

IMX_OBDS : On-Board Diagnostic Suit for the i.MX28.

and check NAND timings with oscilloscope.

Best regards

chip

Re: About HW_RTC_PERSISTENT1 register on i.MX28

hongyuplim — Wed, 04 Jun 2014 08:17:22 GMT

Hi,

I know someting strange.

I downloaded imx28_ivt_linux.sb using kobs-ng on Mfgtools.

===================================================

<CMD type="push" body="send" file="files/imx28_ivt_linux.sb">Sending firmware</CMD>

<CMD type="push" body="$ kobs-ng init -v $FILE">Flashing firmware</CMD>

===================================================

I am not sure but I realized that kobs-ng write the below data into the NAND.

FCB0 : 0x0 (NAND address)

FCB1 : 0x20000

FCB2 : 0x40000

FCB3 : 0x60000

DBBT0 : 0x80000

DBBT1 : 0xa0000

DBBT2 : 0xc0000

DBBT3 : 0xe0000

Firmware image 0(kernel boot) : 0x100000

Firmware image 1(Copy kernel boot) : 0xa80000

But this NAND has bad block as below

Bad eraseblock 8 at 0x000000100000

Bad eraseblock 42 at 0x000000540000

Bad eraseblock 44 at 0x000000580000

Bad eraseblock 90 at 0x000000b40000

Bad eraseblock 105 at 0x000000d20000

Bad eraseblock 485 at 0x000003ca0000

Kernel boot(imx28_ivt_linux.sb) size is 0x412960.

the NAND Bad blcok is located in the both Firmware image 0(block 8) and Firmware image 1(block 90) area.

I realized if one of the Firmware image (0 or 1) avoids the bad block then It works well (Booting is OK).

I wonder about who handles the Bad block .

I wonder whether the Bad block is handled.

In case , What do I do for avoiding bad block?

Please give me a help.

Thanks,

Hongyup

Re: About HW_RTC_PERSISTENT1 register on i.MX28

GraceH — Wed, 04 Jun 2014 09:28:56 GMT

bad block table is written by kobs-ng also. Please reference "12.12.1.12 Bad Block Handling in the ROM" of reference manual.

12.12.1.12 Bad Block Handling in the ROM

Bad blocks are not an issue for the FCB, because FCB found from a search. The search for

the DBBT works with a similar mechanism. The search starts where the FCB indicates the

DBBT Search Area should be and progresses until efNANDBootSearchLimit times in the

same fashion as the search described in Boot Control Blocks (BCB).

ROM uses DBBT to skip any bad block that falls within firmware data on NAND Flash

device.

If the address of DBBT Search Area in FCB is 0, ROM will rely on factory marked bad

block markers to find out if a block is good or bad. The location of bad block information

is at the first 3 or last 3 pages in every block of the NAND Flash. NAND manufacturers

normally use one byte in the spare area of certain pages within a block to mark a block to

be good or bad. 0xFF means good block, non FF means bad block.

Grace