Subject: Re: [PATCH v2] qe: add ability to upload QE firmware

From: Arnd Bergmann <[email-masked]>
Date: Thu, 6 Dec 2007 01:17:14 +0100

On Thursday 06 December 2007, Timur Tabi wrote:
> > In that case, I think it
> > would really be better to just put the blob into the tree and only
> > have the fw loading code in the kernel instead of duplicating it in the boot
> > loader.
> 
> That would require the firmware to present in RAM for all time, since the device 
> tree cannot be unloaded.

Yes, that's a backdraw of my approach, but in the case of spidernet, it was only
an insignificant amount of RAM. Don't know what sizes of RAM and QE firmware
to expect typically on the machines you care about.

> Besides, you might need to have the firmware loaded in  
> U-Boot anyway.  If your console is connected to the QE, then you'll need the 
> UART firmware loaded before you can see anything.  That's why U-Boot needs its 
> own version.

Right, so you can't really get around having it in some boot loaders at least.
IIRC you said that the firmware is only needed for serial output on some chips
but not on others. What about the case where you don't need it for serial but
still want to provide it by the firmware, and perhaps use something other than
U-boot? Is that relevant?

I'm not trying to convince you of this if it's completely pointless for
all your systems, just want to make sure you're aware of this option,
because spending a few extra code lines on it now may save you some trouble
if you need this later.

> > Regarding the question whether the firmware should be a device node or
> > a property of another node, I'd prefer a simple property, because the
> > firmware itself is not really a device you can access, but I don't care
> > much about that.
> 
> Technically, the firmware could be considered a device on the QE, because it's 
> loaded into I-RAM and it can significantly alter the behavior of the device. 

Well, it doesn't have any of the standard properties like registers or interrupts
though.

> Having it its own node also lets me compartmentalize it.  If I want to expand 
> the node and add more properties, it's cleaner.

Yes, that makes a lot of sense.

	Arnd <><