
* 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.
I have filed an internal bug to request this information be added to the TRM. We will see what happens.
I have filed a similar bug (#976261 in the NVIDIA bug tracker) and Vincent has been informed, so that may help.
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.
Oh I see; you're mingling the boot flash and filesystem into a single memory device. It simpler (but I imagine more costly) not too:-)
Yes, it's all about the money. =) On a more serious note it makes a lot of sense. Firstly we want to use the MMC/SD slot for user storage on Plutux and therefore need to have the OS on internal storage (i.e. NAND). And secondly we build a very minimalistic distribution in-house it fits without a problem.
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.
One thing I just remembered which may be a little problem is that currently our boards need to use the L4T binaries for OpenGL ES support, which means they need to run a Chromium kernel and that sadly doesn't properly boot from a mainline U-Boot but requires a setup where we use quickboot as first stage and U-Boot as a second stage bootloader. I haven't had time to investigate this further, though. But having this kind of setup complicates the NAND setup from user space further.
The long term plan was to incrementally move to a mainline system by first replacing the QuickBoot/U-Boot combo that we use now with a mainline U-Boot. Most of the pieces for that are now in place. I'm not sure if the SMSC95xx is already supported by U-Boot (we need it to program the MAC address) during bootstrap. Subsequently we were planning to move to a mainline kernel, which is obviously even longer term because it requires the DRM driver to be merged along with an updated user space to take advantage of it.