Nand Download

[Idara Viengxay]

Iam using a 'stock' AM437x-GP-EVM to start on development while we design our new board. Our board will not have an SD card and will boot from NAND flash, so I am trying to get the GP-EVM to boot entirely from NAND. I have reverted to a 100% stock installation of ti-sdk-am437x-evm-08.00.00.00, but I am still unable to get the board to boot from NAND.

I am using boot mode 0 on the EVM (NAND, USB-MS, MMC0, USB_CL). When I remove the SD card (with nothing in USB either) then apply power, nothing comes out the console log. If I put the SD card in, the ROM bootloader gets MLO and u-boot from the SD card and then boots linux from NAND due to my uboot configuration.

For grins I tried using boot mode 11001b (UART, NAND_I2C, NAND, MMC0). When I remove the SD card, I get the expected "CCCC..." out the UART indefinitely. So it's alive but not finding my MLO and/or u-boot in NAND.

I must be missing something simple here since this seems pretty basic. Am I supposed to program something different into NAND than the files which succesfully load from SD maybe, and if so which ones? Any help is appreciated.

That is a pretty good guide. It lists most of the things I had to do. I also had to adjust the size of the flash partitions in the u-boot code since the NAND flash I was using had large sectors. If you look for MTDPARTS_DEFAULT in am43xx_evm.h in the u-boot code, you'll see where this is defined. And of course you also must set the boot mode pins of the AM43xx to one of the modes which boots from flash (obvious...but I thought I'd mention it).

when it starts up. That means that it's gotten the first stage bootloader from flash. If you don't see that, then MLO is not getting read correctly. If you see that but nothing else, then it may be a problem with u-boot.

If you boot from MMC and halt in u-boot, do all the commands for programming the NAND as described here work correctly, or do some of them give errors? If they all work then that does seem like the hardware is operating correctly and it should boot. If not, you could use the command "nand info" in u-boot to see if the device is detected at all, and if it is detected you can check the detected flash size and sector size against what you've configured in your MTDPARTS_DEFAULT in your u-boot source code.

vefone, there is another chip errata that might be affecting things for you: see advisory 15. It is not very clear what exactly is meant by that though. I can confirm that it appears to be booting reliably for me on at least one of my prototype boards and with one flash device. It will be necessary to get clarification on what that advisory implies.

The first step is to decide on how to partition your NAND to hold all the files you want. Once you've settled on this, you must edit both u-boot and the kernel files with this information. In u-boot, search for MTDPARTS_DEFAULT and edit that with your configuration. In the kernel, edit your dts file (e.g., am437x-gp-evm.dts). You will see a number of lines specifying the partition sizes in the gpmc section.

I have found it easiest to program the files from linux since I can use various scripts. It is also possible to use ubinize to do this, but I find the following scripts more flexible and at least for me easier to understand and debug. But perhaps that is just me. I had to learn all this mtd and ubi stuff while making my system run, so at least in part these scripts were part of my learning process. Hopefully they are helpful to you too.

To mount my user file system I use the following linux script file. I have it in /etc/init.d so it runs automatically when the system starts to mount my user partition where I store data, but you can also call it to mount other partitions. Be careful to edit the USER_PART and PART_NAME variables at the top of this script to align with your NAND partition usage.

The first time this script runs it will initialize the ubi partition, and on subsequent boots it will mount it on /mnt/ubi. Then you can use it just like any linux file system and write to it. You can also pass arguments to this script to mount other file system partitions. Note that you should not mount the MLO, u-boot, or kernel partitions using this script. Those are written to using the previous script file and are not directly accessible as linux files. Only the NAND partitions which will hold linux file systems should use this script.

To get my linux file system installed , I run from SD or NFS, then mount the linux file system partition using the above script. I use tar -c to create a copy of a working file system, and then use tar -x to extract it to my ubi file system. Note: I have my system set up with one partition for my linux file system and another for my data files. This is a good idea because then you can mount your linux filesystem readonly and it will never become corrupted due to power interruption.

I understand that these errors can be corrected so far at hardware level (is it true?) But is there a more permanent solution to this problem? Is it possible to mark those blocks as bad blocks now, before I put LEDE on the device? I would rather lose some nand space now, than risk instability later, then the router is put in service.

A "bitflip" is a situation where a bit changes its state on its own, a 1 becomes a 0 or the reverse. It's not a bad block (permanent damage), it's just something that randomly happens in NAND because they are less reliable by design (to keep costs down), and work around this drawback by having ECC logic implemented to correct any bitflip (and this is still cheaper than making them more reliable at the hardware level).

The same thing happens inside SSDs, usb flash drives, SD cards and Smartphones (all use NAND flash), you just don't see this happening it because it's all handled by the storage controller, while in an embedded device where read/write speed isn't important (like a router) the flash memory is accessed raw, there is no such controller, so the system itself uses ECC when reading/writing it.

EDIT: bonus fact: the reason you are using "nanddump" tool instead of the more common "dd" tool to create a backup of the flash partition is that nanddump is aware of all the above and reads the NAND with ECC logic, and stores only the actual data (correcting bitflips) in the backup you are creating.

dd tool is not aware of NAND ECC logic, so it will read all the NAND partition, both data AND parity and will generate a backup that is exactly the same as actually on flash, but is completely useless and unreadable as it will contain both data and hardware-specific parity information which cannot be restored on a different device.

The dd tool (or something more advanced like pv ) can only be used on block devices. Hard drives, SSDs, SDcards and so on where any ECC is done by the storage controller, not by the system, so whatever it reads is pure data, no metadata or parity for ECC logic.

Ok, added. I split my text in an informative part about bitflips (which have nothing to do with bad blocks so they go in their own paragraph), and another paragraph about the tools that MUST be used to read/write on raw NAND due to all this ECC thing.

I'm trying build a linux system on beaglebone black and following to mastering embedded linux programming book, however when I boot my u-boot on beaglebone black, I have received a error: unknown command 'nand' - try 'help'.

Within the kernel NAND partitions are accessed via mtd devices. Insteadare referring to a partition by its name or its offset a user simplyneeds to specify the NAND partition in question in the form of its mtddevice path. Usually in the format of /dev/mtdX where X is the mtddevice number.

Within the kernel figuring out the mtd device number that is for aparticular NAND partition is simple. A user simply needs to view thelist of mtd devices along with its name. Below command will provide thisinformation:

The symbol should be replaced with the name of a file youwant to be created that contains with contents of the NAND partition.Note that the above command by default with save to a file the completecontents of the NAND partition. If your interested in only a certainamount of data being dumped additional parameters can be passed to theutility.

In some situations, partitions defined in device-tree may not besufficient or correct. Note that once partitions are defined indevice-tree and present in a mainline kernel release, they cannot bechanged because this breaks users who have existing data on NAND flashand upgrade to new kernel and device-tree. If you are not affected bythis issue, you may choose to override partition information passed fromdevice-tree using command line.

When building a UBI file system you need to have a directory thatcontains the exact files and directories layout that you plan to use foryour file system. This is similar to the files and directories layoutyou will use to copy a file system onto a SD card for booting purposes.It is important that your file system size is smaller than the filesystem partition in the NAND.

On the board, NAND Flash signals are muxed between NAND, NOR and VideoOut signals. Therefore, to have the signals properly muxed for NAND towork Pin 1 (first pin on the left) must be turned on and Pin 2 must beturned off. Pin 1 and 2 must never be switched on at the same time.Doing so may cause damage to the board or SoC.

The current NAND subsystem within Linux currently deals with reading asingle page from the NAND at a time. Unfortunately, the page size issmall enough that the overhead for using the DMA (including Linux DMAsoftware stack) negatively impacts the performance. Based on nandperformance tests done in early 2016 using the DMA reduced NAND read andwrite performance by 10-20% depending on SOC. However, cpu load whenusing polling via the same NAND test were around 99%. When using DMAmode the CPU load for reading was around 35%-54% and for writing wasaround 15%-30% depending on SOC.

3a8082e126