any significant difference between XM prototype and final product?

GoogleGroups
1

i have one of the earlier XM prototypes so is there any meaningful
difference between that and the finished product that will be
available shortly? i'll probably still order a new one just to play
it safe.

rday

p.s. sadly, the woman at digikey tells me that their computer system
lists the XM as having a *november* availability. why are these
people so relentlessly and consistently out to lunch regarding their
own supply chain?

2

Because your asking the question to the wrong person... Their system
doesn't know Gerald and Company are shooting for late June/early
July... :wink:

Regards,

3

i know. so it would make more sense for the digikey lady to simply
say she has no idea, rather than have totally erroneous info at her
fingertips.

  in any event, i think we're all used to getting outrageously
inaccurate availability info from the suppliers by now. so we just
listen to it, roll our eyes and move on. :slight_smile:

rday

4

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

  i have one of the earlier XM prototypes so is there any meaningful
difference between that and the finished product that will be
available shortly? i'll probably still order a new one just to play
it safe.

The major difference is that the shipping boards have working RAM.

p.s. sadly, the woman at digikey tells me that their computer system
lists the XM as having a *november* availability. why are these
people so relentlessly and consistently out to lunch regarding their
own supply chain?

That is one of the unsolved mysteries of the century.

5

The P7 has 256MB DDR and 256MB NAND. The P8 has 512MB DDR, the same DDR that is in the Rev A version. The Rev A boards have working DDR. The ones sitting on the shelf at the CM, don’t have working DDR. DDR works fine in UBoot but fails in the kernel and it never fails in the same place.

On Rev A, we moved the power connector over, reworked the overvoltage circuit to fix a gap in the design, and we changed the power arrangement on the camera port.

As soon as we figure out this DDR thing, we are ready to build boards, but we can’t afford to scrap 50% of our boards so we have to wait. So, we could start production next Friday, the next week, the month, or the month after that. We are anxious to start production because we are sitting on hundreds of thousands of dollars of inventory. So, while I know everyone is anxious to get their board, think of our position needing to sell these boards so we can pay our bills.

Gerald

2010/6/19 Måns Rullgård <mans@mansr.com>

6

Hi Gerald,

I understand that this is a painful theme but isn’t the memory used in XM also POP? If it is POP then how is it possible to have problems with memory if it sits right on the CPU?

BTW do you use CBP or CBC package of the CPU?

2010/6/19 Gerald Coley <gerald@beagleboard.org>

7

Regarding the November thing, remember that their system is setup for normal conditions and not communicating every one of the details of the supplier for the tens or hundreds of thousands of components they sell. There are contracts involved and we all need to be conservative when it comes to those kind of commitments.

Fortunately, we have Gerald who says it like it is to anyone who will listen.

Some other smaller details in work:

  • The camera port doesn’t have I2C pull-ups as we want folks to be able to use those signals as GPIOs on the expansion header and they aren’t on the camera module either. We could have something that plugs onto the expansion header, but this needs a winning idea that can be supported by the camera module vendor.
  • The S-Video port still needs some clocking changes in the kernel. We’ve gotten some community help on this (read Vladimir), but the work still needs to be done and tested.
  • Look for clean-up on the u-boot patches to fix some Rev C compatibility issues and to get the ramdisk loading mode right.
8

* The camera port doesn't have I2C pull-ups as we want folks to be able to

use those signals as

GPIOs on the expansion header and they aren't on the camera module either.

We could have something that plugs onto the expansion header, but this

needs a winning idea

that can be supported by the camera module vendor.

Why not just use the internal OMAP pull up resistors?
These pins actually have special pull up according to I2C spec – See the DM
for further info...
This was my main reason for not pointing at this while reviewing the
schematics long time ago :slight_smile:

I though (unfortunately) haven’t found time for testing it yet :slight_smile:

Maxim: With respect to PoP: Yes XM uses PoP as well, which makes the memory
issue even more strange...

Best regards
  Søren

9

I recall people complaining that the internal pullups are too weak to be used.

regards,

Koen

10

Hi Koen,

I recall people complaining that the internal pullups are too weak to be

used.
I remember people complaining about this as well. Never the less I have
never seen any problem using 100kHz I2C using just the internal resistors
:slight_smile:

That being said there is a new special I2C pull-up feature (featuring
stronger pull) in OMAP36xx/DM37xx, which is supposed to make even high-speed
I2C working with just the internal resistors - For more information please
check the data manual :slight_smile:

Regards,
  Søren

11

Excuse the blackberry induced top-post, but this is a great example of the community at work.

12

This has nothing to do with POP. Afterall, the parts that work are POP as well. This is some sort of timing issue that is right on the edge of certain devcies. We are not sure where the issue is. We use CBP packages as always.

Gerald

13

I hear that reading is fundamental.

Gerald