drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
sjb
sjb's picture
Level: Hangaround
Joined: Tue. Apr 24, 2007
Posts: 100 View posts
Location: UK
#1
Posted by sjb: Mon. Feb 4, 2008 - 07:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

dmesg gives...
...
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:12:58 2007 UTC).
ALSA device list:
No soundcards found.
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.

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. 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?).

Tags:

AVR Microcontrollers, AVR UC3
Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. Feb 5, 2008 - 01:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

-S.

Blag: http://www.niasdigital.com/blag

Top
sjb
sjb's picture
Level: Hangaround
Joined: Tue. Apr 24, 2007
Posts: 100 View posts
Location: UK
Posted by sjb: Tue. Feb 5, 2008 - 01:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I do have the 8563 driver compiler in, but no I didn't notice any mention of it in the logs. I'll get the 'scope on it tomorrow.

I assume I can test the I2c to the RTC chip by using the atmel_twi driver directly from user space. Do you know of any sample/example code that might help me write something to do this?

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. Feb 5, 2008 - 03:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

-S.

Blag: http://www.niasdigital.com/blag

Top
sjb
sjb's picture
Level: Hangaround
Joined: Tue. Apr 24, 2007
Posts: 100 View posts
Location: UK
Posted by sjb: Tue. Feb 5, 2008 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

2. 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?

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. Feb 5, 2008 - 11:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The attached patch should work for you.

As for userspace programming, I've never done it sorry. There are other threads on this forum describing how it might be done but IMO the easiest thing is probably to peek inside lmsensors.

lmsensors is the userspace tools for hardware monitoring and almost all hardware monitors talk i2c.

Good luck :-)

-S.

Attachment(s): 

let at32_add_device_twi take a board info struct for new-style i2c device tree generation

Blag: http://www.niasdigital.com/blag

Top
how
how's picture
Level: Posting Freak
Joined: Wed. Apr 26, 2006
Posts: 1079 View posts
Location: Trondheim, Norway
Posted by how: Wed. Feb 6, 2008 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That patch looks very useful. Could you post it to the kernel list with a proper signed-off-by line?

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Wed. Feb 6, 2008 - 12:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have it all lined up to send but my outgoing mail server is in paaaain. Shall post it asap, thx.

-S.

Blag: http://www.niasdigital.com/blag

Top
sjb
sjb's picture
Level: Hangaround
Joined: Tue. Apr 24, 2007
Posts: 100 View posts
Location: UK
Posted by sjb: Wed. Feb 6, 2008 - 02:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks. That a good start to get this working in the kernel.

I've just begun to look at this patch, and what else I need to do for my external RTC, and have spotted a couple inconsistencies...

1. I believe the patch ought to change the prototype in include/asm-avr32/board.h to match the extended function in arch/avr32/mach-at32ap/at32ap700x.c.

2. There are two identical prototypes for this function in include/asm-avr32/board.h - one on line 36, the other on line 72. Only one is needed.

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Wed. Feb 6, 2008 - 11:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are of course right, thanks.

Attached is a respun version.

how: It doesn't look like I'm going to be in email contact for a little while: the mail server is on strike and the IT guy is on a beach D: The attached patch has appropriate From and Signed-Off-By lines, feel free to grab it if the mood takes you.

Either way I'll post to lists asap.

Thx,
-S.

EDIT: A bit of USB-stick magic and it's away. Should be on-list now.

Attachment(s): 

Pass i2c board information through at32_add_device_twi()

Blag: http://www.niasdigital.com/blag

Top
sjb
sjb's picture
Level: Hangaround
Joined: Tue. Apr 24, 2007
Posts: 100 View posts
Location: UK
Posted by sjb: Thu. Feb 7, 2008 - 05:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Attachment(s): 

Fixes a bug with a buffer counter decrement. On I2c writes this bug caused 2nd byte to be missed and one byte read passed end of the buffer.
Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Fri. Feb 8, 2008 - 08:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Coolies, what kernel version? I'm assuming latest :-). Mind firing it through to kernel@avr32linux.org for review and inclusion?

Thx,
-S.

Blag: http://www.niasdigital.com/blag

Top
sjb
sjb's picture
Level: Hangaround
Joined: Tue. Apr 24, 2007
Posts: 100 View posts
Location: UK
Posted by sjb: Fri. Feb 8, 2008 - 08:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's against linux-2.6.23.atmel.4

I'm with a customer today, but I'll try to 'fire it through' when I get back. I'm not sure how to do this yet. Will they take a .atmel.4 patch ?

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Fri. Feb 8, 2008 - 09:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, that should be fine, it can be rebased if needed.

Make sure your email client doesn't mangle patches (replacing tabs with spaces is a big one) and format it like set out in Documentation/SubmittingPatches in the kernel source tree which would be as follows:

Quote:

[Description]

Signed-Off-By: Your Name
---
[Paste patch here]


^^ That bit between the signed off and patch should be 3 '-' characters in a row, that isn't clear in this font!

And that's it :-). It's really just the Signed-Off-By bit which affirms that you're the author of the patch, have the rights to submit it and can take credit for it.

Thanks mate,
-S.

Blag: http://www.niasdigital.com/blag

Top