碰到一个非常怪的关于ioremap_nocache的问题

Ohman

/*我用的内核是linux2.4.19-rmk7  芯片AT91rm9200*/

#define PHY_ADDR        0X30000000
#define PHY_REG_SIZE 0x10000000

volatile uint16 *io_base_addr;

if (NULL == request_mem_region(PHY_ADDR,PHY_REG_SIZE, "I/O Space"))
{
        printk(const char * fmt,...)(KERN_NOTICE
                "region 0x%x is already in use\n",  PHY_ADDR);
}

io_base_addr = ioremap_nocache(PHY_ADDR,PHY_REG_SIZE);
if (NULL == io_base_addr)
{
        printk(KERN_ERR "\r\n(io %d): can't set up page "
                 "mapping\n", io);
        return NULL;
}

/*1111*/printk(KERN_NOTICE
                        "io_base_addr = 0x%x \n",  io_base_addr);

/*2222*/printk(KERN_NOTICE
                        "io_base_addr = 0x%x \n",  io_base_addr+0x8100000);


问题是1111处的printk打印出来的是 0xc2c81000
而    2222处的printk打印出来的是 0xd2e81000
0xc2c81000 +0x8100000应该是等于0xCAD81000的


可能是个很弱的问题,但我就是不知是怎么回事,大家帮我分析一下.

0xfffff

咯 ....................干嘛不在2.6.18核心找 问题呢..... 要是有问题也是过去式了

Ohman

[quote:95538c27a9="0xfffff"]咯 ....................干嘛不在2.6.18核心找 问题呢..... 要是有问题也是过去式了[/quote]


我在用2.4.19开发啊,人家的DEMO是这个版本的,没时间移植

好象是找到问题,还是我太弱了,定义成uint16 *addr后,居然addr+offset实际得到的地址是addr+2*offset,看来真的是以半字来计算字节地址的