AW: Re: __setup_cpu_be problem

Benjamin Herrenschmidt benh at kernel.crashing.org
Mon Feb 13 08:24:22 EST 2006


> 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 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...

> - We want to use 64k pages in the future, so the firmware needs to
>   add the 'ibm,segment-page-sizes' property ASAP, preferrably at
>   the same time they start setting up HID6. I currently have a
>   hack for the kernel to override that, but we're in the process
>   of eliminating all the special hacks that won't make in into
>   the mainline kernel.

The only things you need is to have this property set and the new
ibm,pa-feature for which I need to dig out the latest spec.... The
problem is that the kernel will currentl not enable 64k pages on any
processor due to the lack of a feature bit (intentionally) from the
cputable. That bit will be extracted from ibm,pa-features at least on
pSeries. It's the bit indicating that L=1 works for cache inhibited
mappings.

> Yes, 1M mappings are probably not of much use to us, and other OSs
> already do whatever they like ;-).

Sure. Note that the firmware can still set HID6 to 1M pages and put the
appropriate entries in the device-tree for 1M large pages. Linux won't
be able to use them as-is though but at least the device-tree infos will
be sane. I don't want to enter a debate wether we should be able to
change HID6 etc... right now. It's more a firmware configuration issue
as far as I'm concerned.

> Then please try to at least send the spec or a link to Hartmut's IBM
> internal address (hpenner at de.ibm.com). I already pointed him to the
> linux code when it was initially merged, but he argued that reverse
> engineering that code is not good enough to be sure to get the
> property right and not having it in there is better than having incorrect
> properties.

Will do
Ben.




More information about the Linuxppc64-dev mailing list