[PATCH 2/5] [PPC] Merge common virtex header files

[Grant Likely]

On 4/30/07, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
> Peter Korsgaard wrote:
> > GL> Alternate suggestion: Can we change virtex support to use the
> > GL> structure defined in ppcboot.h instead?  (I've actually got that
> > GL> change in my tree and was planning on posting it for review today
> > GL> or tomorrow).  bd_t is a stinking ugly mess, but things would be
> > GL> better if we standardize all virtex platforms on the stinking ugly
> > GL> mess shared by almost all the other ppc embedded board ports.
> >
> > That's where the ugly mess pops up - RedBoot uses another
> > (incompatible) bd_t definition than U-boot, E.G:
> >
> > typedef struct bd_info {
> >       unsigned int   bi_tag;        /* Should be 0x42444944 "BDID" */
> >
> snip
> >
> >       int            bi_flashwidth; /* Width (8,16,32,64) */
> >       unsigned char *bi_cmdline;    /* Pointer to command line */
> > } bd_t;
> >
> > I should probably migrate to U-boot anyway, but still ..
> >
>
>     Can we please not standardize on some specific implimentation of
> bd_info ?
>
>     We have our own bootloader - actually a monitor. It does alot of
> things besides boot Linux.
>     and it does so in less than 16K.
>     our bd_info struct is used to pass info to OS's besides Linux.
>     It does not have all the crap the u-boot bd_info has in it that has
> no meaning for us.
>     But it does have some things that are very specific to our
> hardware/firmware.

I understand your concerns.  Here are my thoughts when I put together
this patch:

- Only the ML300 and ML403 board ports are in mainline.  There has
been no serious push to get other Virtex platforms supported from
mainline; so patches need to be applied *regardless* for any boards
other than the ml300 and ml403 ref designs.  Patching to a different
bd_t is trivial.
- Even ml300 and ml403 ports in mainline don't work for anything other
than zImage.  The custom bd_t doesn't buy us anything.
- bd_t is a truly awful solution to the problem of passing information
from bootloader to kernel.  In arch/ppc, we cannot get away from it,
so I want to minimize it's stinkyness as much as possible.  By moving
from the custom virtex bd_t to the one in ppcboot.h at least makes it
work with one of the boot loaders (u-boot).
3. Unfortunately, even in moving to arch/powerpc we're still stuck
with bd_t as long as we continue to support older boot loaders (via
the boot wrapper).  As such, I'm actively discouraging the practice of
board specific bd_t.  Between now and the move to arch/powerpc there
will be plenty of people starting new virtex board ports, and I want
to make it clear that custom bd_t's are strongly discouraged.
However, if you already have a board port w/ a different bd_t, then
it's still no problem.  It is trivial to conditionally omit
#include<ppcboot.h> in favor of a different bd_t.

>     Besides, I am not current on the powerpc tree but isn't this kind of
> thing what device trees are
>     supposed to be about and don't we have to do that anyway to migrate
> to the powerpc tree ?

Yes, the ideal is that a single kernel image will be bootable on any
Virtex FPGA design if it is passed the correct device tree by a
compliant boot loader, but we're not there yet and I don't want to
make the situation any worse between now and then.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195