blob-cvs-commit

timer interrupt handler in blob

[Abraham vd M. <ab...@2d...>]

Hi!

I have a watchdog on my board which needs to be strobed at least every
500ms, otherwise it resets the board. Therefore I need to use a timer
interrupt. I have a couple of questions to ask though:

1) Interrupts are disabled in blob at the moment right? So I won't be
interfering with something else if I setup an interrupt handler?

2) If I setup an interrupt handler, then I obviously need to uninstall the
interrupt handler (or at least disable interrupts) before I load the kernel
(or anything else for that matter). Where is the best/least intrusive place
to do that in blob?

--=20

Regards
 Abraham

Vulcans worship peace above all.
		-- McCoy, "Return to Tomorrow", stardate 4768.3

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Re: timer interrupt handler in blob

[Erik M. <J.A...@it...>]

On Mon, Apr 15, 2002 at 04:04:57PM +0200, Abraham vd Merwe wrote:
> I have a watchdog on my board which needs to be strobed at least every
> 500ms, otherwise it resets the board. Therefore I need to use a timer
> interrupt. I have a couple of questions to ask though:
> 
> 1) Interrupts are disabled in blob at the moment right? So I won't be
> interfering with something else if I setup an interrupt handler?

No. Might be tricky, though. Best way is to modify the irq/firq entries
in start.S to jump to a known location in trampoline.S, which on its
turn can do the dirty work and call a C interrupt handling function.

> 2) If I setup an interrupt handler, then I obviously need to uninstall the
> interrupt handler (or at least disable interrupts) before I load the kernel
> (or anything else for that matter). Where is the best/least intrusive place
> to do that in blob?

As for the best place to do it: look at how the icache gets disabled:
code is in lib/icache.c, and in blob/initcalls.c the functions
enable_icache() and disable_icache() are registered in the init and
exitlist.

I *hope* that the kernel boots fast enough before the watchdog kicks
in. However, I wonder if you really need to keep the watchdog busy in
blob. All watchdog devices I know have an option that they aren't
enabled at boot time, but only start working after you first use them.
So for as long as you don't touch the watchdog in blob, you also won't
need any driver for it in blob.

If you are affraid about a broken blob, think twice: the normal way of
operation is that blob initialises the system and immediately boots the
kernel. This even works with an unattended system. It can be tested in
the lab that a normal unattended boot always succeeds, and the path
through the blob code is completely repeatable every time. If there
goes something wrong in blob, it's most probable that it is because
something has been overwriting the flash. If that happens and there is
no watchdog, blob will just crash and the system will be unusable. With
a watchdog, the system will be rebooted, blob will crash again, the
watchdog will kick in again, the system will be rebooted ... (ad
nauseam).

Anyway, in both cases it will result in a broken system that needs
manual intervention, and no watchdog is more intelligent than a human
being. So unless you have a brain damaged watchdog that simply needs to
be kept happy, I don't think we need a watchdog driver in blob.

It's not that I am against adding features in blob, it's just that I
don't see a point in adding useless features.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: timer interrupt handler in blob

[Abraham vd M. <ab...@2d...>]

Hi Erik!

> > I have a watchdog on my board which needs to be strobed at least every
> > 500ms, otherwise it resets the board. Therefore I need to use a timer
> > interrupt. I have a couple of questions to ask though:
> >=20
> > 1) Interrupts are disabled in blob at the moment right? So I won't be
> > interfering with something else if I setup an interrupt handler?
>=20
> No. Might be tricky, though. Best way is to modify the irq/firq entries
> in start.S to jump to a known location in trampoline.S, which on its
> turn can do the dirty work and call a C interrupt handling function.

At the moment, I've just added a hook in my hardware initialization routine
to setup my interrupt handler at 0x0018 and program the OS timer to trigger
irq 26 every 400ms. That way I don't mess around with the generic stuff.

> I *hope* that the kernel boots fast enough before the watchdog kicks
> in. However, I wonder if you really need to keep the watchdog busy in

There's more than enough time. The minimum timeout is 500ms which is longer
than what blob takes to boot, but it just makes it and during development,
it obviously times out if I have a delay. In the kernel, I can just add a
hook to the timer interrupt which gets iniialized pretty early on in the
boot process, so that's not a problem either...

> blob. All watchdog devices I know have an option that they aren't
> enabled at boot time, but only start working after you first use them.

This one can't be disabled which is as it should be. If you can disable it
in software the whole idea of a watchdog is flawed...

> It's not that I am against adding features in blob, it's just that I
> don't see a point in adding useless features.

I totally agree, but in this case it's kind of necessary in order to get a
functional board.

--=20

Regards
 Abraham

The verdict of a jury is the a priori opinion of that juror who smokes
the worst cigars.
		-- H. L. Mencken

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Re: timer interrupt handler in blob

[Erik M. <J.A...@it...>]

On Wed, Apr 17, 2002 at 12:51:38PM +0200, Abraham vd Merwe wrote:
> > > I have a watchdog on my board which needs to be strobed at least every
> > > 500ms, otherwise it resets the board. Therefore I need to use a timer
> > > interrupt. I have a couple of questions to ask though:
> > > 
> > > 1) Interrupts are disabled in blob at the moment right? So I won't be
> > > interfering with something else if I setup an interrupt handler?
> > 
> > No. Might be tricky, though. Best way is to modify the irq/firq entries
> > in start.S to jump to a known location in trampoline.S, which on its
> > turn can do the dirty work and call a C interrupt handling function.
> 
> At the moment, I've just added a hook in my hardware initialization routine
> to setup my interrupt handler at 0x0018 and program the OS timer to trigger
> irq 26 every 400ms. That way I don't mess around with the generic stuff.

The generic code is pretty easy, and the interrupt system works the
same on all ARM CPUs anyway, so I'd rather think it belonged there :)

> > blob. All watchdog devices I know have an option that they aren't
> > enabled at boot time, but only start working after you first use them.
> 
> This one can't be disabled which is as it should be. If you can disable it
> in software the whole idea of a watchdog is flawed...

No, the watchdog you're using right now is brain damaged. Every
watchdog I know is disabled at hardware reset and should be enabled by
the OS. The OS just can't *disable* the watchdog, though. This
enable-but-can't-disable feature was made exactly because it allows the
system to initialise itself.

> > It's not that I am against adding features in blob, it's just that I
> > don't see a point in adding useless features.
> 
> I totally agree, but in this case it's kind of necessary in order to get a
> functional board.

Please double check the data sheet. I just can't believe there is such
crap watchdog hardware on the market. If you have an option to change
the hardware, consider using a better watchdog.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: timer interrupt handler in blob

[Abraham vd M. <ab...@2d...>]

Hi Erik!

> > At the moment, I've just added a hook in my hardware initialization rou=
tine
> > to setup my interrupt handler at 0x0018 and program the OS timer to tri=
gger
> > irq 26 every 400ms. That way I don't mess around with the generic stuff.
>=20
> The generic code is pretty easy, and the interrupt system works the
> same on all ARM CPUs anyway, so I'd rather think it belonged there :)

Ok, I'll take a look at start.S

> > > blob. All watchdog devices I know have an option that they aren't
> > > enabled at boot time, but only start working after you first use them.
> >=20
> > This one can't be disabled which is as it should be. If you can disable=
 it
> > in software the whole idea of a watchdog is flawed...
>=20
> No, the watchdog you're using right now is brain damaged. Every
> watchdog I know is disabled at hardware reset and should be enabled by
> the OS. The OS just can't *disable* the watchdog, though. This
> enable-but-can't-disable feature was made exactly because it allows the
> system to initialise itself.

So how do you prevent the OS from disabling the watchdog. If there is a way
to disable the watchdog during boot time it is theoretically possible that
something in the OS can disable it again by mistake - this is obviously not
likely to happen, but possible. We have a watchdog exactly to prevent this,
so I think a watchdog that can be disabled during startup is brain damaged.

> > > It's not that I am against adding features in blob, it's just that I
> > > don't see a point in adding useless features.
> >=20
> > I totally agree, but in this case it's kind of necessary in order to ge=
t a
> > functional board.
>=20
> Please double check the data sheet. I just can't believe there is such

Its a Dallas DS1832 chip - it has to be strobed periodically once it
receives power.

> crap watchdog hardware on the market. If you have an option to change
> the hardware, consider using a better watchdog.

Hehe, if you can convince me that it's not necessary I can change it, but
you still haven't convinced me that being able to disable a watchdog is a
good thing.

--=20

Regards
 Abraham

Love tells us many things that are not so.
		-- Krainian Proverb

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Re: timer interrupt handler in blob

[J.D. B. <ba...@th...>]

At 14:55 +0200 17-04-2002, Abraham vd Merwe wrote:
>  > crap watchdog hardware on the market. If you have an option to change
>>  the hardware, consider using a better watchdog.
>
>Hehe, if you can convince me that it's not necessary I can change it, but
>you still haven't convinced me that being able to disable a watchdog is a
>good thing.

A sane watchdog is off after reset/power-on, and will only turn on at 
(the rising edge of) the first trigger pulse. If the system doesn't 
manage to produce the first trigger pulse, resetting the machine to 
run the exact same firmware usually makes little sense.

JDB.
-- 
In protocol design, perfection has been reached not when there is 
nothing left to add, but when there is nothing left to take away.
                    -- RFC 1925, "Fundamental Truths of Networking"

Re: timer interrupt handler in blob

[Tim R. <Ti...@Ri...>]

agreed. watchdog off at boot. sw can turn it on. only a reset can turn
it off.

"J.D. Bakker" wrote:
> 
> At 14:55 +0200 17-04-2002, Abraham vd Merwe wrote:
> >  > crap watchdog hardware on the market. If you have an option to change
> >>  the hardware, consider using a better watchdog.
> >
> >Hehe, if you can convince me that it's not necessary I can change it, but
> >you still haven't convinced me that being able to disable a watchdog is a
> >good thing.
> 
> A sane watchdog is off after reset/power-on, and will only turn on at
> (the rising edge of) the first trigger pulse. If the system doesn't
> manage to produce the first trigger pulse, resetting the machine to
> run the exact same firmware usually makes little sense.
> 
> JDB.
> --
> In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away.
>                     -- RFC 1925, "Fundamental Truths of Networking"
> 
> _______________________________________________
> blob-cvs-commit mailing list
> blo...@li...
> https://lists.sourceforge.net/lists/listinfo/blob-cvs-commit

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.