Continuing the discussion from Patch for Jetson AGX Orin 32GB Incorrect number of CPU Core :
Hello, I adjusted according to the operation of the article here, and an error was reported after reflashing the system.
Does it make a difference? Or is there a way to fix this error?
Are you still using rel-35.1? Please at least upgrade your BSP.
Yes, still using R35.1.
It’s a custom board. Can I upgrade the version directly from the system? In this way, there is no need to do functional adaptation.
No, you will just crash your board. Functional adaptation is must have.
OK. However, the way to patch is to operate on R35.1 and want to solve it on R35.1.
Sorry, we don’t debug on old BSP. Please just upgrade BSP.
I want to mention that if your customization is a device tree change, then there is a good chance that using that tree on the most recent R35.x would do the job if you know which one it is and can place it on the host PC at the correct location. You could also clone your R35.1 to have a copy of what is installed for future reference (beware that it uses a huge amount of disk space…you get one raw clone the size of the partition, and one sparse clone which is the size of all of the content in the partition). It isn’t a guarantee that the device tree is the only change, but it would give you a chance.
Not only did I change the device tree, but I made some major changes.
I have tried to update to R35.3.1 or R35.4.1, but there will be an error in the process of reflashing the system, so I did not do the adaptation of the custom board.
Like this:
Read this:
Q: How do I know which Jetson Linux release I am using?
Please execute the command to get information:
$ cat /etc/nv_tegra_release
# R35 (release), REVISION: 1.0, GCID: 31346300, BOARD: t186ref, EABI: aarch64, DATE: Thu Aug 25 18:41:45 UTC 2022
If you see R34, the release is developer preview, and please upgrade to at least >= r35.1
Q: How to know if I use Orin developer kit or Orin 32GB module?
Please execute the command:
$ cat /etc/nv_boot_control.conf
And check the information:
[Orin d…
→ Q: I get a USB timeout error during flash Orin. How to resolve that?
不是same error. 卡住的地方不一樣了
只是你看起來都是timeout in usb write. 請你抓燒機時的uart log.
20231115-101703-R3541-flash.log (9.5 KB)
这是烧录R35.4.1时的log,麻烦帮忙看下,谢谢。
請問這個還是custom board嗎? 能把你host端燒錄log也分享一下嗎?
這個error是典型的燒錯板子config的狀況.
这是custom board。底板之前刷R35.1没有问题。
好的,这是host端的log。
R3541-flashfailed.log (73.8 KB)
請問你那邊有nv devkit可以燒這片module然後抓uart log嗎?
那請你試試看35.2.1之類的能不能燒 , 能的話請抓一下uart log
35.2.1可以刷,这是uart log。
20231115-115254-R3521-debug.log (126.6 KB)
Hi,
現在看起來問題是在這
rel-35.2.1的時候DRAM config是從 MEM-BCT-0
[0278.659] I> get_binary_info: Binary name: MEM-BCT-0
[0278.664] I> Size of crypto header is 8192
[0278.668] I> BCH load address is : 0x40050000
[0278.672] I> Size of crypto header is 8192
[0278.680] I> BCH of MEM-BCT-0 read from storage
[0278.684] I> BCH address is : 0x40050000
[0278.688] I> MEM-BCT-0 header integrity check is success
[0278.693] I> Binary magic in BCH component 0 is MEM0
[0278.698] I> component binary type is 0
[0278.704] I> MEM-BCT-0 binary is read from storage
[0278.709] I> MEM-BCT-0 binary integrity check is success
[0278.714] I> Binary MEM-BCT-0 loaded successfully at 0x40040000 (0xe580)
[0278.720] I> RAM_CODE 0x4000031
[0278.726] I> RAM_CODE 0x4000031
rel-35.4.1的時候DRAM config是從一個錯的地方 MEM-BCT-2 讀出來
[0285.200] I> RAM_CODE 0x4000081
[0285.203] I> Loading MEMBCT
[0285.205] I> Slot: 0
[0285.207] I> Binary[2] block-0 (partition size: 0x40000)
[0285.213] I> Binary name: MEM-BCT-2
[0285.216] I> Size of crypto header is 8192
[0285.220] I> Size of crypto header is 8192
[0285.238] I> BCH of MEM-BCT-2 read from storage
[0285.242] I> BCH address is : 0x40050000
[0285.246] I> MEM-BCT-2 header integrity check is success
[0285.252] I> Binary magic in BCH component 0 is MEM2
[0285.256] I> component binary type is 2
[0285.262] I> MEM-BCT-2 binary is read from storage
[0285.267] I> MEM-BCT-2 binary integrity check is success
[0285.272] I> Binary MEM-BCT-2 loaded successfully at 0x40040000 (0xe580)
[0285.279] I> RAM_CODE 0x4000081
[0285.284] I> RAM_CODE 0x4000081
[0285.288] I> Task: Load Page retirement list
[0285.292] I> Task: SDRAM params override
[0285.296] I> Task: Save mem-bct info
[0285.299] I> Task: Carveout allocate
[0285.303] I> Update CCPLEX IST carveout from MB1-BCT
[0285.307] I> ECC region[0]: Start:0x0, End:0x0
[0285.312] I> ECC region[1]: Start:0x0, End:0x0
[0285.316] I> ECC region[2]: Start:0x0, End:0x0
[0285.320] I> ECC region[3]: Start:0x0, End:0x0
[0285.324] I> ECC region[4]: Start:0x0, End:0x0
[0285.329] I> Non-ECC region[0]: Start:0x80000000, End:0x80000000
[0285.335] I> Non-ECC region[1]: Start:0x0, End:0x0
[0285.339] I> Non-ECC region[2]: Start:0x0, End:0x0
[0285.344] I> Non-ECC region[3]: Start:0x0, End:0x0
[0285.349] I> Non-ECC region[4]: Start:0x0, End:0x0
[0285.360] E> BL_CARVEOUT: Failed to allocate memory of size 0x36800000 for CO:44.
由於RAM code預設是從硬體讀出來 而且rel-35.4.1是最新的BSP.
現在這個狀況就還是回到得用devkit驗證你這顆module的DRAM config到底要從config幾讀出來
我手上有另一块可以刷R35.4.1的底板,也是custom board。
这是它烧录时的uart log:
20231115-143222-R3541-rtso-debug.log (112.3 KB)
从这里看好像是也是MEM-BCT-0。
如果是这部分差异,应该从哪修改呢?