AW: Re: __setup_cpu_be problem

[Arnd Bergmann]

On Sunday 12 February 2006 22:24, Benjamin Herrenschmidt wrote:
> > The current firmware on the Cell blades does neither the setup of
> > the HID6 register nor have the correct tables in the device tree.
> > 
> > Since I'm still currently sitting in a garden in NZ instead of the
> > Böblingen lab, I can't find out what the HID6 power-on defaults
> > are. We might get away with just leaving the default there, but that
> > might prevent us from using 16M and/or 64k pages and there are 
> > definitely some application which depend on 16M hugetlb mappings
> > on Cell. 
> 
> Yes, however, how much widely distributed and "frozen" is this current
> Cell firmware ? I mean, do we really need to add a workaround to the
> kenrel instead of just fixing the firmware here ?

The firmware update procedure is a little tricky, so our firmware
people decided to as few updates as possible, which means we won't
have small 'hotfix' updates going to the customer.

> > The two problems we are facing currently are:
> > - If HID6 defaults to disabling 16M large pages, the kernel will
> >   get the wrong information from the CPU features and applications
> >   that use it break. The firmware should add the setup if HID6
> >   _now_, but we also should be prepared for users of old firmware
> >   that want to upgrade their kernel without upgrading the firmware
> >   at the same time.
> 
> Do we really need to support old/broken firmware ? It's not like we had
> a released product all over the field...

Basically, we do want to support old firmware that went out in our
customer shippings, but as I wrote in the other mail, we don't need
to worry about that in this case. Also, the requirement is only to
be able to boot with the mainline kernel, for production setup, users
of the currently shipping hardware would also need other patches e.g.
to work around performance errata in the CPU stepping.

I expect that for the systems that ship in larger quantities (Mercury,
Sony and IBM ones in the forseeable future) we can do without ugly
hacks of that sort.

	Arnd <><