[U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Most of the time it's just:
""" Out: serial Err: serial i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write grp_sel to reg 96 (2) Die ID #500400029ff800000168300f0701b011 """
and the boot goes on fine.
But sometimes it's something like the below (which goes on indefinitely, preventing the platform from booting):
""" NAND: 512 MiB MMC: OMAP SD/MMC: 0 i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfd] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfd] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) [... more of these indefinitely ...] """
or it can be *some* error messages, but the boot goes on:
""" NAND: 512 MiB MMC: OMAP SD/MMC: 0 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0x6] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0x6] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 In: serial Out: serial Err: serial i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 7d (2) i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 91 (2) i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 99 (2) Die ID #500400029ff800000168300f0701b011 Net: smc911x-0 Hit any key to stop autoboot: 0 U-Boot # """
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
Best regards,
Thomas Petazzoni
Hi Thomas,
CC'ing Javier Martínez
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Right, I've reproduced the issue. Any OMAP3-based board affected for this issue ?
Most of the time it's just:
""" Out: serial Err: serial i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write grp_sel to reg 96 (2) Die ID #500400029ff800000168300f0701b011 """
and the boot goes on fine.
But sometimes it's something like the below (which goes on indefinitely, preventing the platform from booting):
""" NAND: 512 MiB MMC: OMAP SD/MMC: 0 i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfd] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfd] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) [... more of these indefinitely ...] """
Looks like there is problem with i2c pads, but seeing the code are configured.
or it can be *some* error messages, but the boot goes on:
""" NAND: 512 MiB MMC: OMAP SD/MMC: 0 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0x6] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0x6] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 In: serial Out: serial Err: serial i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 7d (2) i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 91 (2) i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 99 (2) Die ID #500400029ff800000168300f0701b011 Net: smc911x-0 Hit any key to stop autoboot: 0 U-Boot # """
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
Best regards,
I'll try to investigate more.
Best regards, Enric
Thomas Petazzoni
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Enric Balletbo Serra,
On Wed, 27 Nov 2013 14:56:15 +0100, Enric Balletbo Serra wrote:
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Right, I've reproduced the issue. Any OMAP3-based board affected for this issue ?
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
Best regards,
I'll try to investigate more.
Thanks! In the mean time, I'll just keep this commit reverted.
Best regards,
Thomas
Hi Thomas,
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Dear Enric Balletbo Serra,
On Wed, 27 Nov 2013 14:56:15 +0100, Enric Balletbo Serra wrote:
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Right, I've reproduced the issue. Any OMAP3-based board affected for this issue ?
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
Best regards,
I'll try to investigate more.
Thanks! In the mean time, I'll just keep this commit reverted.
Best regards,
Thomas
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Dear Enric Balletbo Serra,
On 11/27/2013 03:22 PM, Enric Balletbo Serra wrote:
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
On Wed, 27 Nov 2013 14:56:15 +0100, Enric Balletbo Serra wrote:
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Right, I've reproduced the issue. Any OMAP3-based board affected for this issue ?
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
not here on tricorder board, it has an AM37xx core.
Best regards
Andreas Bießmann
On 11/27/2013 04:22 PM, Enric Balletbo Serra wrote:
Hi Thomas,
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Dear Enric Balletbo Serra,
On Wed, 27 Nov 2013 14:56:15 +0100, Enric Balletbo Serra wrote:
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Right, I've reproduced the issue. Any OMAP3-based board affected for this issue ?
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of "i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)") message.
Thanks,
Thomas
On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of "i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)") message.
Thanks,
Thomas
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
Hi Nikita,all,
On 27-Nov-13 17:52, Nikita Kiryanov wrote:
On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of "i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)") message.
Thanks,
Thomas
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
I think you are on the right track.
Tom R, I guess I have been right back in spring when proposing this to be a driver for OMAP4+ only.
Best regards, Lubo
On Wed, Nov 27, 2013 at 06:01:18PM +0200, Lubomir Popov wrote:
Hi Nikita,all,
On 27-Nov-13 17:52, Nikita Kiryanov wrote:
On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of "i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)") message.
Thanks,
Thomas
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
I think you are on the right track.
Tom R, I guess I have been right back in spring when proposing this to be a driver for OMAP4+ only.
Well, the kernel driver handles omap1/2/3/4 so the problem is we aren't respecting (and tracking) the differences like we need to. I do not want to if at all possible have an omap3 driver (since we dropped omap24xx and will be dropping the last omap1 shortly) and an omap4+ driver that're pretty close, with just a few differences.
Hi Tom,
On Wed, Nov 27, 2013 at 06:01:18PM +0200, Lubomir Popov wrote:
Hi Nikita,all,
On 27-Nov-13 17:52, Nikita Kiryanov wrote:
On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
>Not sure to understand your question: my paragraph above mentions the >IGEP board as being the platform on which I'm seeing this. >So indeed, a >OMAP3-based board is affected. But maybe I misunderstood >your question. >
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of "i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)") message.
Thanks,
Thomas
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
I think you are on the right track.
Tom R, I guess I have been right back in spring when proposing this to be a driver for OMAP4+ only.
Well, the kernel driver handles omap1/2/3/4 so the problem is we aren't respecting (and tracking) the differences like we need to. I do not want to if at all possible have an omap3 driver (since we dropped omap24xx and will be dropping the last omap1 shortly) and an omap4+ driver that're pretty close, with just a few differences.
Generally you are right; the problem is that it is very hard, if ever possible, to test some piece of software on all targets that it would be run on, and account for every fancy silicon errata.
Regarding this particular issue, the clearing of the byte count reg is actually not needed at the end of every transaction. I guess it is some jic legacy from older times, and I also kept it (even excessively, it tuns out ;-) ) for some level of backward compatibility. Shall try to find some time next week to test the driver on all OMAP-based boards that I can gather with this operation removed from all functions and see what happens.
Thanks again everyone for catching and fixing this.
Regards, Lubo
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 17:52:31 +0200, Nikita Kiryanov wrote:
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
It works. I've removed all the writew(0, ...cnt register...), and then I've done at least 20 boots of the IGEP board, and all of them were successful.
I've attached the ugly patch that comments out all of those cases. Of course, it's not a patch intended for merging, just to show which locations I've commented.
Since I've absolutely no idea of the background for the problem, would you mind submitting a proper patch with a good explanation? I will be happy to test it, of course.
Thanks!
Thomas
On 11/27/2013 06:10 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 17:52:31 +0200, Nikita Kiryanov wrote:
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
It works. I've removed all the writew(0, ...cnt register...), and then I've done at least 20 boots of the IGEP board, and all of them were successful.
I've attached the ugly patch that comments out all of those cases. Of course, it's not a patch intended for merging, just to show which locations I've commented.
Since I've absolutely no idea of the background for the problem, would you mind submitting a proper patch with a good explanation? I will be happy to test it, of course.
Sure. I'm about to leave office though, so I'll prepare it tomorrow.
Thanks!
Thomas
Hi all,
2013/11/27 Nikita Kiryanov nikita@compulab.co.il:
On 11/27/2013 06:10 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 17:52:31 +0200, Nikita Kiryanov wrote:
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
It works. I've removed all the writew(0, ...cnt register...), and then I've done at least 20 boots of the IGEP board, and all of them were successful.
I've attached the ugly patch that comments out all of those cases. Of course, it's not a patch intended for merging, just to show which locations I've commented.
Since I've absolutely no idea of the background for the problem, would you mind submitting a proper patch with a good explanation? I will be happy to test it, of course.
Sure. I'm about to leave office though, so I'll prepare it tomorrow.
Thanks!
Thomas
-- Regards, Nikita.
Maybe I'm wrong but I think the problem could be related to that OMAP3430 and OMAP3630 has a different I2C revision and current code don't handle this correctly, As I know the I2C revision on OMAP3630 and OMAP4 is the same but different than OMAP3530. If the Tom's board uses the OMAP3530 processor this will explain why he's not affected for the issue. Others like me and Thomas, using DM3730, have the problem because the driver do not handle this, it supposes that we're using an OMAP3530.
See for example the following code in drivers/i2c/omap24xx_i2c.c,
#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) /* * Have to enable interrupts for OMAP2/3, these IPs don't have * an 'irqstatus_raw' register and we shall have to poll 'stat' */ writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE | I2C_IE_NACK_IE | I2C_IE_AL_IE, &i2c_base->ie); #endif
This is right for OMAP34/35xx but not for OMAP36xx and AM/DM37xx
As a reference see the following patch introduced in the kernel:
commit f518b482c89b3ff51804f09c14b1cedbef811b84 Author: Jon Hunter jon-hunter@ti.com Date: Thu Jun 28 20:41:31 2012 +0530
i2c: omap: Correct I2C revision for OMAP3
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C revision is the same for 3430 and 3530. However, the OMAP3630 device has the same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hunter@ti.com Changes from his patch - Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Reviewed-by: Felipe Balbi balbi@ti.com Signed-off-by: Jon Hunter jon-hunter@ti.com Signed-off-by: Shubhrajyoti D shubhrajyoti@ti.com Signed-off-by: Wolfram Sang w.sang@pengutronix.de
Best regards, Enric
On 11/27/2013 07:12 PM, Enric Balletbo Serra wrote:
Hi all,
2013/11/27 Nikita Kiryanov nikita@compulab.co.il:
On 11/27/2013 06:10 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 17:52:31 +0200, Nikita Kiryanov wrote:
The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well.
In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead.
What happens if you remove all the lines that zero the cnt register?
It works. I've removed all the writew(0, ...cnt register...), and then I've done at least 20 boots of the IGEP board, and all of them were successful.
I've attached the ugly patch that comments out all of those cases. Of course, it's not a patch intended for merging, just to show which locations I've commented.
Since I've absolutely no idea of the background for the problem, would you mind submitting a proper patch with a good explanation? I will be happy to test it, of course.
Sure. I'm about to leave office though, so I'll prepare it tomorrow.
Thanks!
Thomas
-- Regards, Nikita.
Maybe I'm wrong but I think the problem could be related to that OMAP3430 and OMAP3630 has a different I2C revision and current code don't handle this correctly, As I know the I2C revision on OMAP3630 and OMAP4 is the same but different than OMAP3530. If the Tom's board uses the OMAP3530 processor this will explain why he's not affected for the issue. Others like me and Thomas, using DM3730, have the problem because the driver do not handle this, it supposes that we're using an OMAP3530.
Well, this issue is mentioned in the errata for both OMAP3530 and DM3730, and the TRM for OMAP4430 mentions the same thing. It seems to me that the zeroing of cnt register being problematic is something the different OMAPs have in common.
Either way, these lines seem unnecessary, so I'm still in favor of removing them.
Best regards, Enric
On 11/27/2013 04:22 PM, Enric Balletbo Serra wrote:
Hi Thomas,
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Dear Enric Balletbo Serra,
On Wed, 27 Nov 2013 14:56:15 +0100, Enric Balletbo Serra wrote:
2013/11/27 Thomas Petazzoni thomas.petazzoni@free-electrons.com:
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Right, I've reproduced the issue. Any OMAP3-based board affected for this issue ?
Not sure to understand your question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question.
Oops, sorry, bad question :)
Anybody knows if other OMAP3-based boards are affected for this issue ?
Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata.
I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/
On Wed, Nov 27, 2013 at 01:19:29PM +0100, Thomas Petazzoni wrote:
Hello,
We've recently updated from u-boot 2013.04 to u-boot 2013.10 on our IGEP boards (OMAP3 based, U-Boot shows "OMAP36XX/37XX-GP ES1.2"), and we're seeing random I2C communication problems at startup.
Most of the time it's just:
""" Out: serial Err: serial i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write grp_sel to reg 96 (2) Die ID #500400029ff800000168300f0701b011 """
and the boot goes on fine.
But sometimes it's something like the below (which goes on indefinitely, preventing the platform from booting):
""" NAND: 512 MiB MMC: OMAP SD/MMC: 0 i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_write: pads on bus 0 probably not configured (status=0x10) i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfd] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfd] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xff] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) [... more of these indefinitely ...] """
or it can be *some* error messages, but the boot goes on:
""" NAND: 512 MiB MMC: OMAP SD/MMC: 0 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0x6] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0x6] Error 2 i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Read[0xfe] Error 2 i2c_write: pads on bus 0 probably not configured (status=0x10) TWL4030:USB:Write[0xfe] Error 2 In: serial Out: serial Err: serial i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 7d (2) i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 91 (2) i2c_write: pads on bus 0 probably not configured (status=0x10) Could not write vsel to reg 99 (2) Die ID #500400029ff800000168300f0701b011 Net: smc911x-0 Hit any key to stop autoboot: 0 U-Boot # """
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
I don't see this problem on my omap3_beagle, but I don't have that in heavy rotation either. Looking things over, can you try the following patch, which just drops the extra sanity check for unconfigured pads. The kernel doesn't have any logic like this and I suspect that while it's reliable enough of a check on some platforms, it's only true for the OMAP4+ variant of the block.
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c index 3d38c03..c870550 100644 --- a/drivers/i2c/omap24xx_i2c.c +++ b/drivers/i2c/omap24xx_i2c.c @@ -304,13 +304,6 @@ static int omap24_i2c_read(struct i2c_adapter *adap, uchar chip, uint addr, /* Send register offset */ while (1) { status = wait_for_event(adap); - /* Try to identify bus that is not padconf'd for I2C */ - if (status == I2C_STAT_XRDY) { - i2c_error = 2; - printf("i2c_read (addr phase): pads on bus %d probably not configured (status=0x%x)\n", - adap->hwadapnr, status); - goto rd_exit; - } if (status == 0 || status & I2C_STAT_NACK) { i2c_error = 1; printf("i2c_read: error waiting for addr ACK (status=0x%x)\n", @@ -344,17 +337,6 @@ static int omap24_i2c_read(struct i2c_adapter *adap, uchar chip, uint addr, /* Receive data */ while (1) { status = wait_for_event(adap); - /* - * Try to identify bus that is not padconf'd for I2C. This - * state could be left over from previous transactions if - * the address phase is skipped due to alen=0. - */ - if (status == I2C_STAT_XRDY) { - i2c_error = 2; - printf("i2c_read (data phase): pads on bus %d probably not configured (status=0x%x)\n", - adap->hwadapnr, status); - goto rd_exit; - } if (status == 0 || status & I2C_STAT_NACK) { i2c_error = 1; goto rd_exit; @@ -426,13 +408,6 @@ static int omap24_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr, while (alen) { /* Must write reg offset (one or two bytes) */ status = wait_for_event(adap); - /* Try to identify bus that is not padconf'd for I2C */ - if (status == I2C_STAT_XRDY) { - i2c_error = 2; - printf("i2c_write: pads on bus %d probably not configured (status=0x%x)\n", - adap->hwadapnr, status); - goto wr_exit; - } if (status == 0 || status & I2C_STAT_NACK) { i2c_error = 1; printf("i2c_write: error waiting for addr ACK (status=0x%x)\n",
Dear Tom Rini,
On Wed, 27 Nov 2013 09:45:55 -0500, Tom Rini wrote:
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
I don't see this problem on my omap3_beagle, but I don't have that in heavy rotation either. Looking things over, can you try the following patch, which just drops the extra sanity check for unconfigured pads. The kernel doesn't have any logic like this and I suspect that while it's reliable enough of a check on some platforms, it's only true for the OMAP4+ variant of the block.
Seems a little bit better with this patch. But now, amongst approximately 12 boots, I had two boots that failed with:
OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz IGEPv2 + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 512 MiB MMC: OMAP SD/MMC: 0 *** Warning - bad CRC, using default environment
Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_read: error waiting for addr ACK (status=0x0) TWL4030:USB:Read[0xfd] Error 1 [... more of the same stuff indefinitely ...]
Thanks!
Thomas
Hi Thomas
On Wed, Nov 27, 2013 at 4:35 PM, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:
Dear Tom Rini,
On Wed, 27 Nov 2013 09:45:55 -0500, Tom Rini wrote:
I see that 960187ffa125b3938fec4b827bd9e8c04a204af8 ("ARM: OMAP: I2C: New read, write and probe functions") has changed significantly the OMAP I2C driver. And it turns out that reverting this commit actually fixes the problem. No more error messages, no more hang at boot. The commit message says that it was tested on OMAP4, OMAP5 and AM335x, but apparently OMAP3 isn't working all that well with this commit.
I don't see this problem on my omap3_beagle, but I don't have that in heavy rotation either. Looking things over, can you try the following patch, which just drops the extra sanity check for unconfigured pads. The kernel doesn't have any logic like this and I suspect that while it's reliable enough of a check on some platforms, it's only true for the OMAP4+ variant of the block.
Seems a little bit better with this patch. But now, amongst approximately 12 boots, I had two boots that failed with:
OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz IGEPv2 + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 512 MiB MMC: OMAP SD/MMC: 0 *** Warning - bad CRC, using default environment
Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_write: error waiting for addr ACK (status=0x0) Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus 0 are properly configured i2c_read: error waiting for addr ACK (status=0x0) TWL4030:USB:Read[0xfd] Error 1 [... more of the same stuff indefinitely ...]
I had a problem in the past with fail communication with twl. Can you try the following code?
struct control_prog_io *prog_io_base;
prog_io_base = (struct control_prog_io *)OMAP34XX_CTRL_BASE;
/* Enable i2c2 pullup resisters */ writel(~(PRG_I2C2_PULLUPRESX | PRG_I2C1_PULLUPRESX), &prog_io_base->io1);
The pullup for twl bus should be enable by default on reset but for some reason that I had no time to investigate I found it asserted
Michael
Thanks!
Thomas
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (7)
-
Andreas Bießmann -
Enric Balletbo Serra -
Lubomir Popov -
Michael Trimarchi -
Nikita Kiryanov -
Thomas Petazzoni -
Tom Rini