Hi Frits,

Responses inline below:

Frits van der Holst wrote:
> Hello,
> 
> We have a question about the kernel boot sequence. 
> A normal kernel boot should look like this:
> 
> VFPv3: fpsid=410330c1
> coproc_attach(10): replacing fe074a20 with fe07426c
> coproc_attach(11): replacing fe074a20 with fe07426c
> Welcome to QNX Neutrino 6.4 on the Texas Instruments OMAP3530 (ARMv7 Cortex-A8 core) EVM Board
> 
> Question 1:
> In which phase of the boot process is each line printed. In other words which steps does the kernel execute before 
each of the printed lines.

The coproc_attach messages are printed during kernel initialisation.
This is fairly early on in the initialisation sequence.

The "Welcome to QNX ..." is presumably the display_msg in the boot
script. This is executed by the process manager in a thread context
after the kernel initialisation.

Basically the steps are:
1. startup runs, set up the system page etc. loads procnto into memory
    enables the MMU and jumps to the procnto entry point
2. procnto (kernel) does its basic initialisation
3. procnto (kernel) creates the idle thread for each processor
4. kernel begins execution of the idle thread
5. idle thread performs procnto (process manager) initialisation
6. process manager creates a thread pool to service procmgr/memmgr messages
7. idle thread sends a pulse to start processing the boot script
8. idle thread enters the idle loop
9. process manager thread pool thread receives pulse and executes boot script

> Our kernel crashes just after the second "coproc_attach(" message, so we want to know what the kernel is doing at that
 point.

You have crashed some point after (2) above, but we can't tell where...

> Question 2:
> Is there a way to increase amount of debugging from the procnto kernel (with command line options for example). We 
don't have access to the kernel source at this moment.

Unfortunately there isn't any way to debug this further.
It normally "just works" :-)

Can you confirm exactly what cpu revision of the A9 MPCore you are using?
I seem to recall a previous post indicated it was an r0p1?

Our current platforms are r1p1 or r1p2 - I seem to recall we had some problems
with an earlier r0p1 implementation. I don't recall details and that particular
SoC has now moved onto r1p2.

As I said in my other reply, it might be quickest to have a quick inspect of
your code to see if there's anything obviously missing..
.
	Sunil.