Posts by ThoPos

    hi,


    fixed!


    First I've added the correct configuration for tx18 / tx20 displays.


    Unfortunately that's not the solution.


    In

    Code
    1. static void update_lcdc(struct fb_info *info)

    I've replaced the 60 by the given refresh cycle, 35.

    Code
    1. t *= 60; /* ### TODO: Use given framerate resp. var->pixclock */


    Code
    1. t *= 35; /* ### TODO: Use given framerate resp. var->pixclock */


    With this fix it's possible to move back to the mode_str 800x480.


    by the way:

    Quote

    Why do you think the M will forward the driver to fbcvt.c?


    I tried multiple mode_str and added a few debug lines in fbcvt.c; in several configurations the fbcvt was activated.

    Thank you for your reply.


    I tried to implement the timing mode in "fb_videomode" for the type display type "'800x480M-16@60'".
    It looks like that the "M" inside the mode string will forward the driver to use the "fbcvt.c".
    So later i tried it with just a custom name to link the mode_str to our customized display timing string but also without effect.

    We have to replace our display from the type KOE TX20D19VM2BPA to the new type KOE TX20D33VM2BPA.
    Unfortunately it's not just replacing the display.


    By the given mode_str the timings should calculate correctly.

    Code
    1. .mode_str = "800x480M-16@60"


    The display shows only a flicker with the given mode_str.


    Which mode_str we have to use to drive the TX20D33 correctly?


    By the way, the display is fully compatible on netdcu10 by selecting the tx18 display.

    Hello,


    normaly, to build an image with contains two stepps.

    • make your-defconfig
    • make

    did you check the compiler settings in your defconfig file?

    Code
    1. # our defconfig for external toolchain
    2. BR2_TOOLCHAIN_EXTERNAL=y
    3. BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
    4. BR2_TOOLCHAIN_EXTERNAL_PATH="/usr/local/arm/fsvybrid/fs-toolchain-4.7.2-cortexa5-neonvfpv4"
    5. BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="$(ARCH)-fs-linux-gnueabi"


    With this Toolachain Path:

    Code
    1. /usr/local/arm/fsvybrid/fs-toolchain-4.7.2-cortexa5-neonvfpv4


    maybe, is this the mistake?
    arm-linux-gcc instead of arm-fs-linux-gnueabi

    by the way! The error with "page aligned data..." isn't important, because we are able to write the whole partition size ( ... empty RAM after "binary image" recommended ).

    Thanks for your reply.
    After download the NBoot "D" and save with "f and after download the uboot with "d" and "f" followed by "x" the system starts without bootselect jumper.


    By the way, flashing the uboot inside uboot isn*t possible ( see first note with "page aligned data..." ).

    Hello,


    failed a few times during update the bootloader uboot ( u-boot-efusa9_V1.2 ).


    In short, what I did; first I liked to flash custom build uboot.

    Code
    1. tftp uboot.bin
    2. nand erase UBoot
    3. nand write $loadaddr UBoot $filsize


    nand write was acknowledged with

    Code
    1. NAND write: device 0 offset 0x0, size 0x50a3c
    2. Attempt to write non page aligned data
    3. 330300 bytes written: ERROR


    Now i ran into problems, because I erased the whole UBoot partition.


    With the MfgTool2, and bootselect jumper setting, I was able to stepp into F&S Nand Loader ( built May 23 2014, 11:41:56 ).


    First I totaly erased the flash by pressing "E". Then I started download binary file u-boot-efusa9_V1.2.bin. Followed by pressing "f" for save and "x" for restart.
    Now, I'm able to stepp into uboot ( F&S and also the custom build ), but only with the closed bootselect jumper and the trigger by the MfgTool2.


    If I remove the bootselect jumper and restart the board, the board failed to boot. I get every few seconds a "\0" character on serial line.


    Where Is my mistake, what did I wrong? I played a little bit with bootselect, but more or less without effects.

    Hello,


    take a look into your linux kernel source:

    Code
    1. arch/arm/mach-mvf/mach-netdcua5.c


    search for

    Code
    1. mode_str


    Code
    1. // Replace
    2. .mode_str = "800x480",
    3. // by
    4. .mode_str = "640x480",


    you have to rebuild & reload your kernel.

    SPI compatibliy between netDCU10 & netDCUA5 moved from "J5 Pin 2, 3, 4, 6" to "J5 Pin 10, 11, 13, 15" - These pins are also used by our i2c bus.
    An alternative would be the kernel included spi_gpio driver. For the spi_gpio driver initialization we do need the gpio references ( gpio_request_one(...) ) for J5 Pin 2, 3, 4, 6.


    Thanks

    at a netdcu 10 (2.6.19) I have tried a simply bluetooth dongle for serial communication and it works fine. In general, if the embedded system has usb, the bluetooth dongles should work.

    Hello,


    and again; take a look into the source-file. /drivers/i2c/chips - maybe, it could be that the given range/area of "addresses to scan" is too small.
    previously check the chip-connection / identification with dmesg ( dmesg | grep i2c should help you ).


    good luck

    Hello,


    take a look at the kernel sources; <drivers/i2c/busses>
    i think, that it is similarly to the netdcu8-sources; the bus and max-frequency is hard coded in a platform-dependet source file (whole i2c initialisation). at the moment i can't look at the picocom1 sources, but i think, the name of this file is similarly to "i2c-at91xyz".

    oh - thank you for your reply.


    i try to port the newest uboot; and i forgot to protect the initial nand-flash-areas.
    confused - sometimes in uboot-console i can't use the "nand erase" accurately...(swap some parameters...)...

    Hello,


    my mistake, i overwrite the first bytes in nandflash-area.
    i think, that the fs-nandloader is broken.


    after reboot, the picocom2 stand still; if i connect the device with the mini-usb-cable to my pc; i can connect the cpu via Atmel SAM-BA (i know, that i doesn't need this tool) - the picocom stand still in bootstrap...?!?.


    what can i do to renew the fs-nandloader?

    as far as i can remember, i had similar problems with interaction userland-app and i2c-driver. decrease the i2c-clock fixed this problem.