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

[GeorgeHuntingto]

I am trying to get TX-53 support working in Barebox, with not much luck so far.  here is my git repository

https://github.com/gchiii/barebox-tx53.git

any help would be appreciated.

[GeorgeHuntingto]

Rooney, thanks that seems to work well

[Rooney · Accepted solution]

Hello George!

Sorry for my late response. Find attached the patch used for the TX53-1331.

Please download the mainline u-boot from ftp://ftp.denx.de/pub/u-boot/u-boot-2009.08.tar.bz2 and patch the sources using the Freescale patches u-boot-v2009.08-imx_11.09.01.tar.bz2 (incl. in BSP L2.6.35_11_09_ER_SOURCE).

host> tar -xjf u-boot-2009.08.tar.bz2

host> tar -xjf u-boot-v2009.08-imx_11.09.01.tar.bz2 -C u-boot-2009.08

host> cd u-boot-2009.08

host> ./patches/patch-uboot.sh

Afterwards use the attached patch. You can skip the previous patching stage, if you already use the IMX patched u-boot-2009.08 version.

Please give feedback if it works for you.

Regards,

Rooney

[gchiii]

out of curiosity, has anyone tried to make u-boot display a splash-screen with the KaRo TX53?

[GeorgeHuntingto]

that would be great!

[Rooney]

Hello George!

I've a patch for version u-boot-2009.08. It can boot from SATA, MMC, and TFTP + NFS. NAND has not been tested yet. I use NAND only to store the bootloader. If you are interested, I can post the patch.

[GeorgeHuntingto]

I would like to patch u-boot-imx from here git://github.com/Freescale/u-boot-imx.git patches-2012.04.01  to work with the KaRo TX53-1331 and boot from nand.  would anyone care to help with this?  alternatively I started looking at barebox, has anyone used barebox as the bootloader for a TX53?

[FlorianBoor]

Ops... my bad, I somehow read the "#if 1" as "#if 0" - I should get another coffee :-)

[Michael_McTerna]

Florian Boor said:

- Every block written by U-Boot gets identified as bad both by the flasher tool and Linux.

The code I highlighted in my first post, at the very top of this old thread, shows the code which needs removing to fix that.

[FlorianBoor]

I ran into this issue as well and the solution seems to be quite simple: Erase the whole flash. I used the Linux command line flash_program like this: ./flash_program -DVU -P mx53-v3 erase 0 0x08000000 After doing this all the bad blocks were gone here and flashing worked pretty well again. But anyway, it needs to get fixed somehow. So far I have identified two sources of bad blocks: - Some versions of the bootstrap binary for flashing seem to cause this effect. - Every block written by U-Boot gets identified as bad both by the flasher tool and Linux. Apart from this U-Boot is working pretty well for me, apart from the I2C and the fact that the GPU driver seems to expect some initialisation different from what RedBoot and U-Boot do for the TX53. Greetings Florian

[Rooney]

I only get the information about the SDRAM connections from Karo, but I believe this could help. The memory space is constructed with four chips, whereby two chip selects are used. So I did  some further investigations on the code and the strange behaviour if using the two chip select configuration in flash_header.S.

I don't know exactly if the following issues are related to the TX53-8020 as well, you are using. I don't if you have als 1GByte DDR3 memory, can't find any information on that in the www.  But maybe you should have a look on it.

# Two chip selects are used. In this case 512MByte are controlled by one chip select. The configuration of the MMU was wrong, as the original patches assumes 1GByte on ONE SINGLE chip select. The chip arrangement is equal to the MX53 Loco board (i.MX53 QSB), so in board_mmu_init() (tx53.c) the following changes must be done:

-  X_ARM_MMU_SECTION(0x700, 0x700, 0x400, ARM_CACHEABLE, ARM_BUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* CSD0 1G */
-  X_ARM_MMU_SECTION(0x700, 0xB00, 0x400, ARM_UNCACHEABLE, ARM_UNBUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* CSD0 1G */

+  X_ARM_MMU_SECTION(0x700, 0x700, 0x200, ARM_CACHEABLE, ARM_BUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* CSD0 512M */
+  X_ARM_MMU_SECTION(0x700, 0x900, 0x200, ARM_UNCACHEABLE, ARM_UNBUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* CSD0 512M */
+  X_ARM_MMU_SECTION(0xB00, 0xB00, 0x200, ARM_CACHEABLE, ARM_BUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* CSD1 512M */
+  X_ARM_MMU_SECTION(0xB00, 0xD00, 0x200, ARM_UNCACHEABLE, ARM_UNBUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* CSD1 512M */

# dram_init() in tx53.c must use both SDRAM banks.

int dram_init(void)
{
    gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
    gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;

#if defined(PHYS_SDRAM_2)    
    gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
    gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
#endif    
    return 0;
}

# The configuration in tx53.h must slightly be changed to support two SDRAM banks.

#define CONFIG_NR_DRAM_BANKS    2
#define PHYS_SDRAM_1        CSD0_BASE_ADDR
#define PHYS_SDRAM_1_SIZE    (512 * 1024 * 1024)
#define PHYS_SDRAM_2        CSD1_BASE_ADDR
#define PHYS_SDRAM_2_SIZE    (512 * 1024 * 1024)
#define iomem_valid_addr(addr, size) \
    ((addr >= PHYS_SDRAM_1 && addr <= (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE)) \
    || (addr >= PHYS_SDRAM_2 && addr <= (PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE)))

# Change CONFIG_MX53_EVK to CONFIG_MX53_LOCO in tx53.h otherwise the two SDRAM banks are not supported in mmu.h

# PHYS_SDRAM_1_SIZE in flash_jeader.S should be the complete SDRAM size not only the size of one ship. During configuration it will be checked, if two SDRAM banks should be used. This is the case if the memory space is larger than SZ_512M. So in this case it would be better to do the following.

#define SDRAM_SIZE     (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE)

Unfortunately I can't test these changes right now, my NAND flash gots corrupted yesterday and flashing with the Advanced Toolkit fails with "Too many bad blocks encountered" :-(

[Michael_McTerna]

# In your patch you've added compression support (CONFIG_KARO_TX53_REDUCE). Is this necessary?

I was trying to cut down the size of uBoot so it would fit in one flash block.  Then if that block is corrupt, a 2nd copy can easily be placed in the 2nd bock for fallover booting.  I don't think I quite made it small enough though.

# The TX53-1331 provides 1GByte DDR3. The i.MX53 QSB (Loco) also provides 1GByte. So I think the wiring and configuration should be equal to the TX53-1331. But obviously it isn't.

In the absence of any schematics, I guess the only other option is to go digging in the RedBoot sources again.  The DCD will encode memory controller setup which will give some hints, although there maybe other hints around.

Maybe if you asked Karo nicely that might be able to fill in the memory configuration too...

[Rooney]

Thanks for that!

I did a complete reengineering of the patch you provided. Now I understand how the things are working.

But there are two things still unclear:

# In your patch you've added compression support (CONFIG_KARO_TX53_REDUCE). Is this necessary?

# The TX53-1331 provides 1GByte DDR3. The i.MX53 QSB (Loco) also provides 1GByte. So I think the wiring and configuration should be equal to the TX53-1331. But obviously it isn't.

I changed the following lines in the sources. If I use two banks U-Boot does not work anymore.

@ tx53.c

int dram_init(void)
{
#if 0
    gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
    gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
#endif    
#if 1   
    gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
    gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
    gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
    gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
#endif    
    return 0;
}

@ tx53.h

#if 0
#define CONFIG_NR_DRAM_BANKS    1
#define PHYS_SDRAM_1        CSD0_BASE_ADDR
#define PHYS_SDRAM_1_SIZE    (1024 * 1024 * 1024)
#define iomem_valid_addr(addr, size) \
    (addr >= PHYS_SDRAM_1 && addr <= (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE))
#endif

#if 1
#define CONFIG_NR_DRAM_BANKS    2
#define PHYS_SDRAM_1        CSD0_BASE_ADDR
#define PHYS_SDRAM_1_SIZE    (512 * 1024 * 1024)
#define PHYS_SDRAM_2        CSD1_BASE_ADDR
#define PHYS_SDRAM_2_SIZE    (512 * 1024 * 1024)
#define iomem_valid_addr(addr, size) \
    ((addr >= PHYS_SDRAM_1 && addr <= (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE)) \
    || (addr >= PHYS_SDRAM_2 && addr <= (PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE)))
#endif   

@ flash_header.S

#if CONFIG_NR_DRAM_BANKS > 1
    MXC_DCD_ITEM(0x63fd901c, 0x0000803a)
    MXC_DCD_ITEM(0x63fd901c, 0x0000803b)
    MXC_DCD_ITEM(0x63fd901c, 0x00028039)
    MXC_DCD_ITEM(0x63fd901c, 0x09208138)
    //MXC_DCD_ITEM(0x63fd901c, 0x05208138)
    
 
    MXC_DCD_ITEM(0x63fd901c, 0x04008048)
#endif

[Michael_McTerna]

Hi,

The Karo ReleaseNotes.txt indicates v1.5.2 (2011-12-23).  I seem to recall cutting out some of the board/CPU setup code since uBoot already has code to do that - diffing the exact versions is probably the way to go :)

Regards,

Mike

[Rooney]

Hello Mike!

Which RedBoot version from Ka-Ro did you use for adopting flash_header.S?

I took a look into hal_platform_setup.h of version v1.5.0 (2010-06-16) and it includes lots of code lines that are not included in your patch. I just want to get sure, that I'm using the same file version to get a deeper understanding of porting u-boot.

Regards,
Rooney

[Rooney]

Hello Mike!

I solved the problem with the reliabilty when flashing the NAND via the Advanced Toolkit. Just execute nand erase before doing an update. Never failed again, since doing so.

I tried the VM provided by Karo, but the environment looks really strange and I'm not sure if I could develop Qt applications on that VM. So I set up my own. It works as long as the above mentioned packages are installed. I tested it on Debian Squeeze and Ubuntu Lucid.

Concerning the Filesystem. It works with the filesystem provided by Karo, even via NFS. So I tried several things to get my own filesystem running.

I created a filesystem using multistrap and debootstrap for lenny, squeeze and lucid. It is strange, but the lucid filesystem fails with runaway loop modprobe binfmt-464c. Lenny and squeeze works perfectly!!! This is soooooo strange!!! The lucid filesystem works with an older kernel on the i.MX53 QSB but not on 2.6.39-tc6 + TX53.

I'm pretty stumped.

However, in this case I will either use lenny or squeeze.

[PeterThoeming]

Thanks. I'm working on an MX50 EVK, so I'll compare and contrast and make educated changes, but I'll examine your patch-file to see what was done. I'm fairly certain the MX50 and MX53 will use a similar header...

Michael McTernan said:

The very fastest way is to hang off someone else's coat tails I'm afraid!  What are you booting from, or is it a new design?  If it boots, at some point your chip is getting the correct configuration register values from somewhere, so finding that should give you a big clue as to what values are needed in the DCD/FCB.

[Michael_McTerna]

Peter Thoeming said:

In regards to a part of an earlier response you made that I've "snipped" out of this thread (see below).

Had Redboot source not been available for use to form your u-boot header properly (DCD/FCB) for a specific NAND FLASH part specific to the board you are using, how would you have crafted/formed a complete FCB within your u-boot binary header?

I would have found the closest Freescale reference, then noted which parameters needed changing for the DDR and updated the code with those values.  Basically it would be digging in the datasheets and i.MX53 reference manual to work out which registers need poking with each parameter.  The problem is that if the values are off, you probably won't boot or will crash shortly afterwards as the external RAM needs setting up correctly.

If you have a decent JTAG to hand, I think you can speed things up a bit by using that to bootstrap the chip in different configurations by basically poking the registers you would setup using DCD.

Would it be handcrafted and then added into the make-flow through assembly? Perhaps in the flash_header.S file for my board.

Yeah - check the patch.  The .S file is pretty straight forward and is basically a data section laid out as described in the Freescale reference manual without too much code.  There's some use of macros and labels to make the addresses work (that's all from Karo), but it isn't necessary.  You could make a spreadsheet compute the DCD if you wanted.

I'm working on trying to make the MX50 EVK u-boot from NAND FLASH, but the header is not correct, so I'm hoping to learn the fastest way to create such a header file.

Unfortunately, Freescale has not suggested or provided much information that states exactly how that is done.

The very fastest way is to hang off someone else's coat tails I'm afraid!  What are you booting from, or is it a new design?  If it boots, at some point your chip is getting the correct configuration register values from somewhere, so finding that should give you a big clue as to what values are needed in the DCD/FCB.

I'd also harang Freescale for more support if possible - it's not like NAND boot is an exotic requirement these days, and the chips are designed to do it!

[PeterThoeming]

Mike,

In regards to a part of an earlier response you made that I've "snipped" out of this thread (see below).

Had Redboot source not been available for use to form your u-boot header properly (DCD/FCB) for a specific NAND FLASH part specific to the board you are using, how would you have crafted/formed a complete FCB within your u-boot binary header?

Would it be handcrafted and then added into the make-flow through assembly? Perhaps in the flash_header.S file for my board.

I'm working on trying to make the MX50 EVK u-boot from NAND FLASH, but the header is not correct, so I'm hoping to learn the fastest way to create such a header file.

Unfortunately, Freescale has not suggested or provided much information that states exactly how that is done.

Thanks in advance for any tip you may have.

regards,

Pete

Michael McTernan said:

Hi Rooney,

<snip>

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.

<snip>

[Michael_McTerna]

Rooney said:

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

Karo's.

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

I just unpacked Karo's sources (3.0.0) and built that.  They provide a patch, but it's already been applied to their source bundle.

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

I do it with some Makefiles I wrote, but it's simple enough.  Basically I use the CodeSoucery Lite toolchain, and take the sysroot from that as per their instructions.  Then I build busybox and install that into my staging directory with the sysroot.  I also cross-compile and install a bunch of other libs and apps into the same stage, before using a loop mount to create the JFFS2 rootfs image.  I could NFS mount the root too I guess, but I'm past needing that now.

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:

They provide a ready configured VirtualBox machine for this too - maybe give that a go?

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

The Karo stuff is pretty good in my experience, but all the Linux distros vary greatly, so making something work across them all is tough going!  Little differences on some OSes can trip scripts up and make subtle bugs e.g. Ubuntu uses Dash not Bash as the default shell - it's *almost* Bash, but not quite :D

Do you have any ideas?

Try their rootfs with your kernel first.  Once that works, try their kernel with your rootfs.  That should work out broadly where the problem is.