On 04/26/2012 11:10 PM, Thierry Reding wrote:
- Stephen Warren wrote:
On 04/26/2012 12:32 PM, Thierry Reding wrote:
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.
...
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.
Out of curiosity, what's missing from cbootimage?
It's missing support for PT. That may not be necessary in a setup where we initialize the NAND from Linux user space, though, so maybe it would be enough.
I don't believe the Tegra boot process actually /requires/ the PT even exist. IIRC, the boot ROM searches for the BCT, and the BCT contains a pointer to the bootloader (e.g. U-Boot), so it's only at a later stage in the game that anything would care about the PT. As such, worrying about the PT (or even including it) may be pointless.
I believe that TrimSlice's firmware recovery SD card images are created solely using cbootimage, and hence most likely have no PT, although obviously no additional partitions/file-systems on the media.
Perhaps you could define some hard-coded "MTD" partitions (e.g. the first 1MB and the rest), where the first 1MB contains BCT + U-Boot and the rest contains a regular MBR or GPT partition table. I /think/ there may even be a kernel command-line option to define the MTD partition layout?
Or, you could probably even get away with using a GPT for the entire NAND by placing just the secondary GPT at the end of the NAND, putting the BCT+U-Boot right at the start, and defining a GPT partition to protect/cover BCT+U-Boot. I vaguely recall trying this on some Tegra device, but I may be wrong.
Note that while most/all of the suggestions above probably work fine in practice, you should probably run them by your support contacts at NVIDIA in order to determine if we'd actually provide support for any of them and/or whether they negatively interact with the boot ROM in any way.