This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IOCTL_HAL_QUERY_DISPLAYSETTINGS implementation for AM335X?

In order to support our display I had to change the settings in lcd-tfc_s9700.c and recompile,  I also added a few debug messages.  After rebuilding the OS I get the message "OEMIoControl: Unsupported Code 0x10100fc - device 0x0101 func 63" which is IOCTL_HAL_QUERY_DISPLAYSETTINGS.  this appears in C:\WINCE700\OSDesigns\AM335X_OS\AM335X_OS\Wince700\AM33X_BSP_ARMV7_Retail\cesysgen\oak\inc\pkfuncs.h but not in C:\WINCE700\PLATFORM\AM33X_BSP\SRC\inc\ioctl_tab.h.  I found an implementation of this IOCTL in x86 and added it to the IOCTL_tab.h and to oallib.  I no longer get the OEMIoControl error but am instead told "ERROR: Unable to allocate heap memory" just as had happened immediately after the OEMIoControl error I had previously been getting.  I am unable to find succeeding error messages such as "ERROR: Unable to allocate OMAPFlatSurface memory" in the BSP, which I could otherwise update in attempt to work around whatever problem I am having with IOCTL_HAL_QUERY_DISPLAYSETTINGS.  Although I only have 256M rather than the EVM's 512M available on my board, I have updated image_cfg.h accordingly.  This error, and the fact tht I see it only when tryiong to bring up the display, makes perfect sense if the IOCTL call is failing to deliver the proper dimensions to its caller. 

I don't see registry entries that I could update instead, and the screen appears to work just fine during EBOOT, which puts up the 4-color block display as expected. 

Where can I find the proper implemetnation of IOCTL_HAL_QUERY_DISPLAYSETTINGS for the AM335X?

  • I was able to find the source for the "ERROR: Unable to create OMAPFlatSurface" message as the OMAPFlatSurfaceManager::Allocate() routine in C:\WINCE700\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI\DSS\lcdcai\surfmgr_flat.cpp.  When I modified this to report which of the several such callers it happened to be and to display the parameters it had received I got the following values for the parameters: 5, 480, 272, A2865A00, 8FFB0000.  As 480 x 272 = 0x1FE00 and we have a depth of 16 bits I had allocated 2 * 0x20000 + 0x10000 for the palette at the end of physical memory, in my case 0x8FFB0000.  Is more than one such space needed?  if so how many?

    I found that the AM35X EVM has a 480x272 display, so I am trying the image_cfg.h values from its BSP, which allocates a lot of video memory (0x0100_0000) although no explicit provision is made for the palette.  I have updated my AM335X BSP's file to match these values, scooting the palette just before the large chunk of video memory

  • With the video memory sizing from the AM35X BSP I was able to update the AM335X BSP's image_cfg.h, and with the HAL_IOCTL_QUERY_DISPLAYSETTINGS from x86 BSP I was able to get the display up without crashing the OS.

    Please add this IOCTL to the AM335X BSP.  I also didn't see much info on something as central as image_cfg.h: just two mentions in http://processors.wiki.ti.com/index.php/WinCE-BSP_ARM-A8_User_Guide but nothing on video memory sizing

  • As the base AM335X BSP is created for the AM335X EVM it is expected to need to adjust settings for custom hardware.  We are happy to hear you were able to feature our and port the code that was needed for your specific HW customizations.

    Regards

  • Unfortunately that is not the end of the story.  While I have been able to get the touchpad calibration screen to display the OS crashes chortly thereafter.  This appeared to be caused by the thread doing DST adjustment, so I removed it (along with standard shell and network user interface, which required it).  I then got the data abort in udevice.exe rather than servicesd.exe as previously.  I am have now stripped out all drivers in the catalog except for dispaly, touch, gpio, and SD and am again rebuilding.  I do not know whether the problem is caused by drivers or by the new RAM map I had to device in image_cfg.h: the last thing reported was an OMAPDDGPESurface constructor call (using the new memory map), but last activity of the dying thread had been the DST.

    After stripping out these drivers I now have "NMAKE : fatal error U1073: don't know how to make 'C:\WINCE700\OSDesigns\AM335X_OS\AM335X_OS\Wince700\AM33X_BSP_ARMV7_Retail\cesysgen\sdk\lib\ARMV7\debug\ndis.lib' {log="C:\WINCE700\build.log(11268)"}" even after manually building ndis under test (excluded from build).  I do not believe I had had to rebuild ndis under previous catalog strippings.  Please advise

  • Note that I had set DEBUG=1 and wincedebug=debug in order to generate these messages- is this the cause of my don't know how to make... problem?  I am also not able to remake the individual components of ndis in test (excluded from build), nor can I see how to un-exclude it.