PWM0 on Jetson nano Rel-32.5 not working

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
22

devmem tool can do that too. Please check it first. This is general tool from Linux.

23

Just in case you don’t know how to use it.

devmem 0x6000D504 0x2

24

It was devmem 0x6000D504 8 0x2 for me, and yes, now it works.
Question: why was this register not properly initialised by the kernel, given the pinmux configuration that I have provided?

25

Hi,

I think it is a flaw that “FDT” in extlinux may not cover every pinmux setting for each pin.

Better doing full flash with flash.sh script and you shall see bit 0 of this register becomes 0 by default.

26

Does this mean that uboot also initialises GPIOs from the device tree as well?
If so, I still think that if Linux fails to set up GPIOs and pinmux from device tree as stated should be considered a bug.
If, on the other hand, loading of device tree differs if device tree is on spiflash or on sdcard, that would also be a bug in my opinion.

27

Hi,

Hope this may explain what happened to your issue.

  1. Currently, it is the cboot to handle pinmux, not uboot.

  2. cboot and kernel side are using different dtb. Same file but copied to different partitions. But sometimes some users may only update “kernel dtb” so cboot dtb does not know it.

  3. The gpio controller has higher priority than the pinmux driver. Thus, though your pinmux setting says “it is SFIO”, if GPIO controller still sets it to GPIO, it will still be a GPIO.

  4. In your case, looks like “FDT dtb” in your extlinux.conf is just another case of (2). The cboot does not know your change and it follows the old one in cboot dtb partition.

Thus, doing full flash may workaround this issue.

Another case is, mismatch kernel dtb and cboot dtb may cause driver to have behavior different. For example, if you enable driver A in kernel dtb but not cboot dtb, and this driver will request a GPIO, then this pin will become gpio in cboot afterwards, even though your pinmux setting in kernel says it is a SFIO, it will not take effect.

29

Me again; we moved the software stack to Jetson Nano 4g (compared to the earlier 2g), and the same problem emerged.
I did the full reflashing of the device to make sure that backlight pwm pin is assigned the appropriate function and settings.
In short, I see the following when I boot the device:

  • devm 0x700031fc → 0x01
  • devm 0x6000d504 → 0x02
    Once I write:
    devm 0x700031fc 8 0x45
    I can run pwmchip0/pwm0 by hand and it works. How can I enforce this change to happen in device tree, and not manually?
    Second part, when I put backlight-pwm driver on top of this pwm0_0, but it doesn’t work at all, with or without devm commands.
    Any help is welcome.
    Thanks in advance.
30

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.