Hi -
Is it possible to obtain the datasheet for the AM572x? I’m happy to sign an NDA.
Ask your local TI sales person.
Gerald
Unfortunately not. I am looking for the pin mix information (I have the header pin out, but no information on which header pin is mapped to what onboard peripheral).
Yogi
No. They need the datasheet with the pin mux information.
Gerald
You can probably fish some bits out of {am5,dra7}*.dts and even more
out of the u-boot mux data... but it's no substitute for a datasheet
obviously
Hi Jason -
Is there any way to get this datasheet?
I’ve requested from the local rep, but no dice.
Just incase anyone else is looking for it…found it on the TI cloud pinmux tool: http://www.ti.com/tool/PINMUXTOOL
Nice a cloud version!
Regards,
Nice catch! That also means you can get the raw data as JSON:
https://dev.ti.com/pinmux/deviceData/AM5728/AM5728.json
https://dev.ti.com/pinmux/deviceData/AM5726/AM5726.json
(you do need to be logged in)
I'm pretty sure those weren't there yet last time I checked. I guess it
must be approaching release then?
I must warn you however that I almost immediately found pretty strange
things in it, like:
The device pin named 'uart2_txd' (ball D26, mux register 0x17f4) has the
uart2_txd signal on two different mux settings: 0 and 4, which is possible
of course but strikes me as pointless and strange.
The device pin named 'uart2_rxd' (ball D28, mux register 0x17f0) has the
uart2_rxd signal only on mux 4, while mux 0 points to a nameless input
signal, ownership of which is claimed by uart2, but the pin doesn't declare
correspondence to any signal of the UART interface. Given that the device
pin is named after it, I would assume that mux 0 is in fact rxd, but that
leaves it a mystery what the deal is with mux 4.
This is going to be fun…
Gerald
Uhuh... take a guess whether the highly redundant information in their JSON
is
(A) consistent, or
(B) inconsistent.
e.g. referencing signal "vin2a_d0" of "VIN1" ... right...
Interestingly these errors again involve mux mode 4 of various pins. That
mode must be cursed across the whole pinmux array or something 
Well, how can I put this. I suspect this is a product of removing things that are still there. Does that make sense?
Gerald
Not really. I mean, I'm familiar with defeaturing but don't really see any
way of explaining these inconsistencies as being the result thereof. Looks
more like simple human error combined with a disturbing lack of
consistency-checking of their data structures.
Anyway, preliminary spreadsheet is done, for more convenient browsing:
https://goo.gl/S4t2lw
Dubious entries have been highlighted in red. Various sort orders available
via menu Data -> Filter views.
I could have provided you the master spreadsheet if you had waited a few days, after the official TI release…
Gerald
I noticed some inconsistencies as well…so I rerouted my attention to updating kernel modules for 4.1 etc. Looking forward to Gerald’s master spreadsheet :).
Also, there was more than feature removal going , there was renaming going on. There is another device coming out that they wanted to make this more “compatible” with that device.
Gerald
Don’t hold your breath guys. Now that you guys have this, you can just work to figure it out. I would not want to cause any confusion here.
And I will not be explaining what is going on here. Doing it over emails, well, that would be impossible.
Gerald
I could have provided you the master spreadsheet if you had waited a few
days, after the official TI release..
Heh, so my guess about release approaching was right. I'll be interesting
to compare the spreadsheets.
At least this motivated me to put some effort into my scripts for
validating and restructuring the pinmux data, which I originally started on
for the AM335x. There's still work to do, but it's also producing output as
YAML and into an SQLite database.
Also, there was more than feature removal going , there was renaming going
on. There is another device coming out that they wanted to make this more
"compatible" with that device.
Ah, that changes things. Renaming and moving things, the easiest way to
make a mess of things So I'm guessing this is a difference between
silicon revison 1.x and 2.x ? (With 1.x probably getting filed under "let's
speak of this no more" just like 1.x of some other SoCs...)