Hi timonske,
Any udpate?
Hi Wayne,
I’ve gotten a bit sick from my trip to Hackaday Supercon but I’ve captured a boot log on the Auvidea carrier and it spat out similar errors about EEPROM, I can’t say for sure if they are not using an EEPROM for the board ID as it seems those errors are mostly about the Ethernet MAC EEPROM.
Right now I’m not really sure what to do at this point.
Edit: Actually one more thing I checked, the pinmux for the 2 HPD pins is the same for A02 and B01.
Now because there are no schematics for the actual module I can’t say if this is correct or not as it depends on whether those pins switched physical position too or if they are still on the same pad and the definition was just supposed to change in software.
timonske,
I have asked our HW engineer to help check.
Are you able to paste your schematic here?
Hi timonske,
Did you measure the HPD level to check if it will change when device plug in?
Hi, see the first post attachment for schematics.
I checked DP HPD level and it acts as expected. HDMI is sitting at a weird 0.6-0.8v which made me believe that it is currently mapped to a different pin that sits at a different voltage, explains the intermittent connects and disconnects in the log.
HPD level shift circuit worked correctly in older revisions as well.
Hi timonske,
For the HDMI issue, I think we find something worth trying.
Please refer to this comment and modify the xbar too.
https://devtalk.nvidia.com/default/topic/1066993/jetson-nano/hdmi-is-not-working/post/5405494/#5405494
I will try that but I’m not sure if that would help? Right now the HPD is preventing anything from working not the signal lanes.
Can we maybe verify that the HPD pins as defined by the default pinmux are mapping to the correct pins on the SoM connector? I can’t verify this myself without information about the CPU pins used and the schematic of the SoM.
Hi timonske,
Ok, sorry again. Then I think your case is still far from changing xbar.
We got another user who also uses the same pinmux and he can see the HPD level change on his board.
Though his case is HDMI only.
https://devtalk.nvidia.com/default/topic/1066993/jetson-nano/hdmi-is-not-working/1
I just go through your posts here. Actually, it is really weird that you hotplug the DP cable but the driver of HDMI gets response.
Could you do below test and share us the log?
-
Disable tegradc.0 in your device tree and flash it #disable DP driver
-
Check the dmesg. If it is really disabled, then there should be no tegradc.0 in log.
If the log is still there, please check the node /proc/device-tree/tegradc.0/status to see if it is really disabled. -
Then try to hotplug the HDMI cable and share the dmesg with us.
I don’t get tegradc in /proc/device-tree. The only thing that sound somewhat related is extcon/extcon@0 whose status is 0. extcon/extcon@1 for some reason doesn’t even has a status. Though not sure if that is even related.
tegradc.0 still shows up in dmesg after setting it do disabled.
I tried modifying this entry
/* tegradc.0 /
dc@54200000 {
status = “disabled”;
nvidia,dc-flags = <TEGRA_DC_FLAG_ENABLED>;
nvidia,emc-clk-rate = <300000000>;
nvidia,cmu-enable = <1>;
nvidia,fb-bpp = <32>; / bits per pixel */
nvidia,fb-flags = <TEGRA_FB_FLIP_ON_PROBE>;
nvidia,dc-or-node = “/host1x/sor1”;
nvidia,dc-connector = <&sor1>;
};
in Linux_for_Tegra\sources\hardware\nvidia\platform\t210\porg\kernel-dts\tegra210-porg-p3448-common.dtsi
I compiled and then copied tegra210-p3448-0002-p3449-0000-b00.dtb over to the SoM and replaced the two occurrences of the file in /boot and /boot/dtb
Again I’m new to the whole device tree setup, is that correct or is there any more steps to update the device tree?
Edit: Ok just realised that the path set in the DT entry (“/host1x/sor1”) is where I needed to look. There “dc@54200000” has status “okay”. So I guess I did something wrong.
Though when I look at the dtb file with dtc it says “status = disabled” in the entry for dc@54200000.
I also tried disabling sor1 but that made no difference.
Hi timonske,
Sorry for my mistake. It should be under host1x.
And DTB is not like Image file which could be updated by putting into /boot.You need to replace it under Linux_for_Tegra/kernel/dtb and reflash it with “sudo ./flash.sh -r -k DTB mmcblk0p1”
I replaced the dtb file in that folder with mine and flashed it with the latest L4T release with “sudo ./flash.sh -r -k DTB p3448-0000 mmcblk0p1”
It seems to have flashed successful but nothing changed unfortunately tegradc.0 still shows up. Anything else I might be missing?
yes, I suspect you modify the wrong dtb.
Please make sure what you modified is same as the one flashed to your board. During the flash process, the flash log shall tell you the dtb name that is sent to jetson nano.
BTW, another forum user already had working HDMI on his board and he didn’t need to change the pinmux.
It does seem to use the correct file. I attached my flash log and the boot log after flashing. I also tried with the jetson-nano-emmc.conf but no difference.
When in recovery mode the debug UART prints “A02 Bootrom Patch rev = 1023” is that supposed be like that and not be “B0”?
I also tried again with the rootfs in place but the only difference in the log is that it copies that last .xml file that was not found before.
Edit: Something a friend noticed. Shouldn’t dc.1 define “sor” and not “sor0”? Or the other way that “sor” should be named “sor0”.
It says
nvidia,dc-connector = <&sor0>;
but the corresponding sor entry is just called sor without a 0
sor {
status = "okay";
nvidia,xbar-ctrl = <2 1 0 3 4>;
dp-display {
status = "okay";
};
};
flashlog-29.11.19.log (3.84 KB)
bootlog-after-dtb-flash.log (70.2 KB)
Hi timonske,
When in recovery mode the debug UART prints “A02 Bootrom Patch rev = 1023” is that supposed be like that and not be “B0”?
This is not an error. You should see this line even on emmc module + carrier board too.
Edit: Something a friend noticed. Shouldn’t dc.1 define “sor” and not “sor0”? Or the other way that “sor” should be named “sor0”.
Again, this is not an error. This is a trick in device tree which uses alias to represent the actual node.
You could check below file which defines sor0.
soc/t210/kernel-dts/tegra210-soc/tegra210-soc-base.dtsi
sor0: sor {
compatible = "nvidia,tegra210-sor";
reg = <0x0 0x54540000 0x0 0x00040000>;
reg-names = "sor";
status = "disabled";
nvidia,sor-ctrlnum = <0>;
nvidia,dpaux = <&dpaux0>;
nvidia,xbar-ctrl = <2 1 0 3 4>;
clocks = <&tegra_car TEGRA210_CLK_SOR_SAFE
There is a quick way to check whether your dts is updated correctly… as I previously pointed out, just check the nodes under /proc/device-tree. If you updated something in dtb but it is still the old value under these nodes, then it means the flash is not successful.
I just checked your flash log and it didn’t go through flash process…
Board ID(3448) version(400)
copying bctfile(/home/timon/Linux_for_Tegra/bootloader/t210ref/BCT/P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg)... done.
copying bootloader(/home/timon/Linux_for_Tegra/bootloader/t210ref/cboot.bin)... done.
copying initrd(/home/timon/Linux_for_Tegra/bootloader/l4t_initrd.img)... done.
populating kernel to rootfs... done.
populating initrd to rootfs... done.
populating /home/timon/Linux_for_Tegra/kernel/dtb/tegra210-p3448-0002-p3449-0000-b00.dtb to rootfs... done.
Making Boot image... done.
Existing sosfile(/home/timon/Linux_for_Tegra/bootloader/nvtboot_recovery.bin) reused.
copying tegraboot(/home/timon/Linux_for_Tegra/bootloader/t210ref/nvtboot.bin)... done.
copying cpu_bootloader(/home/timon/Linux_for_Tegra/bootloader/t210ref/cboot.bin)... done.
copying bpffile(/home/timon/Linux_for_Tegra/bootloader/t210ref/sc7entry-firmware.bin)... done.
Existing badpagefile(/home/timon/Linux_for_Tegra/bootloader/badpage.bin) reused.
copying wb0boot(/home/timon/Linux_for_Tegra/bootloader/t210ref/warmboot.bin)... done.
Existing tosfile(/home/timon/Linux_for_Tegra/bootloader/tos-mon-only.img) reused.
Existing eksfile(/home/timon/Linux_for_Tegra/bootloader/eks.img) reused.
copying dtbfile(/home/timon/Linux_for_Tegra/kernel/dtb/tegra210-p3448-0002-p3449-0000-b00.dtb)... done.
Copying nv_boot_control.conf to rootfs
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can't read /home/timon/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
Reusing existing system.img...
file does not exist.
Could you share how did you get this “Linux_for_Tegra”? From sdkmanager? What is the flash command you are using?
I got it from the download page here: https://developer.nvidia.com/embedded/linux-tegra
I downloaded “L4T Driver Package (BSP)”
I also downloaded from the same site the “Sample Root Filesystem” and placed it into the rootfs folder.
I synced the sources with the provided script.
-
Did you ever run the script apply_binaries.sh after you copy the sample rootfs to rootfs folder?
-
Please note that your flash process did not start at all. It just stopped before flashing…
If you still get stuck on this and cannot resolved, please just use sdkmanager and it would download Linux_for_Tegra under your home directory too. Don’t need to spend too much time on this. We should just focus on your original topic.
I did not not know you have to run that script. Is there maybe a guide about this setup that I might be missing?
I ran this, while it didn’t work initially it did now after fiddling around and running it again.
Though I had to ommit the “-r” flag to make it work. It does seem that the flash was successful and I don’t get any more DC.1 messages.
Unfortunately I’m traveling atm and only got the third party dev kit with me. I will test again on my own carrier and post the boot log of that.
I booted with my carrier now. I attached 2 logs. One where I did not attached DP and one where I had it attached since boot and then after it finished booting I did a hot plug by removing the cable and then plugging it back in.
This triggered something but no LT initiated or anything.
bootlog_hdmi_disabled_WITH_dp_attached.log (71.2 KB)
bootlog_hdmi_disabled_no_dp_attached.log (70.3 KB)
Sorry for late reply. I was out of office for few days.
I see only tegradc.1 is in log which means tegradc.0 is truly disabled now.
[ 5.121509] hpd: hpd_switch 0
[ 5.121512] hpd: switching from state 0 (Reset) to state 1 (Check Plug)
[ 5.121527] hpd: state 1 (Check Plug), hpd 0, pending_hpd_evt 0
[ 5.121532] hpd: switching from state 1 (Check Plug) to state 3 (Disabled)
However, still don’t get the hotplug detection according to above log. Please try to hotplug the dp cable after system boots up and see if hpd log spews or not. If still not, please review your carrier board with product design guide.
BTW, please also check if the “reversed” case between HDMI and DP port is still there or not.