[U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET
Hi there,
as mentioned on list before some boards/cpus might need some extra code to be executed _before_ rebooting. E.g. the i.MX hangs when doing "reset" while the LCD controller is still enabled.
That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and board_pre_reset(). The attached does exactly that. But only for cpu/arm920t. If wished I'll add the appropriate code to all cpu/$(CPU)/cpu.c files.
* Patch by Steven Scholz, 25 Oct 2004: - Introducing CONFIG_BOARD_PRE_RESET and board_pre_reset() to allow code to be executed before actually rebooting
In message 417D0D67.2000000@imc-berlin.de you wrote:
as mentioned on list before some boards/cpus might need some extra code to be executed _before_ rebooting. E.g. the i.MX hangs when doing "reset" while the LCD controller is still enabled.
I remember that we discussed this before, but now that I think about this again I changed my mind: I don't think there is a valid reason to add this code.
That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and board_pre_reset().
No. You write: i.MX hangs when doing "reset". I guess the board does not hand if you power cycle it, or if you press the reset button, right? So the conclusion is that the reset code does not do what you think it does - i. e. it does not cause a reset of the processor.
This is a problem that should be fixed. Once fixed, this patch is not needed any more.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 417D0D67.2000000@imc-berlin.de you wrote:
as mentioned on list before some boards/cpus might need some extra code to be executed _before_ rebooting. E.g. the i.MX hangs when doing "reset" while the LCD controller is still enabled.
I remember that we discussed this before, but now that I think about this again I changed my mind: I don't think there is a valid reason to add this code.
That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and board_pre_reset().
No. You write: i.MX hangs when doing "reset". I guess the board does not hand if you power cycle it, or if you press the reset button, right? So the conclusion is that the reset code does not do what you think it does - i. e. it does not cause a reset of the processor.
This is a problem that should be fixed. Once fixed, this patch is not needed any more.
Well, it's a bug in the CPU. If the LCDC DMA is running, the cpu won't reboot with a simple "mov pc, r0". But then switching off the i.MX LCD controller has to be done in cpu/arm920t/start.S where reset_cpu() is. And you don't wanna do this. There already are enough #ifdefs in cpu/arm920t/start.S.
And how about the AT91RM9200(DK) where the author wants to "shutdown the console to avoid strange chars during reset"???
In message 417DF771.5010904@imc-berlin.de you wrote:
Well, it's a bug in the CPU. If the LCDC DMA is running, the cpu won't reboot with a simple "mov pc, r0".
Ummm... you don't call this a "reset", do you?
And how about the AT91RM9200(DK) where the author wants to "shutdown the console to avoid strange chars during reset"???
Well, that's IMHO polishing, and forgiveable ;-)
In your case, I think you really want to implement a _real_ reset function that takes the CPU back into it's virgin state. Is there a watchdog on this hardware?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 417DF771.5010904@imc-berlin.de you wrote:
Well, it's a bug in the CPU. If the LCDC DMA is running, the cpu won't reboot with a simple "mov pc, r0".
Ummm... you don't call this a "reset", do you?
Well that's what is done (work) for most ARM920T... Execeptions are
#ifdef CONFIG_S3C2400 bl disable_interrupts # ifdef CONFIG_TRAB bl disable_vfd # endif ...
BTW cominh to think about it: Does "bl disable_vfd" by any chance disable video controller for CONFIG_TRAB !?!? ;-)
In your case, I think you really want to implement a _real_ reset function that takes the CPU back into it's virgin state. Is there a watchdog on this hardware?
Sure. That means you have board _and_ cpu specific reset code! Some want to toggle a GPIO pin. Some want to use a cpu watchdog... So should we move the reset code out of cpu/arm920t/start.S into the brand new cpu/arm920t/$(SOC)/reset.{S.c} !?
-----Messaggio originale----- Da: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]Per conto di Steven Scholz Inviato: martedi, 26. ottobre 2004 10:32 Cc: u-boot-users Oggetto: Re: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET
Wolfgang Denk wrote:
In message 417DF771.5010904@imc-berlin.de you wrote:
Well, it's a bug in the CPU. If the LCDC DMA is running, the
cpu won't reboot
with a simple "mov pc, r0".
Ummm... you don't call this a "reset", do you?
Well that's what is done (work) for most ARM920T... Execeptions are
#ifdef CONFIG_S3C2400 bl disable_interrupts # ifdef CONFIG_TRAB bl disable_vfd # endif ...
BTW cominh to think about it: Does "bl disable_vfd" by any chance disable video controller for CONFIG_TRAB !?!? ;-)
In your case, I think you really want to implement a _real_ reset function that takes the CPU back into it's virgin state. Is there a watchdog on this hardware?
Sure. That means you have board _and_ cpu specific reset code! Some want to toggle a GPIO pin. Some want to use a cpu watchdog... So should we move the reset code out of cpu/arm920t/start.S into the brand new cpu/arm920t/$(SOC)/reset.{S.c} !?
This would be a good step towards clean up the clobbered start.s !!! -P.Broggini
Dear Wolfgang,
Well, it's a bug in the CPU. If the LCDC DMA is running, the cpu won't reboot with a simple "mov pc, r0".
Ummm... you don't call this a "reset", do you?
Well that's what is done (work) for most ARM920T... Execeptions are
#ifdef CONFIG_S3C2400 bl disable_interrupts # ifdef CONFIG_TRAB bl disable_vfd # endif ...
BTW cominh to think about it: Does "bl disable_vfd" by any chance disable video controller for CONFIG_TRAB !?!? ;-)
In your case, I think you really want to implement a _real_ reset function that takes the CPU back into it's virgin state. Is there a watchdog on this hardware?
Sure. That means you have board _and_ cpu specific reset code! Some want to toggle a GPIO pin. Some want to use a cpu watchdog... So should we move the reset code out of cpu/arm920t/start.S into the brand new cpu/arm920t/$(SOC)/reset.{S.c} !?
Any new opinions on this topic? Or is it closed for you and my suggestion rejected?
Wolfgang,
I wrote:
as mentioned on list before some boards/cpus might need some extra code to be executed _before_ rebooting. E.g. the i.MX hangs when doing "reset" while the LCD controller is still enabled.
That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and board_pre_reset(). The attached does exactly that. But only for cpu/arm920t. If wished I'll add the appropriate code to all cpu/$(CPU)/cpu.c files.
- Patch by Steven Scholz, 25 Oct 2004:
- Introducing CONFIG_BOARD_PRE_RESET and board_pre_reset() to allow code to be executed before actually rebooting
any new opinions on this topic?
In message 41A346BD.2060207@imc-berlin.de you wrote:
- Patch by Steven Scholz, 25 Oct 2004:
- Introducing CONFIG_BOARD_PRE_RESET and board_pre_reset() to allow code to be executed before actually rebooting
any new opinions on this topic?
No.
[Actually I think that it might make sense to perform certain cleanup operations in case of an orderly reboot; on the other hand the reboot code _must_not_ depend on such cleanup. In your case there seems to be such a dependency. I'd rather see that you fix the reset code first, and then (if there is still need for it) we might allow for pre-reset cleanup functions.]
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 41A346BD.2060207@imc-berlin.de you wrote:
- Patch by Steven Scholz, 25 Oct 2004:
- Introducing CONFIG_BOARD_PRE_RESET and board_pre_reset() to allow code to be executed before actually rebooting
any new opinions on this topic?
No.
[Actually I think that it might make sense to perform certain cleanup operations in case of an orderly reboot; on the other hand the reboot code _must_not_ depend on such cleanup. In your case there seems to be such a dependency. I'd rather see that you fix the reset code first, and then (if there is still need for it) we might allow for pre-reset cleanup functions.]
But as I pointed out apparently other boards need something like that too:
.globl reset_cpu reset_cpu: ... # ifdef CONFIG_TRAB bl disable_vfd # endif
So reset is cpu (better SoC) specific and might even be board specific.
Of coures we can clobber cpu/arm920t/start.S with reset code for every cpu, SoC and board ... adding loads of nice #ifdef's ;-)
-- Steven
In message 41A35BBE.90501@imc-berlin.de you wrote:
But as I pointed out apparently other boards need something like that too:
No.
.globl reset_cpu reset_cpu: ... # ifdef CONFIG_TRAB bl disable_vfd # endif
The TRAB board will perfectly reset the board if you remove this code. It just doesn't look as nice (flicker on the display). That's what I meant that some boards may _want_ such a function.
So reset is cpu (better SoC) specific and might even be board specific.
You may want to run board-specific code _before_ reset, but the reset operation itself should IMHO not depend on board specific features. It's always processor (CPU or SoC or what you may call it) specific.
Of coures we can clobber cpu/arm920t/start.S with reset code for every cpu, SoC and board ... adding loads of nice #ifdef's ;-)
This is certainly NOT my intention. I think I explained before what I have in mind.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
So reset is cpu (better SoC) specific and might even be board specific.
You may want to run board-specific code _before_ reset, but the reset operation itself should IMHO not depend on board specific features. It's always processor (CPU or SoC or what you may call it) specific.
Sorry. But I have to ask again:
If I don't want to rely on the processor reset (since it might be broken), how am I able to use my boards pecific hardware watchdog?
In message 41A36B54.3000904@imc-berlin.de you wrote:
If I don't want to rely on the processor reset (since it might be broken), how
If you cannot rely on the basic functions of your processor than you are lost. Get new hardware and go back to START. Do not cash $100.
am I able to use my boards pecific hardware watchdog?
That's a catch question. I do recognize it as such ;-)
Best regards,
Wolfgang Denk
participants (3)
-
Paolo Broggini -
Steven Scholz -
Wolfgang Denk