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