[U-Boot] ARM926ej, trying to serve interrupt

[Ricardo Martínez]

Wolfang,

Thank you very much for your answer.

I've removed printf and any other dangerous code from "do_irq". But it still
hangs. Only timer interrupt is enabled. Then, serial driver can't generate
interrupts. I've programmed timer to count 10secs and CPU hangs just then.

I think my problem is that I am assuming that when CPU is interrupted,
".irq:" code in start.S is executed. Unfortunately, I don't quite understand
start.S code, neither ARM926 architecture. Maybe I'm missing something
important. Does ARM926 u-boot code by default support interrupt handling? Is
it necesary to configure it further?

Freescale's MPCxxx architectures include install_hdlr in order to register
an interrupt handler for a concrete source. In ARM926ej, I expect CPU to
automatically jump to "do_irq" when it is interrupted. Maybe, I'm being too
optimistic ;S

The code in start.S that I expect to get executed is.

irq:
	get_irq_stack
	irq_save_user_regs
	bl	do_irq
	irq_restore_user_regs

But I can't see why CPU would jump to that address when interrupted. In
other architectures, CPU jumps to a concrete address depending on interrupt
source. With install_hdlr we define where to jump after. This example makes
me think I'm missing a lot of things for ARM926...

Regards,
Ricardo


-----Mensaje original-----
De: Wolfgang Denk [mailto:wd at denx.de] 
Enviado el: miércoles, 26 de agosto de 2009 20:13
Para: Ricardo Martínez
CC: u-boot at lists.denx.de
Asunto: Re: [U-Boot] ARM926ej, trying to serve interrupt

Dear =?iso-8859-1?Q?Ricardo_Mart=EDnez?=,

In message
<!&!AAAAAAAAAAAYAAAAAAAAAJp7zGtD32xAi3bhcLYAeQ3CgAAAEAAAAOIGRX5gEblKkejr+11M
kVQBAAAAAA==@teltronic.es> you wrote:
>
> I'm trying to printf something when one timer generates an interrupt.

Hm... there are certain things you can do in interrupt contect, amd certain
things you cannot do.

Remember that in standard C you can in a signal handler  only  modify
vailables  of  type  sigatomic_t  -  you  must  not  call any library
functions, you must noit call any system calls. Well, in  praxis  you will
probably  find  tat  system  calls  are  safe to call, and most library
functions can be used as well - but nly when you  know  their implementation
well enough to understand exactly what they are (not) doing.

Calling a printf() [which internally may need to allocate buffers, and thus
call malloc() and a lot of other complex functions] is something you must
never do ina signal handler.

Why do you think you can get away with the same here in U-Boot? Even in
interrupt contxt, which is probably even more restricitve?

> u-boot version is 1.3.4.

Old. OLD. I mean: OLD!!!  Please update.

> The problem is that when timer generates interrupt (reaches 0 after 
> several cycles), I expect default u-boot code "do_irq", called from 
> ".irq:" address defined in "start.S" get executed. In that function is 
> where I want to printf anything to check it is working. But the whole 
> system hangs. When timer generates the interrupt, ARM9 hangs without 
> printing anything and normal execution is freezed.
>  
> printf and serial driver work perfectly because I've checked the steps 
> above with prinft debugguing.

Is there any chance that the serial driver might be using interrupts, too,
and that you run into some nested interrupt  handling  which  is not or not
correctly supported by U-Boot?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de After
a time, you may find that "having" is not so pleasing a thing, after all, as
"wanting."  It is not logical, but it is often true.
	-- Spock, "Amok Time", stardate 3372.7