From hector.oron@gmail.com Thu Jun 09 17:02:59 2011 Received: from mail-qw0-f44.google.com ([209.85.216.44]) by stoneboat.aleph1.co.uk with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1QUhh5-0007ZJ-Un for balloon@balloonboard.org; Thu, 09 Jun 2011 17:02:59 +0100 Received: by qwc23 with SMTP id 23so1104836qwc.31 for ; Thu, 09 Jun 2011 09:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EFUYIRfcRmIXgl9+Xxhvmz1YkFLIAaa7RdzYrzHKxUE=; b=liSwI+apKs7dNMuCIQg7XsB0b+qBCKxRw1uASgqNcFyiewi//MTt+w2z1kLqQPo/qS UWYEMPoWSiprfUMej2PuezVBdPyjxM9iKqxIdHRohed64Cgr2VhYhIvukR74NUMXIagU 33pMcTkw7hMwJ7rVdifSrGhmIyVoQE4NyXnhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EVI0RRe/HLGMmSW5uP9NVtBbEBV0aOLyV4miH3BXsQy8bwgixip5tMxZxuuB1K6Isd a/QyPh0avqfxG+OvBngneG5zJpo/MqJctdsJAMTj7exIjb3hPAIwm7vxr2ujejarRFce 90xtkjpMCoXh94kSnFf7svmpj5QR07PBYBPGI= MIME-Version: 1.0 Received: by 10.229.78.133 with SMTP id l5mr644056qck.260.1307635365299; Thu, 09 Jun 2011 09:02:45 -0700 (PDT) Received: by 10.229.228.212 with HTTP; Thu, 9 Jun 2011 09:02:45 -0700 (PDT) In-Reply-To: <55365.1306175220@arbury.com> References: <55365.1306175220@arbury.com> Date: Thu, 9 Jun 2011 17:02:45 +0100 Message-ID: From: Hector Oron To: steve@arbury.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 209.85.216.44 X-SA-Exim-Mail-From: hector.oron@gmail.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-3.4 required=4.5 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Cc: balloon@balloonboard.org Subject: Re: [Balloon] Balloon4 - progress & questions... X-BeenThere: balloon@balloonboard.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Balloon List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:02:59 -0000 Hello, Yesterday I had the opportunity to attend to Silica seminar with lots of manufacturers (ARM, Micron, Xilinx, TI, Freescale, ST, ..) and very interesting people (Wookey was there too :)) 2011/5/23 Steve Wiseman : > Hi, all. Some progress report, some questions, and no doubt some sidetrac= ks: > --------------Concerns: --------------------- > Power. > The mission for Balloon4 is to have it manufacturable, which means that T= I's Power Management ICs (PMICs) are, in general, tricky. The best ones are= in 0.4mm BGA packages, which is _not_ good for PCB costs. They're also not= oriously fragile. Expensive. Single-sourced. > The ones in packages we can use aren't rated to drive the OMAP at its hig= hest speed profiles. (The OMAP counts its toes, then checks its process geo= metry, temperature, phase of moon, then chatters over i2c to the PMIC to pi= ck a supply voltage that will probably allow it to work without failing unr= easonably quickly. This is explicitly defined in the datasheet - we don't h= ave to use a PMIC, we could build a little micro to listen to the i2c, and = set the voltage as requested. But, if we're having a little micro, what els= e would we want it to do? Boot stuff? RTC in ultra-powerdown? Battery Charg= ing? Keyboard Checking?) > The spiffy PMICs also tend to have handy stuff like USB OTG PHYs, which c= an be used to boot. If we don't have the exact same phy, I'm unconvinced we= 'll be able to boot from USB. I don't think I care. Does anyone? We can sti= ll boot from (at least) serial, NAND, MMC... Discussion is still open on whether use TI PMIC or uController to do the job, for which we do need to write firmware for. Someone needs to carefully review specs, datasheets and make _very_ sure of what he is doing is going to work and do it as soon as possible. Currently this is most critical point in our current status. If someone feels confident on doing proper work on this, please step up and do it. > DRAM: > Oh good grief. Been round this a dozen times. Anyone know what LPDDR devi= ces actually exist? 1 or preferably 2 Gbit. (although I'll take 4GBit if th= ey exist). Not POP package. If there's a sweet spot, I have yet to find it.= Anyone with access to purchasing channels, anything that says 'LPDDR' is f= air game. DDR, DDR2, DDR3 are not acceptable. 'Mobile SDR' is not acceptabl= e. 'Mobile DDR' may be. x16 or x32 are both of interest (although x32 may o= r may not be acceptable to run 2 banks. The POP packages run with 2 banks o= f x32, but with short buses. The datasheet says not to, so, if we want a lo= w-risk 2-chip solution, we may need x16 chips, but I'll take what we can ge= t). I have had discussion and talking with Silica, MSC and Micron representatives, we are probably safe to get samples and get orders, safest bet might be using VFBGA 60 pin (for x16) or 90 pin (for x32). According to MSC representative some parts can be interchangeable between manufacturers so we can select many providers, not just one, as in Micron, Elpida, Samsung, Hynix and Nanya. Having a talk to Micron representative, they have a product longevity program but LPDDR parts have not made it there yet, according to Micron FAE they had planned to include LPDDR in the longevity program this month (June 2011). As a summary, using Micron is feasible and it narrows down the availability of chips to: It is on the TODO list check compatibility with other manufacturers. I'll try to find out information about it and update. > NAND: > Likewise. We want 1.8V, which means BGA package. Which seems to be non-ca= talogue. =C2=A0 What's out there, and how much NAND do people want? I can d= esign for x8 or x16 widths, and pretty much any page size, although, if the= OMAP bootloader is to be involved in booting from NAND, there are some res= trictions on device ID and page sizes (maybe - inconsistent data). > I've got more sources of NAND than LPDDR, though, and we can, if necessar= y, run without NAND. LPDDR solutions are more urgent. NAND can be brought to us from Micron as well, it might worth to look the longevity parts (MT42): which are SLC chips 1.8V 1-4Gb Complementary there is what is so called "Automotive eMMC" which might be interesting as well and they plan to start production on those parts 3Q2011, but again those are not in the longevity program (PLP) yet. Q: Would it be interesting to fit both technologies down, then we mount whatever we are more interested on? > HDMI: > Licensing. Lawsuits. Compliance. Generally being a pain. > Given Nick's great success today in ramming an X display down USB, does a= nyone still want HDMI? We don't have the hardware (or software resource) to= play video. HDMI will only bring us woe, and I say that as a seasoned HDMI= designer-inner. Bike shedding still open topic? > Xilinx: > Spartan-6, still not decided on the device of our dreams yet. It partly d= epends on what we can get in a package that doesn't compromise manufacturab= ility - and I won't know that until I know what design rules other componen= ts force us into using. > All packages will have more pins than we can sanely use. Once we've strap= ped some DDR to the chip, attached it to the OMAP through the GPMC bus, cam= ped it on the camera bus and a serial bus or two, how many pins are people = thinking they want? Tens? Hundreds? Enough for a couple of LEDs and a few m= otors / i2c buses / Samosa-style parallel buses? Spartan-6 now in production, it is probably no problem to get those parts, do we still want highest in line supported freely by ISE webpack? Extra, miscellanea and curiosities: * TI OMAP3 Parts can be shipped with or without GPU, do we want it? (it is just $3 difference) I would say we should go for it. * Display Might we want a TFT panel, LCD or some short of display for a breakout or main board, so I could start having a look to components availability. * eUSB memory in the pipeline USB memory that one can solder into the PCB, it sounds very wrong technology for low power concerns and it is still too experimental. * Cortex-M Microcontrollers Freescale has its Kinetis (Cortex-M4) line which they release a free of charge and licensing RTOS, MQX, which makes life easier as it provides TCPIP stack, USB drivers, CAN libraries, etc... the pity is that is mainly works with CodeWarrior tools which about =C2=A33000 for licensing. They have a Tower Development Kit, where they have backplane boards on the sides connecting main board with edge connectors and easily extendable by adding breakout boards on the rest of slots. It might be worth to play with that technology. ST was also there an they have the STM32 (Cortex-M3) line of products which are also nice components and could be used as a replacement for the TI PMIC. So, if more or less all this is fine with you I'll start sampling and trying to get parts for revision 1, which quantity do we need for rev1 and do the hardware bring-up part? At least 10 boards? 5 with FPGA/ 5 without it? Sounds about fine? Once I know part numbers I'll let you know. I guess we are fine on the commercial grade. Lead times varies between 6-8 weeks to 20 weeks (on some TI OMAP components), so we should be starting the sampling process right away. On best effort terms and highly optimistic approach Nick Bane was wanting to take with him a board to DebConf, which it is last week of July, could we try to meet this deadline, please? :-) Let me know if you want further information or if I am missing something. Cheers, --=20 =C2=A0H=C3=A9ctor Or=C3=B3n =C2=A0-.. . -... .. .- -. =C2=A0 -.. . ...- . .= -.. --- .--. . .-. -- Would you like to make a donation for Debian Conference? =C2=A0 =C2=A0** http://debconf11.debconf.org/payments.xhtml **