Redundant u-boot

Technical Support
, ,
#1

In our sensor firmware images we would like to use two copies of u-boot. During the image update only one copy of u-boot shall be flashed.
As stated in BCT Overview the NVIDIA Tegra provides up to 4 bootloader informations in the BCT.
In the case something would went wrong during the u-boot update the boot mechanism could then fall back to the still working u-boot copy.

The Apalis Linux BSP v2.7Beta1 contains one single BTC file (PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.bct).
Does the BCT file support redundant bootloaders?
What would we have to configure (e.g. location, size, load address, execution address, etc.)?
How would we have to configure these values?
We looked into the BCT file using “bct_dump” and wondered about a string stating that 0 of 4 bootloaders are used (’# Bootloader used = 0; # Bootloaders max = 4;’)?
We could also not find the regions in the file which address the bootloader. Where can we find that info and what does it contain?

For the case that the contained BCT files does not support redundant bootloaders could we create the BCT ourself?

#2

Unfortunately so far we do not have any experience with redundant boot loaders with NVIDIA’s tooling aka cbootimage/tegrarcm. That said I am very well aware of their public appnotes mentioning this but whether or not their tooling actually supports any of this I have my doubts.

#3

Ok that is sad.

We would like to implement it by our own. Could you please provide some information about the Apalis Linux BSP v2.7Beta1 which would help us to implement it our own:

  • Is it possible for us to create the BCT file on our own?
  • How was the BCT file created? (Has your BCT file been created with cbootimage?)
  • How did you set the BCT configuration to create the BCT file? ( There is a Jetson TK1 BCT configuration file for the NVIDIA cbootimage which is similar to our dumped BCT file. Do we have to use a modified version of a file like that?)
  • How would we have to modify the BCT file or its configuration to get support of redundant u-boot? (The dumped BCT file and the BCT configuration file contain very low level information. Where can I find information about that?)
  • Needs the BCT file to be created together with u-boot? (This section of the BCT Overview notes that “whenever the bootloader is modified, the BCT must be re- generated and re-programmed” to beeing able to detect a corruption of the bootloader in some cases.)
  • How is the BCT file used? (In the update script ‘update.sh’ when ‘tegracrm’ is called the BCT file is passed as command line argument?)
  • How would we have to modify the use of the BCT file? (In the update script ‘update.sh’ needs the call of ‘tegracrm’ to be modified w.r.t. its command line arguments?)
#4

I recently added a comment:

Florian_K moved the comment “Redundant u-boot” to moderation
12 minutes ago

Florian_K commented on the question “Redundant u-boot”
12 minutes ago

How can I restore it from “moderation” to be displayed?

#5

Could you provide the BCT configuration file for cbootimage in NVIDIAs official github repository for cbootimage configurations. In the README is explained how to get the BCT configuration file e.g. from the BCT file. This would us enable to rely on an officially supported BCT configuration of you which we can use as basis for customizations to build in support for a redundant u-boot?

#6

How can I restore it from “moderation” to be displayed?

Sorry, I really don’t know what you are talking about.

#7

Could you provide the BCT configuration file for cbootimage in NVIDIAs official github repository for cbootimage configurations. In the README is explained how to get the BCT configuration file e.g. from the BCT file. This would us enable to rely on an officially supported BCT configuration of you which we can use as basis for customizations to build in support for a redundant u-boot?

Sorry, but the validation & verification of Apalis TK1 is ongoing and so far there is no such officially supported BCT configuration you are talking about. You may just use the one from Jetson TK1 for now.

#8

Ok that is sad.

We would like to implement it by our own. Could you please provide some information about the Apalis Linux BSP v2.7Beta1 which would help us to implement it our own:

I believe most information would be required from NVIDIA and not from us.

Is it possible for us to create the BCT file on our own?

Sure, as mentioned before just used the one from Jetson TK1 for now.

How was the BCT file created? (Has your BCT file been created with cbootimage?)

Yes, according to NVIDIA’s Memory Characterisation Tool.

How did you set the BCT configuration to create the BCT file? ( There is a Jetson TK1 BCT configuration file for the NVIDIA cbootimage which is similar to our dumped BCT file. Do we have to use a modified version of a file like that?)

No, that should generally work just fine.

How would we have to modify the BCT file or its configuration to get support of redundant u-boot? (The dumped BCT file and the BCT configuration file contain very low level information. Where can I find information about that?)

Good question but as initially noted this would rather be a question for NVIDIA to be answered.

Needs the BCT file to be created together with u-boot? (This section of the BCT Overview notes that “whenever the bootloader is modified, the BCT must be re- generated and re-programmed” to beeing able to detect a corruption of the bootloader in some cases.)

I guess, whatever you mean by “together with U-Boot”.

How is the BCT file used? (In the update script ‘update.sh’ when ‘tegracrm’ is called the BCT file is passed as command line argument?)

NVIDIA’s tooling currently uses it in two distinct use cases, either for recovery mode aka tegrarcm or when creating the combined BCT/U-Boot binary image with cbootimage.

How would we have to modify the use of the BCT file? (In the update script ‘update.sh’ needs the call of ‘tegracrm’ to be modified w.r.t. its command line arguments?)

I really guess modifying resp. update script is the least of ones problems towards a full redundant boot solution.