So far, wd has always configured the highest-priority watchdog when
multiple are available. Add an optional -d parameter to support
configuring the other watchdogs as well. The name passed can be either
the watchdog device name (e.g. wdog0) or the hardware device name (e.g.
efi-wdt).
8f4cf30903 ("watchdog: Allow multiple watchdogs") introduced the ability
to set a per-watchdog priority from within drivers, which is usually
populated with of_get_watchdog_priority.
For debugging, it can be useful to query and override this priority on
the fly. Provide a device parameter to do
55da0cf1 ("efi: add support for initrd loading") introduced support for
the Linux v3.6+ handover protocol[1]. As part of this change a x86 cli
(Clear Interrupt Flag) instruction was introduced just prior to the jump
into the kernel's EFI handover protocol entry point.
While the normal Linux x86
The UEFI specification paragraph quoted above notes:
> The watchdog timer is only used during boot services. On successful
> completion of ExitBootServices() the watchdog timer is disabled.
Thus disabling the watchdog is _the_ only proper behavior. Adjust the
wording accordingly.
Cc: Oleksij
The barebox EFI documentation notes:
> Current linux kernel (v5.0) will execute ExitBootServices() during the
> early boot stage and thus will automatically disable the (U)EFI watchdog.
> Since it is the proper behavior according to the (U)EFI specification, it
> is impossible to protect full
So far watchdog users could only configure the watchdog with the highest
priority. In preparation for having the wd command configure a watchdog
by name, extend watchdog_set_timeout with a struct watchdog *parameter
and export functions to query default watchdog and to find watchdog by
name.
No
On 10/23/19 6:45 PM, Ahmad Fatoum wrote:
> On a system with multiple watchdogs, the highest priority watchdog is the one
> affected by the ``boot.watchdog_timeout`` parameter. If multiple watchdogs
> share the same priority, only one will be started.
Oh still not correct, but wait now I got it:
On 10/23/19 6:22 PM, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel
> ---
> Documentation/user/user-manual.rst | 1 +
> Documentation/user/watchdog.rst| 85 ++
> 2 files changed, 86 insertions(+)
> create mode 100644 Documentation/user/watchdog.rst
>
>
Signed-off-by: Oleksij Rempel
---
Documentation/user/watchdog.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/user/watchdog.rst b/Documentation/user/watchdog.rst
index 7373b81a8d..5c671a9f26 100644
--- a/Documentation/user/watchdog.rst
+++
Signed-off-by: Oleksij Rempel
---
Documentation/user/user-manual.rst | 1 +
Documentation/user/watchdog.rst| 85 ++
2 files changed, 86 insertions(+)
create mode 100644 Documentation/user/watchdog.rst
diff --git a/Documentation/user/user-manual.rst
On Wed, Oct 23, 2019 at 3:33 PM Sascha Hauer wrote:
>
> On Wed, Oct 23, 2019 at 11:39:00AM +0200, Mihaita Ivascu wrote:
> > Hello all,
> >
> > I would like to know what possibilities do I have to flash a barebox
> > image to mtd partition from Linux?
> > Using ubifs commands does not work. the
On Wed, Oct 23, 2019 at 11:39:00AM +0200, Mihaita Ivascu wrote:
> Hello all,
>
> I would like to know what possibilities do I have to flash a barebox
> image to mtd partition from Linux?
> Using ubifs commands does not work. the barebox will not boot so
> probably additional info needs to be
On Wed, Oct 23, 2019 at 12:27 PM Andreas Geisenhainer
wrote:
>
> On 2019-10-23 11:39 a.m., Mihaita Ivascu wrote:
> > Hello all,
> >
> >I would like to know what possibilities do I have to flash a barebox
> > image to mtd partition from Linux?
> > Using ubifs commands does not work. the
Hello all,
I would like to know what possibilities do I have to flash a barebox
image to mtd partition from Linux?
Using ubifs commands does not work. the barebox will not boot so
probably additional info needs to be written except the barebox image
itself.
Thanks,
Mihaita
On Tue, Oct 22, 2019 at 03:47:32PM +0200, Robert Karszniewicz wrote:
> Before this, ret was falsely polluted, which caused a misleading error
> message if the function bailed out at a later point.
>
> Signed-off-by: Robert Karszniewicz
> ---
> lib/libfile.c | 17 -
> 1 file
On Tue, Oct 22, 2019 at 11:15:38AM +0200, Roland Hieber wrote:
> Cc: Juergen Borleis
> Signed-off-by: Roland Hieber
> ---
> common/Kconfig | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks
Sascha
--
Pengutronix e.K. |
On Mon, Oct 21, 2019 at 07:00:43PM +0200, Ahmad Fatoum wrote:
> When debugging partitions detected by barebox, knowing the partuuid
> can be useful. Include it in the dev_dbg output.
>
> Signed-off-by: Ahmad Fatoum
> ---
> common/partitions.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Mon, Oct 21, 2019 at 02:20:46PM +0200, Ahmad Fatoum wrote:
> /dev/random can block long after boot time. It seems there's a consensus
> that /dev/urandom is safe to use except for very early boot, which isn't
> when barebox sandbox is usually run. To make the HWRNG more useful,
> always use
On Mon, Oct 21, 2019 at 01:50:19PM +0200, Oleksij Rempel wrote:
> It will be done in main_entry() any way.
>
> Signed-off-by: Oleksij Rempel
> ---
> arch/mips/lib/reloc.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
Applied, thanks
Sascha
--
Pengutronix e.K.
On Mon, Oct 21, 2019 at 02:59:08PM +0200, Robert Karszniewicz wrote:
> Signed-off-by: Robert Karszniewicz
> ---
> arch/sandbox/os/common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks
Sascha
--
Pengutronix e.K. |
On Mon, Oct 21, 2019 at 11:23:40AM +0200, Ahmad Fatoum wrote:
> Despite assigning efi_sys_table->{con_in,con_out} to priv->{in,out},
> some functions still use the global efi_sys_table->{con_in,con_out}.
> Let's restrict globals access to the probe function and have the priv
> struct completely
21 matches
Mail list logo