Posts by Habi

  • PCL-Driver for WEC7?

    Hello,


    I found some older versions of the PCL printer driver for WEC5 and WEC6 in this forum. Is there a newer version available for WEC7? We want to use it together with the USB printer class.


    Best regards

    Habi

  • Problem with adding "all" locales (out of memory)

    Solved.


    The file wince.nls is assigend to the XIPKERNEL section in config.bib. This section has a size of 4 MBytes. After increasing it to 6 MBytes and adapting the other sections accordingly building the image worked.


    The origianl settings in config.bib:

    Code
    1. XIPKERNEL 80220000 00400000 RAMIMAGE
    2. NK 80624000 03E00000 NANDIMAGE
    3. CHAIN 80620000 00004000 RESERVED
    4. RAM 80620000 0F9E0000 RAM ; size= (0x90000000-0x80620000)
    6. XIPSCHAIN=80620000


    And my changes:

    Code
    1. XIPKERNEL 80220000 00600000 RAMIMAGE
    2. NK 80824000 03C00000 NANDIMAGE
    3. CHAIN 80820000 00004000 RESERVED
    4. RAM 80820000 0F7E0000 RAM ; size= (0x90000000-0x80820000)
    6. XIPSCHAIN=80820000

  • Problem with adding "all" locales (out of memory)

    Hello,


    I'm using the BSP BSP_FSIMX6SX_WLAN_20190219 for WEC7 on efusA9X and have a problem when trying to add nearly all locales to the OS image.

    I followed this article to add the locales "Adding (all) locales to WEC7"


    When making the runtime image I get the following error message in pass 1, build.log shows:

    Quote

    Failed to find a range for data of size 1608282

    Error: Ran out of space in ROM for wince.nls size 1608282

    Fatal error hit, exiting...


    The problem seems to be the size of the file wince.nls. When removing some Chinese related LCIDs (language code identifier) from the nlscfg.inf file, the size of the file wince.nls is reduced from 1.608.282 bytes to 691.814 bytes and everything works fine.


    The overall size of the OS image (xip.bin) seems to be not the problem. The size of my xip.bin file was about 54 MBytes when I have experienced this problem. I reduced the size by removing some features to 50 MBytes and got the same error message as with the bigger image.


    I have not modified the memory mapping in config.bib.


    If I reduce the size of wince.nls so that making the OS image works, I get the following information about this file:

    In ce.bib:


    In build.log


    To reproduce this issue, please enable all Catalog Locale items in "FSiMX6SX -> Core OS -> Windows Embedded Compact -> International -> Language -> xxx -> Locale -> yyy" and use the following nlscfg.inf file:


    When removing the last 5 LCIDs (0804, 0C04, 1404, 1004, 0404, all are related to China) the size of wince.nls is reduced significantly and everything works fine.


    Any ideas what to do so that the file fits into the image?


    Best regards,

    Habi

  • eMMC on efusA9X hardware 1.10, 1.20 and 1.30 (and newer)

    I'm using the BSP BSP_FSIMX6SX_WLAN_20190219 for WEC7 on efusA9X with hardware version 1.10, but later we will update to the current hardware version 1.30.


    Regarding the eMMC there was a change between hardware 1.10 and 1.20 (using different SD-slots).


    In the registry of the BSP there are two keys for these two hardware versions.


    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\EFUSA9X\USDHC4_REV110]

    …

    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\EFUSA9X\USDHC4_REV120]

    …


    Every key defines with the value "GEBoardRevision" an explicit hardware version (dword:78(=120) respectively 6E(=110)).


    According to the hardware history the current hardware version is 1.30. I'm wondering what happens if this BSP is used on hardware 1.30.

    Will the eMMC work then, because the registry key with the highest version is taken automatically, which would be the key _REV120?


    If this will not work, what is the correct approach to get eMMC working on hardware 1.30 with this BSP?


    - Add a registry key for hardware 1.30?

    I don't like this because for future hardware version the registry must be updated.


    - Add a more generic key without hardware version in its name and without GEBoardRevision in the hope that this key is taken into account, if hardware 1.30 is found and that the keys ...USDHC4_REV110 and ...USDHC4_REV120 are still used for hardware versions 1.10 and 1.30?


    Best regards,

    Habi