[U-Boot] Bisected "sdhci_transfer_data: Error detected in status(0x208002)!" problem on ODROID-X

[Siarhei Siamashka]

On Thu, 22 Oct 2015 11:57:18 +0900
Jaehoon Chung <jh80.chung at samsung.com> wrote:

> Hi,
> 
> On 10/20/2015 10:57 AM, Siarhei Siamashka wrote:
> > Hello,
> > 
> > Currently SD card support seems to be broken at least on the ODROID-X
> > board in U-Boot v2015.10. Checking older U-Boot releases shows that
> > it used to work in v2014.10, and bisecting points to the commit
> > a276172cf32386c211c75638f6bf3c0d59ba03ba ("arm: exynos: fix the
> > div value for set_mmc_clk"):
> >     http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a276172cf32386c211c75638f6bf3c0d59ba03ba
> > 
> > Reverting this commit resolves the problem and the SD card starts
> > working properly.
> > 
> > As an extra test, I also tried to add debugging print at the end of the
> > exynos4_set_mmc_clk() function, so that it calls exynos4_get_mmc_clk()
> > with the original 'dev_index' and reports the resulting mmc clock
> > speed. After reverting the patch, the reported value is 50MHz. Before
> > reverting it, the reported value was 100MHz. This is a Transcend
> > class 6 SDHC card.
> > 
> > Is this enough information or should I check something else?
> 
> I will check this..

Thanks a lot! I'm expecting that it should not be very difficult to
reproduce the problem. I guess, you just need an old slow SD card for
this, which can't handle high clock speeds. The "Error detected in
status(0x208002)!" problem has been also reported earlier:
    http://lists.denx.de/pipermail/u-boot/2015-June/217326.html

But if my SD card is unique enough and you have difficulties
reproducing it, then I don't mind debugging the exynos mmc
clocking code myself. So please let me know if you can or can't
reproduce the bug.

> I needs to get more information. I want to know div value passed
> by argument.

The div value is passed as 1 and decremented to 0.

Frankly speaking, I don't quite like the fact that this adjustment of
the divisor is done relatively far from writing it to the hardware
register. The point is that we are dealing with two different things
here:
  1. the divisor in a mathematical sense.
  2. the divisor representation as encoded in the hardware register
     (which is decremented by 1).
Confusing between these two may lead to bugs. For example, not
adjusting the divisor at all or doing this more than once.

-- 
Best regards,
Siarhei Siamashka