[U-Boot] RTC value corruption on QIL-A9G20 startup
Hello Albin,
I tried using your patches for the TNY-A9G20 on my QIL-A9G20 board from Calao. Everything seems to work properly except the RTC. They use the same M41T94 part and the CS is the same on both boards (PA3). I can set the RTC using the "date" command and read back the value okay. However, when I power cycle the board, the value is getting corrupted at startup due to some erroneous SPI write.
I don't believe the code you submitted is causing this problem because the RTC is getting corrupted even if I compile out SPI and RTC support completely. I was just wondering if you have seen this problem on your board? I probed the CS line with an oscilloscope and I am definitely seeing it go low on U-Boot startup for a short time, but the clock line seems to be floating. I believe the activation of the CS at startup is causing junk data to be written to the RTC, which is corrupting it. Any idea why this might be happenning?
Regards, Stephen
Hi Stephen,
On Mon, Aug 24, 2009 at 10:01:16PM -0400, Stephen Caudle wrote :
I tried using your patches for the TNY-A9G20 on my QIL-A9G20 board from Calao.
I guess you mean SBC35-A9G20?
Everything seems to work properly except the RTC. They use the same M41T94 part and the CS is the same on both boards (PA3). I can set the RTC using the "date" command and read back the value okay. However, when I power cycle the board, the value is getting corrupted at startup due to some erroneous SPI write.
I don't believe the code you submitted is causing this problem because the RTC is getting corrupted even if I compile out SPI and RTC support completely. I was just wondering if you have seen this problem on your board?
Yes, I also experience this issue.
I probed the CS line with an oscilloscope and I am definitely seeing it go low on U-Boot startup for a short time, but the clock line seems to be floating. I believe the activation of the CS at startup is causing junk data to be written to the RTC, which is corrupting it. Any idea why this might be happenning?
Currently, I don't really have any idea. Besides, it's going to be hard for me to debug this, as I don't have an oscilloscope at hand. Would you please try to run u-boot within a debugger to see where exactly the CS line is driven low?
Thanks for your feedback. Regards,
Hi,
Albin Tonnerre a écrit :
Currently, I don't really have any idea. Besides, it's going to be hard for me to debug this, as I don't have an oscilloscope at hand. Would you please try to run u-boot within a debugger to see where exactly the CS line is driven low?
isn't the RTC connected to the SPI chip select that the internal firmware toggle on boot to probe for a SPI Flash ?
Eric
Hello Eric,
On Tue, Aug 25, 2009 at 5:38 AM, Eric Bénarderic@eukrea.com wrote:
isn't the RTC connected to the SPI chip select that the internal firmware toggle on boot to probe for a SPI Flash ?
That is certainly possible. This problem went away for me when I upgraded to the "next" branch. Could the SPI dataflash code have been removed between v2009.06 and "next"? I'll look into this some more. Thanks for the hint!
Regards, Stephen
On Tue, Aug 25, 2009 at 08:51:56AM -0400, Stephen Caudle wrote :
Hello Eric,
On Tue, Aug 25, 2009 at 5:38 AM, Eric Bénarderic@eukrea.com wrote:
isn't the RTC connected to the SPI chip select that the internal firmware toggle on boot to probe for a SPI Flash ?
That is certainly possible. This problem went away for me when I upgraded to the "next" branch. Could the SPI dataflash code have been removed between v2009.06 and "next"? I'll look into this some more. Thanks for the hint!
Using the "next" branch doesn't help here. Anyway, the code Eric is referring to is the firmware code the CPU executes from its internal ROM very early in the boot process, so you likely won't find anything remotely related to this in U-Boot.
Regards,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albin Tonnerre Sent: Tuesday, August 25, 2009 12:49 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] RTC value corruption on QIL-A9G20 startup
On Tue, Aug 25, 2009 at 08:51:56AM -0400, Stephen Caudle wrote :
Hello Eric,
On Tue, Aug 25, 2009 at 5:38 AM, Eric Bénarderic@eukrea.com wrote:
isn't the RTC connected to the SPI chip select that the internal firmware toggle on boot to probe for a SPI Flash ?
That is certainly possible. This problem went away for me when I > upgraded to the "next" branch. Could the SPI dataflash code have been removed between v2009.06 and "next"? I'll look into this some more. Thanks for the hint!
Using the "next" branch doesn't help here. Anyway, the code Eric is referring to is the firmware code the CPU > executes from its internal ROM very early in the boot process, so you likely won't find anything remotely related to > this in U-Boot.
Regards,
Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...]
Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select?
Thanks, Bill Landolina Technology Atlanta Corporation 500 Sugar Mill Road, Suite 202A Atlanta, GA 30350
(404) 303-0446 (Voice) (404) 303-0448 (FAX) (678) 596-3625 (Cell) wcl@techatl.com
Hi Willian,
William C. Landolina a écrit :
Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...]
Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select?
u-boot is executed after the bootrom so there is nothing to do on the software point of view. You can connect a RTC on the I2C ...
Eric
On Thu, Aug 27, 2009 at 1:48 PM, William C. Landolinawcl@techatl.com wrote:
Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...]
No resolution here. I am still seeing the problem (even on the next branch). This definitely seems to be caused by the processor boot ROM.
Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select?
I believe a hardware change is the only way to fix this problem.
Regards, Stephen
Hi Albin,
On Tue, Aug 25, 2009 at 4:37 AM, Albin Tonnerre albin.tonnerre@free-electrons.com wrote:
I guess you mean SBC35-A9G20?
I actually tried it with the patches for both boards (TNY & SBC35) and saw the same result.
Everything seems to work properly except the RTC. They use the same M41T94 part and the CS is the same on both boards (PA3). I can set the RTC using the "date" command and read back the value okay. However, when I power cycle the board, the value is getting corrupted at startup due to some erroneous SPI write.
I don't believe the code you submitted is causing this problem because the RTC is getting corrupted even if I compile out SPI and RTC support completely. I was just wondering if you have seen this problem on your board?
Yes, I also experience this issue.
Well, at least I'm not the only one. :)
I probed the CS line with an oscilloscope and I am definitely seeing it go low on U-Boot startup for a short time, but the clock line seems to be floating. I believe the activation of the CS at startup is causing junk data to be written to the RTC, which is corrupting it. Any idea why this might be happenning?
Currently, I don't really have any idea. Besides, it's going to be hard for me to debug this, as I don't have an oscilloscope at hand. Would you please try to run u-boot within a debugger to see where exactly the CS line is driven low?
I upgraded to the "next" branch and the problem seems to have gone away. I will continue to investigate the root cause of this and let you know what I find.
Regards, Stephen
participants (4)
-
Albin Tonnerre -
Eric Bénard -
Stephen Caudle -
William C. Landolina