I am trying to configure u-boot and the partition layout for our hardware. We plan to boot from a 2k page size, 128k block size 512MB SLC NAND flash. Looking at the configuration files for Freescale's i.MX6 development boards, they seem to allocate a very large (16-20MB) partition to contain the boot structures and u-boot. Also, u-boot's environment storage seems to be located at some seemingly arbitrary offset inside that partition. Comments inside the board's u-boot config.h header reference kobs-ng, but searching the kobs-ng source code didn't really explain the layout very well. Could someone please summarize where all of the boot structures, u-boot, and the u-boot environment are stored inside the partition? What is the minimum viable size for a boot partition given the above flash parameters and a u-boot image that can fit inside 3 blocks?
Thanks for the info.
Solved! Go to Solution.
Hi Jason,
In order to boot from any device i.mx ROM need the following boot structures:
IVT - Image Vector
DCD - Device Configuration Data
The first one is only a header with some pointers to functions like the start up function or the DCD table.
The seconds one is a table with the commands describing devices register and the values to be written for each one.
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.
Also these structures should have a fixed offset in the device. The offset depends on the device but on mostly of the cases is 0x400 that is 1KB.
These tables are hard coded and can be checked in u-boot source code. (board/freescale/mx6xxxxxx/flash_header.S)
On the same directory there's also a linker script which tell how those binaries are going to be placed in the final binary.
(u-boot.lds)
In the case of the nand there's two extra structures required by the ROM those are:
FCB
DBBT
FCB have the nand specifications like the geometry(page size, erase block size etc).
DBBT have a copy the information from the Bad Block Table and some extra information.
Those structures are read by the ROM before the previous one when you boot from NAND.
Because nand erase block could wear out those FCB and DBBT tables have a extra copies on other blocks.
When you program the nand using kobs-ng init -v option the address of all the copies are going to be displayed.
Each pair of strutures (FCB,DBBT ) are going to be placed in different erase block and never there's
going to be a two pairs on the same block.
Also the FCB is going to be in the first page of the block.
But you should notice the data in each page have a layout because the gmpi is using ecc and the BCH module need
a layout based on the page size and the syndrome that layout is choose by the gmpi driver and MTD layer.
So at the end if you do a raw read you are going to have something like this:
Where the FCB ,DBBT and in general all data is going to be split in each page with intermixed ecc.
And the ROM expect that layout when is read because the FCB have it.
The environment in u-boot as you mention is a hard coded offset after u-boot offset and only ensures nothing could overwrite it. That could be changed in the board config file.
Related to you question about minimum that need to be calculated knowing the nand geometry and also the layout to be used. You could change those if you like. 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.
Regards,
-Israel.
Hi Jason,
In order to boot from any device i.mx ROM need the following boot structures:
IVT - Image Vector
DCD - Device Configuration Data
The first one is only a header with some pointers to functions like the start up function or the DCD table.
The seconds one is a table with the commands describing devices register and the values to be written for each one.
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.
Also these structures should have a fixed offset in the device. The offset depends on the device but on mostly of the cases is 0x400 that is 1KB.
These tables are hard coded and can be checked in u-boot source code. (board/freescale/mx6xxxxxx/flash_header.S)
On the same directory there's also a linker script which tell how those binaries are going to be placed in the final binary.
(u-boot.lds)
In the case of the nand there's two extra structures required by the ROM those are:
FCB
DBBT
FCB have the nand specifications like the geometry(page size, erase block size etc).
DBBT have a copy the information from the Bad Block Table and some extra information.
Those structures are read by the ROM before the previous one when you boot from NAND.
Because nand erase block could wear out those FCB and DBBT tables have a extra copies on other blocks.
When you program the nand using kobs-ng init -v option the address of all the copies are going to be displayed.
Each pair of strutures (FCB,DBBT ) are going to be placed in different erase block and never there's
going to be a two pairs on the same block.
Also the FCB is going to be in the first page of the block.
But you should notice the data in each page have a layout because the gmpi is using ecc and the BCH module need
a layout based on the page size and the syndrome that layout is choose by the gmpi driver and MTD layer.
So at the end if you do a raw read you are going to have something like this:
Where the FCB ,DBBT and in general all data is going to be split in each page with intermixed ecc.
And the ROM expect that layout when is read because the FCB have it.
The environment in u-boot as you mention is a hard coded offset after u-boot offset and only ensures nothing could overwrite it. That could be changed in the board config file.
Related to you question about minimum that need to be calculated knowing the nand geometry and also the layout to be used. You could change those if you like. 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.
Regards,
-Israel.