EzDoum

찾기
처음으로 | 찾기 | 아카이브 | 글 올리기 | 링크 | 자료실 | 통계 | 연락처 | 자유게시판
이지도움 특집
전체보기
네트워크
TI OMAP35x
TI DaVinci
Analog Blackfin
RobotWar2005
임베디드!
캐쉬의 모든것
메모리 할당 알고리즘
CPU 파이프라이닝
자료구조(Tree)
금융

Login
이름

암호

기억하기


사용자 등록

현재 접속중인 등록 사용자는 0명, 익명 사용자는 4명 입니다.
전체 등록 사용자: 751명

마지막 답장
·libcurl + fuse 조합으로 되는게 많네. (1)
·Linux Ftrace에 관해 (3)
·Android MTP ( Media Transfer Protocol ) (1)
·Lighttpd에 인증을 digest 사용시 IE 오동작 문제? (1)
·Dtrace에 관해 (1)

최근글
·OpenSSL and multi-threads (0)
·ARM 환경에서 OpenCL 사용 (0)
·IoT용 WIFI 모듈 비교 ( MCU ) 클래스 (0)
·Glances - 리눅스 여러 가지 항목을 한 화면에서 모니터링 (0)
·plugin 방식의 로그 분석기 (0)

뜨거운 감자
·나는 인터렉티브한 환경에서 역어셈블 한다. (12)
·GNU REGEX (정규표현식) 프로그래밍 강좌 (7)
·SoCRobotWar 2005 - 신입생 기초 교육자료 (7)
·ASP.NET의 데이터 그리드와 사용자 컨트롤 (7)
·DHTML Editing Control (7)

가장 많이 읽은 글
·[Cache] 2-way Set-Associative 방식이란 무엇일까? (2)
·멀티쓰레드(Pthread) 프로그래밍
·GNU REGEX (정규표현식) 프로그래밍 강좌 (7)
·Sorting Algorithm Animation (2)
·SoCRobotWar 2005 - 신입생 기초 교육자료 (7)

DaVinci - 메일링 리스트 내용정리
글쓴이: EzDoum 글쓴날: 2007년 01월 23일 오후 03:22
하드웨어



메일링 리스트 중에 괜찮은 내용들은 여기에 모아둘테다!!.

프레임 버퍼를 크게 쓰고 싶은데, mmap 때문에 제약 사항이 있네.


Amol Lad wrote:
> Part 2:
>
> How Linux framebuffer maps to these windows ? i.e. Is
> /dev/fb0 maps to OSD window 0 and so on...
>
> Can I configure framebuffer device in 1280x720 mode ?
> (This should be possible as the spec says the chips
> support YPbPr component video, so framebuffer should
> also support 1280x720 resolution...)
I also tried to get a higher resolution by modifying the encodedecode
example sources but failed with a EINVARG return value of mmap() because
there is a limitation in the DMA-based mapping of 2MB. So just 720 x 576 x
16bit x 2buffers seems to be supported.
I someone can show a way out of this limitation I'd be very happy, because I
also want a VGA video output of 1280 x 1024 (4:3 PC display, not TV).

--------------------------------


OSD/Video window in Davinci
Amol Lad
Wed, 20 Sep 2006 01:48:15 -0700

Hi,

There are two parts to my queries:

Part 1:

My graphical application requires RGB888A support from
the platform. (R = 8 bits , G = 8 bits , B = 8 bits ,
Alpha = 8 bits)

I'm going through DaVinci specs and I understood
below:
1. Two OSD windows and they can be only configured for
max 16 bit color (R = 5, G = 6, B = 5).
2. Video window 1 can be configured to read 24 bit RGB
data.

If I'm to run my application on Davinci then do I need
to use Video window 1 for the display ? In this case,
can I blend video window 1 data with video window 0
data (which is used for displaying video) ?

Part 2:

How Linux framebuffer maps to these windows ? i.e. Is
/dev/fb0 maps to OSD window 0 and so on...

Can I configure framebuffer device in 1280x720 mode ?
(This should be possible as the spec says the chips
support YPbPr component video, so framebuffer should
also support 1280x720 resolution...)

Thanks


  • 관련 링크
  • [분류: 하드웨어 인쇄용 페이지 본문 email로 보내기 ]

    <  무료 E-Mail Icon, Favicon을 만들어주는 주소 총집합 | DaVinci - Embedded Linux  >
    DaVinci - 메일링 리스트 내용정리 | 답장: 5개 | 본문에 답장
    정렬 :  
    답장 EzDoum 2007년 01월 23일 오후 03:33 [ 이글에 답장 | 본문에 답장 | 책갈피 ]
    http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg01489.html

    Can the ARM and DSP accessing the RAM simulatenously?
    Andy Ngo
    Wed, 17 Jan 2007 16:57:45 -0800

    I have question that I wanted to ask. The DVEVM board has 256 MB DDR RAM
    available to the ARM and DSP; according to the document
    that comes with codec examples, this RAM is partitioned as follows:

    · 0x80000000 .. 0x87800000 (0-120MB; size 120MB): Linux, booted with MEM=120M
    · 0x87800000 .. 0x88000000 (120-128MB; size 8MB): CMEM -- shared buffers between Arm, DSP
    · 0x88000000 .. 0x8FA00000 (128-250MB; size 122MB): DDRALGHEAP (*)-- DSP segment used exclusively for algorithm heaps
    · 0x8FA00000 .. 0x8FE00000 (250-254MB; size 4MB): DDR (*)-- DSP segment for code, stack, static data, and system dynamic data
    · 0x8FE00000 .. 0x8FF00000 (254-255MB; size 1MB): DSPLINKMEM (*) memory for DSPLINK
    · 0x8FF00000 .. 0x8FF00080 (255MB-255MB; size 128B): CTRLRESET (*) memory for reset vectors)
    · 0x8FF00080 .. 0x8FFFFFFF (255MB-256MB; size 1MB): waste

    Since this DDR RAM is physically being shared by both the ARM and DSP, does
    this mean only one can access the RAM at a time? For
    example, if the DSP is accessing RAM, does that mean the ARM is put on hold if
    it trying to use RAM at that time? If this is the case, then
    the ARM and DSP cannot operate simultaneously and there is a performance issue?
    I’m asking because my hardware engineer believes that is
    the case since both the ARM and DSP are using the same bus to access the same
    DDR RAM chip so only one of them can access the RAM at a given
    time, regardless of the actual location within the 256 MB space. This is most
    likely not the case but I need to know why so I can convince my
    hardware engineer. I want him to put a similar 256 MB chip on our custom
    board, but he insists on putting a 128MB for the ARM and a dedicated
    tiny 512 Kb for the DSP (which I told him is not enough for CE server I'm
    trying to run on the DSP).

    I appreciate your response. Thanks.

    Regards,
    Andy

    _______________________________________________

    RE: Can the ARM and DSP accessing the RAM simulatenously?
    Azbell, Brandon
    Wed, 17 Jan 2007 17:54:42 -0800

    Andy,



    The DM6446 has exactly 2 memory interface busses on it. One
    interfaces to DD2 memories and the other is the EMIFA, which can support
    Asynchronous SRAM and Flash.

    These 2 memory interfaces are completely independent of each other. At any
    given moment in time, one and only one transaction, or access, can/will occur
    on each bus. The master/initiator of that access for each memory interface can
    be one of many different masters inside the device, including the ARM, DSP,
    EDMA, VPSS, EMAC, USB, etc. Due to the Switched Central Resource internal bus
    architecture, multiple masters can access different targets simultaneously, as
    long as they are not conflicting for the same resource. If they do conflict,
    then yes, one of them will be stalled.

    You really need to make an assessment as to why having a different
    memory, connected to the EMIFA which the DSP would use, is necessary. What is
    the motivation? Is the motivation based on something you have measured using
    the DVEVM, or is it perception?



    Based on the scenario that you illustrated below:



    "Since this DDR RAM is physically being shared by both the ARM and DSP, does
    this mean only one can access the RAM at a time? For

    example, if the DSP is accessing RAM, does that mean the ARM is put on hold if
    it trying to use RAM at that time? If this is the case, then

    the ARM and DSP cannot operate simultaneously and there is a performance issue?
    I'm asking because my hardware engineer believes that is

    the case since both the ARM and DSP are using the same bus to access the same
    DDR RAM chip so only one of them can access the RAM at a given

    time, regardless of the actual location within the 256 MB space."



    If both the ARM and DSP are accessing DDR2 memory (for instance) at
    the same time, one of them will be stalled. You can not physically have 2
    accesses occurring at the same time on the same bus. Look at it this way, if
    both the ARM and DSP were writing a value to DDR2, what would you expect to see
    on the 32-bit data bus in a given clock cycle: data from the ARM, or data from
    the DSP?

    Regards,

    Brandon Azbell
    Texas Instruments
    Senior, Group Technical Staff
    System Applications


    [수정]

    답장 EzDoum 2007년 01월 23일 오후 03:43 [ 이글에 답장 | 본문에 답장 | 책갈피 ]
    http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg00573.html

    Re: DaVinci MV linux Fast Real-Time Domain Configuration
    Kevin Hilman
    Mon, 16 Oct 2006 09:49:07 -0700

    XiweiWang wrote:
    > Hello,
    >
    >
    >
    > I want to build a kernel that support realtime thread,so i open
    >
    > the realated option :

    >
    > Library routines --->
    >
    > Fast Real-Time Domain --->
    >
    > Fast Real-Time Domain --->
    >
    > (8) Number of real-time threads to run
    >
    > Fast Real-Time Domain Advanced Options --->
    >
    >
    >
    > but when i compile it the compiler report the error message:
    >
    > In file included from include/linux/frd.h:25,
    >
    > from kernel/timer.c:38:
    >
    > include/asm/frd.h:15:26: asm/arch/frd.h: 没有那个文件或目录
    >
    > make[1]: *** [kernel/timer.o] Error 1
    >
    > make: *** [kernel] Error 2
    >
    > I do my best to find this file ,but finally faild. Is any one who can help me!
    >

    YOu have an early, pre-release version of the MV kernel where FRD was
    not supported. The final release has a working FRD.

    Kevin
    [수정]

    답장 EzDoum 2007년 01월 23일 오후 07:30 [ 이글에 답장 | 본문에 답장 | 책갈피 ]
    RE:Using both ATA and EMIF
    Satheesh S.
    Mon, 30 Oct 2006 19:58:36 -0800

    Hello Johannes,

    EMIFA and ATA are multiplexed modules. You cannot access both
    simultaneously. This is clearly documented in the EMIFA and ATA/CF pin
    terminal function tables. Please refer to Section 3.6.6.4 of
    TMS320DM6446 Datasheet.

    Regards,
    Satheesh S


    Using both ATA and EMIF
    chendh
    Wed, 15 Nov 2006 00:41:23 -0800

    hi,everyone
    I have tried to use both ata and emif, they can be used at the same time.I try
    to send some control commands via EMIF, while copy some data to ATA hard disk.
    you can just to use they as follows:
    1)change PINMUX0 to enable ATA after kernel boot time
    2)when you want to use emif bus to control some device, you can change PINMUX0
    to disable ATA and enable EMIF,then do something.
    3)after finishing to use emif, change PINMUX0 to enable ATA, now ata is
    accessible

    notice:
    1)the occasion to change PINMUX0 to enable EMIF is very important, you must
    ensure ATA has finished one operation, otherwise, may cause errors.
    I know how to ensure it when access ATA hard disk via PIO mode, but don't known
    how to do it when access ATA hard disk via DMA or UDMA mode, Can anybody help
    me?

    ------------------------------------------
    jit chen
    ANHUI USTC iFLYTEK CO.,LTD


    [수정]

    답장 EzDoum 2007년 01월 23일 오후 07:31 [ 이글에 답장 | 본문에 답장 | 책갈피 ]
    Connecting a different video sensor to the DaVinci
    Bill Lawson
    Fri, 15 Sep 2006 13:20:14 -0700

    Hi All,

    We are trying to connect a different CCD video sensor to the DaVinci in place of the tvp5146. Our sensor can output a number of different video formats. Currently it is configured for YCbCr 4:2:2. What files will need to be modified to make the VPFE use our sensor? I assume that the following files will need to be changed: drivers/media/video/davinci_vpfe.c, and drivers/media/video/ccdc_davinci.c as well as their header files. Are there any other that I will need to modify? What kind of changes will I need to make? Any advice will be greatly appreciated.

    Thanks,
    Bill Lawson

    RE: Connecting a different video sensor to the DaVinci
    Scherrer Stefan (scherste)
    Fri, 15 Sep 2006 15:37:15 -0700

    Hi Bill,



    We also try to connect a CMOS Camera to davinci, but didn't get it to work till
    now.



    To get I2C connection to our camera, we changed the tvp5146 file. We disabled
    the original i2c_write_reg and added a new one with the address of our cam.
    This works and we can change registers. (to deselect tvp5146 you have to set
    pin "capture_enable" on DC4 to 1.8V)



    Our camera supports ITU 656 protocol as tvp5146 do. But our camera has
    progressive scanning instead of interlaced(PAL).



    In the davinci_vpfe we changed to progressive and changed the solution
    according to our camera.

    We also tried to change the interrupt service routine, because we think that we
    don't have to toggle if we don't have interlaced scanning.



    The ITU-Header generates interrupts, but something is wrong with writing in
    memory. We only get a screen with green and red bars.



    the ccdc_davinci we didn't change.



    Anybody with more experience around?



    Greets Stefan

    Re: Connecting a different video sensor to the DaVinci
    Hiroshi Uchino
    Sun, 17 Sep 2006 17:57:38 -0700

    Hi,

    I've attatched 1.3M CMOS camera module to DC4.
    It's still in the middle of development, but I can get images viaV4L2 API.

    The camera outputs YCC422 8bit data, pixel clock, HSYNC, VSYNC.
    I don't use CCIR656 mode (REC656IF R656ON=0), so register settings
    may be a bit different, but the way to capture data into DDR2 should be
    almost the same.

    What I modified are follows.

    drivers/media/video/davinci_vpfe.c
    change video format, default parameters
    modified vpfe_isr for progressive mode
    v4l2 apis (camera parameter get/set etc.)

    drivers/media/video/ccdc_davinci.c
    modified to use PACK8 mode

    drivers/media/video/mc3xd.c
    camera driver to initialize, control my camera (based on tvp5146.c)

    include/media/ccdc_davinci.h
    include/media/davinci_vpfe.h
    add some definitions

    include/media/mc3xd.h
    definition for my camera driver (based on tvp5146.h)

    Regards,
    Hiroshi
    [수정]

    답장 EzDoum 2007년 01월 23일 오후 07:32 [ 이글에 답장 | 본문에 답장 | 책갈피 ]
    LCD attached, image shrinked
    Carlos Ojea
    Fri, 15 Sep 2006 04:51:23 -0700

    Hello

    I attached a LCD and I am looking for proper VPBE configuration.
    For now, I am able to see the full image, but shrinked to the upper
    part of the LCD.
    Anyone knows the reason of this behaviour?
    Maybe a bad Horizontal interval (VPBE_HINT)?




    Re: LCD attached, image shrinked
    Carlos Ojea
    Mon, 18 Sep 2006 05:23:30 -0700

    > Try to set VIDWIN0OFST, VIDWIN1OFST, OSDWIN0OFST,
    > OSDWIN1OFST to half of current setting.
    >
    > When I attatched WideVGA LCD(800x480), according to sprue37 6.3.7,
    > VIDWIN0OFST shoud be 800*2/32=0x32 (Video Window 0 is YCC mode),
    > but this results in vertically shrinked image.
    > In this case, by setting VIDWIN0OFST to 0x19 (0x32/2), the image
    > became normal.
    > It seems window offset has something to do with setting of DCLKCTL.

    Thank you Hiroshi !! Now it works with OSD windows !!
    I am using : (640*2/32) / 2 = 0x14 for OSD_OSDWIN0OFST

    However OSD_VIDWIN0OFST and OSD_VIDWIN0OFST have actually a value of
    (720*2/32) = 45 = 0x2D, so I can't divide it by 2.
    I tried with 0x16 (22) and 0x17 (23), but video lines are not aligned ...

    Do you have any idea about how to solve this problem? Maybe changing
    DCLKCTL?

    Finally I am using a 640x480 video so it works now with (640*2/32) /
    2 = 0x14 for OSD_VIDWIN1OFST

    Thank you Hiroshi!
    Regards,
    Carlos
    [수정]

    DaVinci - 메일링 리스트 내용정리 | 답장: 5개 | 본문에 답장
    정렬 :  

    답장 쓰기
    글을 올리시려면 로그인 (사용자 등록) 하셔야 합니다.

    검색
    Google

    분류
    ·공지 (6)
    ·인터넷 (87)
    ·하드웨어 (260)
    ·C/C++ (65)
    ·어셈블리 (7)
    ·리눅스 (136)
    ·리눅스 커널 (67)
    ·윈도우즈 (25)
    ·데이터베이스 (20)
    ·보안 (16)
    ·.NET (25)
    ·그래픽 (13)
    ·책소개 (42)
    ·호기심 천국 (80)
    ·잡담 (111)
    ·사랑 (3)

    전체 본문수: 963
    전체 답장수: 525


    분류 : 하드웨어
    최근글
    최근글
    가장 많이 읽은 글
    ·[Cache] 2-way Set-Associative 방식이란 무엇일까? (2)
    뜨거운 감자
    ·SoCRobotWar 2005 - 신입생 기초 교육자료 (7)

    EzDoum투표
    이지도움 어때요?
    이게 뭐야. 다시 안올란다. --;
    아이 좋아라~ +_+;
    관심없다.
    먼가는 있는거 같은데 뭐하는 곳이지?
    기타 (자유게시판에 글로 남겨 주세요)
    [ 결과 | 투표 ]

    랜덤 링크
    http://kldp.net


     Home ^ BACK TO TOP ^ EzDoum - 도움이 필요하세요~??
     Powered by KorWeblog 1.5.8 Copyleft © 2001 EzDoum, 관리자: EzDoum