On Wed, 8 Apr 2015, Robert Nelson wrote:
> On Wed, Apr 8, 2015 at 9:33 AM, Robert P. J. Day <[email protected]>
> wrote:
> > On Wed, 8 Apr 2015, Robert Nelson wrote:
> >
> >> On Wed, Apr 8, 2015 at 9:14 AM, Robert P. J. Day <[email protected]>
> >> wrote:
> >> >
> >> > seeing differing opinions online ... if you read this:
> >> >
> >> > https://e2e.ti.com/support/arm/sitara_arm/f/791/t/233139
> >> >
> >> > i should be able to display the first few bytes of the BBB's EEPROM
> >> > from u-boot using:
> >> >
> >> > i2c md 0x50 0 16
> >> >
> >> > but, for me, that just displays "ff" throughout, which is what *other*
> >> > people claim to see when they try it.
> >> >
> >> > should this command work? do i need to initialize something first?
> >> > am i (theoretically) using the correct arguments?
> >>
> >> U-Boot# i2c probe
> >> Valid chip addresses: 24 34 50
> >> U-Boot# i2c md 0x24 0 16
> >> 0000: e2 3f 00 01 b1 80 b2 01 00 00 08 00 7f 0c 18 11 .?..............
> >> 0010: 09 06 09 38 26 3f ...8&?
> >> U-Boot# i2c md 0x34 0 16
> >> 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> >> 0010: 00 00 00 00 00 00 ......
> >> U-Boot# i2c md 0x50 0 16
> >> 0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
> >> 0010: ff ff ff ff ff ff ......
> >
> > ok, you're seeing what i'm seeing but shouldn't that last command
> > print the first 16 bytes of the EEPROM (header, board name, version)?
> > if i boot into linux, and:
> >
> > # cd /sys/devices/ocp.3/44e0b000.i2c/i2c-0/0-0050
> >
> > then i can certainly dump what corresponds to the EEPROM:
> >
> > # hexdump -C eeprom | less
> > 00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 41 35 43
> > |.U3.A335BNLT0A5C|
> > 00000010 32 37 31 33 42 42 42 4b 37 35 37 31 ff ff ff ff
> > |2713BBBK7571....|
> > 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > |................|
> > ... snip ...
> >
> > so can i not do that from within u-boot?
>
> U-Boot# i2c md 0x50 0x0c.2
> 000c: 30 30 30 43 32 34 31 34 42 42 42 4b 30 31 30 33 000C2414BBBK0103
ah, i overlooked the need for the ".2" suffix, to specify that
the chip uses 2 bytes for addresses. my bad. movin' on ...
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
