PAL/NTSC Jumper

Hotplugging the jumper should not cause any damage, though it will not do anything once the board has booted. The PAL/NTSC jumper on the DM355 EVM is little more than a GPIO pin being pulled one way or the other, this pin can then be polled by U-Boot to tell the display driver what video display format is needed. See appendix A.1 of the EVM getting started guide in \dvsdk_1_30_01_41\docs\spruf73a.pdf for a description of how you can configure your U-Boot arguments to adjust the video output standard based on the jumper.

From the terminal you can change the output standard of the board using the sysfs as discussed in \dvsdk_1_30_01_41\PSP_01_20_00_014\docs\SPRUEL6.pdf, in particular running the commands below can switch between PAL and NTSC. Note that this will differ if you are using a different version of the DVSDK software package, you will have to consult the documentation included with your particular DVSDK version.

echo "PAL" >/sys/class/davinci_display/ch0/mode

echo "NTSC" >/sys/class/davinci_display/ch0/mode

Hi

Bernie Thompson said:

Hotplugging the jumper should not cause any damage, though it will not do anything once the board has booted. The PAL/NTSC jumper on the DM355 EVM is little more than a GPIO pin being pulled one way or the other, this pin can then be polled by U-Boot to tell the display driver what video display format is needed. See appendix A.1 of the EVM getting started guide in \dvsdk_1_30_01_41\docs\spruf73a.pdf for a description of how you can configure your U-Boot arguments to adjust the video output standard based on the jumper.

Thanx Bernie, this is already a part of my bootargs.

Bernie Thompson said:

From the terminal you can change the output standard of the board using the sysfs as discussed in \dvsdk_1_30_01_41\PSP_01_20_00_014\docs\SPRUEL6.pdf, in particular running the commands below can switch between PAL and NTSC. Note that this will differ if you are using a different version of the DVSDK software package, you will have to consult the documentation included with your particular DVSDK version.

echo "PAL" >/sys/class/davinci_display/ch0/mode

echo "NTSC" >/sys/class/davinci_display/ch0/mode

This could be a way how i can solve my problem. But in dvsdk_1_30_00_23 there is no SPRUEL6.pdf at PSP directory. Isnt it implemented? Or am i to silly to find it?
i also dont have a "/sys/class/davinci_display" directory at my nand flash.
If this is already a part of this older dvsdk version, do you know the command for it, or is the only way to update the dvsdk version?

If i do the update, must the kernel also be updated?

greetings alex

Just found this thread, i will have a fast look at the *.doc u mentioned there.
im soon back. *g*

Hmmmm

https://community.ti.com/forums/p/3220/11976.aspx#11976

I cant find anything related to sysfs in the VPBEUsersManual.doc...
So my questions are still there...

Alex

It looks like that the sysfs entries to change NTSC/PAL were not implemented in 1.30.00.23, so to get them you would have to upgrade as discussed in that other thread you referenced (www.ti.com/davinciregistration). This would mean a kernel update.

To do this with the software you have you would have to do this from an application that modifies the vpbe_fb_videomode structure and uses the FBIO_SET_TIMING IOCTL to switch between PAL and NTSC.

Thanks a lot, i will try it tomorrow.

Good Bye!

Hotplugging the jumper should not cause any damage, though it will not do anything once the board has booted. The PAL/NTSC jumper on the DM355 EVM is little more than a GPIO pin being pulled one way or the other, this pin can then be polled by U-Boot to tell the display driver what video display format is needed.

Mostly right; yes, just a GPIO. In the GIT kernel just read GPIO 251 (that's what /sys/kernel/debug/gpio says) ... it's exported, so from userspace

cat /sys/class/gpio/gpio251/value

to see what's up.  It's NTSC/nPAL, so "1" means NTSC mode.  What's wrong is the statement that changing the jumper is pointless after boot. If I pull the jumper, it's immediately reflected in sysfs.  Same thing with the SW6 switch block ... SW6.1 is GPIO 247 and visible through sysfs, and so on through SW6.4 being GPIO 250 and in sysfs.  Observe any of them changing in real-time through sysfs.

You make a good point, that would be a fine way of making the jumper effective during runtime, though this is something that would have to be implemented, such as checking that pin every frame or every so many frames in your video processing loop (or even within the display driver). At the moment the only NTSC/PAL switching functionality it has out of the box is in U-Boot, as most applications would only need to operate in one mode.