Re: MPC5200 does not boot
From: Nicholas Piggin <npiggin@gmail.com>
Date: 2016-08-02 03:16:52
On Tue, 02 Aug 2016 12:44:33 +1000 Benjamin Herrenschmidt [off-list ref] wrote:
On Tue, 2016-08-02 at 00:44 +0200, Michal Sojka wrote:quoted
Hi Benjamin, =20 the following commit causes my MPC5200 not to boot. =20 =C2=A0=C2=A0=C2=A0=C2=A0commit 9402c684613163888714df0955fa1f17142b08bf=
=20
quoted
quoted
=C2=A0=C2=A0=C2=A0=C2=A0Author: Benjamin Herrenschmidt <benh@kernel.c=
rashing.org> =20
quoted
=C2=A0=C2=A0=C2=A0=C2=A0Date:=C2=A0=C2=A0=C2=A0Tue Jul 5 15:03:41 2016 =
+1000
quoted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0powerpc: Factor do_feat=
ure_fixup calls
quoted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A032 and 64-bit do a simi=
lar set of calls early on, we move it all to
quoted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0a single common functio=
n to make the boot code more readable.
quoted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Signed-off-by: Benjamin=
Herrenschmidt [off-list ref] =20
quoted
quoted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Signed-off-by: Michae=
l Ellerman [off-list ref] =20
quoted
=20 I suspect that the cause will be similar as described in commit 1cd03890ea64795e53f17a94928cca22495acb2a. Unfortunately, I don't have much time to debug this, but I can easily test patches. =20=20 Are you sure of your bisection ? Did you verify that reverting that one patch fixes it ? Because all this does is move code to a function, the code is functionally the same and called in the same place...
+ struct cpu_spec *spec =3D *PTRRELOC(&cur_cpu_spec); + + /* + * Apply the CPU-specific and firmware specific fixups to kernel text + * (nop out sections not relevant to this CPU or this firmware). + */ + do_feature_fixups(spec->cpu_features, + PTRRELOC(&__start___ftr_fixup), + PTRRELOC(&__stop___ftr_fixup)); Shouldn't these be PTRRELOC(spec)->cpu_features ? You are relocating access to the pointer word, but not the address it contains. identify_cpu() returns the relocated pointer which is what 32-bit used to use. Thanks, Nick