I'm seeing initialisation problems with the rtc driver It's compiled in to the kernel (not a module - in fact I have everything compiled in, no modules at all). I2c /dev entries driver atmel_twi atmel_twi.0: Atmel TWI/I2C adapter (baudrate 100k) at 0xffe00800. Mmc_host mmc0: Atmel MCI controller at 0xfff02400 irq 28 Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09: UTC). ALSA device list: No soundcards found. Drivers/rtc/hctosys.c: unable to open rtc device (rtc0) VFS: Mounted root (jffs2 filesystem). Unable To Open Rtc Device![]() Freeing init memory: 56K (90000000 - 9000e000) Mounting virtual filesystems: /proc mounted /sys mounted /dev mounted /dev/pts directory made. This is on a circuit derived from the STK1000/1002 but I'm using a Philips 8563 device, not the internal rtc. Kernel is configured with I2c bit bang off, atmel_twi on. I'm using the patch supplied by lubos (Jan 18 ) which seems to fix the atmel_twi driver. After boot I see no /dev/rtc0 was created. Also, /sys/class/rtc exists but is an empty directory, but I'm not sure waht that means. The rtc driver fails in initialisation when it tries to open the device. I'm beginning to wonder if it's trying to access /dev/rtc0 before /dev/rtc0 is created. Drivers/rtc/hctosys.c: unable to open rtc device (rtc0) VFS: Mounted root (jffs2 filesystem). Freeing init memory: 56K (90000000 - 9000e000) Mounting virtual filesystems: /proc mounted /sys mounted /dev mounted /dev/pts directory made. This is on a circuit derived from the STK1000/1002 but I'm using a Philips 8563 device, not the internal rtc. Has this driver known to work. If so has it been used as built in to the kernel or just as a module? (Or am I barking up the wrong tree?). The hctosys driver isn't in fact an RTC driver in it's own right, it's a small nugget of kernel code which, when enabled, will try and read an RTC and set the system time to this time on startup. Since its in-kernel it doesn't use the /dev interface and so (confusingly) rtc0!= /dev/rtc0 What seems to be going wrong is that the driver for _your rtc_ isn't working correctly so when it comes time for hctosys to try and read from it, the read fails. Do you have the driver for the 8563 built in or just hctosys? Can you see anything earlier in your bootlogs which would have come from the 8563 driver complaining that something exploded? If you've got a CRO, can you see activity on the RTC's sda/scl lines? If you see _nothing_ from that driver then there's a good chance it's not being bound to a device and therefore not being loaded. Have you told the board setup code that your RTC exists? I'm not 100% sure how this is supposed to be done for old-style I2C drivers, or even whether the 8563 driver is old or new style, but you'll probably have to fill out a struct i2c_board_info[] array just as is done for SPI. In that array you specify the slave address and driver alias of each device on the bus. Then pass that to i2c_register_board_info() along with the bus number and number of devices. See include/linux/i2c.h starting at line 206 (as of 2.6.23) for details. There seems to be no support for attached devices in the current avr32 code (at32ap700x.c) as unlike at32_add_device_spi(), the equivant at32_add_device_twi() takes no *_board_info[] array. So I think I have two options: 1. Fix at32_add_device_twi() so it takes and uses board info arrays (presumably using other architectures as a guide). English question tags exercises. Drop the PCF8563 and the RTC drivers out of the kernel and write a user space program to read the time from the PCF8563 using the atmel_twi, and use this to set the time at start up. The later sound easier, and would be a useful precursor to the former anyway. So, does anyone know of any sample/example code that might help me write the atmel_twi (=i2c I assume) control code in user space? I'm still having problems getting the kernel driver for the pcf8563 to work, so have been looking a simple user space test application, and using a 'scope to diagnose problems. This has shown up a bug in the atmel twi driver that has two symptoms: 1. On a multi-byte write on the I2C the 2nd byte is missing 2. The last byte that's sent is one byte past the end of the write buffer. This will affect all write of two or more consecutive data bytes on the twi/i2c bus (not just to pcf8563 devices). The attached patch fixes this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |