Workaround for RAM_CODE strapping issue?

I have a custom carrier board which has strapping problems with RAM_CODE. UART0_RTS was left floating, so I believe that should be correct. UART1_TX was sent to a level translator, which has an internal pullup. This is causing the below issue on boot:

[    3.235248] ------------[ cut here ]------------
[    3.235252] WARNING: at ffffffc00086f850 [verbose debug info unavailable]
[    3.235258] Modules linked in:
[    3.235259] I am pretty skeptical on that toshiba thing working. F
[    3.235270] CPU: 5 PID: 149 Comm: kworker/u12:3 Tainted: G        W       4.4.38-tegra #1
[    3.235272] Hardware name: quill (DT)
[    3.235303] Workqueue: events_unbound async_run_entry_fn
[    3.235305] task: ffffffc1ea99d780 ti: ffffffc1e6088000 task.ti: ffffffc1e6088000
[    3.235321] PC is at __tegra_isomgr_register+0x30c/0x4d4
[    3.235324] LR is at __tegra_isomgr_register+0x30c/0x4d4
[    3.235327] pc : [<ffffffc00086f850>] lr : [<ffffffc00086f850>] pstate: 80000045
[    3.235329] sp : ffffffc1e608ba70
[    3.235333] x29: ffffffc1e608ba70 x28: 0000000000000460 
[    3.235337] x27: ffffffc001467000 x26: ffffffc0013a7000 
[    3.235340] x25: ffffffc000c2d000 x24: 0000000000000000 
[    3.235343] x23: 0000000000000000 x22: 000000000000000a 
[    3.235346] x21: 0000000000014000 x20: ffffffc001467718 
[    3.235349] x19: ffffffc001467bd8 x18: ffffffc000baa0e0 
[    3.235351] x17: 000000000000000e x16: ffffffc000b38a60 
[    3.235353] x15: ffffffc000b38a60 x14: ffffffc000b38a60 
[    3.235358] x11: 0000000000000000 x10: ffffffc001400e88 
[    3.235361] x9 : ffffffc1e608b910 x8 : 206d6f726620424b 
[    3.235363] x7 : 3032343936373420 x6 : ffffffc001401838 
[    3.235365] x5 : 000000000601c525 x4 : 0000000000000000 
[    3.235367] x3 : 0000000000000000 x2 : 0000000000000000 
[    3.235370] x1 : 0000000000000000 x0 : 0000000000000031 
[    3.235370] 
[    3.235374] ---[ end trace 2e64859adabeb6a6 ]---
[    3.235378] Call trace:
[    3.235381] [<ffffffc00086f850>] __tegra_isomgr_register+0x30c/0x4d4
[    3.235385] [<ffffffc00086fa34>] tegra_isomgr_register+0x1c/0x2c
[    3.235400] [<ffffffc000688a84>] eqos_probe+0xad0/0x11c4
[    3.235412] [<ffffffc00056a28c>] platform_drv_probe+0x50/0xbc
[    3.235422] [<ffffffc000567d1c>] driver_probe_device+0xc8/0x408
[    3.235425] [<ffffffc0005680f8>] __driver_attach+0x9c/0xa0
[    3.235428] [<ffffffc000565d98>] bus_for_each_dev+0x58/0x98
[    3.235432] [<ffffffc0005677c4>] driver_attach+0x20/0x28
[    3.235436] [<ffffffc000566254>] driver_attach_async+0x14/0x50
[    3.235439] [<ffffffc0000c4264>] async_run_entry_fn+0x44/0x180
[    3.235449] [<ffffffc0000bbc24>] process_one_work+0x154/0x434
[    3.235452] [<ffffffc0000bc038>] worker_thread+0x134/0x40c
[    3.235457] [<ffffffc0000c18c8>] kthread+0xe0/0xf4
[    3.235467] [<ffffffc000084f90>] ret_from_fork+0x10/0x40
[    3.235468] __tegra_isomgr_register(): ISO BW usage:
[    3.235470] __tegra_isomgr_register(): client=disp_0, iso dedi bw=0KB
[    3.235472] __tegra_isomgr_register(): client=disp_1, iso dedi bw=0KB
[    3.235474] __tegra_isomgr_register(): client=disp_2, iso dedi bw=0KB
[    3.235476] __tegra_isomgr_register(): client=isp_a, iso dedi bw=0KB
[    3.235480] __tegra_isomgr_register(): client=tegra_camera_ctrl, iso dedi bw=4687500KB
[    3.235483] __tegra_isomgr_register(): client=ape_adma, iso dedi bw=0KB
[    3.235485] __tegra_isomgr_register(): client=eqos, iso dedi bw=81920KB
[    3.235487] __tegra_isomgr_register(): revisit BW usage of iso clients

Which results in the below issue:

root@tegra-ubuntu:~# cat /sys/kernel/debug/tegra_bwmgr/emc_max_rate 
0
root@tegra-ubuntu:~# cat /sys/kernel/debug/tegra_bwmgr/emc_min_rate 
0
root@tegra-ubuntu:~# cat /sys/kernel/debug/tegra_bwmgr/emc_rate
0
root@tegra-ubuntu:~# cat /sys/kernel/debug/bpmp/debug/clk/emc/rate
0
root@tegra-ubuntu:~# cat /sys/kernel/debug/bpmp/debug/emc/possible_rates
cat: /sys/kernel/debug/bpmp/debug/emc/possible_rates: No such file or directory

This leads to me being unable to use peripherals like cameras on the carrier board.

I tried to modify P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg and make SDRAM[0] the same as SDRAM[2] (basically deleted SDRAM[0], copied SDRAM[2], and changed the copied SDRAM[2] to be [0]), but had the same problem after flashing.

Can someone please suggest a workaround? Such as how to properly modify P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg in this case?

Or am I reading this backwards, and UART1_TX is for selecting the boot device? In which case, what file / changes do I need to make to make the BCT boot device selection the same regardless of the pin strapping? Or am I screwed here?

Please help!

Full boot log is attached.
full_boot_log.log (87.3 KB)

hello jrestifo,

you should not edit that memory config file, these’s also a description about why not to modify that.
could you please confirm everything works normally with the default settings. thanks

I edited it to make them all the same because I thought this design was modifying RAM_CODE0, but it actually was modifying RAM_CODE1. Modifying the emc-strap node in my device tree resolved this particular issue. Thanks