[U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
Now when I'm trying to migrate to U-Boot 2013.01 I face problems with a sudden hang. I see console output until the "Flash:" from arch/powerpc/lib/board.c::board_init_r() but nothing more until the board reboots on a watchdog reset after 30s.
Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks(). Reverting commit "ppc: Create a stack frame for wait_ticks()" made everything work again.
I am not fluent enough in powerpc assembly or gcc stack frames for the same to see exactly what is wrong. Perhaps someone with the necessary mileage could take a look?
BR // Mats
Dear Mats Kärrman,
In message ED3E0BCACD909541BA94A34C4A164D4C427B4AA5@post.tritech.se you wrote:
Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks(). Reverting commit "ppc: Create a stack frame for wait_ticks()" made everything work again.
This makes no sense to me - especially as it works on all other systems.
I am not fluent enough in powerpc assembly or gcc stack frames for the same to see exactly what is wrong. Perhaps someone with the necessary mileage could take a look?
Well, you mentioned you were using a MPC5125 processor which is not supported in mainline U-Boot, and which is known to have enough differences in it's register layout that anything might be the cause for such issues.
Is it correct to assume that you have a _lot_ of local modifiucations in your tree? I bet the problem lies there...
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks(). Reverting commit "ppc: Create a stack frame for wait_ticks()" made everything work again.
This makes no sense to me - especially as it works on all other systems.
If you say it works, it makes no sense to me either. I thought it might be some subtle difference in the way the e300c4 core or GCC works compared to other PPC cores. If there are no such differences, then a patch with no intended functional difference beyond keeping gdb happy should not make any difference, good or bad.
Well, you mentioned you were using a MPC5125 processor which is not supported in mainline U-Boot, and which is known to have enough differences in it's register layout that anything might be the cause for such issues.
Is it correct to assume that you have a _lot_ of local modifiucations in your tree? I bet the problem lies there...
I wouldn't say a lot. I'm using only the serial console to be able to download and flash images (using CFI flash) and to boot Linux so the primary patches are the serial driver and the DRAM initialization. On top of that there are some minimal I/O initialization and of course I went through and updated the register mappings for the relevant peripherals. It worked fine with 2009.03 and with 2012.07 but of course I might have overlooked something.
I will report back when / if I find out something more. I'm not much for betting though ;)
Best regards, Mats
Mats Kärrman Mats.Karrman@tritech.se wrote on 2013/01/23 22:58:56:
Dear Wolfgang Denk,
Found that it was looping endlessly in
arch/powerpc/lib/ticks.S::wait_ticks
(). Reverting commit "ppc: Create a stack frame for wait_ticks()" made everything work again.
This makes no sense to me - especially as it works on all other systems.
Me neither, there is not a lot details. I do recall having other problems with wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in get_ticks) would not increment so one would just loop forever in wait_ticks. This problem had nothing to do with my patch though. Never got around to finding out what caused it, we ended up blaming unstable HW.
Some ideas though: - Perhaps you have some alignment problem, try adding nop's here and there. - My patch uses r0(which is what one should use to make gdb happy) instead of r8 to stash the LR. Possibly you have some odd dependency on r0, try using r8 again.
None of the above is a real fix tough.
If you say it works, it makes no sense to me either. I thought it might
be
some subtle difference in the way the e300c4 core or GCC works compared
to
other PPC cores. If there are no such differences, then a patch with no intended functional difference beyond keeping gdb happy should not make
any
difference, good or bad.
hmm, we use e300c2 with no problem.
Jocke
participants (3)
-
Joakim Tjernlund -
Mats Kärrman -
Wolfgang Denk