Team,
For the different AM1xxx, AM3xxx and OMAP-L13x are there plan to document the changes that are introduced between 2 versions of the ROM bootloader code?
I have a precise examples (see below) where customers in production were impacted by changing to a device with an other RBL version.
I assumes that the issue does not manifest on TI SW as I guess the LSP/BSP are being validated with the different silicon revsion/ROM version. But for custom low level code customers a likely to face issues.
Ideally it would help to list the registers content (when the PC exits the RBL code) that changed between 2 ROM revision.
example:
On OMAP-L137/C6747 after a succesful boot via (UART) the same custom UART2 code not working anymore in D800K003 (vs D800K001).
Customer description:
We are using the BSL from Spectrum Digital and found following problem:
The BSL didn't set the UART MDR register where you can select 16x
oversampling or 13x oversampling. That's also in the newest version from
Spectrum Digital.
It seems to be that the UART of the TMX320C6747 with the ROM ID D800K001
in any case works in the 16x oversampling mode.
In the TMS320C6747 with the ROM ID D800K003 after UART boot it looks
like that the MDR is in 13x oversampling mode and then all configuration
settings are incorrect and he UART didn't work.
We modified the BSL code to set the MDR register to 0 (16x oversampling)
and now it runs on both processor revisions.
But we are wondering why TI have bring code incompatible processor
revisions on the market. That makes us a lot of trouble. For us it's a
quit new processor and we see silicon revisions from 1.0, 1.1, 2.0 and
2.1. For all we need to modify in minimum
the binary image with the AISgen to select the correct ROM ID. There is
also a newest type with ROM ID D800K005 available and the images must
match the correct ROM ID. Thats difficult to handle in production!
Thanks and best regards,
Anthony
