Interafcing 8GB Nand in T1042

[debduttabanerje]

Hi,

we have MT29F64G08AFAAAWP 8GB Nand with T1042. This is a dual die device so it is connected via CS0 and CS1.

We had some issue configuring the u-boot to use whole 8GB, so we followed two approach:

Case-1:

Configured the u-boot to use only the 4GB on CS0 and CS1 disabled. Successfully able to read/erase/write 4GB of CS0 nand.

Case-2:

Configured the u-boot to only use 4GB on CS1 and CS0 disabled.

This way I am able to read from the nand flash but erase operation (though it returns success) is unable to set the contents to 0xFF. As a result write operation fails.

But strangely, I am able to read/erase/write on the 4GB of CS1 through lauterbach debugger. So I am starting to believe it is a software issue.

CS1 IFC settings in T104xRDB.h are exactly same as IFC CS0 of Case-1.

To disable CS0, this is set in include/configs/T104xRDB.h

#define CONFIG_SYS_CSPR0 0
#define CONFIG_SYS_CSOR0 0
#define CONFIG_SYS_AMASK0 0
#define CONFIG_SYS_CS0_FTIM0 0
#define CONFIG_SYS_CS0_FTIM1 0
#define CONFIG_SYS_CS0_FTIM2 0
#define CONFIG_SYS_CS0_FTIM3 0

My question:

1. Is my approach wrong?

2. can there be a hardware issue?

Thanks

Debdutta

[debduttabanerje]

Hi,

I have changed my approach and trying to access the whole Nand flash, i.e 8GB.

following were set accordingly:

#ifdef CONFIG_USE_NAND_CS0
#define CONFIG_SYS_NAND_BASE            0xff800000
#define CONFIG_SYS_NAND_BASE_PHYS       (0xf00000000ull | CONFIG_SYS_NAND_BASE)
#endif

#ifdef CONFIG_USE_NAND_CS1
#define CONFIG_SYS_NAND_BASE1           0xff880000
#define CONFIG_SYS_NAND_BASE_PHYS1      (0xf00000000ull | CONFIG_SYS_NAND_BASE1)
#endif

#define CONFIG_SYS_NAND_CSPR_EXT        (0xf)

#ifdef CONFIG_USE_NAND_CS0
#define CONFIG_SYS_NAND_CSPR    (CSPR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \
                                | CSPR_PORT_SIZE_8 /* Port Size = 8 bit */ \
                                | CSPR_MSEL_NAND        /* MSEL = NAND */ \
                                | CSPR_V)
#endif
#ifdef CONFIG_USE_NAND_CS1
#define CONFIG_SYS_NAND_CSPR1   (CSPR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS1) \
                                | CSPR_PORT_SIZE_8 /* Port Size = 8 bit */ \
                                | CSPR_MSEL_NAND        /* MSEL = NAND */ \
                                | CSPR_V)
#endif

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍#define CONFIG_SYS_NAND_AMASK   IFC_AMASK(512*1024)


#if defined(CONFIG_USE_NAND_CS0) && defined(CONFIG_USE_NAND_CS1) 
 #define CONFIG_SYS_NAND_BASE_LIST      { CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE1 }
 #define CONFIG_SYS_MAX_NAND_DEVICE     2 
#endif‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Likewise, all CS0 and CS1 registers are set. TLB abd LAW are also set

In this way, all nand operations end up on Nand die CS1.

On debugging, these lines were found to be the reason (drivers/mtd/nand/fsl_ifc_nand.c

line no 11: cs_nand is overwritten

/* Find which chip select it is connected to.
*/
for (priv->bank = 0; priv->bank < MAX_BANKS; priv->bank++) {
        phys_addr_t phys_addr = virt_to_phys(addr);

        cspr = ifc_in32(&gregs->cspr_cs[priv->bank].cspr);
        csor = ifc_in32(&gregs->csor_cs[priv->bank].csor);

        if ((cspr & CSPR_V) && (cspr & CSPR_MSEL) == CSPR_MSEL_NAND &&
                (cspr & CSPR_BA) == CSPR_PHYS_ADDR(phys_addr)) {
                 ifc_ctrl->cs_nand = priv->bank << IFC_NAND_CSEL_SHIFT;
                 break;
        }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

And, this:

/* set the chip select for NAND Transaction */
ifc_out32(&ifc->ifc_nand.nand_csel, ifc_ctrl->cs_nand);
‍‍

So last written value of ifc_ctrl->cs_nand is used hence all operations are performed on CS1

this behaviour was proved in u-boot also:

// read NAND_CSEL
=> md.l 0xfe12515c 1
fe12515c: 04000000 ....   // CS1
=> mw.l 0xfe12515c 0x0    // select CS0 manually
=> md.l 0xfe12515c 1 
fe12515c: 00000000 ....

=> nand device
Device 0: nand0, sector size 1024 KiB
Page size 8192 b
OOB size 448 b
Erase size 1048576 b
subpagesize 8192 b
options 0x40000200
bbt options 0x 20000

=> nand dump 0x0
fsl_ifc_run_command:300 IFC_NAND_CSEL=0x4000000 //dbg print:CSEL overwritten fsl_ifc_nand.c
Page 00000000 dump:
aa 55 aa 55 01 0e 01 00 0c 10 00 0e 0e 00 00 00
00 00 00 00 00 00 00 00 85 00 00 00 00 40 00 12
ec 11 00 00 21 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 03 90 00 00 00 00 00 d4 16 aa 05
00 00 00 00 00 00 00 00 09 25 01 00 00 00 04 00
09 25 01 08 00 00 20 00 09 00 00 10 00 00 00 0b
09 00 00 14 c0 00 00 00 09 00 00 18 81 d0 00 17
89 02 04 00 a1 00 00 00 09 13 80 c0 00 0f 00 00
89 02 04 00 00 00 00 00 09 01 00 00 00 20 04 00
09 13 80 00 00 00 00 00 09 13 80 c0 00 00 01 00

=> <INTERRUPT>
=> md.l 0xfe12515c 1
fe12515c: 04000000 ....
=> ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

To verify I commented this:

ifc_out32(&ifc->ifc_nand.nand_csel, ifc_ctrl->cs_nand);‍

and set chip select manually in u-boot by writing NAND_CSEL, now able to access both die i.e CS0 and CS1

I think this is a serious flaw in the ifc nand driver. 

Please comment.

[vladimir_oltean · Accepted solution]

Hi Debdutta,

Thank you for the thorough debugging, and sorry to hear this has consumed so much of your time.

I discussed with Fedor, and the dual-die issue in fsl_ifc_nand.c has been solved in mainline U-Boot by Kurt Kanzenbach through this patch:

mtd: nand: fsl-ifc: fix support of multiple NAND devices (99145c48) · Commits · U-Boot / U-Boot · Gi... 

Since there are no further maintenance releases planned for SDK 2.0, my recommendation is to backport this upstream patch to your tree.

Regards,

-Vladimir

[debduttabanerje]

Hi Vladimir,

after enbaling both chip selects in kernel through device tree, I am able to access them.

UBI0 is corresponding to Nand chip-0

and UBI1 is corresponding to Nand chip-1

However, the board gets stuck in reboot/halt, here is the output from console:

Broadcast message from root@hopk (ttyS0) (Sun Jan 21 02:18:38 2018):

The system is going down for reboot NOW!
INISwitching to runlevel: 6
INIT: Sending processes the TERM signal
INIT:Stopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid 1305)
.
Stopping network benchmark server: netserverstopped /usr/sbin/netserver (pid 1312)
.
Stopping system log daemon...0
Stopping kernel log daemon...0
Stopping internet superserver: xinetd.
Deconfiguring network interfaces... done.
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting remote filesystems...
Deactivating swap...
Unmounting local filesystems...
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
UBIFS (ubi1:0): un-mount UBI device 1
UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Rebooting... INFO: task reboot:1484 blocked for more than 120 seconds.
      Tainted: G           O    4.1.8-rt8 #6
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
reboot          D 0ff4d69c     0  1484   1483 0x00000000
Call Trace:
[e6473d20] [c06bf280] __schedule+0x1f0/0x4b0
[e6473d50] [c06bf580] schedule+0x40/0xf0
[e6473d60] [c03a3518] nand_get_device+0xa8/0x160
[e6473db0] [c0389150] mtd_reboot_notifier+0x20/0x40
[e6473dc0] [c004af90] notifier_call_chain+0x60/0xb0
[e6473de0] [c004b370] __blocking_notifier_call_chain+0x50/0x80
[e6473e00] [c004c790] kernel_restart_prepare+0x20/0x50
[e6473e10] [c004c898] kernel_restart+0x18/0x90
[e6473e20] [c004cbdc] SyS_reboot+0xfc/0x220
[e6473f40] [c000f130] ret_from_syscall+0x0/0x3c
--- interrupt: c01 at 0xff4d69c
    LR = 0x10000c68
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

On debugging, I found that device-0 is set to state FL_SHUTDOWN in nand_get_device(),

But, device-1 is stuck in schedule().

Are there any kernel patch as well for multiple nand chip?

[vladimir_oltean]

Hi Debdutta,

It is difficult to assess how the deadlock occurs, and whether it has been resolved in mainline.

I can suggest the following:

- For your SDK 2.0-1703 kernel, enable CONFIG_DEBUG_LOCKDEP, CONFIG_DEBUG_RT_MUTEXES, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_LOCK_ALLOC, CONFIG_PROVE_LOCKING, CONFIG_DEBUG_ATOMIC_SLEEP. Then run your shutdown test again. Hopefully, you should get a kernel splat which shows exactly how the task hangs.

- It looks like you have CONFIG_DETECT_HUNG_TASK enabled, otherwise the kernel wouldn't have detected the hung task otherwise. As a workaround, you can also reduce CONFIG_DEFAULT_HUNG_TASK_TIMEOUT to a small value (5 seconds) and enable CONFIG_BOOTPARAM_HUNG_TASK_PANIC. The kernel will panic and reboot, which is ok, since you want to reboot anyway.

- There _has_ been a fix for multi-chip locking, but your kernel tree does have that patch already, so it's not your problem: mtd: nand: fix multi-chip suspend problem · torvalds/linux@6b0d9a8 · GitHub . Actually I think it is a problem with the NAND core and not with the fsl ifc driver.

- The NAND maintainers in Linux don't seem to be very strict in marking bugs when they fix them. So it seems possible that a fix was provided as part of a patch, without being marked as such. My suspicion is that the commit mtd: rawnand: Simplify the locking · torvalds/linux@013e629 · GitHub  may solve this problem. But you'll need to apply it manually to your 4.1 kernel, since there has been some moving around of files in the meantime (see mtd: nand: move raw NAND related code to the raw/ subdir · torvalds/linux@93db446 · GitHub ).

Hope this helps,

-Vladimir

[debduttabanerje]

Thank you so much...

Following your first strategy i.e Lock debugging enabled.

I am still trying to figure out, but here is the dump in case you wanted to have a look.

Stopping internet superserver: xinetd.
Deconfiguring network interfaces... done.
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting remote filesystems...
Deactivating swap...
Unmounting local filesystems...
[ 1185.816094] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
Rebooting... 
[ 1189.939864] BUG: sleeping function called from invalid context at /home/debdutta/workspace/GPON/kernel/hopk/linux-4.1.8-rt8/kernel/locking/mutex.c:616
[ 1189.953354] in_atomic(): 1, irqs_disabled(): 0, pid: 1504, name: reboot
[ 1189.959978] INFO: lockdep is turned off.
[ 1189.963906] CPU: 2 PID: 1504 Comm: reboot Tainted: G        W       4.1.8-rt8 #15
[ 1189.971398] Call Trace:
[ 1189.973847] [e8ab1ce0] [c075fcd8] dump_stack+0x84/0xbc (unreliable)
[ 1189.980137] [e8ab1cf0] [c0759634] mutex_lock_nested+0x34/0x450
[ 1189.985989] [e8ab1d40] [c00cee3c] perf_event_exit_cpu+0xbc/0x150
[ 1189.992009] [e8ab1d90] [c00cef04] perf_reboot+0x34/0x70
[ 1189.997248] [e8ab1db0] [c0053584] notifier_call_chain+0x74/0xd0
[ 1190.003181] [e8ab1de0] [c00538e0] __blocking_notifier_call_chain+0x50/0x80
[ 1190.010077] [e8ab1e00] [c0054ec0] kernel_restart_prepare+0x20/0x50
[ 1190.016270] [e8ab1e10] [c0054fc8] kernel_restart+0x18/0x90
[ 1190.021769] [e8ab1e20] [c005530c] SyS_reboot+0xfc/0x220
[ 1190.027010] [e8ab1f40] [c000fbf0] ret_from_syscall+0x0/0x3c
[ 1190.032596] --- interrupt: c01 at 0xff4d69c
[ 1190.032596]     LR = 0x10000c68
[ 1190.040028] BUG: scheduling while atomic: reboot/1504/0x00000002
[ 1190.046040] INFO: lockdep is turned off.
[ 1190.049958] Modules linked in:
[ 1190.053023] CPU: 2 PID: 1504 Comm: reboot Tainted: G        W       4.1.8-rt8 #15
[ 1190.060512] Call Trace:
[ 1190.062965] [e8ab1d20] [c075fcd8] dump_stack+0x84/0xbc (unreliable)
[ 1190.069252] [e8ab1d30] [c005829c] __schedule_bug+0x5c/0x90
[ 1190.074751] [e8ab1d40] [c0756ff4] __schedule+0x554/0x610
[ 1190.080074] [e8ab1d70] [c07570f0] schedule+0x40/0xf0
[ 1190.085052] [e8ab1d80] [c03b7c88] __pm_runtime_barrier+0x88/0x130
[ 1190.091159] [e8ab1dc0] [c03b8f1c] pm_runtime_barrier+0x5c/0xd0
[ 1190.097003] [e8ab1de0] [c03aac80] device_shutdown+0xd0/0x250
[ 1190.102675] [e8ab1e10] [c0054fc8] kernel_restart+0x18/0x90
[ 1190.108172] [e8ab1e20] [c005530c] SyS_reboot+0xfc/0x220
[ 1190.113409] [e8ab1f40] [c000fbf0] ret_from_syscall+0x0/0x3c
[ 1190.118992] --- interrupt: c01 at 0xff4d69c
[ 1190.118992]     LR = 0x10000c68
[ 1190.127174] BUG: scheduling while atomic: reboot/1504/0x00000002
[ 1190.133195] INFO: lockdep is turned off.
[ 1190.137120] Modules linked in:
[ 1190.140183] CPU: 1 PID: 1504 Comm: reboot Tainted: G        W       4.1.8-rt8 #15
[ 1190.147674] Call Trace:
[ 1190.150127] [e8ab1d20] [c075fcd8] dump_stack+0x84/0xbc (unreliable)
[ 1190.156413] [e8ab1d30] [c005829c] __schedule_bug+0x5c/0x90
[ 1190.161909] [e8ab1d40] [c0756ff4] __schedule+0x554/0x610
[ 1190.167231] [e8ab1d70] [c07570f0] schedule+0x40/0xf0
[ 1190.172207] [e8ab1d80] [c03b7c88] __pm_runtime_barrier+0x88/0x130
[ 1190.178312] [e8ab1dc0] [c03b8f1c] pm_runtime_barrier+0x5c/0xd0
[ 1190.184155] [e8ab1de0] [c03aac80] device_shutdown+0xd0/0x250
[ 1190.189825] [e8ab1e10] [c0054fc8] kernel_restart+0x18/0x90
[ 1190.195320] [e8ab1e20] [c005530c] SyS_reboot+0xfc/0x220
[ 1190.200555] [e8ab1f40] [c000fbf0] ret_from_syscall+0x0/0x3c
[ 1190.206144] --- interrupt: c01 at 0xff4d69c
[ 1190.206144]     LR = 0x10000c68
[ 1190.214625] BUG: scheduling while atomic: reboot/1504/0x00000002
[ 1190.220649] INFO: lockdep is turned off.
[ 1190.224575] Modules linked in:
[ 1190.227638] CPU: 3 PID: 1504 Comm: reboot Tainted: G        W       4.1.8-rt8 #15
[ 1190.235128] Call Trace:
[ 1190.237575] [e8ab1d10] [c075fcd8] dump_stack+0x84/0xbc (unreliable)
[ 1190.243861] [e8ab1d20] [c005829c] __schedule_bug+0x5c/0x90
[ 1190.249358] [e8ab1d30] [c0756ff4] __schedule+0x554/0x610
[ 1190.254680] [e8ab1d60] [c07570f0] schedule+0x40/0xf0
[ 1190.259656] [e8ab1d70] [c00c2644] wait_for_stop_done+0x54/0xc0
[ 1190.265499] [e8ab1d90] [c00c2e30] stop_one_cpu+0x50/0x80
[ 1190.270823] [e8ab1dd0] [c00608b0] set_cpus_allowed_ptr+0x1d0/0x1e0
[ 1190.277015] [e8ab1e10] [c0054fcc] kernel_restart+0x1c/0x90
[ 1190.282510] [e8ab1e20] [c005530c] SyS_reboot+0xfc/0x220
[ 1190.287747] [e8ab1f40] [c000fbf0] ret_from_syscall+0x0/0x3c
[ 1190.293328] --- interrupt: c01 at 0xff4d69c
[ 1190.293328]     LR = 0x10000c68
[ 1190.300673] reboot: Restarting system
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I had one more query, currently I am mounting the Nand chip select 0 and chip select 1 and  on two different partitions configured in device tree:

ifc: localbus@ffe124000 {
  reg = <0xf 0xfe124000 0 0x2000>;

  /* NAND Flash on board */
  ranges = <0 0 0xf 0xff800000 0x00010000
            1 0 0xf 0xff810000 0x00010000>;

  nand@0,0 {
   #address-cells = <1>;
   #size-cells = <1>;
   compatible = "fsl,ifc-nand";
   reg = <0x0 0x0 0x10000>;

   nand-rootfs@40000000 {
    reg = <0x40000000 0xc0000000>; // 3GB 
    label = "nand-rootfs";
   };
  };

  nand@1,0 {
                     #address-cells = <0x1>;
                     #size-cells = <0x1>;
                     compatible = "fsl,ifc-nand";
                     reg = <0x1 0x0 0x10000>;

                     nand-extra@0 {
                         reg = <0x0 0x00000000 0x1 0x00000000>; // 4GB 
                         label = "nand-extra";
                     }; 
               };‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Is it possible to combine some portion of NAnd CS0 and CS1 into One single partiton. Like we do for two NOR flash.

If possible can you share some example.

Thanks

Debdutta

[vladimir_oltean]

Sorry for responding so late, I've been caught up with debugging other issues
and didn't have time to look into the reboot hang issue on kernel 4.1 any
further.
Initially I had thought that UBI allows attaching multiple MTD devices to the
same UBI device. Such as:
# ubiattach -d 0 -p /dev/mtd1
# ubiattach -d 0 -p /dev/mtd2
However, after trying it out, it is obvious that this is not the case.
So because the higher layers cannot merge multiple physical devices into one
logical device, the strategy should be in the reverse direction: make the lower
layers hide the fact that this flash responds to 2 different chip selects, and
present both dies as a single MTD device.

Actually it seems that doing this to multi-die NAND flashes that behave as
individual devices _is_ supported by the Linux MTD core, but not by the
fsl_ifc_nand.c driver. See for example the prototype of the nand_scan function:

/**
 * nand_scan_with_ids - [NAND Interface] Scan for the NAND device
 * @chip: NAND chip object
 * @maxchips: number of chips to scan for.
 * @ids: optional flash IDs table
 *
 * This fills out all the uninitialized function pointers with the defaults.
 * The flash ID is read and the mtd/chip structures are filled with the
 * appropriate values.
 */
int nand_scan_with_ids(struct nand_chip *chip, unsigned int maxchips,
               struct nand_flash_dev *ids)

The number of chip select signals to scan for (@maxchips) is passed as an
argument, and most drivers pass 1. So it would be more correct to extend this
value, in order to allow the MTD core to treat both dies as a unified flash. I
_think_ this is how this should work, this piece of documentation seems to
confirm my thoughts:

  Advanced board driver functions
  ===============================

  This chapter describes the advanced functionality of the NAND driver.
  For a list of functions which can be overridden by the board driver see
  the documentation of the nand_chip structure.

  Multiple chip control
  ---------------------

  The nand driver can control chip arrays. Therefore the board driver must
  provide an own select_chip function. This function must (de)select the
  requested chip. The function pointer in the nand_chip structure must be
  set before calling nand_scan(). The maxchip parameter of nand_scan()
  defines the maximum number of chips to scan for. Make sure that the
  select_chip function can handle the requested number of chips.

  The nand driver concatenates the chips to one virtual chip and provides
  this virtual chip to the MTD layer.

  *Note: The driver can only handle linear chip arrays of equally sized
  chips. There is no support for parallel arrays which extend the
  buswidth.*

https://www.kernel.org/doc/Documentation/driver-api/mtdnand.rst

Although please be aware that in mainline, the select_chip operation (with only
a dummy fsl_ifc_select_chip provided in fsl_ifc_nand.c) is already part of the
legacy driver operations. In the new set of operations, the position of the
targeted die is identified by a struct nand_pos, with a more complex
identification based on die index, LUN, plane, erase block and page:

https://elixir.bootlin.com/linux/latest/source/include/linux/mtd/nand.h#L75
https://elixir.bootlin.com/linux/latest/source/include/linux/mtd/nand.h#L154

I didn't try out anything that I've suggested thus far, since I don't seem to
have access to any board with multi-die NAND flashes that act as independent
devices.

I think if you make any enhancement to fsl_ifc_nand.c you should do it to the
mainline version first.

Hope this helps,
-Vladimir

[debduttabanerje]

Many thanks

[ufedor]

Please provide the NAND Flash connection schematics for inspection.

[debduttabanerje]

attached the schematic

[ufedor]

It is required to debug U-Boot code to check how RBn signals are handled.

Described issue could be caused by non-processed IFC_RB1.

[debduttabanerje]

Hi,

But T1040 reference board already have Nand on CS1, so IFC_RB1 must be handled in u-boot.

And as I said we haven't changed ifc or nand driver in u-boot.

attaching relevant sec of T1040RDB user guide

[ufedor]

I agree that this is additional point to debug U-Boot behaviour on your board.

[debduttabanerje]

Hello,

In the u-boot, the RB signal is handled through  ifc_nand_fir_opcodes. I didn't go into full details of driver: fsl_ifc_nand.c,

but there seems to be no evidence that IFC_RB1 is not processed.

[debduttabanerje]

OK..but we are using uboot from sdk 2.0 by nxp. 

Of course we have made some changes for our platform but haven't touched ifc driver.

anyway will try to debug.

Thanks