hi!
I wonder how you are going to chill out am3892 in a such small form factor? This chip consumes too much current
2012/10/29 lkcl <luke.leighton@gmail.com>
hi!
I wonder how you are going to chill out am3892 in a such small form factor? This chip consumes too much current
i just checked http://processors.wiki.ti.com/index.php/File:DM816x_C6A816x_AM389x_Power_spreadsheet_RevD.zip which is rather hard to do given that it uses visual basic macros and libreoffice is showing “!#VALUE” for many of the fields, but an AM3892 at 1.2ghz if you enable SATA and PCIe and use both RAM interfaces as best i can tell it’s around 1.9 watts. if someone else happens to have a proprietary application which can successfully run this spreadsheet and doesn’t mind potentially running viruses then the parameters are:
- AM3894: yes
- SGX: no
- HDVCP 1,2,3: no
and so on.
if it comes out too high then darn it i may have to cut back to a 32-bit RAM interface, those DDR3 interfaces consume a hell of a lot of current.
to answer your question: we’re setting a limit of 3.5 watts (for the whole board). anything above that we simply go “nope - scale it back”. we’re not going for records, here, or making life difficult for ourselves: the point of the exercise is to get an FSF-Hardware-Endorseable board with decent performance i.e. won’t be too embarrassing when compared against today’s “latest and greatest” such as OMAP4 and 5.
i picked the AM3892 more because it has built-in SATA and Gigabit Ethernet than anything else - adding e.g. a GL831A onto say a DM3730 wouldn’t be half as much fun, and, because i’m the one doing the schematics, more complex and more work for me 
for those people who want AM3894, that’ll likely be ok, too: special order item, no problem. DM816x might get a bit hot, though, i think you’re right about that. don’t know to be honest!
thanks for raising this lisarden.
l.
The suggestions I have are to try to make it simple, and to improve the consumption.
I’m sorry but I’m going to compare the current boards with others to explain the reason:
For example if you compare the BeagleBoard PCB (or the BeagleBone PCB) to the Raspberry PI PCB (or the Carambola PCB) you will realize that the firts one has an awfull quantity of chips, and what is worst (in my opinion) is that the most of that chips have more functionality than you will ever use. Less chips would result in a cheaper, lower power and an easier product as is the case of the RaspBerry Pi and the Carambola.
gerald, hi,
many apologies: it came to my attention that the AM3892 requires proprietary firmware “ti816x_hdvpss.xem3” to be uploaded to an on-board Cortex M3 in order for the VPSS functionality to be enabled.
as the primary reason why i’m looking at this SoC is for FSF Hardware-Endorseable purposes, the product must be 100% free software. no proprietary firmware must be required for any of its functions to operate.
just ignoring one particular piece of hardware which happens to require proprietary firmware is not good enough. however, blowing an e-fuse such that that hardware is completely and utterly and irrevocably without fail disabled is absolutely fine. also, blowing an e-fuse which irrevocably stops firmware upload from working is also fine.
there are several other technical ways in which hardware may be disabled, and they are all acceptable: it just has to be possible.
could i please therefore ask you the favour of making some enquiries or pointing me in the direction of the right people who may be able to answer one of the following questions:
a) can information regarding how to program the on-board Cortex M3 including its toolchain be provided?
OR:
b) can the on-board Cortex M3 be somehow disabled through either some software command or some hardware external pin configuration or just … anything such that it may never, at any time after, ever and i really mean ever, be used, enabled, re-activated or otherwise have any means or method by which the sole exclusive and proprietary firmware that is exclusively within T.I.'s control can never be uploaded to the device or if uploaded would not work or if uploaded would remain permanently within the memory of the device, even surviving reboots
sorry that’s complex but it’s the way that FSF Endorsement works, and i’m trying to outline the many methods by which compliance is possible.
if the answer is “no” to all of these ways then we have to eliminate the AM3892, just like all other ARM Cortex CPUs from TI and many many other SoC vendors have been eliminated, and we have to wait until one that is both good enough (*1) and FSF Endorseable comes along, or we need to find out if there are enough people who want AM389x or DM816x beagle-board-like processor cards out there who don’t mind proprietary firmware.
thanks gerald,
l.
(*1) there are plenty of FSF-Endorseable SoCs from TI and other SoC vendors, such as the 720mhz OMAP3525, or the 1ghz DM3725, or the 600mhz AM335x with no on-board GPU: they’re just not good enough. too slow, or just… not enough interfaces. the DM37xx series and AM335x series have no HDMI output and no SATA. 720mhz OMAPs are a bit… old. the upcoming 1ghz OMAP3 might be ok, but it’s not available yet.
http://www.fsf.org/resources/hw/endorsement/criteria
the “secondary embedded processor” rule doesn’t apply here, because in this case the “secondary embedded processor” (the Cortex M3) must have its proprietary firmware uploaded each and every time (presumably into RAM somewhere)
if that was EEPROM that the firmware was uploaded into, it would be fine: upload once, and forget about it.
is the Cortex M3 “upload” procedure putting the proprietary firmware into RAM or is it putting it into EEPROM?
if “EEPROM” then it can be done once, left alone, and never touched again. as the Cortex M3 is a “secondary embedded processor” this would qualify.
l.