[PATCH 10/11] Add MPC8360EMDS board support

Eugene Surovegin ebs at ebshome.net
Thu Oct 5 16:29:26 EST 2006

On Thu, Oct 05, 2006 at 10:27:14AM +1000, Paul Mackerras wrote:
> Dan Malek writes:
> > I'm not against using the device tree (or platform data
> > or #defines) when it's appropriate to do so.  I think our
> > obsession to represent everything there is what is
> > creating the complexity.  If a #define in a board
> > specific port file makes sense, then just do that,
> > even if it is a BSCR address.
> So, where this discussion started was that I saw an ioremap in an
> ethernet driver using a physical address defined with #define, and I
> said "that should go in the device tree".  And I would still say that
> if the ioremap was still there, since the driver is one that is useful
> across a range of boards and chips.
> My other point would be that what you say is valid *until* the
> hardware engineers come to you and say "we're doing rev 2 of the
> board, and we had to move the BCSR a bit.  That's OK with you, isn't
> it?".
> If you have the BCSR address in the device tree, you don't even need
> to recompile your kernel.  You can just copy your board.dts to
> board-rev2.dts, change the address in there, and rerun the wrapper
> script to create the flash image to put on the new board.  Or if you
> are using a bootloader that knows how to supply a device-tree blob,
> you just put board-rev2.dtb into flash along with your existing kernel
> image.


it doesn't really matter if you have to rebuild a kernel or some 
other blob and have it re-flashed in the actual board.

Having something in device tree doesn't change a simple fact that you 
have to update some firmware component, be it boot code, kernel or 
some dts blob. You still have to prepare new flash image, period.


More information about the Linuxppc-dev mailing list