OMAPL138 revision history between L138A and L138B

This question is answered

Posted by Jamaal_Charles

on Aug 28 2012 17:22 PM

Expert1315 points

Hi,

We designed some prototypes a while back with the OMAPL138A, and now are going to production, but the part has rev'd to OMAPL138B. Our Kernel that we used in the prototypes is crashing in the new parts. What are the differences between A and B? I can't find that information anywhere. Do we have to recompile the kernel for the new version?

Thanks

All Replies

Posted by Rahul Prabhu

on Aug 28 2012 18:16 PM

Genius16100 points

Jamaal,

The bugs reported and fixed in silicon revisions can be viewed from the silicon errata that can be found on the product folder. Here is the link to it:

http://www.ti.com/lit/er/sprz301h/sprz301h.pdf

For ROM bootloader changes refer to Appendix E of the Boot loader app notes:

http://www.ti.com/lit/an/sprab41d/sprab41d.pdf

Could you specify what kind of a kernel failure do you see with the new OMAPL138 revision.

Regards,

Rahul

---------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
---------------------------------------------------------------------------------

Posted by Jamaal_Charles

on Aug 28 2012 19:06 PM

Expert1315 points

Thanks Rahul,

Is there a difference in power up reset? We see that the B version board appears to be held in reset for 8.6 seconds after power on. The older boards would start after a little less than a second. Either the PMIC is driving resetn, or the OMAP. We don't see any difference in the PMIC wiring. I don't see anything in the documents above that would explain that either.

We'll work on getting more details on the Kernel failure.

-J

Posted by Jamaal_Charles

on Aug 29 2012 10:45 AM

Verified Answer

Verified by Jamaal_Charles

Expert1315 points

Rahul,

We were able to find the cause of the long reset time. We had a 0.1uF installed instead of a 0.0015uF off the TRESPWRON line so it was being held in reset for 8 seconds.

As for our kernel issue, it is identical to the one in the post below. It gets stuck after booting the kernel. However reading through the post we were able to determine that the B devices have a different ID code and wont boot with A's kernel. So, we are recompiling the kernel, and should be good to go.

Thanks for your help!

http://e2e.ti.com/support/embedded/linux/f/354/p/67290/248486.aspx#248486