It looks like there is no clock privided for EMC module but TX2 Module DataSheet says “The Jetson TX2 requires no external clocks for operation, all system clocks are generated within the module”
Does anyone experience the same issue?
Do I miss something and do you have any suggestion to make it work?
Could we find the docs for Terga clock, isomgr sybsystem?
nvidia@tegra-ubuntu:~$ sudo cat /sys/kernel/debug/bpmp/debug/clk/emc/rate
0
nvidia@tegra-ubuntu:~$ sudo cat /sys/kernel/debug/bpmp/debug/emc/possible_rates
cat: /sys/kernel/debug/bpmp/debug/emc/possible_rates: No such file or directory
Could you let me know where DVFS is stored? (eg. in EEPROM on Dev Kit or TX2 module?)
The same TX2 module works on Dev Kit but not on our carrier board.
Please find the attached for flashing/booting logs
I just concern about whether MB1/MB2/ATF/Cboot are generic enough or rely on some components on Dev Kit (Eg. I2C devices, GPIOs,…) that are reduced on our custom carrier board.
Only MB1 cfg files and kernel dt files are platform dependent.
Can you try making the following change and provide new logs.
since your platform does not have the expander i2c slave @ 0x74. can you remove all instances of it from kernel dt. Just add the below lines to kernel final dts and rebuild the dtb. Replace the new dtb to Linux_for_Tegra/kernel/dtb/ folder
File: tegra186-quill-p3310-1000-c03-00-base.dtb
I want to see BPMP logs for emc issue. Make below change to bpmp dtb and reflash
File: tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb from Linux_for_Tegra/bootloader/ folder
convert to dts :
dtc -I dtb -O dts tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb > tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dts
Make the change here:
serial {
- port = <0x00000007>;
+ port = <0x000000ff>;
has_input;
};
And then flash. After kernel boots.
cat /dev/ttyBPMP0 > bpmp.log
share boot log and bpmp.log
Now my next question is:
What are you doing with these two pins coming out of Jetson TX2 connector, in your custom base board?
Pin Name Ball number
UART0_RTS G11
UART1_TX D9
Value on these two pins decide the pin strap. Its recommended to not use these two pins.
Thank you for your information.
The EMC module is now working on our carrier board after isolating UART0_RTS and UART1_TX. These 2 pins are connected to a multiplexer on our carrier board that causes unexpected value for EMC pin strap detection.
We assume these pins are used for serial console only.
In my opinion, the UART pins should not be used as pin strap (dedicated GPIOs instead, I think).
By the way, Could you please share where we can find the official documentation for TX2 pin strap?
Could someone explain in a little more detail how to resolve this issue?
I also have this issue where emc_min/max/rate read as zero on a custom carrier, and memory performance is terrible (apparently the zero value means “really slow”). I am using an auvidea J100 board, which breaks out UART0 and UART1 to connectors (including G11 and D9).
What do I need to do with those pins to bring back the EMC clock settings?
The J100 carrier has level shifters to bring out UART0, UART1 and UART2 at 3.3V. The level shifters must be pulling these pins and causing the EMC misconfiguration.
I could sever the traces to fix this, but that would sacrifice precious I/O, we rely on the UARTs for sensor inputs.
Is there any way to reconfigure the TX2 to use different pins for the strapping procedure?
This is an off-the-shelf carrier, the level shifters seem to be powered with everything else.
TX2 brings out 5 UARTs, TX1 only 3. So a board designed to use TX1 UARTs can’t just take a TX2 as a drop-in replacement without a hardware revision. Just some dashed hopes of being able to upgrade quickly.