大家有没有测试过skyeye 1.2.5 LCD模拟啊

zbluecn

在1.2.4中可以模拟LCD 1.2.5 就不可以了

duzhig

对啊 我测试也是 ./configure --enable-lcd make 然后测试还是不能打开LCD 1。2。4就可以为什么啊

ksh

目前LCD模拟在skyeye-1.2.5有些问题，目前还没有修复

duzhig

感觉好像不是gtk库连接的问题，用1。2。4的makefile也不行，有时间跟一下

duzhig

skyeye-1.2.5  LCD原来是GTK_LCD和LCD没有宏定义，在编译的时候没编译进去lcd相关功能改好以后
gdb跟踪发现还是出错在

gtk_lcd_open中

if ((fbmem = (guint32*)skyeye_find_lcd_dma(lcd_dev)) == NULL) {
                fprintf(stderr, "[GTK_LCD]: Can't find LCD DMA from address 0x%x\n", lcd_dev->lcd_addr_begin);
                return -1;
        }
       
skyeye_find_lcd_dma函数中

unsigned char* skyeye_find_lcd_dma (struct lcd_device *lcd_dev)
{
        unsigned char *dma = NULL;

        if (lcd_dev == NULL ||
            skyeye_config.arch == NULL ||
            skyeye_config.arch->arch_name == NULL) return NULL;

        if (strcmp(skyeye_config.arch->arch_name, "arm") == 0) { /* arm */
                extern mem_bank_t *bank_ptr(ARMword addr);
                mem_bank_t *mbp;
                ARMul_State *state = (ARMul_State*)lcd_dev->state;

                if(!(state == NULL || (mbp = bank_ptr(lcd_dev->lcd_addr_begin)) == NULL)) {
                        dma = (unsigned char*)(&state->mem.rom[(mbp - state->mem_bank->mem_banks)]
                                                              [(lcd_dev->lcd_addr_begin - mbp->addr) >> 2]);
                }
        }        }
       
这个函数什么意思DMA实现的原理大概是怎么进行的
其中运行到这里出错
dma = (unsigned char*)(&state->mem.rom[(mbp - state->mem_bank->mem_banks)]
                                                              [(lcd_dev->lcd_addr_begin - mbp->addr) >> 2]);
这个句子没怎么明白，state->mem.rom[X]是指针数组那后面的[(lcd_dev->lcd_addr_begin - mbp->addr) >> 2]
是怎么回事是2维数组吗还是当成指向指针的指针数组
不好意思我C基础不太好，请教一下

ksh

state->mem.rom[(mbp - state->mem_bank->mem_banks)][(lcd_dev->lcd_addr_begin - mbp->addr) >> 2]

state->mem.rom是skyEye模拟的内存数组，定义如下：
typedef struct mem_state_t
{
        ARMword *dram;
        ARMword *rom[ROM_BANKS];
        unsigned int rom_size[ROM_BANKS];
        uint8_t *tbp[ROM_BANKS];        //translate block pointer
        struct tb_s *tbt[ROM_BANKS];    //translate block structure pointer
} mem_state_t;
这个数组对应了我们在skyeye.conf写的bank的数量和大小，他是一个指针数组，可以理解为2维数组，行为bank的序号，第几个bank。列为bank内部的偏移量。lcd_dev->lcd_addr_begin可以理解为是在skyeye上运行的lcd的frame buffer的地址。 这句话，是为了获取 lcd_dev->lcd_addr_begin 这个地址在 state->mem.rom 中的地址。

[(mbp - state->mem_bank->mem_banks)] 可以得到是第几个bank
[(lcd_dev->lcd_addr_begin - mbp->addr) >> 2] 可以得到在这个bank中的偏移量，mbp->addr为这个bank的首地址。 右移两位是因为lcd_addr_begin是byte，我们这个数组是int。

duzhig

是不是可以理解state->mem.rom[(mbp - state->mem_bank->mem_banks)]是所在bank的地址
加上偏移[(lcd_dev->lcd_addr_begin - mbp->addr) >> 2]后得到的就是内存的实际内容了，然后在&state->XXX就是得到内容的起始地址啊谢谢
另外
                
Anthony Lee          
说到：

对比与 1.2.4 版本，现 SVN 上的版本 arch/arm/common/armmem.c 好像变化很大，
所以现在 LCD 仍然是用不了！请在补丁后看 device/lcd/skyeye_lcd.c 第 126 行。
请熟悉现在 mem_bank 机制的成员看看怎么修改吧。
原来是mem_bank 机制变化了吗
http://groups.google.com/group/s ... ad/eaf674abdff71cbd

duzhig

发现奇怪的问题
                ARMul_State *state = (ARMul_State*)lcd_dev->state;

                if(!(state == NULL || (mbp = bank_ptr(lcd_dev->lcd_addr_begin)) == NULL)) {
                        dma = (unsigned char*)(&state->mem.rom[(mbp - state->mem_bank->mem_banks)]
                                                              [(lcd_dev->lcd_addr_begin - mbp->addr) >> 2]);

ARMul_State *state   应该是全局的 ARMul_State吧，执行这句话以后发现lcd_dev->state并不等于全局的
里面的内容也是错的，所以运行结果出错
还有lcd_dev->lcd_addr_begin指向的是skyeye里跑的linux的fb内存的物理地址还是在host上的skyeye里的
内存地址，跟了一下发现lcd_dev->lcd_addr_begin＝0xc0f00000好像不是skyeye里的内存地址，
现在主要是数组mem.rom[(mbp - state->mem_bank->mem_banks)]有问题可能得到的mbp不对
state->mem.rom[x][xx]得到的是framebuffer真实的内容对吗
熟悉的帮忙看看

AnthonyLee

state 是 lcd_dev->state，来源于 mach->state。
我想当初 william 设计设备框架的时候是准备去除全局变量的，
因为不同架构的 state 数据结构不同。
此值应在每个 mach 中具体赋值，有如下：

        /* mach_set_intr, mach_pending_intr, mach_update_intr, state : for devices, such as NET,LCD etc. */
        this_mach->mach_set_intr = MACH_IO_SET_INTR_FUNC(s3c44b0x_set_interrupt);
        this_mach->mach_pending_intr = MACH_IO_PENDING_INTR_FUNC(s3c44b0x_pending_intr);
        this_mach->mach_update_intr = MACH_IO_UPDATE_INTR_FUNC(s3c44b0x_update_intr);
        this_mach->state = (void*)state;

lcd_dev->lcd_addr_begin指向的是skyeye里跑的linux的fb内存的物理起始地址。
此函数通过这个地址取得相对应的在 skyeye 里分配的内存起始地址。

这里得到的 dma 是为实际内存内容，
也即 little/big endian 两种字节序的模式其字节序对应也不同，
为加快图形缓冲区的转换，利用此内存直接进行色彩变换，
而非调用通用的 real_read_byte/half_word/word() 函数。

[ 本帖最后由 AnthonyLee 于 2008-7-29 22:10 编辑 ]

duzhig

lcd_dev->lcd_addr_begin指向的是skyeye里跑的linux的fb内存的物理起始地址。
这个lcd_dev->lcd_addr_begin好像一般不变啊，只有调用S3C2410_CHANGED（）的时候
才会改变，好像linux的fb驱动lcd_addr_begin使用固定的物理地址是吗

ksh

skyeye-1.2.5的lcd 的bug 已经fix,如链接所述： http://groups.google.com/group/s ... 04542d705?hl=zh-CN#

能否帮我测试一下？

duzhig

好的我明天测试一下，原来是编译选项的问题啊，我说怎么state指向的东西老是不对呢，呵呵，搞了好半天

duzhig

版主你的那个patch好像Makefile.am和utils/Makefile.am有点问题
我拿以前下载的skyeye-1.2.5的文件patch不上
我改了一下发上来吧
测试后lcd可以用了，主要是编译的时候宏定义没包含进来，
和连接的时候gtk的库的问题
http://groups.google.com/group/s ... 5_lcd.diff?hl=zh-CN

[ 本帖最后由 duzhig 于 2008-8-6 20:00 编辑 ]

crook

我从SVN下载最新的代码，打的patch， 编译测试了s3c2410的LCD。 没问题！

[ray@localhost arm-linux]$ patch -p0 < lcd_fix_anthony_mk.diff
patching file trunk/configure.in
Hunk #2 succeeded at 155 with fuzz 1.
patching file trunk/device/Makefile.am
patching file trunk/Makefile.am
patching file trunk/utils/Makefile.am

ksh

恩，如我贴中所说“I had tested my patch on head of trunk of svn repository”
我只在skyeye的svn的trunk上测试过，没有在skyeye-1.2.5上测试。所以有可能在 skyeye-1.2.5上打不上patch。