Hi,
I wish to modify the MB1/MB2 BCTs as described in bringup & adaptation section.
My problem is that there are many .dtb files in the relevant directories and I didn’t find the final dtb composed from all these smaller parts.
I looked in the primary dtb (the one mentioned in the configuration file) but didn’t find the relevant settings there.
where can I find the final dtb containing the BCTs and verify is the one that actually being flashed?
Thanks
Hi BSP_User,
Are you using the devkit or custom board for Orin NX?
What’s your Jetpack version in use?
There are many dtb files in the BSP package for different platforms and also boot stages.
You could just check the flash log to know which dtb is in use.
Thank you for your quick answer.
I’m using both custom carrier board and orin nano devkit for hosting the orin nx.
snapshot from the jetson-orin-nano-devkit.conf:
DEFAULT_EMC_FUSE=“0”;
PINMUX_CONFIG=“tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi”;
PMC_CONFIG=“tegra234-mb1-bct-padvoltage-p3767-dp-a03.dtsi”;
BPFDTB_FILE=“tegra234-bpmp-3767-0000-a02-3509-a02.dtb”;
DTB_FILE=“tegra234-p3767-0000-p3768-0000-a0.dtb”;
TBCDTB_FILE=“${DTB_FILE}”;
EMMC_CFG=“flash_t234_qspi_sd.xml”;
During flashing process I recognize that the flashed dtb is $DTB_FILE (tegra234-p3767-0000-p3768-0000-a0.dtb). This dtb doesn’t contain the BCT options. Which variable responsible to indicate this configuration file the specific dtb containig the BCT options?
Thanks
Please share the full flash log in your case.
log:
flash.log (283.5 KB)
from the log:
tegraparser_v2 --generategpt --pt flash.xml.bin
[ 4.6397 ] gpt_secondary_3_0.bin:
[ 4.6402 ] partition_id partition_name StartingLba EndingLba
[ 4.6407 ] 1 BCT 0 2047
[ 4.6413 ] 2 A_mb1 2048 3071
[ 4.6419 ] 3 A_psc_bl1 3072 3583
[ 4.6425 ] 4 A_MB1_BCT 3584 3839
[ 4.6431 ] 5 A_MEM_BCT 3840 4351
[ 4.6437 ] 6 A_tsec-fw 4352 6399
[ 4.6443 ] 7 A_nvdec 6400 8447
[ 4.6449 ] 8 A_mb2 8448 9471
[ 4.6456 ] 9 A_xusb-fw 9472 9983
[ 4.6456 ] 10 A_bpmp-fw 9984 13055
[ 4.6456 ] 11 A_bpmp-fw-dtb 13056 21247
[ 4.6456 ] 12 A_psc-fw 21248 22783
[ 4.6456 ] 13 A_mts-mce 22784 23807
[ 4.6456 ] 14 A_sc7 23808 24191
[ 4.6456 ] 15 A_pscrf 24192 24575
[ 4.6456 ] 16 A_mb2rf 24576 24831
[ 4.6456 ] 17 A_cpu-bootloader 24832 31999
[ 4.6456 ] 18 A_secure-os 32000 40191
[ 4.6456 ] 19 A_smm-fw 40192 44287
[ 4.6456 ] 20 A_eks 44288 44799
[ 4.6456 ] 21 A_dce-fw 44800 55039
[ 4.6457 ] 22 A_spe-fw 55040 56191
[ 4.6457 ] 23 A_rce-fw 56192 58239
[ 4.6457 ] 24 A_adsp-fw 58240 62335
[ 4.6457 ] 25 A_reserved_on_boot 62336 65023
[ 4.6457 ] 26 B_mb1 65024 66047
[ 4.6457 ] 27 B_psc_bl1 66048 66559
[ 4.6457 ] 28 B_MB1_BCT 66560 66815
[ 4.6457 ] 29 B_MEM_BCT 66816 67327
[ 4.6457 ] 30 B_tsec-fw 67328 69375
[ 4.6457 ] 31 B_nvdec 69376 71423
[ 4.6457 ] 32 B_mb2 71424 72447
[ 4.6457 ] 33 B_xusb-fw 72448 72959
[ 4.6457 ] 34 B_bpmp-fw 72960 76031
[ 4.6457 ] 35 B_bpmp-fw-dtb 76032 84223
[ 4.6457 ] 36 B_psc-fw 84224 85759
[ 4.6457 ] 37 B_mts-mce 85760 86783
[ 4.6457 ] 38 B_sc7 86784 87167
[ 4.6457 ] 39 B_pscrf 87168 87551
[ 4.6457 ] 40 B_mb2rf 87552 87807
[ 4.6457 ] 41 B_cpu-bootloader 87808 94975
[ 4.6457 ] 42 B_secure-os 94976 103167
[ 4.6457 ] 43 B_smm-fw 103168 107263
[ 4.6457 ] 44 B_eks 107264 107775
[ 4.6457 ] 45 B_dce-fw 107776 118015
[ 4.6457 ] 46 B_spe-fw 118016 119167
[ 4.6457 ] 47 B_rce-fw 119168 121215
[ 4.6457 ] 48 B_adsp-fw 121216 125311
[ 4.6457 ] 49 B_reserved_on_boot 125312 127999
[ 4.6457 ] 50 uefi_variables 128000 128511
[ 4.6457 ] 51 uefi_ftw 128512 129535
[ 4.6457 ] 52 worm 129920 130303
[ 4.6457 ] 53 BCT-boot-chain_backup 130304 130431
[ 4.6457 ] 54 reserved_partition 130432 130559
[ 4.6457 ] 55 secondary_gpt_backup 130560 130687
[ 4.6457 ] 56 B_VER 130688 130815
[ 4.6457 ] 57 A_VER 130816 130943
[ 4.6457 ] gpt_primary_6_0.bin:
[ 4.6457 ] partition_id partition_name StartingLba EndingLba
[ 4.6457 ] 1 APP 3050048 118393407
[ 4.6457 ] 2 A_kernel 40 262183
[ 4.6457 ] 3 A_kernel-dtb 262184 263719
[ 4.6457 ] 4 A_reserved_on_user 263720 328487
[ 4.6457 ] 5 B_kernel 328488 590631
[ 4.6457 ] 6 B_kernel-dtb 590632 592167
[ 4.6457 ] 7 B_reserved_on_user 592168 656935
[ 4.6457 ] 8 recovery 656936 820775
[ 4.6457 ] 9 recovery-dtb 820776 821799
[ 4.6458 ] 10 esp 821800 952871
[ 4.6458 ] 11 recovery_alt 952872 1116711
[ 4.6458 ] 12 recovery-dtb_alt 1116712 1117735
[ 4.6458 ] 13 esp_alt 1117736 1248807
[ 4.6458 ] 14 reserved 1248808 3050023
[ 4.6458 ] gpt_secondary_6_0.bin:
[ 4.6458 ] partition_id partition_name StartingLba EndingLba
[ 4.6458 ] 1 APP 3050048 118393407
[ 4.6458 ] 2 A_kernel 40 262183
[ 4.6458 ] 3 A_kernel-dtb 262184 263719
[ 4.6458 ] 4 A_reserved_on_user 263720 328487
[ 4.6458 ] 5 B_kernel 328488 590631
[ 4.6458 ] 6 B_kernel-dtb 590632 592167
[ 4.6458 ] 7 B_reserved_on_user 592168 656935
[ 4.6458 ] 8 recovery 656936 820775
[ 4.6458 ] 9 recovery-dtb 820776 821799
[ 4.6458 ] 10 esp 821800 952871
[ 4.6458 ] 11 recovery_alt 952872 1116711
[ 4.6458 ] 12 recovery-dtb_alt 1116712 1117735
[ 4.6458 ] 13 esp_alt 1117736 1248807
[ 4.6458 ] 14 reserved 1248808 3050023
Thank you
For the MB1 BCT config in your case, it should be the following one.
copying device_config(/home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb1-bct-device-p3767-0000.dts)... done.
For the A_MB1_BCT partition, it is using mb1_cold_boot_bct_MB1_sigheader.bct.encrypt, which is generated from initrd.
Writing mb1_cold_boot_bct_MB1_sigheader.bct.encrypt (parittion: A_MB1_BCT) into /dev/mtd0
Thank you for your answer.
1.Why I need two MB1 (or MB2) BCTs?
The A/B mechanism is applied to A rootfs and B rootfs and not A MB1 and B MB1.
Am I worng?
If I modify the first one then the second is modified as well?
Bootloader has A/B mechanism too. Not only rootfs.
Thank you for the clarification.
which bootloader? (MB1/MB2/UEFI)
What I mean is:
at which point we split into two separate bootloaders?
obviously the ROM state machine is unique. From there we jump into two possible bootloaders? or we jump to additional unique bootloader which on its turn he jumps to one of two possible bootloaders?
Do we also get two copies of UEFI which load the suitable kernel?
In case of A/B mechanism, the file:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb1-bct-device-p3767-0000.dts (MB1 BCT)
is not being used (because its general and not relate to specific A/B partition) or that A MB1 BCT and B MB1 BCT both are constructed from him?
Thanks
please refer to Update and Redundancy — Jetson Linux Developer Guide documentation
The A/B switch will not happen randomly. When you full flash the board, each A/B slot will have same binary. The boot flow won’t be like “I want to boot from A MB1 then B MB2 and then again A UEFI”. There won’t be such flow. It will only switch to the other slot when error happened. A/B is a mechanism to prevent the other partition goes dead. Not for you to go boot separately.
As for your 2nd question, both A/B BCT are constructed from that file. MB1 bct file is more like a list of parameters.
Thank you for all your answers.
I have last 3 questions please regarding this matter:
KevinFFF helped me here:
but only by looking at the flash log.
I wish to find the file that tells the flash process which .dts to use for the target BCTs (and then I will know which exact files I will need to modify in order to modify the BCTs)
{
device {
qspiflash@0 {
clock-source-id = <0x5>; /* PLLC_OUT0 /
clock-source-frequency = <199999999>;
interface-frequency = <99999999>;
enable-ddr-mode;
maximum-bus-width = <2>;
fifo-access-mode = <1>;
read-dummy-cycle = <8>;
trimmer1-val = <0>;
trimmer2-val = <0x0c>;
};
sdmmc@3 {
clock-source-id = <8>; / 3:PLLP_OUT0, 8:PLLC4_OUT0_LJ /
clock-source-frequency = <200000000>;
best-mode = <3>; / 1:DDR52, 3:HS400 /
pd-offset = <0>;
pu-offset = <0>;
enable-strobe-hs400;
dqs-trim-hs400 = <40>;
init-type = <0>; / 0:SKIP_NONE(Full init) 1:SKIP_INIT 3:PARTIAL_INIT /
};
ufs@0 {
max-hs-mode = <4>;
max-pwm-mode = <4>;
max-active-lanes = <2>;
page-align-size = <4096>;
enable-hs-mode;
// enable-fast-auto-mode;
// enable-hs-rate-b;
enable-hs-rate-a = <1>;
init-state = <0>;
};
sd@0 {
/ These fields are informational as there is no
GPIO driver in mb1/mb2. */
cd_gpio_pin = <0>;
cd_gpio_polarity = <0>;
en_vdd_sd_gpio = <0>;
};
};
};
If I use only internal qspi and external nvm , can I remove the sd, ufs, sdmmc nodes from here? (my logic is that I don’t use them in my system hence can remove them from the BCT)
Thanks again
Finding the file used in flash log is the method eaily for you to know which file is in use. You could also track the board config used in the flash command.
We would not suggest you to do that because that would not affect anything in your use case.
You could also remove the entry of boot-device in UEFI menu.
No, the SoM should be flashed at least once to have required boot contents.
Thank you for your help