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.

GSG 4.5 Building a New Linux Kernel

Other Parts Discussed in Thread: TVP5146

Hi,

When I try to compile the kernel using the below command:

make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage

There always gives me an error like

**************************************

 SYSMAP  System.map
 SYSMAP  .tmp_System.map
 OBJCOPY arch/arm/boot/Image
 Kernel: arch/arm/boot/Image is ready
 GZIP    arch/arm/boot/compressed/piggy.gz
 AS      arch/arm/boot/compressed/piggy.o
 LD      arch/arm/boot/compressed/vmlinux
 OBJCOPY arch/arm/boot/zImage
 Kernel: arch/arm/boot/zImage is ready
 UIMAGE  arch/arm/boot/uImage
"mkimage" command not found - U-Boot images will not be built
 Image arch/arm/boot/uImage is ready

**********************************************

Although Image and zImage  can be created, uImage can not. How can I solve this problem?

Ferhat OLGUN

 

  • Did you run

    make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_evm_defconfig

    first?

  • In addition to Juan's suggestion you may want to check your PATH variable that is set in earlier steps (section 4.4) of the GSG, one of the paths in your PATH variable should be to \opt\mv_pro_4.0\montavista\pro\bin or something similar depending on your DVSDK version, this particular path in the PATH variable should go to a directory that contains mkimage. My suspicion is that there may be a typo in this particular path such that it cannot find mkimage, so I would check PATH and verify that the folder it points to contains mkimage.

  • I run firstly the below line,

    make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_evm_defconfig

    Below is my .bashrc file that I have modified

    # Source global definitions
    if [ -f /etc/bashrc ]; then
    . /etc/bashrc
    fi
    # User specific aliases and functions
    PATH="/opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin:
     /opt/mv_pro_4.0.1/montavista/pro/bin:
     /opt/mv_pro_4.0.1/montavista/common/bin:$PATH"

    I looked at the link "/opt/mv_pro_4.0.1/montavista/pro/bin" ..there is already  mkimage in that location. Can the written type (spaces, tabs etc. )  in .bashrc file be the reason so that it can not see the PATH?

    Is it possible to send me the  files:

    1)".bashrc" file which is already working and

    2)"uImage"   which have already builtted with no change in menuconfig . (Settings at menuconfig are all ok for me now) This is critical for me to have an uImage file as soon as possible.

    Thank you for now.

    Ferhat

     

     

  • If you take out the carriage returns in your .bashrc file for the path this should work, this is the sort of typo I was thinking of, unfortunately with the GSG representation this sort of thing happens often. What this is doing is making it so that the only part of the PATH variable that is recognized is the /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin which just gets you the compiler tools, but when it goes to find mkimage it gets confused by the carriage return (enter).

    So lets try making it so that this:

    Ferhat OLGUN said:
    # User specific aliases and functions
    PATH="/opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin:
     /opt/mv_pro_4.0.1/montavista/pro/bin:
     /opt/mv_pro_4.0.1/montavista/common/bin:$PATH"

    Looks more like this:

    PATH="/opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin:/opt/mv_pro_4.0.1/montavista/pro/bin:/opt/mv_pro_4.0.1/montavista/common/bin:$PATH"

    If this does not work please let us know and we can look into alternatives such as sending you a pre built uImage (we would need to know more about what version DVSDK you are using and such to do so).

  • I can built the kernel at the end. The way I tried and solved the problem is manually exporting the PATH (Before building the kernel I export the PATH in console).

    Then I built the modules to generate tvp5146.ko, mt9t001.ko and davinci_capture.ko

    When I write " insmod davinci_capture.ko device_type=0"  So much errors appear like:

    *************************************************************

    "I2C write failed<4>DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected

    DaVinci I2C WARNING: i2c: NACK detected
    DaVinci I2C WARNING: i2c: NACK detected

    I2C write failed<3>
     Unable to initialize MT9T001...insmod: error inserting 'davinci_capture.ko': -1 Operation not permitted"

    **********************************************************

    I have not still connected MT9T001 to the imager inputs J30-31. Is that the reason for these above I2C errors?

    Is there any document which explains the J30-J31 pins? (IMAGER_TRG, IMAGER_GBL_SHUTTER, IMAGER_FRAME_VALID, IMAGER_LINE_VALID etc.)

     

    Ferhat

     

     

  • since you are specifyung device_type=0, it is looking for MT9001 board and this is indeed the reason you are seeing IC NACK errors. 

    FYI, you can find information on J30 and J31 in the hardware Technical Reference Manual for the EVM available from Spectrum Digital: http://c6000.spectrumdigital.com/evmdm355/revd/

  • When I looked at the Technical Reference Manual for the EVM only the pin names are given for the J30 and J31, not the meanings. I have a ST VS6724 camera module and I am trying to run it on DM355 EVM. It is not pin compatible for J30 and J31 so I need to know the MT9T001 at this point and the work that I have to do (writing a new driver, designing a daughter card etc.)

    About the Aptina MT9T001 ,

    It seems that it is just an image sensor isn't it?  Does it include a built in lens on it?  Is there any daughter card for that sensor which at least I can reach its schematic  ? 

    Could you please give me some part numbers for the sensor and daughter card?

     (I can not reach anybody from Aptina to ask these questions )

     

    Thank you for your helps.

    Ferhat

     

  • Ferhat OLGUN said:
    It seems that it is just an image sensor isn't it?  Does it include a built in lens on it?

    I would suppose that the part number by itself would be just the sensor, however I have only seen them in small modules with a lens.

    Ferhat OLGUN said:
    Is there any daughter card for that sensor which at least I can reach its schematic  ? 

    There is a daughter card out there from Leopard Imaging, however it does not look like the schematics are publicly available (at least I do not see them), you may want to ask them.

  • Ferhat OLGUN said:

    When I looked at the Technical Reference Manual for the EVM only the pin names are given for the J30 and J31, not the meanings. I have a ST VS6724 camera module and I am trying to run it on DM355 EVM. It is not pin compatible for J30 and J31 so I need to know the MT9T001 at this point and the work that I have to do (writing a new driver, designing a daughter card etc.) 

    The Technical Reference Manual from Spectrum Digital should contain the DM355 schematics which will allow you to map J30 and J31 signal names to DM355 pin names; you can look up the meaning of the pin names using the DM355 data-sheet (http://focus.ti.com/lit/ds/symlink/tms320dm355.pdf) and/or VPFE User Guide (http://focus.ti.com/lit/ug/spruf71a/spruf71a.pdf).

    You could theoretically design a small connector board that will map the pins from ST VS6724 camera module to J30 and J31 pins; then you will need to write you own driver for the ST VS6724 camera module (assuming one is not provided by vendor). 

    Analogously, in the case of the Leopard Imaging camera module (based on MT9T001), it was originally build for our DM6446 EVM; however, Leopard Imaging does provide a small connector board (similar to the one I suggested you build for STVS6724) that allows use with our DM355 EVM as well.  The software driver is avalable from Leopard Imaging and easily integrates with our DVSDK software.