Posts by fs-support_MK

We will inlcude roadmap and changelog information in the download area on our website in short term.

It should not be a problem to register with NetDCU8. Is this still an issue?

BSP release version 1.1 now includes openGL support. You will find the GPU SDK in the examples directory in the download area. This SDK includes documentation, tips&tricks and some demonstration examples.

Currently OpenGL support is restricted to FBdev. This means it is not possible to run OpenGL programs out of X11. This will required DRI support which will be included in a future release of FS-iMX6 platform.

BSP release version 1.1 now includes openGL support. You will find the GPU SDK in the examples directory in the download area. This SDK includes documentation, tips&tricks and some demonstration examples.

Currently OpenGL support is restricted to FBdev. This means it is not possible to run OpenGL programs out of X11. This will required DRI support which will be included in a future release of FS-iMX6 platform.

Hi,

unfortunatly PicoCOM4 BSP does not support ethernet debuggung. So you should leave KITL and Debugging option in platform builder deselected.

Is your custom kernel image already stored in NAND flash?
If so, does a prebuild kernel image still work properly with this board?

Did you remove any features?
Please verify that your OSDesign includes hive based registry support.

This problem might be related to a bugfix that has been applied in V1.1 of PicoCOM4 EBoot.
According to your debug output you are still using V0.7 which indeed is very old. Especially the USB driver has been reworked massively in V1.1 so I would recommend updating EBoot.

When flashing the Ubuntu RootFS on a new SD card, the screen might stay blank when booting up this image the first time. This is because by default X11 server is configured to used the hw accelerated video driver which isn't available until sw release V1.0. To resolve this you need to configure the xorg configuration file and disable this driver.

uncomment the following line

and restart the board.

This information is available in windows ce registry unter: HKLM\Platform and HKLM\System

By default with buildroot based image, X Server is running on primary display which is the HDMI interface. To run X Server on LVDS display interface you might need to set the FRAMEBUFFER environment variable.

To set this behaviour as default you could simply modify the XDM init script (S99xdm).

Sorry that we missed to fix this issue yet.
As a workaround it should be possible to use the "MasterOutMute" value in registry. Please refere to chapter 2.4 for the PicoCOM Device Driver documentation.

Here is a small example programm to detect the HW revision of a board programmatically. The key in this method is using a function (GetBoardRevision) in CEDDK.dll that is exported on all F&S Boards.

Quote from "Roland183"

Regarding Pin 24 (IO7 - USB PWR): I configured this Pin as GPIO Input, and with a 100kOhms resistor it could be set High and Low. Suppose it was really an Input. By now I had no possibility to read out that Pin. Anyway, the USB Host interface was still working correctly. Keyboard, mouse and Memory-Stick are recognized and handled as usual. May be, the opportunity to switch the USB Power is not related directly to the USB driver, as this feature is not ultimately required.

DIO driver instead is be loaded very lately and therefor will overwrite the pin configuration. I am suposing that you are are not using this pin to enable/disable USB power. Therefore it should be possible to use this pin without problems.
BTW: A DIO-read should always return the current pins state, indepent if the pin is configured by the DIO driver.

Quote from "Roland183"

Regarding XIP-Kernel: By now we should manually resize the standard partition to accommodate the latest kernel. The EBoot Roadmap promises an increased standard size in future Version 1.7. When this will be available?

A new E-Boot release is scheduled within the next two weeks.

Quote from "resolut"

After switching from PicoCOM2 to PicoCOM4 (kernel NKPC4_CORE_CF35_120119.bin) we are unable to use pins 27 and 28 (IO pins 9 and 10) as inputs. According to the manual, these pins can function as outputs only. However, the same is stated to PicoCOM2, where these pins work as inputs normally.

Unfortunatly these pins are outputs only on PicoCOM4. This is cause by the alternative SPI-functionality where the internal power supply for theses pins is too weak - sorry for that inconvinience :(.

Quote from "resolut"

The kernel NKPC4_CORE_CF35_120119.bin is rather old, but the latest release comes with XIP-version only. Will there be an update on NKPC4_CORE_CF35? Should I use XIPNKPC4_CORE_CF35 instead (requires larger partition)?

We will no longer create regular NK-images, only XIP-images. But you can switch to this kernel variant without any problems. They only differe in the internal organization of the files. Instead to NK-images the kernel must be be extracted and copied to system memory completly. It will be loaded dynamically as required which offers much better boot times and lower overall memory utilization.

Quote from "resolut"

4. If these pins really can be used as outputs only on PicoCOM4, we could switch to pins 40 (IO 20) and 24 (IO 7). The latter one is related to USB power - could there be any side effects when using thi pin as input?

IO20 will be no problem at all. When switching to IO7 (USB-PWR) you will need to disable USB host interface driver.

Attached you will find a small sample programm to adjust contrast voltage.

We have done some progress in this problem. It looks like that there is another service that is trying to use COM1 -> "Bluetooth modem".

Please try to set the BT modem to another port. E.g.:

We are curently looking in more detail into this issue to get a proper solution.

Have you already check the USB host limitation?
See <!-- l --><a class="postlink-local" href="http://forum.fs-net.de/viewtopic.php?f=3&t=2870">viewtopic.php?f=3&t=2870</a><!-- l -->

First beta-release for QBlissA9 is available in the download area!

Important note
Current firmware versions available for QBlissA9 are in beta state.
Therefore not all features available on QBlissA9 are working
properly yet. Following features are known to be missing:

• Camera interface
• Video Processing
• GPU 2D/3D support
• SPI (not tested)

Following features are verified already:

• UART (Uart2,3,4)
• SD-MMC (SD3)
• Display:
  - LDVS (tested at 800x600 single channel)
  - HDMI (tested from 800x600 up to 1920x1080/FullHD)
• USB (4 channels)
• PCI-Express (problem on scanning devices behind PCI-bridge)
• SATA
• I2C (I2C1 and I2C2/HDMI-EDIO)
• CAN (CanSocket)
• Ethernet (HW issue with GBit ethernet)
• WLAN
• Bluetooth (BlueZ BT-stack)
• Audio:
  - AC97 (tested with SKIT codec WM9715)
  - HDMI audio
• NAND flash (MTD)
• Power management (standby and dynammic cpufrequency scaling working)

Root filesystem
Currently there are only available two pre-build system images:

• Ubuntu (qblissa9-rootfs-ubuntu-v0.1.tgz):
  Pre-build ubuntu image that has primarly created by linaro
  development group.
  This image is very helpful on first start-up. There are available
  lots of additional software packages that can be installed via the
  internet.
  

  
  

• flsgnome (qblissa9-rootfs-ubuntu-v0.1.tgz):
  LTIB based rootFS that includes matchbox window manager.

Additionally we will soon release a buildroot based rootFS that can be
configured for your needs.

Documentation
Because of the early software state of QBlissA9 according
documentations are missing yet. We will release these documentations
step by step. FirstStep documentation that includes basic usage of
QBlissA9 will be released within this wwek (KW46).

There was a more general problem of using IO46 (Pin 69).
We will release a new kernel image today where this problem is resolved.

After adding support for SDHC card on PicoCOM1 we received a lot of request if it is possible to add this feature on an existing system without the need to reflash the complete kernel image. This HowTo will describe one solution we have preprared to arrange this.

The basic problem with SDHC update is that there where involved a lot of DLLs in this updated. These DLLs are located in the Windows directory by default. These Dlls are not only referenced in registry settings but there also some directly interconnectiones (with LoadLibrary). To avoid that there appears a mixup between old and new versions of these DLLs it is required to replace them in Windows directory. But as this directory is virtual only it is required to repeat this copying on every bootup. Therefore we needed to implement a small patch driver that replaces the DLLS in Windows directory on startup.

The ZIP package attached to this thread includes all DLLS and settings to patch an older kernel image. Just copy the SDHC directory into \FFSDISK\ and apply the settings in the included NDCUCFG script (SDCH-Update.txt). This script will ajdust all registry settings required to get the new SDHC driver working.

After booting up the you should see debug messages similiar to following:

Of course you can adjust the Update-Script according to your needs.

If you want to put the new SD card libraries into another location please adjust the following settings according:

• Modify the location of the SDHC-Patch driver
  
  
  Code

  1. reg open \Drivers\Builtin\SDHCPatch
  2. reg set val Dll string <The locatoion of the SDHCPatch.dll (default: "\FFSDISK\SDHC\sdhcpatch.dll")>

  
  

• Tell SDHC Patch driver to copy the files from a different location
  
  
  Code

  1. reg open \Drivers\Builtin\SDHCPatch
  2. reg set val SourceDir string <Your source directory (default: "\FFSDISK\SDHC")>

Please note that this fix is posted without warrenty, We advise to to test this fix before applying it to modules in the field.

Please try to adjust contrast voltage with ndcucfg:

or

It might be possible that the contrast voltage has been changed by another mode.

A new kernel has been released today that includes SDHC support.