From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 20 Sep 2012 13:24:27 -0500 Subject: [U-Boot] QE firmware/microcode handling In-Reply-To: <505B34AD.7070801@freescale.com> (from timur@freescale.com on Thu Sep 20 10:22:21 2012) References: <505AE6C3.5080708@keymile.com> <505B34AD.7070801@freescale.com> Message-ID: <1348165467.8195.3@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/20/2012 10:22:21 AM, Timur Tabi wrote: > Gerlando Falauto wrote: > > Hi everyone, > > > > following up Timur's patch on QE microcode: > > > > http://marc.info/?l=u-boot&m=132197537730440&w=2 > > > > I was wondering, would it make any sense to *embed* QE's firmware > within > > u-boot image itself? > > There are three problems: > > 1) A lot of U-Boot images are already very close to the 512KB limit. > We > often have to disable features in U-Boot to get it to build > properly. An > additional 64KB would be prohibitive. The 512K limit is arbitrary and can be changed. It exists just to provide a stable start address on something that grows from the end of flash. > 2) The firmware license is not exactly GPL-compatible. The firmware > files > themselves are freely distributable, but the source code is closed. > I'm > not sure how that would work in a GPL U-Boot. > > 3) For Fman, at least, we often update the firmware after the board > ships, > which means you would need to update U-Boot to get a new firmware. > So no > one might actually use this feature because they're afraid they won't > be > able to update the firmware. > > If you can do it, go ahead. I would approve a patch that adds the > ability > to inject a firmware binary into u-boot.bin, provided it's controlled > via > a build or CONFIG_SYS_xxx option. CONFIG_xxx. CONFIG_SYS_xxx options are supposed to describe hardware, and CONFIG_xxx options are supposed to be software config. -Scott