Hi Simon,

On 11/05/2017 00:03, Simon Glass wrote:

Hi Angelo,

On 10 May 2017 at 15:58, Angelo Dureghello angelo@sysam.it wrote:

...

Coldfire arch is not happy with timer_init since interrupt handlers are still not set at that stage, and the boot hangs silently.

Signed-off-by: Angelo Dureghello angelo@sysam.it

common/board_f.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c index d9431ee79a..30e588e213 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -740,7 +740,9 @@ static const init_fnc_t init_sequence_f[] = { /* get CPU and bus clocks according to the environment variable */ get_clocks, /* get CPU and bus clocks (etc.) */ #endif +#if !defined(CONFIG_M68K) timer_init, /* initialize timer */ +#endif #if defined(CONFIG_BOARD_POSTCLK_INIT) board_postclk_init,

#endif

2.11.0

I'm really hoping we can get rid of all arch-specific things from the init sequence.

Yes, i have seen you unified that step for all archs, and unfortunately i discovered the issue now only updating u-boot on my mcf5307 based board.

Is there no way that m68k can init its timer here? Or perhaps it could be a nop function?

I checked now all the cpu/xxx/start.S. At that early stage, all the vector handlers are set to _fault thats is just and endless loop.

In Coldfire arch, timer_init() is implemented in lib/time.c, as to setup and start the system timer overflow interrupt. It is called later from board_init_r(), line 863, after interrupt_init().

So, no :( unless you don't have some suggestion, i don't see any easy way to keep that timer_init() call enabled in board_init_f().

Regards, Simon

Regards, angelo

Hi Simon.

On 17/05/2017 03:38, Simon Glass wrote:

Hi Angelo,

On 10 May 2017 at 16:36, Angelo Dureghello angelo@sysam.it wrote:

...

Hi Simon,

On 11/05/2017 00:03, Simon Glass wrote:

...

Hi Angelo,

On 10 May 2017 at 15:58, Angelo Dureghello angelo@sysam.it wrote:

...

Coldfire arch is not happy with timer_init since interrupt handlers are still not set at that stage, and the boot hangs silently.

Signed-off-by: Angelo Dureghello angelo@sysam.it

common/board_f.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c index d9431ee79a..30e588e213 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -740,7 +740,9 @@ static const init_fnc_t init_sequence_f[] = { /* get CPU and bus clocks according to the environment variable */ get_clocks, /* get CPU and bus clocks (etc.) */ #endif +#if !defined(CONFIG_M68K) timer_init, /* initialize timer */ +#endif #if defined(CONFIG_BOARD_POSTCLK_INIT) board_postclk_init,

#endif

2.11.0

I'm really hoping we can get rid of all arch-specific things from the init sequence.

Yes, i have seen you unified that step for all archs, and unfortunately i discovered the issue now only updating u-boot on my mcf5307 based board.

...

Is there no way that m68k can init its timer here? Or perhaps it could be a nop function?

I checked now all the cpu/xxx/start.S. At that early stage, all the vector handlers are set to _fault thats is just and endless loop.

In Coldfire arch, timer_init() is implemented in lib/time.c, as to setup and start the system timer overflow interrupt. It is called later from board_init_r(), line 863, after interrupt_init().

So, no :( unless you don't have some suggestion, i don't see any easy way to keep that timer_init() call enabled in board_init_f().

My only ideas are:

• user driver model for timer and then call the interrupt init from

your driver's probe() method

• make timer_init() a nop for you arch

thanks, it sounds good.

Ok, i see the patch has been applied to master so we have the things working for now.

I'll try to do the change above in the next future, i keep it in the todo list.

Regards, Angelo

Regards, Simon