On 06/09/2011 03:06 PM, Guenter Roeck wrote:
> Hi David,
>
> On Thu, Jun 09, 2011 at 05:41:57PM -0400, David Daney wrote:
>> On 06/09/2011 02:08 PM, Guenter Roeck wrote:
>>> Hi folks,
>>>
>>> I am trying to get Linux 2.6.39
>>
>> Where did you get your 2.6.39?  Or in othe rwords, what's the SHA1 Kenneth?
>>
>> From kernel.org. 2.6.39.1, more specifically. We have some local modifications,
> but nothing relevant, ie nothing in the mips boot path.
>
>> And, what is your .config?
>>
> Please see attached.


With:

commit cf29f916c310c9b13c19514b496700c549597e11
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Fri Jun 3 09:34:20 2011 +0900

     Linux 2.6.39.1


And with the attached config I can do:

octeon:~# cat /proc/version
Linux version 2.6.39.1 (ddaney@dd1.caveonetworks.com) (gcc version 4.6.1 
20110328 (prerelease) [gcc-4_6-branch revision 171639] (GCC) ) #1031 SMP 
Thu Jun 9 15:44:46 PDT 2011
octeon:~# head /proc/cpuinfo
system type		: EBT3000 (CN3860p3.X-500-NSP)
processor		: 0
cpu model		: Cavium Octeon V0.3
BogoMIPS		: 1000.00
wait instruction	: yes
microsecond timers	: yes
tlb_entries		: 32
extra interrupt vector	: yes
hardware watchpoint	: yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb]
ASEs implemented	:


Boots on all 16 CPUs.

>
>>> to run on a board with Cavium CN38xx
>>> (pass 3, cpu ID 0x000d0003).
>>>
>>> Problem I have is that CPUs 1..15 come online, but get stuck in and
>>> endless interrupt handling loop as soon as interrupts are enabled. I
>>> attached a log generated with instrumentation code in the interrupt
>>> handler.
>>>
>>> Any idea what I might be doing wrong ? Note that I don't start the
>>> system from u-boot; the board uses OFW, so some register initialization
>>> may be wrong.
>>>
>>
>> Octeon only supports the Octeon u-boot 'bootoctlinux' protocol.
>>
> That is a little problem, obviously, since I am not in a position to modify OFW
> on the board. I modified setup.c instead to get and initialize required parameters
> as passed from OFW.
>
>> You have to make sure that the octeon_bootinfo structure is filled in
>> properly, and all the CPUs in the core_mask enter the kernel.
>>
> All CPUs do enter the kernel. Problem is that they get stuck in an endless
> interrupt loop as soon as interrupts are enabled for a core for the first time
> (or soon thereafter).
>
> I know (or at least I am quite sure) that I am doing something wrong during
> initialization, I just hoped someone might have an idea what it might be.
>

If you could run it under the simulator, you could easily debug it.

Otherwise it is not so easy.

David Daney