[U-Boot-Users] [PATCH] Fix for mcf5329evb - spurious interrupts on Linux/uClinux kernel boot
Hi TsiChung,
I followed your most recent advice, and it works like a charm! Thanks!
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way to submit patches, but I assume you'll take over from here, right?
Aaron, Wolfgang: I sent this directly to you in case you're interested...
Take care, -Bob
P.S. Aaron, you were right - I do indeed have 32 MBytes... Thanks!
On Wednesday 08 August 2007, Robert S. Grimes wrote:
I followed your most recent advice, and it works like a charm! Thanks!
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way to submit patches, but I assume you'll take over from here, right?
Could one of you guys please send this fix as a real patch with a proper signed-off line please. I'll commit the outstanding patches from TsiChung later and will ask Wolfgang to pull from the ColdFire custodian repository.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan, sorry, in hindsight it is clear that I could have handled this better...
TsiChung, I really meant to send this to you for you to submit, as I didn't want to step on your changes. That, and I don't know the proper patch submittal process.
List, I sent it to the list for others to use.
Some day maybe I'll get the hang of this... :-[ -Bob
Stefan Roese wrote:
On Wednesday 08 August 2007, Robert S. Grimes wrote:
I followed your most recent advice, and it works like a charm! Thanks!
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way to submit patches, but I assume you'll take over from here, right?
Could one of you guys please send this fix as a real patch with a proper signed-off line please. I'll commit the outstanding patches from TsiChung later and will ask Wolfgang to pull from the ColdFire custodian repository.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Robert,
in message 46B91373.1090809@alum.mit.edu you wrote:
I followed your most recent advice, and it works like a charm! Thanks!
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way to submit patches, but I assume you'll take over from here, right?
Aaron, Wolfgang: I sent this directly to you in case you're interested...
I am interested, but can you please send a proper patch, with Signed-off-by: line and all that? Please see http://www.denx.de/wiki/UBoot/Patches
Best regards,
Wolfgang Denk
Dear Wolfgang, Robert, and Tsi-Chung,
On 9 Aug 2007 at 23:31, Wolfgang Denk wrote:
Dear Robert,
in message 46B91373.1090809@alum.mit.edu you wrote:
I followed your most recent advice, and it works like a charm! Thanks!
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way
[...]
is this considered the correct solution?
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
In this case, I think we should have a function doing this in cpu/.../interrupts.c and call this function always befor control is transferred to the linux kernel. Additionally, this would prevent additional #ifdefs, because the cpu specific things would be handled in cpu/.../interrupts.c.
For mcf532x, interrupt_init() does exactly this, but this seems not the case for mcf52x2, at least not for all the processors handled there.
Any comments of those having an overview over m68k?
Best regards, Wolfgang
Here I was, preparing the patch in the correct format, and I decided to check my inbox!
On 8/10/07, w.wegner@astro-kom.de w.wegner@astro-kom.de wrote:
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way
is this considered the correct solution?
I don't know! :)
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
In this case, I think we should have a function doing this in cpu/.../interrupts.c and call this function always befor control is transferred to the linux kernel. Additionally, this would prevent additional #ifdefs, because the cpu specific things would be handled in cpu/.../interrupts.c.
For mcf532x, interrupt_init() does exactly this, but this seems not the case for mcf52x2, at least not for all the processors handled there.
I don't know the "big picture" for Das U-Boot, so I can't really comment here, other than to note that fewer #ifdefs is good!
I can send my patch in at any time, but until this is resolved, I'm going to hold off...
-Bob
In message 46BC68C1.1965.E9A829@w.wegner.astro-kom.de you wrote:
Attached is a very small patch that implements the fix - when CONFIG_MCF532x is defined, the timer interrupt is masked immediately prior to calling into the kernel. I don't know if this is the right way
[...]
is this considered the correct solution?
It probably fixes an immediate problem...
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
Right.
Best regards,
Wolfgang Denk
On Friday 10 August 2007, Wolfgang Denk wrote:
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
Right.
IIRC the function we are talking about here is do_bootm_linux() (m68k version) which is called from the common do_bootm() function. Before calling do_bootm_linux() the follwing code is called:
/* * We have reached the point of no return: we are going to * overwrite all exception vector code, so we cannot easily * recover from any failures any more... */
iflag = disable_interrupts();
So at the point of do_bootm_linux() the interrupts should already be off. If this is not the case, then it is probably better to fix this in the disable_interrupts implementation of the ColdFire.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Stefan,
On Fri, Aug 10, 2007 at 03:15:00PM +0200, Stefan Roese wrote:
On Friday 10 August 2007, Wolfgang Denk wrote:
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
Right.
IIRC the function we are talking about here is do_bootm_linux() (m68k version) which is called from the common do_bootm() function. Before calling do_bootm_linux() the follwing code is called:
/* * We have reached the point of no return: we are going to * overwrite all exception vector code, so we cannot easily * recover from any failures any more... */ iflag = disable_interrupts();So at the point of do_bootm_linux() the interrupts should already be off. If this is not the case, then it is probably better to fix this in the disable_interrupts implementation of the ColdFire.
you are completely right. Sorry for not recognizing the previous call to disable_interrupts in the first place, I only had looked at do_bootm_linux() itself.
In fact, I also tried calling disable_interrupts() before the call to the kernel, and it did not work.
The problem is that disable_interrupts is in lib_m68k/interrupts.c and simply sets the interrupt level mask to 0x7: sr = get_sr (); set_sr (sr | 0x0700);
interrupt_init() almost does the opposite: int interrupt_init(void) { volatile int0_t *intp = (int0_t *) (CFG_INTR_BASE);
/* Make sure all interrupts are disabled */ intp->imrh0 |= 0xFFFFFFFF; intp->imrl0 |= 0xFFFFFFFF;
enable_interrupts(); return 0; }
There must be something in the kernel that relies on the interrupts being masked in the interrupt controller and not only in the processor, but I can not check right now because I do not have the sourcecode of uClinux I use at work here at home right now.
I do not know if we should blame uClinux here for relying on the interrupt controller being in the reset (all sources disabled) state, or if we should try to fix this in u-boot.
Best regards, Stefan
Best regards, Wolfgang
Hi all,
After some investigation on other archs, most of the peripherals interrupts are disabled in OS (linux, vxWorks, etc) rather than in u-boot. In u-boot, it is just disabled the global interrupt exception vector. In CF, global interrupt exception vector is set_sr (sr | 0x0700).
Well, my suggestion is kept the way it is in u-boot. And, diasabled all peripherals interrupts before enabled the global interrupt exception vector in linux.
Regards, TsiChung
-----Original Message----- From: Wolfgang Wegner [mailto:wolfgang@leila.ping.de] Sent: Friday, August 10, 2007 3:22 PM To: Stefan Roese Cc: u-boot-users@lists.sourceforge.net; Wolfgang Denk; Aaron Sells; Liew Tsi Chung-r5aahp Subject: Re: [U-Boot-Users] interrupts in general / Fix for mcf5329evb - spurious interrupts on Linux/uClinux kernel boot
Hi Stefan,
On Fri, Aug 10, 2007 at 03:15:00PM +0200, Stefan Roese wrote:
On Friday 10 August 2007, Wolfgang Denk wrote:
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
Right.
IIRC the function we are talking about here is do_bootm_linux() (m68k version) which is called from the common do_bootm() function. Before calling do_bootm_linux() the follwing code is called:
/* * We have reached the point of no return: we are going to * overwrite all exception vector code, so we cannot easily * recover from any failures any more... */ iflag = disable_interrupts();So at the point of do_bootm_linux() the interrupts should already be off. If this is not the case, then it is probably better to fix this in the disable_interrupts implementation of the ColdFire.
you are completely right. Sorry for not recognizing the previous call to disable_interrupts in the first place, I only had looked at do_bootm_linux() itself.
In fact, I also tried calling disable_interrupts() before the call to the kernel, and it did not work.
The problem is that disable_interrupts is in lib_m68k/interrupts.c and simply sets the interrupt level mask to 0x7: sr = get_sr (); set_sr (sr | 0x0700);
interrupt_init() almost does the opposite: int interrupt_init(void) { volatile int0_t *intp = (int0_t *) (CFG_INTR_BASE);
/* Make sure all interrupts are disabled */ intp->imrh0 |= 0xFFFFFFFF; intp->imrl0 |= 0xFFFFFFFF;
enable_interrupts(); return 0; }
There must be something in the kernel that relies on the interrupts being masked in the interrupt controller and not only in the processor, but I can not check right now because I do not have the sourcecode of uClinux I use at work here at home right now.
I do not know if we should blame uClinux here for relying on the interrupt controller being in the reset (all sources disabled) state, or if we should try to fix this in u-boot.
Best regards, Stefan
Best regards, Wolfgang
Hi all,
I am going to replace the old do_bootm_linux() in lib_m68k/m68k_linux.c to pass bd_t struct, initrd and cmdline. So that, the linux kernel able to obtain the information of bd_t struct, initrd and cmdline thru the stack.
The implementation has been successful proven working very well in other platforms using linux 2.6.xx kernel.
Regards, TsiChung
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Friday, August 10, 2007 8:15 AM To: u-boot-users@lists.sourceforge.net Cc: Wolfgang Denk; w.wegner@astro-kom.de; Aaron Sells; Liew Tsi Chung-r5aahp Subject: Re: [U-Boot-Users] interrupts in general / Fix for mcf5329evb - spurious interrupts on Linux/uClinux kernel boot
On Friday 10 August 2007, Wolfgang Denk wrote:
Please correct me if I am wrong, but should not interrupts be completely disabled before transferring control to the linux kernel to avoid any confusion?
Right.
IIRC the function we are talking about here is do_bootm_linux() (m68k version) which is called from the common do_bootm() function. Before calling do_bootm_linux() the follwing code is called:
/* * We have reached the point of no return: we are going to * overwrite all exception vector code, so we cannot easily * recover from any failures any more... */
iflag = disable_interrupts();
So at the point of do_bootm_linux() the interrupts should already be off. If this is not the case, then it is probably better to fix this in the disable_interrupts implementation of the ColdFire.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (7)
-
Bob Grimes -
Liew Tsi Chung-r5aahp -
Robert S. Grimes -
Stefan Roese -
w.wegner＠astro-kom.de -
Wolfgang Denk -
wolfgang＠leila.ping.de