mxc_nand.c driver in uBoot

[Michael_McTerna]

Hi,

I'm trying to get uBoot working from NAND on an i.MX53 (actually a Karo TX53 module).  I've got it starting up okay and the FEC works, but I'm finding a few problems with the NAND driver.

Specifically while uBoot thinks it can read and write okay, when booting Linux the JFFS system reports lots and lots of CRC errors and fails to mount.  JFFS is fine when if I use RedBoot to write the flash.

So I'm not entirely sure if the uBoot mxc_nand.c supports this NAND device (Samsung K9F1G08U0A, 128MB, 2k pages).  Specifically I notice in the uBoot mxc_nand driver that it doesn't appear to have the ECC layouts used by the Linux Kernel version of this same driver (struct nand_ecclayout nandv2_hw_eccoob_largepage is missing for example).  Also the driver has the following unhelpful code which appears to make the BBT non-standard such that RedBoot and Linux don't see it and vice versa:

/* keep compatible for bbt table with old soc */
#ifdef CONFIG_MX53
    bbt_mirror_descr.offs = BAD_BLK_MARKER_OOB_OFFS + 2;
    bbt_main_descr.offs = BAD_BLK_MARKER_OOB_OFFS + 2;
    bbt_mirror_descr.veroffs = bbt_mirror_descr.offs + 4;
    bbt_main_descr.veroffs = bbt_main_descr.offs + 4;
#endif

This is with uBoot taken from Freescale's L2.6.35_11.09.01_ER BSP fwhich itself looks to be pretty old.  However, the mainline uboot imx git tree (git://www.denx.de/git/u-boot-imx.git), while much much neater, appears to have an older drivers for the mxc_nand controller.

I was wondering if anyone else has had success with NAND access from uboot on an i.MX53, and which flash device and software version they used?

Regards,

Mike

[Michael_McTerna]

Rooney said:

    Sometimes it takes up to 10 minutes till I get the loader flashed!!! My current setup is not ideal at the moment. As the Advanced Toolkit v1.71 from Freescale is not working on Window 7, I'm using a VM with Win XP... Don't blame me using Windows when developing Linux applications ;-)

    The flash tool provided by Karo for linux does not support TX53, so I have to use Windows to flash at least u-boot.

I asked their support (actually the UK reseller DirectInsight) about that and they helpfully got me a version of flash_program that does work.  I think this went into their BSP update, although for my part I have to use the following command:

./flash_program -P mx53 -U -m tx53-v3-meminit.txt -i

The meminit file is somewhere in the recent BSPs too, but in a different directory to where you'd expect.  This works okay via USB, but sometimes fails or crashes, although that maybe because ./flash_program is built for Debian with a slightly different libusb to on my Fedora machine.

    Did you already run the kernel successfully, loaded by u-boot? Which kernel do you use?

Yep.  I took the kernel from the Karo BSP.  This is already patched, but was missing the tx53_defconfig file for some reason.  They do include a patch of their changes (which has already been applied to the sources) which does have the defconfigs in it, so I grabbed that and built, then modified the config from there (e.g. adding Thumb binary support & removing some device drivers).

    I just compiled 2.6.39.4 using the patch from Karo, but I'm pretty sure that there must be adopted something to work correctly.

    The following is listed during boot:

    Creating 6 MTD partitions on "mxc_nand":
    0x000000000000-0x000000040000 : "RedBoot"
    0x000000040000-0x000004080000 : "wince"
    0x000004080000-0x000007080000 : "pstorage"
    0x000007080000-0x000007f60000 : "unallocated"
    0x000007f60000-0x000007f7f000 : "FIS directory"
    0x000007f7f000-0x000007f80000 : "RedBoot config"

    RedBoot message, during U-Boot? That is really strange :-) I will have to take a closer look on that by searching through the code.

Disable RedBoot cmdline partition parsing and add in the mtd cmdline parsing.  Then you should get the partition scheme as defined in uBoot, which makes thing easier (see drivers/mtd/cmdlinepart.c).

[Rooney]

Just a short update...

The Karo Toolchain is now running on my system (tested on Ubuntu 10.04), had to install the following packages. They were not mentioned in the README file of the toolchain, but somewhere in a PDF for the VM that is provided by Karo.

But the binfmt-464c error still exists. Shouldn't be the filesystem "nearly" independent of the used kernel? Why does it work with i.MX53 QSB and not with TX53?

autoconf
autoconf-archive
automake
autotools-dev
bison
bzip2
fakeroot
flex
gawk
gettext
gperf
libc6-dev
libgmp3-dev
libmpfr-dev
libncurses-dev
libstdc++6-4.4-dev
libtool
linux-libc-dev
lynx
make
mtd-utils
pkg-config
tcl-dev
texi2html
tk-dev

[Rooney]

Hello Mike!

I know, it's a little bit off-topic, but which kernel are you using for the TX53?

Which patch do you use to patch the mainline kernel? 2.6.39-rc6 or 3.0.0 provided by Karo?

How do you build the root filesystem? Debootstrap? BusyBox?

I tried to install the tool-chain provided by karo (on Starterkit CD), but it fails on Debian Squeeze 6.0.3 and Ubuntu 10.04 complaining something like this:

...
mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed (bad class -- [], [^] or [)/[^
mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ]
...
mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed (bad class -- [], [^] or [)/[^
mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ]
...
/usr/bin/install: cannot stat `/var/tmp/build-toolchain-4.4.1-armv7a-soft/arm-cortexa8-linux-gnueabi/bootstrap-eglibc/gnu/lib-names.h': No such file or directory
make[1]: *** [/usr/local/arm/cross-gcc-4.4.1-armv7a-soft/i686-pc-linux-gnu/arm-cortexa8-linux-gnueabi/sys-root/usr/include/gnu/lib-names.h] Error 1
make[1]: Leaving directory `/home/spiderman/starterkit/tool-chain/cross-eglibc/libc'
make: *** [install-headers] Error 2
...

I'm not sure if my system is the problem or the stuff provided by Karo is not that mature as it should.

So I tried to use the gcc-4.3-arm-linux-gnueabi compiler, installed via apt-get. Compiling the patched kernel 2.6.39-rc6 succeeds, but if I use NFS for my root filesystem it fails with request_module: runaway loop modprobe binfmt-464c (see my last post).

The filesystem has been created as follows using debootstrap:
sudo debootstrap --arch armel --include="lynx,nano,wget,udev" --foreign lucid rootfs

The filesystem is definitely correct, because it works if using the i.MX53 QSB. Can the error be caused due to different kernel versions? I use 2.6.35 on the i.MX53 QSB and 2.6.39-rc6 on the TX53.

I googled several hours to find a solution for the binfmt-464c error, but couldn't find any usefull information. It is stated at several sources, that there is a problem between 32 bit guest and 64 bit host, but my host is 32 bit and target as well. This seems very strange!!

Do you have any ideas?


Thanks a lot for your help!!!!

[Rooney]

Sometimes it takes up to 10 minutes till I get the loader flashed!!! My current setup is not ideal at the moment. As the Advanced Toolkit v1.71 from Freescale is not working on Window 7, I'm using a VM with Win XP... Don't blame me using Windows when developing Linux applications ;-)

The flash tool provided by Karo for linux does not support TX53, so I have to use Windows to flash at least u-boot.

Did you already run the kernel successfully, loaded by u-boot? Which kernel do you use?

I just compiled 2.6.39.4 using the patch from Karo, but I'm pretty sure that there must be adopted something to work correctly.

The following is listed during boot:

Creating 6 MTD partitions on "mxc_nand":
0x000000000000-0x000000040000 : "RedBoot"
0x000000040000-0x000004080000 : "wince"
0x000004080000-0x000007080000 : "pstorage"
0x000007080000-0x000007f60000 : "unallocated"
0x000007f60000-0x000007f7f000 : "FIS directory"
0x000007f7f000-0x000007f80000 : "RedBoot config"

RedBoot message, during U-Boot? That is really strange :-) I will have to take a closer look on that by searching through the code.

However, currently I get a panic when using NFS:

VFS: Mounted root (nfs filesystem) on device 0:13.
devtmpfs: mounted
Freeing init memory: 168K
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
INFO: task swapper:1 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
swapper         D c02fff10     0     1      0 0x00000000
Kernel panic - not syncing: hung_task: blocked tasks
[<c003c5e4>] (unwind_backtrace+0x0/0xfc) from [<c02ff7a4>] (panic+0x5c/0x18c)
[<c02ff7a4>] (panic+0x5c/0x18c) from [<c0080c8c>] (check_hung_task+0x94/0xa4)
[<c0080c8c>] (check_hung_task+0x94/0xa4) from [<c0080ea4>] (check_hung_uninterruptible_tasks+0x10c/0x138)
[<c0080ea4>] (check_hung_uninterruptible_tasks+0x10c/0x138) from [<c0080f18>] (watchdog+0x48/0x50)
[<c0080f18>] (watchdog+0x48/0x50) from [<c0062fc4>] (kthread+0x84/0x8c)
[<c0062fc4>] (kthread+0x84/0x8c) from [<c00389cc>] (kernel_thread_exit+0x0/0x8)

[Michael_McTerna]

I find the USB bootstrap unreliable too.  In my case I think it's just the loader app being flaky as it fails sometimes on every device.

Anyway, when booting I get the following:

Boot Device: NAND
DRAM:  512 MB
NAND:  Manufacturer      : Samsung (0xec)
Device Code       : 0xf1
Cell Technology   : SLC
Chip Size         : 128 MiB
Pages per Block   : 64
Page Geometry     : 2048+64
ECC Strength      : 4 bits
ECC Size          : 512 B
Data Setup Time   : 15 ns
Data Hold Time    : 12 ns
Address Setup Time: 20 ns
GPMI Sample Delay : 6 ns
tREA              : Unknown
tRLOH             : Unknown
tRHOH             : Unknown
Description       : K9F1F08
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000000880000

It's worth double checking you have the same flash device and values.

Also worth checking the block holding the environment isn't bad, or marked bad.  I think it would print something if that were the case when writing the env though.  For me it looks like this:

U-Boot > saveenv
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x80000 -- 100% complete.
Writing to Nand... done
U-Boot >

[Rooney]

Tried that already, but still the same error.

But maybe there is a problem with my board. Flashing the u-boot via the build-in USB bootstrap loader of the processor fails very very often.

[Michael_McTerna]

Rooney said:

There are still some open issues I'm facing when using u-boot:

# Error "bad block table found at page..."

# Warning "bad CRC, using default environment"

Use the "saveenv" command in uBoot to write the environment to Flash.  Then you won't get this message.

[Rooney]

Hello Peter!

I didn't changed anything to the patch file of Mike.

The CONFIG_FLASH_HEADER_OFFSET is defined as follows in configs/tx53.h:

#define CONFIG_FLASH_HEADER_OFFSET 0x400

There are still some open issues I'm facing when using u-boot:

# Error "bad block table found at page..."

# Warning "bad CRC, using default environment"

I will do further investigation on that. If there a news, I post them here.

Regards,

Rooney

[PeterThoeming]

Rooney,

May I ask?

In your final uboot board header file, what was the value of this define?

CONFIG_FLASH_HEADER_OFFSET

Thanks,

Pete

[Rooney]

You are so great!!!!!

Thanks for that really helpful information.

I compared the TX53-1x31.ecc and TX53-8x30.ecc file from RedBoot (version 2012-01-02) and they are identical, so I did not further adoption to tx53.h except the environments (TFTP/NFS boot) and the defines you mentioned.

First compiling U-Boot fails with the error: "no rule to make target..."

So I had to add the following lines to the Makefile located in the top directory of U-Boot:

tx53_config :unconfig
    $(MKCONFIG) $(@:_config=) arm arm_cortexa8 tx53 karo mx53

Flashed the bootloader into the NAND and rebooted... U-Boot started successfully and loaded the kernel. Currently the kernel is for the MX53 QSB board, so loading stops somewhere during initialisation. I need to recompile für the TX53 and I'm expecting that it works!!!

Regards,

Rooney

[Michael_McTerna]

Hmm, that's still seems to be lots of work...

I think you have a good head start in the patch I've supplied.  It's probably a day's work or so.

How could you do the porting without a schematic? Just looking to the sources? I tried to get one from Karo, but no chance!!

Ha - yes, we've asked about schematics before, but no luck which seems odd given that Karo probably just based their design on a Freescale reference.

Anyway, the RedBoot sources have everything you need in them, and the linux board file have some of the pin configurations, though these will be the same across the TX53 module I think.  Specifically though I didn't actually reverse engineer the RedBoot code - I took the flash header in one chunk and made sure it was identical.  This header sets up the essential peripheral pins, clocks and timings, so you don't have to do much after that.

Must the binary for the NAND flash have a defined format or header to work correctly?

To boot from NAND, yes.  The format is given in the i.MX53 Reference Manual.  Again though, I took flash_header.S from the RedBoot sources and patched it into uBoot, replacing the flash header provided by Freescale for their boards.  If you compare flash_header.S from my patch to the similar file packages/hal/arm/mx53/karo/current/include/hal_platform_setup.h you'll see what I mean.

# U-Boot is executed from NAND or DDR? In other words, is u-boot copied from NAND to DDR and then executed from DDR?

DDR.  It is copied from NAND into the DDR by the i.MX53 ROM boot loader which uses the header block on the NAND image to determine what and how much to copy, as well as the DDR controller register values to setup the RAM prior to that.

# If U-Boot is executed from NAND and the i.MX53 QSB boot loader uses the same UART as the TX53, shouldn't u-boot display at least some messages on the uart, even if no adoptations has been done? The i.MX53 QSB board seems to be very similar to the TX53-1331.

The NAND header block contains critical DDR timings and clock setup.  So if the NAND header block is wrong/bad, you won't see anything.  If you undefine CONFIG_FLASH_HEADER and define SKIP_LOW_LEVEL_INIT in uBoot, you can build a uBoot without the NAND header which you can load into memory and use 'go' from RedBoot to execute.  If that doesn't display anything, your uBoot is definitely bad and needs fixing.  That said, I think the TX53-1331 and 8020/30 are the same in this respect, so it might just work with my patch.

Checking over my changes again, to get the NAND header right, I think you probably need to start by updating include/configs/tx53.h, using TX53-1x31.ecc from the RedBoot sources for guidance.  Specifically I think you need to change least these defines to these values:

• CPU_CLOCK 1000
• CONFIG_TX53_SDRAM_TYPE DDR3  /* same as 8030 */
• CONFIG_SYS_PLL2_FREQ 333     /* same as 8030 */
• PHYS_SDRAM_1_SIZE  (1024 * 1024 * 1024)

After that, if you build uBoot.bin and open it in a hex editor (okteta is my favourite) you should see 'FCB' in bytes 4-6, followed by some magic numbers and lots of blanks.  If you compare that to a RedBoot image for your module, it should be much the same.  If it isn't, recheck the values you've configured.

It's also possible to use the hex editor to copy values from the RedBoot binary to the uBoot one, although beware that there are a couple of values that should differ e.g. image_len.

Mike

[Rooney]

Hmm, that's still seems to be lots of work...

How could you do the porting without a schematic? Just looking to the sources? I tried to get one from Karo, but no chance!!

Must the binary for the NAND flash have a defined format or header to work correctly?

Just a few general questions:

# U-Boot is executed from NAND or DDR? In other words, is u-boot copied from NAND to DDR and then executed from DDR?

# If U-Boot is executed from NAND and the i.MX53 QSB boot loader uses the same UART as the TX53, shouldn't u-boot display at least some messages on the uart, even if no adoptations has been done? The i.MX53 QSB board seems to be very similar to the TX53-1331.

Regards,

Rooney

[Michael_McTerna]

Hi Rooney,

What I did was take the uBoot 2009.08 + Freescale patches from the Freescale BSP (u-boot-v2009.08-imx_11.09.01.tar.bz2) and then get it working on the TX53, using RedBoot to load it into RAM and then execute (with the 'go' command).  I based the config on the mx53_evk, and made small changes for the UART pins etc...

Once running from RAM was working, I merged across the DCD/FCB setup block from the Karo Redboot sources into the tweaked config cloned from the Freescale mx53_evk.  This was surprisingly easy, and once done I binary compared the NAND header block from the Karo Redboot binary with the built uBoot, then checked all the clocks were correct once uBoot had started and ran some tests.

This was for the Karo TX53-8020/8030 (it's a build switch to change between the two), so you'd need to dig out and patch the FCB setup from the Redboot code for the 1331 and patch that.

I've attached the patch I produced for the 8030 - the stuff from Redboot which you'll need to change should be obvious from the original eCOS copyright notices (GPLv2+ so the same as uBoot).

Let me know how you get on.

Regards,

Mike

[Rooney]

Hello Michael!

I'm using a TX53 from Karo as well (TX53-1331) and I would prefer to use u-boot instead of red boot that is preinstalled on the module.

Can you provide the source code that is working for the TX53?

Or have you written a patch so the U-Boot version U-Boot 2009.08 can be used (included in L2.6.35_11.09.01_ER_source_bundle.tar.gz)?

Regards,

Rooney

[Michael_McTerna]

Okay, I found the function mxc_nand_bi_swap() is swapping a byte or data into the OOB area of each 2k page.  I'm not sure why, but it only does this for large page NAND.

Removing this function has improved the situation and I can read and write to the NAND from uBoot and boot Linux without ECC errors.