AW: Re: __setup_cpu_be problem
Hartmut Penner
HPENNER at de.ibm.com
Tue Feb 14 05:19:10 EST 2006
Hello
the initial value set by FW of the HID6 is 0x00010034_00000000.
I would like to support the large pages in the Firmware, but need to know
excactly what properties I have to set.
Looked at the linux code, but still are not quiet sure what values to put
into ibm,segment-page-sizes.
Could somebody enlighten me, how to find out ? I am right now in Rochester,
would there be somebody here
to talk about ?
regards, Hartmut
|---------+---------------------------->
| | Benjamin |
| | Herrenschmidt |
| | <benh at kernel.cras|
| | hing.org> |
| | |
| | 02/12/06 10:24 PM|
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Arnd Bergmann <arnd at arndb.de> |
| cc: Masato.Noguchi at jp.sony.com, linuxppc64-dev at ozlabs.org, geoffrey.levand at am.sony.com, Hartmut Penner/Germany/IBM at IBMDE|
| Subject: Re: AW: Re: __setup_cpu_be problem |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------------------|
> 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