[U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support

[Thierry Reding]

* Simon Glass wrote:
> This series adds NAND flash support to Tegra and enables it on Seaboard.
> 
> Included here is a proposed device tree binding with most of the properties
> private to "nvidia,". The binding includes information about the NAND
> controller as well as the connected NAND device. The Seaboard has a
> Hynix HY27UF4G2B.
> 
> The driver supports ECC-based access and uses DMA and NAND acceleration
> features of the Tegra SOC to provide access at reasonable speed.

I've been working on getting a similar driver up and running in the Linux
kernel. While I can successfully read data from the flash (my hardware has
the same Hynix chip) I've run into a bit of a problem with the partition
tables.

When I use nvflash with a given configuration file to write the BCT, the PT
and U-Boot to the NAND, I noticed that the partitioning is not quite as it
should be. For example I use this:

	[device]
	type=nand
	instance=0

	[partition]
	name=BCT
	id=2
	type=boot_config_table
	allocation_policy=sequential
	filesystem_type=basic
	size=262144
	file_system_attribute=0
	partition_attribute=0
	allocation_attribute=8
	percent_reserved=0

	[partition]
	name=PT
	id=3
	type=partition_table
	allocation_policy=sequential
	filesystem_type=basic
	size=262144
	file_system_attribute=0
	partition_attribute=0
	allocation_attribute=8
	percent_reserved=0

	[partition]
	name=EBT
	id=4
	type=bootloader
	allocation_policy=sequential
	start_location=2097152
	filesystem_type=basic
	size=524288
	file_system_attribute=0
	partition_attribute=0
	allocation_attribute=8
	percent_reserved=0
	filename=u-boot.bin

That however doesn't produce the expected results. Looking at the UART output
produced by the bootstrap fastboot.bin it looks like it's actually allocating
more blocks than necessary.

On the Hynix chip, 256K is 2 blocks, but fastboot.bin seems to want to
allocate more:

	Erase Partition part-id=3: Start=6,End=11
	Format partition BCT
	Erase Partition part-id=2: Start=0,End=5
	Format partition EBT
	Erase Partition part-id=4: Start=12,End=19

On another board things are even worse. It has a bad block, which causes the
bootstrap to skip that when allocating the partitions:

	Erase Partition part-id=3: Start=6,End=12
	Factory Bad block: Chip0 Block=8
	Runtime Bad block: Chip0 Block=8,RTB=0xed
	Format partition BCT
	Erase Partition part-id=2: Start=0,End=5
	Format partition EBT
	Erase Partition part-id=4: Start=13,End=20

Both of these issues lead to the problem that if I encode the same partition
information in the DT, the kernel's representation will not match what the
nvflash tool did.

There seems to be more output during bootstrap that indicates that nvflash
does some remapping from logical blocks to physical blocks:

	PartId 2: LB[0 2] PB[0 6] IL1  LS[0 128]
	Factory Bad block: Chip0 Block=8
	Runtime Bad block: Chip0 Block=8,RTB=0xed
	Chip0 Block=8 bad
	PartId 3: LB[2 2] PB[6 7] IL1  LS[128 128]
	PartId 4: LB[4 4] PB[13 8] IL1  LS[256 256]

If we can get at this information (maybe it is stored within the partition
table partition?), then it should be possible to use it to automatically
build a correct partition table for both U-Boot and the kernel.

Anyway, I was wondering how you solved this problem. Or maybe you didn't have
the same problem in the first place?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120426/af5a781d/attachment.pgp>