* 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
pgpAUUHKsCbC5.pgp
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
