I should clarify we needed to patch the flash script to try with 28.2.1 (see Flashing error - ERR: unsupported board revision: D01 - #8 by damien.lefevre)
Today I’ve found if I completely replace the 4.4 bootloader directory with 4.3:
cd JetPack_4.4_Linux_JETSON_TX2/Linux_for_Tegra
mv bootloader bootloader-old
cp -rp ../../JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/ .
Then fix error about missing file by copying existing similarly named file to P3310_A00_8GB_lpddr4_A02_l4t.cfg from P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg
cp bootloader/t186ref/BCT/P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg bootloader/t186ref/BCT/P3310_A00_8GB_lpddr4_A02_l4t.cfg
Then run
sudo ./flash.sh jetson-tx2-devkit mmcblk0p1
I can successfully flash an JP 4.4 image with JP 4.3 bootloader files. I have no idea what this means or if this is really something valid as a workaround, would greatly appreciate suggestions about how to proceed.
That is why I asked to try rel-28.2.1 and rel-28.4. You may see rel-28.4 fail to flash either. But it is not needed to test anymore.
Your issue seems have something to do with pcn206440.
https://developer.nvidia.com/jetson-tx2-pcn-206440-dramemmc-public
This pcn makes some change to the dram config you just pasted. However, the new release (rel-32.4.3/rel-28.4) should only add new config and does not remove the old one from cfg. You shall see that by diff those cfg files between rel-32.4.3 and rel-32.3.1.
Thanks @WayneWWW
Modules with 699 level part number versions equal to or greater than D02 may be built with the new components described in this PCN, or with the older components
So if my revision is 699-83310-1000-D00 M will this apply?
It looks like PCN PCN204840-Jetson_TX2_Multiple_Changes.pdf applies to D00
Any Jetson TX2 module with 699 level part number version greater than or equal to D00 may be affected by this PCN. Each module has a label displaying the 699 level part number.
Linux for Tegra software R28.2 (or later) includes the required changes and can be obtained from the Jetson developer
website at http://developer.nvidia.com/jetson . There are two download options: 1. Obtain “JetPack” version 3.2 from the download center, or 2. Obtain the BSP files directly: “L4T Jetson TX2 Driver Package” version 28.2 from the download center
So it looks like I should be covered with 28.2 when using the D00 SOM unless I’m misunderstanding something here.
However, since the change for https://developer.nvidia.com/jetson-tx2-pcn-206440-dramemmc-public came in starting with JP 4.4 r32.4.3 and 28.4, I think what you are saying is it’s likely the changes to support D00 SOMs have broken something on our hardware when using D00 SOMs. However these changes aren’t strictly needed to support D00 SOMs, only D02 SOMs. This means replacing the bootloader directory completely with JP 4.3 content is probably a solution for supporting D00 SOMs on JP 4.4. However we’ll probably have a problem with D02 SOMs in this case.
Am I understanding this correctly?
Can we make sure this issue is related to these PCN?
Actually PCN204840 should be already existed since 2018/7 so rel-32.3.1 and rel-32.4.3 both have this change.
But rel-32.3.1 and rel-32.4.3 differ in PCN206440. Could you make sure the dram cfg is the cause of your issue?
P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg
Have you tried to replace this file only (not whole bootloader) to rel-32.4.3 and see if it can work? You can also replace the bpmp-dtb file (tegra186-bpmp-quill-p3310-1000-a00-00.dtb). Because pcn 206440 also has change in this file.
You may see rel-28.4 fail to flash either
I do see this fail to flash as well.
Actually PCN204840 should be already existed since 2018/7 so rel-32.3.1 and rel-32.4.3 both have this change.
Understood, I was trying to understand the difference between rev B and rev D SOM from a hardware perspective.
Have you tried to replace this file only (not whole bootloader) to rel-32.4.3 and see if it can work?
I just tried:
cd JetPack_4.4_Linux_JETSON_TX2/Linux_for_Tegra
cp ../../JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/t186ref/BCT/P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg bootloader/t186ref/BCT/P3310_A00_8GB_lpddr4_A02_l4t.cfg
sudo ./flash.sh jetson-tx2-devkit mmcblk0p1
It failed/hung up at the same place:
[ 8.1919 ] tegrahost_v2 --chip 0x18 --generateblob blob.xml blob.bin
[ 8.1939 ] number of images in blob are 9
[ 8.1947 ] blobsize is 4335416
[ 8.1950 ] Added binary blob_nvtboot_recovery_cpu_sigheader.bin.encrypt of size 221312
[ 8.2006 ] Added binary blob_nvtboot_recovery_sigheader.bin.encrypt of size 90016
[ 8.2020 ] Added binary blob_preboot_d15_prod_cr_sigheader.bin.encrypt of size 63104
[ 8.2036 ] Added binary blob_mce_mts_d15_prod_cr_sigheader.bin.encrypt of size 2082144
[ 8.2051 ] Added binary blob_bpmp_sigheader.bin.encrypt of size 533904
[ 8.2068 ] Added binary blob_tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2_sigheader.dtb.encrypt of size 605120
[ 8.2092 ] Added binary blob_tos-trusty_sigheader.img.encrypt of size 366400
[ 8.2106 ] Added binary blob_eks_sigheader.img.encrypt of size 1440
[ 8.2116 ] Added binary blob_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt of size 371824
[ 8.2171 ]
[ 8.2172 ] Sending bootloader and pre-requisite binaries
[ 8.2197 ] tegrarcm_v2 --download blob blob.bin
[ 8.2217 ] Applet version 01.00.0000
[ 8.2424 ] Sending blob
[ 8.2427 ] [................................................] 100%
[ 8.7538 ]
[ 8.7585 ] tegrarcm_v2 --boot recovery
[ 8.7624 ] Applet version 01.00.0000
[ 8.7846 ]
[ 9.7949 ] tegrarcm_v2 --isapplet
However the serial port prints look different:
NOTICE: BL31: v1.3(release):41d46a9cf
NOTICE: BL31: Built : 21:14:44, Jun 25 2020
ipc-unittest-main: 1519: Welcome to IPC unittest!!!
ipc-unittest-main: 1531: waiting forever
ipc-unittest-srv: 329: Init unittest services!!!
hwkey-agent: 40: hwkey-agent is running!!
hwkey-agent: 182: key_mgnt_processing .......
hwkey-agent: 157: Init hweky-agent services!!
platform_bootstrap_epilog: trusty bootstrap complete
You can also replace the bpmp-dtb file (tegra186-bpmp-quill-p3310-1000-a00-00.dtb). Because pcn 206440 also has change in this file.
Starting with the bootloader directory above with modified P3310_A00_8GB_lpddr4_A02_l4t.cfg I tried:
cp ../../JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-a00-00.dtb bootloader/t186ref/
sudo ./flash.sh jetson-tx2-devkit mmcblk0p1
This also fails at
[ 8.1852 ] Added binary blob_nvtboot_recovery_cpu_sigheader.bin.encrypt of size 221312
[ 8.1914 ] Added binary blob_nvtboot_recovery_sigheader.bin.encrypt of size 90016
[ 8.1930 ] Added binary blob_preboot_d15_prod_cr_sigheader.bin.encrypt of size 63104
[ 8.1942 ] Added binary blob_mce_mts_d15_prod_cr_sigheader.bin.encrypt of size 2082144
[ 8.1957 ] Added binary blob_bpmp_sigheader.bin.encrypt of size 533904
[ 8.1973 ] Added binary blob_tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2_sigheader.dtb.encrypt of size 605120
[ 8.1996 ] Added binary blob_tos-trusty_sigheader.img.encrypt of size 366400
[ 8.2007 ] Added binary blob_eks_sigheader.img.encrypt of size 1440
[ 8.2017 ] Added binary blob_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt of size 371824
[ 8.2073 ]
[ 8.2074 ] Sending bootloader and pre-requisite binaries
[ 8.2099 ] tegrarcm_v2 --download blob blob.bin
[ 8.2118 ] Applet version 01.00.0000
[ 8.2312 ] Sending blob
[ 8.2316 ] [................................................] 100%
[ 8.7317 ]
[ 8.7358 ] tegrarcm_v2 --boot recovery
[ 8.7395 ] Applet version 01.00.0000
[ 8.7598 ]
[ 9.7704 ] tegrarcm_v2 --isapplet
with a similar serial port message above:
[0142.160] I> Welcome to MB2(TBoot-BPMP) Recovery(version: 01.00.160913-t186-M-00.00-mobile-82dac681)
[0142.169] I> bit @ 0xd480000
[0142.172] I> Boot-device: eMMC
[0142.294] I> sdmmc DDR50 mode
[0142.299] I> sdmmc bdev is already initialized
[0142.304] I> pmic: reset reason (nverc) : 0x50
[0142.310] I> Found 18 partitions in SDMMC_BOOT (instance 3)
[0142.318] I> Found 33 partitions in SDMMC_USER (instance 3)
[0142.326] I> Binary(16) of size 533504 is loaded @ 0xd7800000
[0142.335] I> Binary(17) of size 604720 is loaded @ 0xd796c5c0
[0142.565] I> Copy BTCM section
[0142.570] I> Binary(13) of size 220912 is loaded @ 0x96000000
[0142.577] I> Binary(20) of size 371424 is loaded @ 0x8520f400
[0142.585] I> Binary(14) of size 366000 is loaded @ 0x8530f600
[0142.593] I> TOS boot-params @ 0x85000000
[0142.596] I> TOS params prepared
[0142.600] I> Loading EKS ...
[0142.603] I> Binary(15) of size 1040 is loaded @ 0x8590f800
[0142.608] I> EKB detected (length: 0x400) @ 0x8590f800
[0142.613] I> Copied encrypted keys
[0142.617] I> boot profiler @ 0x275844000
[0142.621] I> boot profiler for TOS @ 0x275844000
[0142.626] I> Unhalting SCE
[0142.628] I> Primary Memory Start:80000000 Size:70000000
[0142.634] I> Extended Memory Start:f0110000 Size:1856f0000
[0142.640] I> MB2(TBoot-BPMP) Recovery done
NOTICE: BL31: v1.3(release):41d46a9cf
NOTICE: BL31: Built : 21:14:44, Jun 25 2020
ipc-unittest-main: 1519: Welcome to IPC unittest!!!
ipc-unittest-main: 1531: waiting forever
ipc-unittest-srv: 329: Init unittest services!!!
hwkey-agent: 40: hwkey-agent is running!!
hwkey-agent: 182: key_mgnt_processing .......
hwkey-agent: 157: Init hweky-agent services!!
platform_bootstrap_epilog: trusty bootstrap complete
Something changed, I got the same serial port message above about trusty bootstrap complete and hung at the tegrarcm_v2 --isapplet location trying to flash Jetpack 4.4 with Jetpack 4.3 bootloader as well. The change happened after I successfully programed rel-28.4 and then failed to program JP 4.4 with only P3310_A00_8GB_lpddr4_A02_l4t.cfg copied from JP 4.3
I re-flashed JP 4.3 successfully, and booted this once, then retried the JP 4.4 based upload script with both P3310_A00_8GB_lpddr4_A02_l4t.cfg and tegra186-a02-bpmp-quill-p3310-1000-a00-00.dtb copied from JP 4.3. I reproduced the same state again on the serial port
[0187.534] I> Welcome to MB2(TBoot-BPMP) Recovery(version: 01.00.160913-t186-M-00.00-mobile-82dac681)
[0187.543] I> bit @ 0xd480000
[0187.546] I> Boot-device: eMMC
[0187.735] I> sdmmc DDR50 mode
[0187.740] I> sdmmc bdev is already initialized
[0187.744] I> pmic: reset reason (nverc) : 0x80
[0187.751] I> Found 18 partitions in SDMMC_BOOT (instance 3)
[0187.758] I> Found 33 partitions in SDMMC_USER (instance 3)
[0187.767] I> Binary(16) of size 533504 is loaded @ 0xd7800000
[0187.776] I> Binary(17) of size 604720 is loaded @ 0xd796c5c0
[0188.006] I> Copy BTCM section
[0188.010] I> Binary(13) of size 220912 is loaded @ 0x96000000
[0188.018] I> Binary(20) of size 371424 is loaded @ 0x8520f400
[0188.025] I> Binary(14) of size 366000 is loaded @ 0x8530f600
[0188.033] I> TOS boot-params @ 0x85000000
[0188.037] I> TOS params prepared
[0188.040] I> Loading EKS ...
[0188.043] I> Binary(15) of size 1040 is loaded @ 0x8590f800
[0188.049] I> EKB detected (length: 0x400) @ 0x8590f800
[0188.054] I> Copied encrypted keys
[0188.057] I> boot profiler @ 0x275844000
[0188.061] I> boot profiler for TOS @ 0x275844000
[0188.066] I> Unhalting SCE
[0188.069] I> Primary Memory Start:80000000 Size:70000000
[0188.074] I> Extended Memory Start:f0110000 Size:1856f0000
[0188.081] I> MB2(TBoot-BPMP) Recovery done
NOTICE: BL31: v1.3(release):41d46a9cf
NOTICE: BL31: Built : 21:14:44, Jun 25 2020
ipc-unittest-main: 1519: Welcome to IPC unittest!!!
ipc-unittest-main: 1531: waiting forever
ipc-unittest-srv: 329: Init unittest services!!!
hwkey-agent: 40: hwkey-agent is running!!
hwkey-agent: 182: key_mgnt_processing .......
hwkey-agent: 157: Init hweky-agent services!!
platform_bootstrap_epilog: trusty bootstrap complete
So I still don’t have a solution other than replacing the entire bootloader directory, and even that solution doesn’t work after I fail to program the JP 4.4 release after replacing a smaller subset of files, until I completely reprogram with JP 4.3.
Today I tried to prove I could reproduce this observation on meta-tegra and yocto layers.
I started with GitHub - OE4T/tegra-demo-distro at dunfell-l4t-r32.4.3 and reproduced the issue.
I then wrote a script which copied all files in the tegraflash directory with their bootloader components from the JP4.3 stock nvidia install:
#!/bin/bash
sourcebldir=~/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra_original/bootloader
sourcetegraflash=core-image-minimal.tegraflash.tar.gz
targetflash=tegraflash-fun
pushd `dirname $0`
mkdir $targetflash
tar -C ${targetflash} -xvf ${sourcetegraflash}
for file in $targetflash/*
do
blfile=${file#*/}
blfilename=$(basename $blfile)
sourcefile=$(find ${sourcebldir} -name ${blfilename} | head -n 1)
if [ ! -z "$sourcefile" ]; then
echo "replacing bootloader file ${blfile} with content at ${sourcefile}"
cp -r ${sourcefile} ${file}
if [ $? -ne 0 ]; then
echo "Error copying ${sourcefile} to ${blfile}"
exit 1
fi
else
echo "${blfile} does not exist in ${sourcebldir}"
fi
done
This, surprisingly, still failed. Which left me with this list of files which were not modified (because they weren’t matching files in the stock JP 4.3 bootloader) at least one of which must also be required to swap out with JP4.3 versions:
jetson-tx2.cfg
doflash.sh
flashvars
flash.xml.in
generate_bup_payload.sh
nvflashxmlparse
odmsign.func
tegra186-flash-helper.sh
tegrakeyhash
I then built a zeus core-image-minimal here: GitHub - BoulderAI/tegra-demo-distro at zeus-l4t-r32.3.1
I could successfully program this one, as expected.
Starting with the first file in this list jetson-tx2.cfg, and replacing that one with the one from zeus and JP 4.3, along with the other changes from the bootloader directory, was all I need to resolve the issue.
I then went back and tried replacing only the jetson-tx2.cfg file with the one from JP4.3 and leave all other boot files alone. This gets me back to this serial port message:
NOTICE: BL31: v1.3(release):41d46a9cf
NOTICE: BL31: Built : 21:14:44, Jun 25 2020
ipc-unittest-main: 1519: Welcome to IPC unittest!!!
ipc-unittest-main: 1531: waiting forever
ipc-unittest-srv: 329: Init unittest services!!!
hwkey-agent: 40: hwkey-agent is running!!
hwkey-agent: 182: key_mgnt_processing .......
hwkey-agent: 157: Init hweky-agent services!!
platform_bootstrap_epilog: trusty bootstrap complete
So it looks like I need some combination of the changes from the JP 4.3 bootloader for at least some subset of these files
plus the change to the .cfg file (which correspond to P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg), with working version here and failing version here. It looks like the config file changes are all related to adding the SDRAM[3] section added for P3310_A00_8GB_Micron_8GB_lpddr4_204Mhz_P138_A02.cfg.
Remaining questions I have:
- Is using this list of bootloader files from Jetpack 4.3 with Jetpack 4.4 rootfs a valid thing to do? Or will a mismatch between these bootloader components and a Jetpack 4.4 rootfs cause problems?
- Do you have any suggestions about how I could support D02 rev SOMs, or what might be different about our custom carrier board hardware which might explain why the bootloader software and configuration changes to support D02 rev SOMs are causing problems with D00 rev SOMs?
Hi,
I then went back and tried replacing only the jetson-tx2.cfg file with the one from JP4.3 and leave all other boot files alone.
Do you mean if you using jetpack 4.4 BSP and replace only jetson-tx2.conf file from jetpack4.3 can push the device start to flash with no MTS error?
I don’t get an MTS error, but tegraflash fails in the same spot in the host log
[ 8.2074 ] Sending bootloader and pre-requisite binaries
[ 8.2099 ] tegrarcm_v2 --download blob blob.bin
[ 8.2118 ] Applet version 01.00.0000
[ 8.2312 ] Sending blob
[ 8.2316 ] [................................................] 100%
[ 8.7317 ]
[ 8.7358 ] tegrarcm_v2 --boot recovery
[ 8.7395 ] Applet version 01.00.0000
[ 8.7598 ]
[ 9.7704 ] tegrarcm_v2 --isapplet
And serial port shows
NOTICE: BL31: v1.3(release):41d46a9cf
NOTICE: BL31: Built : 21:14:44, Jun 25 2020
ipc-unittest-main: 1519: Welcome to IPC unittest!!!
ipc-unittest-main: 1531: waiting forever
ipc-unittest-srv: 329: Init unittest services!!!
hwkey-agent: 40: hwkey-agent is running!!
hwkey-agent: 182: key_mgnt_processing .......
hwkey-agent: 157: Init hweky-agent services!!
platform_bootstrap_epilog: trusty bootstrap complete
So it looks like I need some combination of the changes from the JP 4.3 bootloader for at least some subset of these files
Through process of elimination I was able to narrow down to only this file: tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb. So if I replace only this file and P3310_A00_8GB_lpddr4_A02_l4t.cfg I’m able to tegraflash successfully on my carrier board using D00 SOMs.
I converted both dtb files to dts for analysis using dtc.
Here’s the working version of tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb in dts format from JP 4.3: link
Here’s the failing version of tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb in dts format from JP 4.4: link
There are quite a few changes between them. Any suggestions about a difference which might explain the behavior I see with failure to tegraflash? Any suggestions about a change I could make which could fix this problem and still allow me to use D02 SOMs?
My solution for the interim will be to completely replace this file so I can get D00 SOMs tegraflashed.
One other question: Should I be concerned about using the JetPack 4.3 version of tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb with Jetpack 4.4 rootfs content as a solution for this issue?
I may have answered my own question. I’m noticed a kernel oops on a few different devices when booting up with this change, at least with D00 SOMs. See this link
This entire issue seems to be related to the fact that we’ve got a pullup on UART1_RTS, violating note 2 of table 83 of the design guide. I’ve proven that if I cut the trace on the UART1_RTS pin I’m able to program and run on JP 4.4 without issue.
The emc-strap settings in 
jp4.4-tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dts between JP 4.3 and JP 4.4 went from:
emc-strap {
select = <0x9 0xa 0xb 0x0>;
};
in JP 4.3 to
emc-strap {
select = <0x9 0xa 0xb 0xc>;
};
in JP 4.4
which adds a 4th option for memory (see this comment which explains how it’s mapped with phandle)
So I suspect because JP4.4 defines an option for the 4th strapping location and because we are pulling UART RTS up, we now select the wrong RAM part on bootup. A hardware fix option is to cut the trace on the UART RTS pin or depopulate a part and I’ve verified this works.
Alternatively, based on the content here it looks like we could redefine the emc-strap entry to populate with the correct device regardless of pin level.
I think this would mean, however, that we might have a future revision of SOM which doesn’t work correctly anymore because it requires this strapping pin to select the correct RAM device. So in that case we’d need to have custom dtb files we use to support different SOM revisions. Am I understanding this correctly?
1 Like
Hi,
that we might have a future revision of SOM which doesn’t work correctly anymore because it requires this strapping pin to select the correct RAM device.
Do you mean future version SOM (D02) + current design of your carrier board? If so, then the answer is yes.
The emc-strap adding in rel-32.4.3 is actually for PCN206440. We have to support a new dram so add one table inside as the 0xc one.
Thus, I would suggest this issue to be fixed from carrier board hardware design part (the pulling UART RTS).
“Alternatively, based on the content here it looks like we could redefine the emc-strap entry to populate with the correct device regardless of pin level.”
Above conclusion is right. If you know what is the DDR connected in your device.
The emc-strap adding in rel-32.4.3 is actually for PCN206440. We have to support a new dram so add one table inside as the 0xc one. Thus, I would suggest this issue to be fixed from carrier board hardware design part (the pulling UART RTS).
We will definitely fix on the carrier board. However, I want to understand the exposure for carrier boards which are already deployed with earlier revision SOMs. I’m curious why we haven’t noticed this problem on rev B SOMs for instance. I would have expected the fact that r32.4.3 defined this new table entry and the strapping pin for UART RTS was pulled high would mean the wrong SOM would be selected on rev B SOM and we’d have similar boot or tegraflash problems on these versions. However thus far we’ve only noticed this problem on rev D00 SOMs and rev B SOMs appear to work properly with r32.4.3. Do you have a way to explain this? The main thing I’d like to understand is the list of scenarios where we’ll notice problems upgrading across L4T revisions with already deployed hardware and SOM revisions before D00.
In this case, it means if I know which revision SOM is in use, correct? Is there a way to query the SOM revision from running software (outside tegraflash)?
If so, I could use the information about the current SOM version at runtime to tweak the emc-strap for deployed hardware.
with end of life for existing ddr in mind, we keep adding new ddr support.
My comment makes sense only when some vendor is changing the ddr in CVM.
TX2 product design guide is having the info about uart pins used for ramcode.
https://developer.nvidia.com/embedded/dlc/jetson-tx2-series-oem-product-design-guide
check the guide and may be you can do some modification in your design to make it work.
Thanks @Bibek , this references the table on page 85 which is a newer version of the one I linked above but has essentially the same content, and states that we need hardware changes for UART0_RTS to prevent violating strapping requirements. This is understood and we will definitely make those changes.
What I’d still like to understand is what the exposure will be for existing deployed devices which will be difficult/impossible to rework (especially those with SOM revisions earlier than D00, and especially with SOM B revisions) across L4T upgrades and what, if anything, I could do in software to detect this scenario and correct it using a modified emc-strap. I think the main thing I need to know is if there is a way to reliably query the SOM revision (or anything else I can tie to DRAM version) from software running on the device and outside tegraflash. As mentioned, I also don’t completely understand how our current B0 SOMs are working on JP 4.4 and r32.4.3 with the wrong pin strap settings, so if anyone could explain this based on what they know about B0 SOMs this would likely help understand the urgency of a software workaround like the one described above.