* Stephen Warren wrote:
Yes, I'd recommend not putting information in DT that can be easily extracted from the partition table on the device itself.
The problem is that neither the format of the BCT nor that of the PT is documented anywhere. It seems like the BCT contains a reference to where in the flash the PT starts but I wasn't able to find out where.
Ideally I think we could probably create a separate partition parser, similar to ofpart, that takes the information directly from the PT. Or alternatively it could be extracted manually at probe time to create the partitions in Linux.
Out of curiosity though, why do you even need the Tegra PT support; I'd assume in a situation like this, you'd just replace the whole flash with BCT, PT, EBT at once rather than attempting to update just parts of it (since the BCT must be updated when writing a new EBT content anyway), so the existing partition layout wouldn't matter, and the whole device could just be treated raw.
Actually I'd need more than those three partitions. I need at least five, optimally six. In addition to BCT, PT and EBT I need one for the uImage and the root filesystem. Those can probably go onto the same partition with JFFS2 or YAFFS. But a fifth will be required to store some other data. If all else fails it could probably be done via the fourth partition as well, but that'd be suboptimal.
As I said before, the biggest problem with updating the whole content is that there's no documentation about either the BCT or the PT. There's cbootimage on gitorious that has some information about the BCT, but it's incomplete.
For production use it is also impractical to bootstrap using nvflash, boot the system to Linux and create all the partitions as well. If that turns out to be the only option, then better documentation is certainly required. In that case I think it may be possible to not use the PT because the partition layout will actually be deterministic and it can be encoded with DT.
Thierry