PATCH: Introducing CONFIG_BOARD_PRE_RESET

U-Boot-Users Steven Scholz 3 participants 13 messages Oct 25, 2004 – Nov 23, 2004

Share & tools

Steven Scholz

author

2004-10-25 14:27 UTC #0 lore raw

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

Signature · 6 lines

Steven Scholz

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: board_pre_reset.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20041025/a2a33314/attachment.txt

Wolfgang Denk

2004-10-25 18:05 UTC #1 lore raw

Quoted 4 lines · In message <[email protected]> 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.

Quoted 1 line

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

Signature · 4 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.

Steven Scholz

author

2004-10-26 07:06 UTC #2 lore raw

Quoted 15 lines · Wolfgang Denk

Quoted 3 lines · In message <[email protected]> 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.
Quoted 1 line
That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and board_pre_reset().

Quoted 7 lines

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"???

Signature · 1 line

Steven Scholz

Wolfgang Denk

2004-10-26 08:25 UTC #3 lore raw

Quoted 3 lines · In message <[email protected]> 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?

Quoted 2 lines

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

Signature · 4 lines

See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."

Steven Scholz

author

2004-10-26 08:32 UTC #4 lore raw

Quoted 7 lines · Wolfgang Denk

Quoted 2 lines · In message <[email protected]> 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 !?!? ;-)

Quoted 3 lines

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} !?

Signature · 1 line

Steven Scholz

Paolo Broggini

2004-10-26 09:14 UTC #5 lore raw

R: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET

Quoted 38 lines

-----Messaggio originale-----
Da: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-admin at 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
Quoted 3 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> you wrote:
Well, it's a bug in the CPU. If the LCDC DMA is running, the
cpu won't reboot
Quoted 4 lines
Quoted 1 line
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 !?!? ;-)
Quoted 3 lines
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?

Quoted 5 lines

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

Steven Scholz

author

2004-10-28 07:36 UTC #6 lore raw

In reply to Steven Scholz

Dear Wolfgang,

Quoted 15 lines

Quoted 3 lines
Quoted 2 lines
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 !?!? ;-)

Quoted 8 lines

Quoted 3 lines
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?

Signature · 1 line

Steven Scholz

Steven Scholz

author

2004-11-23 14:18 UTC #7 lore raw

In reply to Steven Scholz

Wolfgang,

Quoted 4 lines · 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.

Quoted 8 lines

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?

Signature · 1 line

Steven Scholz

Wolfgang Denk

2004-11-23 15:41 UTC #8 lore raw

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 4 lines
* 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

Signature · 4 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."

Steven Scholz

author

2004-11-23 15:48 UTC #9 lore raw

Quoted 9 lines · Wolfgang Denk

Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
* 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?

Quoted 8 lines

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

Wolfgang Denk

2004-11-23 16:47 UTC #10 lore raw

Quoted 2 lines · In message <[email protected]> you wrote:

But as I pointed out apparently other boards need something like that too:

No.

Quoted 6 lines

.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.

Quoted 1 line

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.

Quoted 2 lines

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

Signature · 3 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made machine language; all the rest is the work of man.

Steven Scholz

author

2004-11-23 16:54 UTC #11 lore raw

Quoted 5 lines · Wolfgang Denk

Quoted 1 line
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?

Signature · 1 line

Steven Scholz

Wolfgang Denk

2004-11-23 17:20 UTC #12 lore raw

Quoted 2 lines · In message <[email protected]> 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.

Quoted 1 line

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

Signature · 4 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Killing is stupid; useless!
	-- McCoy, "A Private Little War", stardate 4211.8