Request: Simple procedure for enabling I2S support on Jetson Nano

Hi Ben,

Sorry for the delay. Yes that is a (big) difference between A01 and A02/B00 boards. For A01 it uses I2S1 and then it was changed to I2S4 after that. So this is not an oversight and I have tested this on both the A01 and A02 boards I have.

Yes the changes listed in the below are for I2S4 only and so if this works for you then this would imply that really you have an A02 board and not A01. Now as far as I know the only way for this to happen is if the eeproms on the boards a incorrecly programmed.

https://devtalk.nvidia.com/default/topic/1061108/jetson-nano/i2s-audio-output-not-working/post/5374074/#5374074

On the underside of the devkit you should see lots of different numbers printed on the PCB. There is one number that is something like ‘180-13449-DAAF-A02’ where the suffix indicates the board version. If you can maybe send us a picture of the bottom of the board with all the serial numbers etc visible.

That said I guess we really care about the version of the module and not the baseboard because it was the routing on the module that changed. So if you can unscrew the module and take it out, you will see another version string such as ‘180-13448-DAAA-A02’.

It would be interesting to get photos of the undersides of both the module and baseboard.

Now if it turns out that the module version is A02 and not A01 and so the wrong DTB is being loaded, we could workaround this as follows …

  1. Backup the extlinux.conf
sudo cp /boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.backup
  1. Edit the /boot/extlinux/extlinux.conf and insert the following contents …
TIMEOUT 30
DEFAULT NANO A02

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} 

LABEL NANO A02
      MENU LABEL NANO A02
      LINUX /boot/Image
      FDT /boot/tegra210-p3448-0000-p3449-0000-a02.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs}
  1. Reboot the board and now on reboot it will use the A02 dtb by default. You can always select the ‘primary kernel’ option on boot (via the uart serial console assuming that you have access).

We should only do that above if the module is an A02. However, if the module is an A02 we need to understand why it is loading the wrong DTB. In that case the simplest thing to do maybe to RMA the board.

Regards,
Jon

Hi Jon,

Well I am stunned.

I followed the procedure that you gave above and it worked. I was getting audio from the MIC+.

We have another Nano here at the office so I thought I would do a sanity check and see what model was being reported. It also reported A01 coming from the OS and A02 according to the devkit baseboard.

This is very strange. What are the chances of having 2 defective units when they were purchased separately.

One thing they do share in common was that I created only one SD card and cloned (using linux dd) the card. So it may be an issue with the OS. To test this, I downloaded the 32.3.1 OS from the Getting Started guide and tried again. This time the OS reports B00 which is as expected according to [1].

As I type this I am flashing the OS again but this time using the SDK Manager. The computer running the SDK Manager had its hard disk replaced recently so it should be pristine.

If the problem returns I’ll let you know. If you would like further information (because apparently there is another way for the OS to report an incorrect model besides the eeprom or extlinux.conf) I still have the “bad” sdcard/image and would be happy to provide debugging information.

Regards
Ben

[1] https://devtalk.nvidia.com/default/topic/1068583/jetson-nano/jetpack-4-3-l4t-r32-3-1-released/post/5414045/#5414045

Hi Ben,

Thanks for the update. Good to know that reflashing the entire board fixed it. I am not sure what could have caused that, but I will see if anyone else knows as it would be good to get to the bottom on this.

Thanks
Jon

Hi Ben,

Apologies but I think I mis-read your response. So after re-downloading the SD card image and applying it again fixed the problem. Does that fix the problem for both boards?

I am not sure if the issue was propagated from one board to other or if something went wrong with the very initial update. I think that you need to go through the update process on both boards because I believe it is updating the flash device on the board.

Regards,
Jon

Hi Jon,

Rebuilding the SD card from the downloaded image fixes the issue on both boards. I created one SD card with the downloaded image and tested both boards using the same physical SD card.

Interestingly I noticed that the downloaded image reports the model as B00 but if the OS is flashed from the SDK manager it reports the model as A02. For the moment I am using the downloaded SD card image because the app partition is at the end rather than the start of the card allowing it to be resized.

I am not sure what you mean when you say “I am not sure if the issue was propagated from one board to other or if something went wrong with the very initial update. I think that you need to go through the update process on both boards because I believe it is updating the flash device on the board”. Are you saying that the EEPROM is written to at some point during the first boot of the OS?

Thank you for helping me so much with this issue. Your responses are always been very informative and helpful.

Regards
Ben

Hi Ben,

OK great. I will see if I can reproduce the issue with the SD card image showing B00 and the SDK manager showing A02. To be honest, there is not much difference between the A02 and B00 version and in fact I believe we are trying to consolidate the device-tree for both. However, regardless we should not get a different result from updating from different ways.

My comment about the ‘issue being propagated’ is related to how your board ended up using A01 in the first place. It seems that having gone back through the update you no longer see this problem. So I am wondering how that occurred in the first place or what changed so that this no longer happens.

As far as I know I don’t believe that the eeproms are updated, but there is a SPI flash on the board that does get updated.

Regards,
Jon