uclinux-2008R1-RC8(bf561)到VDSP5的移植(58)

uclinux-2008R1-RC8(bf561)到VDSP5的移植(58): unable to open an initial console blog.

碰到一個郁悶的問題，提示” unable to open an initial console”後再沒有下文了。

搜了下這個錯誤出現的位置，在init_post函數中：

if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
　printk(KERN_WARNING "Warning: unable to open an initial console./n");

剛開始以為是沒有正確建立/dev/console的緣故，但是跟蹤進去後才發現不是那麼回事，/dev/console已經正確的創建了，問題出現在tty_open函數。

在這個函數裡，它首先取得console的tty_driver：

if (device == MKDEV(TTYAUX_MAJOR,1)) {
　driver = console_device(&index);
　if (driver) {
　　/* Don't let /dev/console block */
　　filp->f_flags |= O_NONBLOCK;
　　noctty = 1;
　　goto got_driver;
　}
　mutex_unlock(&tty_mutex);
　return -ENODEV;
}

看下console_device的實現：

/*
　* Return the console tty driver structure and its associated index
　*/
struct tty_driver *console_device(int *index)
{
　　　　 struct console *c;
　　　　 struct tty_driver *driver = NULL;

　　　　 acquire_console_sem();
　　　　 for (c = console_drivers; c != NULL; c = c->next) {
　　　　　　　　 if (!c->device)
　　　　　　　　　　　　　 continue;
　　　　　　　　 driver = c->device(c, index);
　　　　　　　　 if (driver)
　　　　　　　　　　　　　 break;
　　　　 }
　　　　 release_console_sem();
　　　　 return driver;
}

它將查找所有可用的console，找到一個提供了tty_driver的console並返回。在內核中，實際使用的console由bfin_serial_console（drivers/serial/bfin_5xx.c）這個全局變量來描述。在這個結構體中提供了device回調函數用以取得這個console所使用的tty_driver：

static struct console bfin_serial_console = {
　　　　 .name　　　　　　　　 = BFIN_SERIAL_NAME,
　　　　 .write　　　　　　　 = bfin_serial_console_write,
　　　　 .device　　　　　　 = uart_console_device,
　　　　 .setup　　　　　　　 = bfin_serial_console_setup,
　　　　 .flags　　　　　　　 = CON_PRINTBUFFER,
　　　　 .index　　　　　　　 = -1,
　　　　 .data　　　　　　　　 = &bfin_serial_reg,
};

看看uart_console_device函數（drivers/serial/serial_core.c）的代碼：

struct tty_driver *uart_console_device(struct console *co, int *index)
{
　　　　 struct uart_driver *p = co->data;
　　　　 *index = co->index;
　　　　 return p->tty_driver;
}

在這裡console的data指向bfin_serial_reg，這也是一個全局變量，其定義在drivers/serial/bfin_5xx.c文件中：

static struct uart_driver bfin_serial_reg = {
　　　　 .owner　　　　　　　　　　　　 = THIS_MODULE,
　　　　 .driver_name　　　　　　 = "bfin-uart",
　　　　 .dev_name　　　　 = BFIN_SERIAL_NAME,
　　　　 .major　　　　　　　　　　　　 = BFIN_SERIAL_MAJOR,
　　　　 .minor　　　　　　　　　　　　 = BFIN_SERIAL_MINOR,
　　　　 .nr　　　　　　　　　　 = NR_PORTS,
　　　　 .cons　　　　　　　　　　　　　 = BFIN_SERIAL_CONSOLE,
};

這裡沒有明確指出它使用的tty_driver。它將在uart_register_driver函數中動態創建。

/**
　*　　 uart_register_driver - register a driver with the uart core layer
　*　　 @drv: low level driver structure
　*
　*　　 Register a uart driver with the core driver.　 We in turn register
　*　　 with the tty layer, and initialise the core driver per-port state.
　*
　*　　 We have a proc file in /proc/tty/driver which is named after the
　*　　 normal driver.
　*
　*　　 drv->port should be NULL, and the per-port structures should be
　*　　 registered using uart_add_one_port after this call has succeeded.
　*/
int uart_register_driver(struct uart_driver *drv)
{
　　　　 struct tty_driver *normal = NULL;
　　　　 int i, retval;

　　　　 BUG_ON(drv->state);

　　　　 /*
　　　　　 * Maybe we should be using a slab cache for this, especially if
　　　　　 * we have a large number of ports to handle.
　　　　　 */
　　　　 drv->state = kzalloc(sizeof(struct uart_state) * drv->nr, GFP_KERNEL);
　　　　 retval = -ENOMEM;
　　　　 if (!drv->state)
　　　　　　　　 goto out;

　　　　 normal　 = alloc_tty_driver(drv->nr);
　　　　 if (!normal)
　　　　　　　　 goto out;

　　　　 drv->tty_driver = normal;

　　　　 normal->owner　　　　　 = drv->owner;
　　　　 normal->driver_name　　　 = drv->driver_name;
　　　　 normal->name　　　　　　 = drv->dev_name;
　　　　 normal->major　　　　　 = drv->major;
　　　　 normal->minor_start　　　 = drv->minor;
　　　　 normal->type　　　　　　 = TTY_DRIVER_TYPE_SERIAL;
　　　　 normal->subtype　　　　　　　 = SERIAL_TYPE_NORMAL;
　　　　 normal->init_termios　　 = tty_std_termios;
　　　　 normal->init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL;
　　　　 normal->init_termios.c_ispeed = normal->init_termios.c_ospeed = 9600;
　　　　 normal->flags　　　　　 = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
　　　　 normal->driver_state　　　 = drv;
　　　　 tty_set_operations(normal, &uart_ops);

　　　　 /*
　　　　　 * Initialise the UART state(s).
　　　　　 */
　　　　 for (i = 0; i < drv->nr; i++) {
　　　　　　　　 struct uart_state *state = drv->state + i;

　　　　　　　　 state->close_delay　　　　 = 500;　　　 /* .5 seconds */
　　　　　　　　 state->closing_wait　　　 = 30000;　 /* 30 seconds */

　　　　　　　　 mutex_init(&state->mutex);
　　　　 }

　　　　 retval = tty_register_driver(normal);
　out:
　　　　 if (retval < 0) {
　　　　　　　　 put_tty_driver(normal);
　　　　　　　　 kfree(drv->state);
　　　　 }
　　　　 return retval;
}

從這個函數知道，通過uart_driver->tty_driver可以取得一個uart_driver對應的tty_driver，而通過tty_driver->driver_state則可以取得相應的uart_driver，它們相互引用。通過tty_set_operations函數的調用，tty_driver取得了uart_ops這個結構體中的所有回調函數：

static const struct tty_operations uart_ops = {
　　　　 .open　　　　　　　　 = uart_open,
　　　　 .close　　　　　　　 = uart_close,
　　　　 .write　　　　　　　 = uart_write,
　　　　 .put_char = uart_put_char,
　　　　 .flush_chars　 = uart_flush_chars,
　　　　 .write_room　　 = uart_write_room,
　　　　 .chars_in_buffer= uart_chars_in_buffer,
　　　　 .flush_buffer = uart_flush_buffer,
　　　　 .ioctl　　　　　　　 = uart_ioctl,
　　　　 .throttle = uart_throttle,
　　　　 .unthrottle　　 = uart_unthrottle,
　　　　 .send_xchar　　 = uart_send_xchar,
　　　　 .set_termios　 = uart_set_termios,
　　　　 .stop　　　　　　　　 = uart_stop,
　　　　 .start　　　　　　　 = uart_start,
　　　　 .hangup　　　　　　 = uart_hangup,
　　　　 .break_ctl　　　 = uart_break_ctl,
　　　　 .wait_until_sent= uart_wait_until_sent,
#ifdef CONFIG_PROC_FS
　　　　 .read_proc　　　 = uart_read_proc,
#endif
　　　　 .tiocmget = uart_tiocmget,
　　　　 .tiocmset = uart_tiocmset,
};

現在回到tty_open函數上來。

在取得console driver之後，tty_open接著進行如下調用：

retval = init_dev(driver, index, &tty);

在這個調用中，初始化了一個tty_struct，並將此結構體中的driver成員設置為指向bfin_serial_console這個全局變量指定的tty_driver，也就是在uart_register_driver函數中創建的那個結構體，接下來：

if (tty->driver->open)
　　retval = tty->driver->open(tty, filp);
else
　　retval = -ENODEV;

從uart_register_driver函數可知，tty->driver->open這個回調函數指向uart_ops中的open回調函數，也就是uart_open（drivers/serial/serial_core.c）。

/*
　* In 2.4.5, calls to uart_open are serialised by the BKL in
　*　　 linux/fs/devices.c:chrdev_open()
　* Note that if this fails, then uart_close() _will_ be called.
　*
　* In time, we want to scrap the "opening nonpresent ports"
　* behaviour and implement an alternative way for setserial
　* to set base addresses/ports/types.　 This will allow us to
　* get rid of a certain amount of extra tests.
　*/
static int uart_open(struct tty_struct *tty, struct file *filp)
{
　　　　 struct uart_driver *drv = (struct uart_driver *)tty->driver->driver_state;
　　　　 struct uart_state *state;
　　　　 int retval, line = tty->index;
…………………………………………

　　　　 /*
　　　　　 * We take the semaphore inside uart_get to guarantee that we won't
　　　　　 * be re-entered while allocating the info structure, or while we
　　　　　 * request any IRQs that the driver may need.　 This also has the nice
　　　　　 * side-effect that it delays the action of uart_hangup, so we can
　　　　　 * guarantee that info->tty will always contain something reasonable.
　　　　　 */
　　　　 state = uart_get(drv, line);
　　　　 if (IS_ERR(state)) {
　　　　　　　　 retval = PTR_ERR(state);
　　　　　　　　 goto fail;
　　　　 }
…………………….
}

在這裡調用了uart_get函數：

static struct uart_state *uart_get(struct uart_driver *drv, int line)
{
　　　　 struct uart_state *state;
　　　　 int ret = 0;

　　　　 state = drv->state + line;
　　　　 if (mutex_lock_interruptible(&state->mutex)) {
　　　　　　　　 ret = -ERESTARTSYS;
　　　　　　　　 goto err;
　　　　 }

　　　　 state->count++;
　　　　 if (!state->port || state->port->flags & UPF_DEAD) {
　　　　　　　　 ret = -ENXIO;
　　　　　　　　 goto err_unlock;
　　　　 }
…………………….

　err_unlock:
　　　　 state->count--;
　　　　 mutex_unlock(&state->mutex);
　err:
　　　　 return ERR_PTR(ret);
}

在這裡，由於state->port指針為空，所以這個函數調用失敗，從而造成tty_open調用失敗，最後當然就提示unable to open an initial console了。

知道了錯誤發生的原因，開始解決這個問題，搜一下port這個關鍵字，最後發現唯一設置port成員的地方在uart_add_one_port函數中，這也是在uart_register_driver函數的注釋中所指出的，那麼又是在什麼地方會調用uart_add_one_port函數呢？

搜一下，有一個函數對它進行了調用，bfin_serial_probe函數（drivers/serial/bfin_5xx.c），而這個函數則是做為bfin_serial_driver這個結構體中定義的一個回調函數而存在。

static struct platform_driver bfin_serial_driver = {
　　　　 .probe　　　　　　　 = bfin_serial_probe,
　　　　 .remove　　　　　　 = bfin_serial_remove,
　　　　 .suspend = bfin_serial_suspend,
　　　　 .resume　　　　　　 = bfin_serial_resume,
　　　　 .driver　　　　　　 = {
　　　　　　　　　 .name　　　 = "bfin-uart",
　　　　 },
};

由此猜測，內核中應該要調用這個driver的probe回調函數的，但是由於某種原因沒有調用。

在內核驅動初始化的時候，將通過platform_driver_register進行bfin_serial_driver的注冊，如下所示：

static int __init bfin_serial_init(void)
{
　　　　 int ret;

　　　　 pr_info("Serial: Blackfin serial driver/n");

　　　　 bfin_serial_init_ports();

　　　　 ret = uart_register_driver(&bfin_serial_reg);
　　　　 if (ret == 0) {
　　　　　　　　 ret = platform_driver_register(&bfin_serial_driver);
　　　　　　　　 if (ret) {
　　　　　　　　　　　　　 pr_debug("uart register failed/n");
　　　　　　　　　　　　　 uart_unregister_driver(&bfin_serial_reg);
　　　　　　　　 }
　　　　 }
　　　　 return ret;
}

瞧瞧platform_driver_register函數做了麼事：

/**
　*　　 platform_driver_register
　*　　 @drv: platform driver structure
　*/
int platform_driver_register(struct platform_driver *drv)
{
　drv->driver.bus = &platform_bus_type;
　if (drv->probe)
　　　drv->driver.probe = platform_drv_probe;
　if (drv->remove)
　　　drv->driver.remove = platform_drv_remove;
　if (drv->shutdown)
　　　drv->driver.shutdown = platform_drv_shutdown;
　if (drv->suspend)
　　　drv->driver.suspend = platform_drv_suspend;
　if (drv->resume)
　　　drv->driver.resume = platform_drv_resume;
　return driver_register(&drv->driver);
}

嗯，調用了driver_register函數注冊一個device driver。注意，由於drv->driver指向的是一個結構體，而不是一個指針，因此只要知道drv->driver的地址，很容易就可以知道platform_driver這個結構體的頭指針。

在這裡，與probe相關的只有platform_drv_probe函數：

static int platform_drv_probe(struct device *_dev)
{
　struct platform_driver *drv = to_platform_driver(_dev->driver);
　struct platform_device *dev = to_platform_device(_dev);

　return drv->probe(dev);
}

據此可以猜測內核應該對每一個驅動都調用probe函數才對，為什麼不調用呢？

看看driver_register：

/**
　*　　 driver_register - register driver with bus
　*　　 @drv:　　　 driver to register
　*
　*　　 We pass off most of the work to the bus_add_driver() call,
　*　　 since most of the things we have to do deal with the bus
　*　　 structures.
　*/
int driver_register(struct device_driver * drv)
{
　　　　 if ((drv->bus->probe && drv->probe) ||
　　　　　　　　 (drv->bus->remove && drv->remove) ||
　　　　　　　　 (drv->bus->shutdown && drv->shutdown)) {
　　　　　　　　 printk(KERN_WARNING "Driver '%s' needs updating - please use bus_type methods/n", drv->name);
　　　　 }
　　　　 klist_init(&drv->klist_devices, NULL, NULL);
　　　　 return bus_add_driver(drv);
}

最後調用了bus_add_driver，這個函數實際上是將drv放到它的bus的設備鏈表中，從platform_register函數可知，它將存在在platform_bus_type這個全局變量的鏈表中：

struct bus_type platform_bus_type = {
　.name　　　　　　　　 = "platform",
　.dev_attrs　　　 = platform_dev_attrs,
　.match　　　　　　　 = platform_match,
　.uevent　　　　　　 = platform_uevent,
　.suspend = platform_suspend,
　.suspend_late = platform_suspend_late,
　.resume_early = platform_resume_early,
　.resume　　　　　　 = platform_resume,
};

現在的問題變為內核是否會檢測這個bus_type中的設備鏈表，並調用每個設備的probe函數。但是從上面的分析都無法看出哪裡調用了probe函數，看來得逆向分析一下，直接在代碼中搜索probe關鍵字，猜測有一個比較可能的調用：

static int really_probe(struct device *dev, struct device_driver *drv)
{
……………………

　　　　 if (dev->bus->probe) {
　　　　　　　　 ret = dev->bus->probe(dev);
　　　　　　　　 if (ret)
　　　　　　　　　　　　　 goto probe_failed;
　　　　 } else if (drv->probe) {
　　　　　　　　 ret = drv->probe(dev);
　　　　　　　　 if (ret)
　　　　　　　　　　　　　 goto probe_failed;
　　　　 }
………………………..
}

再搜索哪個地方調用了real_probe：

int driver_probe_device(struct device_driver * drv, struct device * dev)
{
　　　　 int ret = 0;

　　　　 if (!device_is_registered(dev))
　　　　　　　　 return -ENODEV;
　　　　 if (drv->bus->match && !drv->bus->match(dev, drv))
　　　　　　　　 goto done;

　　　　 pr_debug("%s: Matched Device %s with Driver %s/n",
　　　　　　　　　 drv->bus->name, dev->bus_id, drv->name);

　　　　 ret = really_probe(dev, drv);

done:
　　　　 return ret;
}

再搜索driver_probe_device：

static int __device_attach(struct device_driver * drv, void * data)
{
　　　　 struct device * dev = data;
　　　　 return driver_probe_device(drv, dev);
}

再搜索__device_attach：

int device_attach(struct device * dev)
{
　　　　 int ret = 0;

　　　　 down(&dev->sem);
　　　　 if (dev->driver) {
　　　　　　　　 ret = device_bind_driver(dev);
　　　　　　　　 if (ret == 0)
　　　　　　　　　　　　　 ret = 1;
　　　　　　　　 else {
　　　　　　　　　　　　　 dev->driver = NULL;
　　　　　　　　　　　　　 ret = 0;
　　　　　　　　 }
　　　　 } else {
　　　　　　　　 ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
　　　　 }
　　　　 up(&dev->sem);
　　　　 return ret;
}

看來我們已經一步步接近目標了。搜索device_attach：

void bus_attach_device(struct device * dev)
{
　　　　 struct bus_type *bus = dev->bus;
　　　　 int ret = 0;

　　　　 if (bus) {
　　　　　　　　 dev->is_registered = 1;
　　　　　　　　 if (bus->drivers_autoprobe)
　　　　　　　　　　　　　 ret = device_attach(dev);
　　　　　　　　 WARN_ON(ret < 0);
　　　　　　　　 if (ret >= 0)
　　　　　　　　　　　　　 klist_add_tail(&dev->knode_bus, &bus->klist_devices);
　　　　　　　　 else
　　　　　　　　　　　　　 dev->is_registered = 0;
　　　　 }
}

再找bus_attach_device：

int device_add(struct device *dev)
{
…………………………………………….
　　　　 bus_attach_device(dev);
……………………………………………
}

找device_add：

int platform_device_add(struct platform_device *pdev)
{
……………………………………………
　　　　 ret = device_add(&pdev->dev);
　　　　 if (ret == 0)
　　　　　　　　 return ret;
…………………………………………..
}

最後在arch/blackfin/mach-bf561/board/ezkit.c中發現了如下調用：

static int __init ezkit_init(void)
{
　int ret;

　printk(KERN_INFO "%s(): registering device resources/n", __func__);

　ret = platform_add_devices(ezkit_devices, ARRAY_SIZE(ezkit_devices));
　if (ret < 0)
　　return ret;

#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
　　　　 bfin_write_FIO0_DIR(bfin_read_FIO0_DIR() | (1 << 12));
　　　　 SSYNC();
#endif

#if defined(CONFIG_SPI_BFIN) || defined(CONFIG_SPI_BFIN_MODULE)
　　　　 spi_register_board_info(bfin_spi_board_info,
　　　　　　　　　　　　　　　　　　 ARRAY_SIZE(bfin_spi_board_info));
#endif

#if defined(CONFIG_PATA_PLATFORM) || defined(CONFIG_PATA_PLATFORM_MODULE)
　　　　 irq_desc[PATA_INT].status |= IRQ_NOAUTOEN;
#endif
　　　　 return 0;
}

arch_initcall(ezkit_init);

哈哈哈，原來是這麼回事，將ezkit.c加到工程中後編譯，搞定。