[PATCH 0/8] powerpc: Kexec fixups and support for booting at 32MB

[Michael Ellerman]

On Tue, 15 Nov 2005 05:23, Milton Miller wrote:
> I do have comments on this series, but have been slow to write them
> down.
>
> PS: Please copy me on kexec/kdump ppc patches so I can reply with
> references.  I read the lists from the web.

Sure.

> [PATCH 1/8] powerpc: Turn cpu_irq_down into kexec_cpu_down

Paul has already merged this so you can fix it up later if you want. It fixes 
bugs so we need it now rather than later.

> [PATCH 5/8] powerpc: Add CONFIG_CRASH_DUMP
> the __va change should be in  [PATCH 4/8] powerpc: Seperate usage of
> KERNELBASE and PAGE_OFFSET

Done.

> And should this not be last, since following patches are required
> to get the kernel to work again?   What, you need PHYISCAL_START
> for them?  well just #define it 0 for a bit in patch 4.

Well I guess. Although it seems like overkill given that the kernel is fine 
unless you turn on CONFIG_CRASH_DUMP. I guess I'll reorder them.

> [PATCH 6/8] powerpc: Reroute interrupts from 0 + offset to
> PHYSICAL_START + offset
>
> The following should be in user space / device tree:
> +#ifdef CONFIG_CRASH_DUMP
> +       lmb_reserve(0, KDUMP_BACKUP_LIMIT);
> +#endif

I disagree. It's a PPC64 implementation detail that we have to fiddle with 
stuff at 0, as far as userspace is concerned the kdump kernel is at 32 MB and 
up. If we require kexec-tools to do this, we'll have to keep the shape of 
head.S in sync with kexec-tools.

> [PATCH 7/8] powerpc: Create a trampoline for the fwnmi vectors
> I totally disagree with this one, espically reregitering with
> the low address in the trampoline.  The registration should be at
> the new address.  And a1, a2 are very generic names.

I'm not sure which bit you disagree with? We have to use a trampoline, the 
addresses we pass to firmware must be < 32MB (see PAPR).
I've changed the names.

> [PATCH 8/8] powerpc: Fixups for kernel linked at 32 MB
> (1) powermac smp.c -- use create_branch

Done.

> (2) The secondary hold code could be done as a 64 bit load in the
> first 0x100 bytes vs LOADADDR

Hmmm, not sure what you mean?

> (3) Why did you move LOAD_HANDLER down one instruction?  It would
> seem not to help optimization

Yep, fixed, that was a hang over from a previous version.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person