Proposed: Patch to fix boot on PA6T

Hello All,

    commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
    powerpc/mm: vmalloc abstraction in preparation for radix

    This commit introduced variables for some linux kernel addresses that had
before
    been constants, unfortunately this stopped PaSemi PA6T systems(*) from
booting as
    they call ioremap to map SoC registers before the mmu is initialised. The
attached
    patch adds a hard-coded init of pci_io_base to the pas_init_early()
function which
    which allows the kernel to boot normally.

    The value will be harmlessly set again once pci starts up.

    (*) At the moment this has only been tested on an AmigaOneX1000, but I
expect PaSemi
    reference systems to have been affected in the same way.

Kind regards
Darren

Hi Darren,

Fantastic news! I'll test your patch with the RC5 tomorrow. Excellent work! Well done!

- Christian

Sent from my iPhone

> On 26 Jun 2016, at 18:42, Darren Stevens <darren@stevens-zone.net> wrote:
> 
> Hello All,
> 
>    commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
>    powerpc/mm: vmalloc abstraction in preparation for radix
> 
>    This commit introduced variables for some linux kernel addresses that had
> before
>    been constants, unfortunately this stopped PaSemi PA6T systems(*) from
> booting as
>    they call ioremap to map SoC registers before the mmu is initialised. The
> attached
>    patch adds a hard-coded init of pci_io_base to the pas_init_early()
> function which
>    which allows the kernel to boot normally.
> 
>    The value will be harmlessly set again once pci starts up.
> 
>    (*) At the moment this has only been tested on an AmigaOneX1000, but I
> expect PaSemi
>    reference systems to have been affected in the same way.
> 
> Kind regards
> Darren
> <pa6t-bootfix.patch>

On Sun, 2016-06-26 at 18:42 +0100, Darren Stevens wrote:
> 
>     commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
>     powerpc/mm: vmalloc abstraction in preparation for radix
> 
>     This commit introduced variables for some linux kernel addresses that had
> before been constants, unfortunately this stopped PaSemi PA6T systems(*) from
> booting as they call ioremap to map SoC registers before the mmu is initialised. The
> attached patch adds a hard-coded init of pci_io_base to the pas_init_early()
> function which which allows the kernel to boot normally.

Tell me more, when is that mapping done ? I'm changing things so that
platform probe is called much later so that might have an impact.

What consumes pci_io_base before it's been initialized ?

>     The value will be harmlessly set again once pci starts up.
> 
>     (*) At the moment this has only been tested on an AmigaOneX1000, but I
> expect PaSemi
>     reference systems to have been affected in the same way.

Hi Darren,

On Sun, 2016-26-06 at 17:42:11 UTC, Darren Stevens wrote:
> Hello All,
> 
>     commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
>     powerpc/mm: vmalloc abstraction in preparation for radix
> 
>     This commit introduced variables for some linux kernel addresses that had before
>     been constants, unfortunately this stopped PaSemi PA6T systems(*) from  booting as
>     they call ioremap to map SoC registers before the mmu is initialised. The attached
>     patch adds a hard-coded init of pci_io_base to the pas_init_early() function which
>     which allows the kernel to boot normally.
> 
>     The value will be harmlessly set again once pci starts up.
> 
>     (*) At the moment this has only been tested on an AmigaOneX1000, but I expect PaSemi
>     reference systems to have been affected in the same way.
> 
> Kind regards
> Darren

I can't merge this because you didn't sign it off.

See section 11 of:

  https://www.kernel.org/doc/Documentation/SubmittingPatches

cheers

Darren Stevens <darren@stevens-zone.net> writes:

> Hello All,
>
>     commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
>     powerpc/mm: vmalloc abstraction in preparation for radix
>
>     This commit introduced variables for some linux kernel addresses that had
> before
>     been constants, unfortunately this stopped PaSemi PA6T systems(*) from
> booting as
>     they call ioremap to map SoC registers before the mmu is initialised. The
> attached
>     patch adds a hard-coded init of pci_io_base to the pas_init_early()
> function which
>     which allows the kernel to boot normally.
>
>     The value will be harmlessly set again once pci starts up.
>
>     (*) At the moment this has only been tested on an AmigaOneX1000, but I
> expect PaSemi
>     reference systems to have been affected in the same way.
>
> Kind regards
> Darren
> diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
> index d71b2c7..6b8d2ab 100644
> --- a/arch/powerpc/platforms/pasemi/setup.c
> +++ b/arch/powerpc/platforms/pasemi/setup.c
> @@ -61,6 +61,7 @@ static struct mce_regs mce_regs[MAX_MCE_REGS];
>  static int num_mce_regs;
>  static int nmi_virq = NO_IRQ;
>  
> +extern unsigned long pci_io_base;
>  
>  static void pas_restart(char *cmd)
>  {
> @@ -341,6 +342,10 @@ out:
>  
>  static void __init pas_init_early(void)
>  {
> +	/* Initialise the IO pointer so we don't crash on boot */
> +
> +	pci_io_base = (H_KERN_VIRT_START + (H_KERN_VIRT_SIZE >> 1));
> +
>  	iommu_init_early_pasemi();
>  }
>  

Another option is to init it along with rest of the variables as done in
hash__early_init_mmu(void)/radix__early_init_mmu(void)


-aneesh

Hello Benjamin

On 27/06/2016, Benjamin Herrenschmidt wrote:
> Tell me more, when is that mapping done ? I'm changing things so that
> platform probe is called much later so that might have an impact.
>
> What consumes pci_io_base before it's been initialized ?

pas_pci_init() is the culprit. Following on from Aneesh's suggestion an
improved patch will follow shoertly.

Regards
Darren

Hello Michael

> I can't merge this because you didn't sign it off.

TBH I wasn't really expecting you too.

> See section 11 of:
>
>   https://www.kernel.org/doc/Documentation/SubmittingPatches

Read and understood (I hope)..

Regards
Darren

Hello Aneesh

On 28/06/2016, Aneesh Kumar K.V wrote:
> Another option is to init it along with rest of the variables as done in
> hash__early_init_mmu(void)/radix__early_init_mmu(void)

*FACEPALM* Why didn't I think of that! I've made this change and seems to work
- obviously I can't test on a Radix system though, as I don't have access to
one.

Patch comming shortly

Regards
Darren