Am 01/30/2011 11:07 PM, schrieb Albert ARIBAUD:

Hi Michael,

Le 30/01/2011 22:39, Michael Schwingen a écrit :

...

Hi,

ist it allowed to call pci_init before relocation?

The code looks like this is not supposed to happen. However, on ARM, arm_pci_init (which calls pci_init in turn) is called from init_sequence, which happens before relocation.

Am I overlooking some way in which this can actually work? Are there boards using this?

If I move pci_init down into board_init_r, I can get PCI working on IXP42x, but I am worried if this will cause problems on other boards.

I cannot see a reason why pci_init should not work before relocation as long as it does not read or write BSS variables or write non-const initialized data -- or overflow the (admittedly limited) C stack.

Because it does just that - from drivers/pci/pci.c:

static struct pci_controller* hose_head;

void pci_init(void) { [...] hose_head = NULL;

/* now call board specific pci_init()... */ pci_init_board(); }

pci_init_board will then call code that ends up calling pci_register_hose, which adds elements into the list at hose_head.

Are you asking because you discovered that pci_init does not work when called from board_init_f? If so, did you determine exactly what goes wrong?

The system hangs during early init, and does not get past relocation.

Note that I can only *test* PCI on IXP42x, however, this is common code, so I do not see how this could behave different on other ARM systems.

If I interpret the code correct, the PCI code is called from board_init_r on PowerPC platforms.

cu Michael

Hello Albert, Michael,

Albert ARIBAUD wrote:

Le 30/01/2011 23:46, Michael Schwingen a écrit :

...

Am 01/30/2011 11:07 PM, schrieb Albert ARIBAUD:

...

Hi Michael,

Le 30/01/2011 22:39, Michael Schwingen a écrit :

...

Hi,

ist it allowed to call pci_init before relocation?

The code looks like this is not supposed to happen. However, on ARM, arm_pci_init (which calls pci_init in turn) is called from init_sequence, which happens before relocation.

Am I overlooking some way in which this can actually work? Are there boards using this?

If I move pci_init down into board_init_r, I can get PCI working on IXP42x, but I am worried if this will cause problems on other boards.

I cannot see a reason why pci_init should not work before relocation as long as it does not read or write BSS variables or write non-const initialized data -- or overflow the (admittedly limited) C stack.

Because it does just that - from drivers/pci/pci.c:

static struct pci_controller* hose_head;

void pci_init(void) { [...] hose_head = NULL;

 /* now call board specific pci_init()... */
 pci_init_board();

}

pci_init_board will then call code that ends up calling pci_register_hose, which adds elements into the list at hose_head.

Tough luck -- BTW, how does this code allocate the memory? The heap is obviously not going to work before relocation.

...

...

Are you asking because you discovered that pci_init does not work when called from board_init_f? If so, did you determine exactly what goes wrong?

The system hangs during early init, and does not get past relocation.

Note that I can only *test* PCI on IXP42x, however, this is common code, so I do not see how this could behave different on other ARM systems.

If I interpret the code correct, the PCI code is called from board_init_r on PowerPC platforms.

Hmm... Now let's reverse the question: why should PCI be initialized before relocation? At this point the only goal of the init_board_f code is to get the RAM working for relocation, and the only useful device is the serial console. Does pci_init() help for either RAM or console?

I think, on arm plattforms we should move the pci_init as it is done on powerpc plattforms, to board_init_r. It seems to me, that this is a leftover from introducing relocation to arm. I also just could think of using a "PCI console" before relocation... and if I looked right, this is not used on any arm plattform ...

bye, Heiko

On 01/31/2011 09:45 AM, Heiko Schocher wrote:

I think, on arm plattforms we should move the pci_init as it is done on powerpc plattforms, to board_init_r. It seems to me, that this is a leftover from introducing relocation to arm. I also just could think of using a "PCI console" before relocation... and if I looked right, this is not used on any arm plattform ...

Fine. I'll include that change with the other changes needed to get PCI up again on IXP425.

cu Michael

Albert ARIBAUD wrote:

Le 30/01/2011 23:46, Michael Schwingen a écrit :

...

Am 01/30/2011 11:07 PM, schrieb Albert ARIBAUD:

...

Hi Michael,

Le 30/01/2011 22:39, Michael Schwingen a écrit :

...

Hi,

ist it allowed to call pci_init before relocation?

The code looks like this is not supposed to happen. However, on ARM, arm_pci_init (which calls pci_init in turn) is called from init_sequence, which happens before relocation.

Am I overlooking some way in which this can actually work? Are there boards using this?

If I move pci_init down into board_init_r, I can get PCI working on IXP42x, but I am worried if this will cause problems on other boards.

I cannot see a reason why pci_init should not work before relocation as long as it does not read or write BSS variables or write non-const initialized data -- or overflow the (admittedly limited) C stack.

Because it does just that - from drivers/pci/pci.c:

static struct pci_controller* hose_head;

void pci_init(void) { [...] hose_head = NULL;

 /* now call board specific pci_init()... */
 pci_init_board();

}

pci_init_board will then call code that ends up calling pci_register_hose, which adds elements into the list at hose_head.

Tough luck -- BTW, how does this code allocate the memory? The heap is obviously not going to work before relocation.

The new hose pointer is passed into that function - the calling code would have to either malloc that, or use a static struct (as it is done on IXP, because there is only one PCI bus). Both will fail before relocation - the hose structure would have to be embedded into the global data struct.

...

...

Are you asking because you discovered that pci_init does not work when called from board_init_f? If so, did you determine exactly what goes wrong?

The system hangs during early init, and does not get past relocation.

Note that I can only *test* PCI on IXP42x, however, this is common code, so I do not see how this could behave different on other ARM systems.

If I interpret the code correct, the PCI code is called from board_init_r on PowerPC platforms.

Hmm... Now let's reverse the question: why should PCI be initialized before relocation? At this point the only goal of the init_board_f code is to get the RAM working for relocation, and the only useful device is the serial console. Does pci_init() help for either RAM or console?

I don't see a reason to do that - my vote would be to do the PCI initialization after relocation, but I am not sure if there are any ARM boards that need this for whatever reason. If there are any, I would expect them to be broken anyway since relocation was added, but I can't be sure.

cu Michael

Wolfgang Denk wrote:

Dear Michael Schwingen,

In message 4D45EA43.3070108@discworld.dascon.de you wrote:

...

The system hangs during early init, and does not get past relocation.

That is to be expected when you use this before relocation. Don't do that, then.

...

If I interpret the code correct, the PCI code is called from board_init_r on PowerPC platforms.

So what? board_init_r() is (quoting the comment) "the next part if the initialization sequence: we are now running from RAM and have a "normal" C environment, i. e. global data can be written, BSS has been cleared, the stack size in not that critical any more, etc."

So it's perfectly safe and clean to run pci_init() there.

I know - I only wanted to point at the differences: the problem is that the ARM code does it before relocation currently, and I was trying to understand why.

cu Michael