EEPROM Cape ID spec

I would like someone to clarify the ambiguity in the CAPE expansion
board EEPROM contents.
Although not specified I am assuming all ASCII data is read out Left
to Right EEPROM address lowest to highest. For example if using an A3
board with "My Board Name" version 3:

ADDRx DATA
00 AA
01 55
02 33
03 EE
04 41 ASCII ‘A’
05 33 ASCII ‘3’
06 4D ASCII ‘M’
07 79 ASCII ‘y’
08 20 ASCII ‘ ‘
... i.e. "My Board Name"

26 20 ASCII ' '
27 20 ASCII ' '
28 20 ASCII ' '
29 33 ASCII '3'

2A 41 ASCII 'A'
2B 43 ASCII 'C'
2C 4D ASCII 'M'
2D 45 ASCII 'E'
2E 20 ASCII ' '
2F 4C ASCII 'L'
30 4C ASCII 'L'
31 43 ASCII 'C'
32..39 20 ASCII ' '

3A 30 ASCII '0'
3B 32 ASCII '2'
3C 20 ASCII ' '
3D-49 20 ASCII ' '

4A 08 8 pins used??
4B 00

4C 31
4D 33 week 13
4E 31
4F 32 year 12

50 no clue? spec says 4P13 I assume ASCII so 34,50,31,33 ??

  APMU Pin ussage comes next. I am assuming the 'A' goes in the low
order byte so first
  configurable pin ..what ever that is (GPIO1_1 ?) would be at address
58.
58 1 Used
59 0 Output
5A 0 Mux=0
5B 1 Pullup
...

E4 F4
E5 01 VDD_3V3EXP Current 01F4x=500 or 500ma for example

E6 64
E7 00 VDD_5V Current 0064x=100ma

E8 90
E9 01 SYS_5V Current 0190x=400ma

EA FA
EB 00 DC supplied 00FAx=250ma

My questions are:
For hardware version is 0x20,0x20,0x20,0x33 ok or should it be
0x30,0x30,0x30,0x33 for "0003"?
Same question for part number, should be space or zero padded or does
not matter?

Biggest question has to do with byte ordering for fields specified as
16 bit words (2 bytes).
Like the Max current fields, Number of Pins etc.
I am assuming Little Endian as this ARM processor is also little
Endian. This means the lower order byte (least significant) of an
integer or word is stored in low memory (lowest address).
Is this a correct assumption?

Since I2C protocols data fields are specified in BYTES it really can
be eather way. We just need to know which.

It is read Left to Right.
Hardware vrsion is ASCII and up to you , i.e 00A0, 00B1, B001, 01.1 …just an ASCII value that reflects how you track your revisions,
Pins used is the total pins used including power.
Part number is in ASCII, so a person can read it when dumping the EEPROM. Part number is up to you, letters, numbers, characters, just whatever you normally use for your prodcuts.
Little Endian fromat low byte low address.
All entries are 8 bits. The EEPROM supports 16bit addressing…

Gerald

Well I just looked at the A5 SRM (I originaly was using A3)
which shows completly different information.

The A5 does resolve much of the ambiguity ... they are using BIG
ENDIAN meaning the Most Significant Byte is stored in lower memory.
So if I am using 8 pins:
Offset 74 would be 0x08
Offset 75 would be 0x00

A byte dump of a properly programmed CAPE would go a long way.

Have a look at this one

lcd7-eeprom (32 KB)

I am the author of the System Reference Manuals and I am working on Rev A6 at the moment. I don’t believe that the Big Endian is correct. In the processor TRM it actually does not say, although most registers are Little Endian and a few are Big Endian. As there is no DSP on this device, which is Big Endian, I am not sure why they would be Big Endian. But, let me check for sure. Right now everything I am putting in Cape EEPROMs is little endian as it will be read by the ARM.

So, for now, I am saying it is Little Endian and we will leave it at that. If it changes, I will let everyone know. The reality is that the SW that would use this information has yet to be writen.
.

Gerald

Thanks for the dump Koen.
From this I can see:
Offset: Data:
74 (0x4A) 0x00
75 (0x4B) 0x1E

So this would mean 0x001E pins are used on the LCD CAPE or 30 pins BIG
ENDIAN i.e. the A5 SRM states it correctly.
(or it could be 7680 pins LITTLE ENDIAN ... which I highly doubt)
http://en.wikipedia.org/wiki/Endianness

I also see:
Offset: Data:
236 (0xEC) 0x00
237 (0xED) 0x02

So it draws 2ma Max from the 3V3EXP supply

Offset: Data:
242 (0xF2) 0x07
243 (0xF3) 0xD0

And it also supplies 0x07D0 or 2000ma (DC Supplied)

The values in the LCD Cape have not been finalized. That is still a work in progress to get it finalized. I would not trust those current values.

Gerald

The values in the LCD Cape have not been finalized. That is still a work in progress to get it finalized. I would not trust those current values.

I don’t think it matters much as long as we can freeze it now. If we’d like to switch to little endian, let me know and I’ll change bonescript right away. Right now, it assumes big endian:

Gerald

Thanks for the dump Koen.
From this I can see:
Offset: Data:
74 (0x4A) 0x00
75 (0x4B) 0x1E

So this would mean 0x001E pins are used on the LCD CAPE or 30 pins BIG
ENDIAN i.e. the A5 SRM states it correctly.
(or it could be 7680 pins LITTLE ENDIAN … which I highly doubt)
http://en.wikipedia.org/wiki/Endianness

It is correct that up to now, the software was being done assuming big endian. I don’t care. If there is any hardware in existence with it set, I think we need to stick with that.

I can change bonescript within the day.

Oh, I found the reference as to why I implemented big endian:

BeagleBoard.org - Page not found (revision A5.0.0) section 8.1.4:

“The 16 bit integers and all 16 bit fields are to be stored in big endian format.”

I say stick with Big Endian.

Gerald

Just an observation as a user of the beagle (bone). It appears that most if not all of everything else on the bone is Little Endian. To me consistancy is what matters and having mixed endianness on a platform is just confusing and error prone. If moving to little endian for the cape EEPROMs would assist in consistancy across the platform I’d be all for that.

Eric

This only applies to how the table is built in the EEPROM and there should be only one piece of code that deals with it, so I don’t see this being too disruptive. On the other hand reworking a bunch of Capes for their EEPROM content and re doing my code that flashes them would be a lot of fun. Wish we had time to get it in before the next shipments.

Let’s leave it as is.

Gerald.

Looking at the document I see the FTDI VID/PID was changed to
0403/6010: Why was that? The old id is now support by the kernel, and
from a quick look at ftdi_sio.c it seems like the new ID won't work
out of the box (wrong quirk).

So that it supports the standard FTDI driver that most PCs already have loaded. No need to install a special driver. Should make a lot of the drivers issues we have been seeing go away.

Gerald

For Windows users you mean? Ok, I guess that's nice, but let's also
make it work on Linux. Could you tell me how to differentiate it from
a normal ftdi 8u223c, then I'll send a new ftdi_sio patch upstream to
get it supported.

The quirk currently is:

static int ftdi_8u2232c_probe(struct usb_serial *serial)
{
  struct usb_device *udev = serial->dev;

  dbg("%s", __func__);

  if (strcmp(udev->manufacturer, "CALAO Systems") == 0)
    return ftdi_jtag_probe(serial);

  return 0;
}

So if you use a unique iManufacturer / iProduct string we can use
that, similar to how it's done for the CALAO stuff.

I will defer to Jason to handle this. My understanding when I agreed to make this requested change, that it was already supported in Linux and MAC.

Gerald

I will defer to Jason to handle this. My understanding when I

> agreed to make this requested change, that it was already
> supported in Linux and MAC.

I don't have an A5 rev to test with, but as far as I read the code, both
ports will be handled in UART mode.

For details, see the recent commit adding the Calao support:

https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c96fbdd0ab9723

We'll need something similar for the new bones.

The Rev A3 is the same functionality as the A5, just with the new PID/VID. Rev A4 with R219 removed is the same functionality as the rev A5.

Gerald

Hi,

> I will defer to Jason to handle this. My understanding when I
> agreed to make this requested change, that it was already
> supported in Linux and MAC.

Jason, any comments on this?

Hi,

I will defer to Jason to handle this. My understanding when I
agreed to make this requested change, that it was already
supported in Linux and MAC.

Jason, any comments on this?

It is on the stock FTDI drivers for Mac (w/o modifications) and works without any kernel patches or udev rules on my Ubuntu virtual machine.

jason@jason-VirtualBox:~$ uname -a
Linux jason-VirtualBox 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:34:47 UTC 2011 i686 i686 i386 GNU/Linux

jason@jason-VirtualBox:~$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 052: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 053: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC

jason@jason-VirtualBox:~$ dmesg | tail
[110551.850929] usb 1-2: Endpoint 2 MaxPacketSize 512
[110551.850930] usb 1-2: Setting MaxPacketSize 512
[110551.857313] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[110551.862261] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
[110551.862283] usb 1-2: Detected FT2232H
[110551.862284] usb 1-2: Number of endpoints 2
[110551.862286] usb 1-2: Endpoint 1 MaxPacketSize 512
[110551.862287] usb 1-2: Endpoint 2 MaxPacketSize 512
[110551.862289] usb 1-2: Setting MaxPacketSize 512
[110551.868024] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1

You’ll note that without a udev rule, you’ll need to use /dev/ttyUSB1 typically.

For Windows users you mean? Ok, I guess that’s nice, but let’s also
make it work on Linux. Could you tell me how to differentiate it from
a normal ftdi 8u223c, then I’ll send a new ftdi_sio patch upstream to
get it supported.

The quirk currently is:

static int ftdi_8u2232c_probe(struct usb_serial *serial)
{
struct usb_device *udev = serial->dev;

dbg(“%s”, func);

if (strcmp(udev->manufacturer, “CALAO Systems”) == 0)
return ftdi_jtag_probe(serial);

return 0;
}

So if you use a unique iManufacturer / iProduct string we can use
that, similar to how it’s done for the CALAO stuff.

Gerald is using the FTDI string for iManufacturer, but the iProduct is unique. I don’t think lsusb is providing me the string Gerald is using in production. I don’t think a quirks is required unless you want to avoid the JTAG from showing up as a serial port.