From: Torsten Fleischer <to-fleischer@t-online.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mxs-i2c: Fix internal address byte order
Date: Mon, 07 May 2012 16:59:23 +0200 [thread overview]
Message-ID: <4003996.WymTGke6fF@linux-1fbo.site> (raw)
In-Reply-To: <201205010445.32996.marex@denx.de>
Dear Marek Vasut,
> > Large EEPROMs, e.g. 24lc32, need 2 byte to address the internal memory.
> > These devices require that the high byte of the internal address has to
> > be written first.
> > The mxs_i2c driver currently writes the address' low byte first.
>
> Are you sure about it? Are you sure what you're seeing isn't FIFO overrun?
Yes, because I used 'i2c md' and 'i2c mw' for the test and these commands do
only a small write transfer. They write 3 and 4 bytes respectively. This is in
both cases only one FIFO word.
> Basically, how does your problem manifest? How did you test this?
First I wrote different bytes into the addresses 0x00 and 0x01 of the EEPROM
using 'i2c mw', for example:
=> i2c mw 54 0.2 12
=> i2c mw 54 1.2 34
Then I read the address range 0x00 - 0x01 and got:
=> i2c md 54 0.2 2
0000: 12 ff ..
That's not what I had expected. On address 0x01 there should be '34' instead
of 'ff'.
But when I read directly from the address 0x01 the command returned the
correct value:
=> i2c md 54 1.2 1
0001: 34 4
Thereupon I checked the I2C frame of the read and write commands to the
address 0x01 with an oscilloscope. The scope showed that after the device's
address the bytes 0x01 followed by 0x00 were sent to the EEPROM. But the two
bytes must be in reverse order.
After inspecting the source code I swapped the address bytes, i.e. I used
'100.2' instead of '1.2'. With it the read/write command accessed the address
0x01 of the EEPROM. I verified this with the scope.
Reading the range 0x00 - 0x01 returned then the expected content:
=> i2c md 54 0.2 2
0000: 12 34 .4
I also tested the address byte swapping - before and after modifying the
driver - with other addresses (e.g. 0x0180 and 0x0fff) by checking the I2C
frames with the scope.
After fixing the driver, I additionally read the whole EEPROM using 'i2c md'
and verified the written addresses.
Best Regards
Torsten Fleischer
next prev parent reply other threads:[~2012-05-07 14:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 15:37 [U-Boot] [PATCH] mxs-i2c: Fix internal address byte order Torsten Fleischer
2012-04-17 20:30 ` Marek Vasut
2012-05-01 2:45 ` Marek Vasut
2012-05-07 14:59 ` Torsten Fleischer [this message]
2012-05-07 16:13 ` Marek Vasut
2012-05-09 9:41 ` Stefano Babic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4003996.WymTGke6fF@linux-1fbo.site \
--to=to-fleischer@t-online.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox