keronmonster.blogg.se

Android se puede unir particion nand fhash
Android se puede unir particion nand fhash







  1. Android se puede unir particion nand fhash how to#
  2. Android se puede unir particion nand fhash driver#

First of all, you don't need to create three partition, you can create two ubi volume in second MTD partition.

Android se puede unir particion nand fhash how to#

Coincidentally i've spent my last three days to find out how to divide and load image into a 256MB nand into boot, rfs (175MB) and data (49MB) which both section is in ubifs filesystem generate images and trying to understand how to program.

Android se puede unir particion nand fhash driver#

The driver dives the partition into two section ~20MB for boot, and the rest (up to the end of nand whatever the actual size ) for general purpose usage. Can't say location off the top but it's in /drivers/mtd/. Also is possible to erase or not write copies of those structures but if something goes wrong with a block in your nand and that block is where the boot structures are even when the boot data is ok are not to be able to boot.Unfortunately -unlike some other uP's BSP's- iMX28 BSP doesn't use mx28evk.c for defining nand partitions, it's hardcoded into nand-flash driver of mx28. Related to you question about minimum that need to be calculated knowing the nand geometry and also the layout to be used.

android se puede unir particion nand fhash

That could be changed in the board config file. The environment in u-boot as you mention is a hard coded offset after u-boot offset and only ensures nothing could overwrite it. Where the FCB ,DBBT and in general all data is going to be split in each page with intermixed ecc.Īnd the ROM expect that layout when is read because the FCB have it.

android se puede unir particion nand fhash

So at the end if you do a raw read you are going to have something like this: Going to be a two pairs on the same block.Īlso the FCB is going to be in the first page of the block.īut you should notice the data in each page have a layout because the gmpi is using ecc and the BCH module needĪ layout based on the page size and the syndrome that layout is choose by the gmpi driver and MTD layer. When you program the nand using kobs-ng init -v option the address of all the copies are going to be displayed.Įach pair of strutures (FCB,DBBT ) are going to be placed in different erase block and never there's Those structures are read by the ROM before the previous one when you boot from NAND.īecause nand erase block could wear out those FCB and DBBT tables have a extra copies on other blocks. In the case of the nand there's two extra structures required by the ROM those are:įCB have the nand specifications like the geometry(page size, erase block size etc).ĭBBT have a copy the information from the Bad Block Table and some extra information. On the same directory there's also a linker script which tell how those binaries are going to be placed in the final binary. (board/freescale/m圆xxxxxx/flash_header.S) These tables are hard coded and can be checked in u-boot source code. The offset depends on the device but on mostly of the cases is 0x400 that is 1KB. This is used in order to set the values of the device controller in the processor like the DRAM controller before u-boot is loaded.Īlso these structures should have a fixed offset in the device. The seconds one is a table with the commands describing devices register and the values to be written for each one. The first one is only a header with some pointers to functions like the start up function or the DCD table.

android se puede unir particion nand fhash

In order to boot from any device i.mx ROM need the following boot structures:









Android se puede unir particion nand fhash