| Message ID | 49760dd82b0.759fd78a@auth.smtp.1and1.co.uk (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
On Fri, Jan 20, 2017 at 05:46:13PM +0000, Darren Stevens wrote: > --- a/arch/powerpc/kernel/head_64.S > +++ b/arch/powerpc/kernel/head_64.S > @@ -79,6 +79,13 @@ _GLOBAL(__start) > /* NOP this out unconditionally */ > BEGIN_FTR_SECTION > FIXUP_ENDIAN > +#ifdef CONFIG_PPC_PASEMI_NEMO > + /* > + * Zero address 8 so Nemo will boot > + */ > + li r0,0 > + std 0,8(0) > +#endif std r0,8(0) for clarity? Segher
Darren Stevens <darren@stevens-zone.net> writes: > Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') added a > macro 'FIXUP_ENDIAN' to head_64.S. The CFE on Nemo has a bug > that shows up when this is included, the system hangs right after > printing the initial memory map, before the CPU's are started. > > Clearing the long long at addr 8 has been shown to fix this, so > add an initalisation to head_64.S so the system will boot. I'd really prefer it if someone could tell me why we need to clear it. But I assume no one knows? > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S > index 1dc5eae..032b317 100644 > --- a/arch/powerpc/kernel/head_64.S > +++ b/arch/powerpc/kernel/head_64.S > @@ -79,6 +79,13 @@ _GLOBAL(__start) > /* NOP this out unconditionally */ > BEGIN_FTR_SECTION > FIXUP_ENDIAN > +#ifdef CONFIG_PPC_PASEMI_NEMO > + /* > + * Zero address 8 so Nemo will boot > + */ > + li r0,0 > + std 0,8(0) > +#endif > b __start_initialization_multiplatform > END_FTR_SECTION(0, 1) I don't want to pollute this code with NEMO workarounds if we can avoid it. You said the hang happens after printing the initial memory map, I'm not quite sure where you mean, but it sounds like that will be late enough that we can do the clear in pasemi platform code? cheers
Hello Michael On 23/01/2017, Michael Ellerman wrote: >> Clearing the long long at addr 8 has been shown to fix this, so >> add an initalisation to head_64.S so the system will boot. > > I'd really prefer it if someone could tell me why we need to clear it. > But I assume no one knows? The problem was found by Christian, and the fix comes courtesy of Olof Johansson, I've not looked into it before. > I don't want to pollute this code with NEMO workarounds if we can avoid > it. To be honest, so would I. > You said the hang happens after printing the initial memory map, I'm not > quite sure where you mean, but it sounds like that will be late enough > that we can do the clear in pasemi platform code? During prom_init. Where it says 'Memory layout at Init' I took a long look today and traced the problem the 'prom_find_boot_cpu' and a much better patch will follow. Regards Darren
Darren Stevens <darren@stevens-zone.net> writes: > On 23/01/2017, Michael Ellerman wrote: >>> Clearing the long long at addr 8 has been shown to fix this, so >>> add an initalisation to head_64.S so the system will boot. >> >> I'd really prefer it if someone could tell me why we need to clear it. >> But I assume no one knows? ... > > I took a long look today and traced the problem the 'prom_find_boot_cpu' and a > much better patch will follow. Awesome work, thanks. cheers
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 1dc5eae..032b317 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -79,6 +79,13 @@ _GLOBAL(__start) /* NOP this out unconditionally */ BEGIN_FTR_SECTION FIXUP_ENDIAN +#ifdef CONFIG_PPC_PASEMI_NEMO + /* + * Zero address 8 so Nemo will boot + */ + li r0,0 + std 0,8(0) +#endif b __start_initialization_multiplatform END_FTR_SECTION(0, 1)
Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') added a macro 'FIXUP_ENDIAN' to head_64.S. The CFE on Nemo has a bug that shows up when this is included, the system hangs right after printing the initial memory map, before the CPU's are started. Clearing the long long at addr 8 has been shown to fix this, so add an initalisation to head_64.S so the system will boot. Signed-off-by: Darren Stevens <darren@stevens-zone.net> ---