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@denx.de] Enviado el: miércoles, 26 de agosto de 2009 20:13 Para: Ricardo Martínez CC: u-boot@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