All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Andy Yan <andy.yan@rock-chips.com>,
	linux-rockchip@lists.infradead.org,
	lk <linux-kernel@vger.kernel.org>,
	lak <linux-arm-kernel@lists.infradead.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Olof Johansson <olof@lixom.net>,
	khilman@linaro.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: set rockchip-specific uboot bootmode flags on reboot (was: [PATCH] ARM: rockchip: add reboot notifier)
Date: Wed, 9 Sep 2015 12:05:37 -0600	[thread overview]
Message-ID: <CAPnjgZ0n7aNY7FRnoDYUBEnQAtUO1BWKs6DDzaMQyHsg1kQ1Jg@mail.gmail.com> (raw)
In-Reply-To: <9364768.6AeuYh3EEP@diego>

Hi,

On 8 September 2015 at 16:46, Heiko Stübner <heiko@sntech.de> wrote:
>
> Hi Andy,
>
> Am Dienstag, 8. September 2015, 20:43:07 schrieb Andy Yan:
> > rockchip platform have a protocol to pass the the kernel
> > reboot mode to bootloader by some special registers when
> > system reboot.By this way the bootloader can take different
> > action according to the different kernel reboot mode, for
> > example, command "reboot loader" will reboot the board to
> > rockusb mode, this is a very convenient way to get the board
> > to download mode.
> >
> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>
> [...]
>
> > @@ -0,0 +1,22 @@
> > +#ifndef __MACH_ROCKCHIP_LOADER_H
> > +#define __MACH_ROCKCHIP_LOADER_H
> > +
> > +/*high 24 bits is tag, low 8 bits is type*/
> > +#define SYS_LOADER_REBOOT_FLAG   0x5242C300
> > +
> > +enum {
> > +     BOOT_NORMAL = 0, /* normal boot */
> > +     BOOT_LOADER,     /* enter loader rockusb mode */
> > +     BOOT_MASKROM,    /* enter maskrom rockusb mode (not support now) */
> > +     BOOT_RECOVER,    /* enter recover */
> > +     BOOT_NORECOVER,  /* do not enter recover */
> > +     BOOT_SECONDOS,   /* boot second OS (not support now)*/
> > +     BOOT_WIPEDATA,   /* enter recover and wipe data. */
> > +     BOOT_WIPEALL,    /* enter recover and wipe all data. */
> > +     BOOT_CHECKIMG,   /* check firmware img with backup part*/
> > +     BOOT_FASTBOOT,   /* enter fast boot mode */
> > +     BOOT_SECUREBOOT_DISABLE,
> > +     BOOT_CHARGING,   /* enter charge mode */
> > +     BOOT_MAX         /* MAX VALID BOOT TYPE.*/
> > +};
> > +#endif
>
> These flags rely on code in the bootloader to actually handle the target
> action. Nowadays this is uboot, but still a rockchip-specific fork. And we're
> actively moving away from that, with the recent rk3288 addition to mainline
> uboot.
>
> So unless you convince uboot people that the _underlying special
> functionality_ behind these flags should be part of uboot, I don't think this
> is going to fly.
>
>
> In a way this is similar to gpu kernel code talking to proprietary userspace
> libs - these are also not eligible for the kernel. (meaning stuff like the
> mali kernel driver not being allowed).

I don't want to comment on what Linux does or does not want. But I can
see this sort of feature being useful for devs at least. So long as it
is defined in a way that is not Rockchip-specific (and the above enum
looks pretty reasonable on that front, I think it makes sense.

Of course it's a bit odd to target a downstream U-Boot with a Linux
feature. But hopefully Rockchip's U-Boot support and development will
move to mainline with time.

>
> [...]
>
> > +static int rockchip_reboot_notify(struct notifier_block *this,
> > +                               unsigned long mode, void *cmd)
> > +{
> > +     u32 flag;
> > +
> > +     rockchip_get_reboot_flag(cmd, &flag);
> > +     regmap_write(regmap, flag_reg, flag);
> > +
> > +     return NOTIFY_DONE;
> > +}
> > +
> > +static struct notifier_block rockchip_reboot_handler = {
> > +     .notifier_call = rockchip_reboot_notify,
> > +     .priority = 150,
> > +};
>
> the restart handlers are meant to really only restart the system, not to
> execute some actions before the restart happens.
>
> See https://lkml.org/lkml/2015/6/3/707 for a similar case.
>
>
> Heiko

Regards,
Simon

WARNING: multiple messages have this Message-ID (diff)
From: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Cc: khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	Russell King - ARM Linux
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	lk <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
	Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	lak
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: set rockchip-specific uboot bootmode flags on reboot (was: [PATCH] ARM: rockchip: add reboot notifier)
Date: Wed, 9 Sep 2015 12:05:37 -0600	[thread overview]
Message-ID: <CAPnjgZ0n7aNY7FRnoDYUBEnQAtUO1BWKs6DDzaMQyHsg1kQ1Jg@mail.gmail.com> (raw)
In-Reply-To: <9364768.6AeuYh3EEP@diego>

Hi,

On 8 September 2015 at 16:46, Heiko Stübner <heiko@sntech.de> wrote:
>
> Hi Andy,
>
> Am Dienstag, 8. September 2015, 20:43:07 schrieb Andy Yan:
> > rockchip platform have a protocol to pass the the kernel
> > reboot mode to bootloader by some special registers when
> > system reboot.By this way the bootloader can take different
> > action according to the different kernel reboot mode, for
> > example, command "reboot loader" will reboot the board to
> > rockusb mode, this is a very convenient way to get the board
> > to download mode.
> >
> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>
> [...]
>
> > @@ -0,0 +1,22 @@
> > +#ifndef __MACH_ROCKCHIP_LOADER_H
> > +#define __MACH_ROCKCHIP_LOADER_H
> > +
> > +/*high 24 bits is tag, low 8 bits is type*/
> > +#define SYS_LOADER_REBOOT_FLAG   0x5242C300
> > +
> > +enum {
> > +     BOOT_NORMAL = 0, /* normal boot */
> > +     BOOT_LOADER,     /* enter loader rockusb mode */
> > +     BOOT_MASKROM,    /* enter maskrom rockusb mode (not support now) */
> > +     BOOT_RECOVER,    /* enter recover */
> > +     BOOT_NORECOVER,  /* do not enter recover */
> > +     BOOT_SECONDOS,   /* boot second OS (not support now)*/
> > +     BOOT_WIPEDATA,   /* enter recover and wipe data. */
> > +     BOOT_WIPEALL,    /* enter recover and wipe all data. */
> > +     BOOT_CHECKIMG,   /* check firmware img with backup part*/
> > +     BOOT_FASTBOOT,   /* enter fast boot mode */
> > +     BOOT_SECUREBOOT_DISABLE,
> > +     BOOT_CHARGING,   /* enter charge mode */
> > +     BOOT_MAX         /* MAX VALID BOOT TYPE.*/
> > +};
> > +#endif
>
> These flags rely on code in the bootloader to actually handle the target
> action. Nowadays this is uboot, but still a rockchip-specific fork. And we're
> actively moving away from that, with the recent rk3288 addition to mainline
> uboot.
>
> So unless you convince uboot people that the _underlying special
> functionality_ behind these flags should be part of uboot, I don't think this
> is going to fly.
>
>
> In a way this is similar to gpu kernel code talking to proprietary userspace
> libs - these are also not eligible for the kernel. (meaning stuff like the
> mali kernel driver not being allowed).

I don't want to comment on what Linux does or does not want. But I can
see this sort of feature being useful for devs at least. So long as it
is defined in a way that is not Rockchip-specific (and the above enum
looks pretty reasonable on that front, I think it makes sense.

Of course it's a bit odd to target a downstream U-Boot with a Linux
feature. But hopefully Rockchip's U-Boot support and development will
move to mainline with time.

>
> [...]
>
> > +static int rockchip_reboot_notify(struct notifier_block *this,
> > +                               unsigned long mode, void *cmd)
> > +{
> > +     u32 flag;
> > +
> > +     rockchip_get_reboot_flag(cmd, &flag);
> > +     regmap_write(regmap, flag_reg, flag);
> > +
> > +     return NOTIFY_DONE;
> > +}
> > +
> > +static struct notifier_block rockchip_reboot_handler = {
> > +     .notifier_call = rockchip_reboot_notify,
> > +     .priority = 150,
> > +};
>
> the restart handlers are meant to really only restart the system, not to
> execute some actions before the restart happens.
>
> See https://lkml.org/lkml/2015/6/3/707 for a similar case.
>
>
> Heiko

Regards,
Simon

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: sjg@chromium.org (Simon Glass)
To: linux-arm-kernel@lists.infradead.org
Subject: set rockchip-specific uboot bootmode flags on reboot (was: [PATCH] ARM: rockchip: add reboot notifier)
Date: Wed, 9 Sep 2015 12:05:37 -0600	[thread overview]
Message-ID: <CAPnjgZ0n7aNY7FRnoDYUBEnQAtUO1BWKs6DDzaMQyHsg1kQ1Jg@mail.gmail.com> (raw)
In-Reply-To: <9364768.6AeuYh3EEP@diego>

Hi,

On 8 September 2015 at 16:46, Heiko St?bner <heiko@sntech.de> wrote:
>
> Hi Andy,
>
> Am Dienstag, 8. September 2015, 20:43:07 schrieb Andy Yan:
> > rockchip platform have a protocol to pass the the kernel
> > reboot mode to bootloader by some special registers when
> > system reboot.By this way the bootloader can take different
> > action according to the different kernel reboot mode, for
> > example, command "reboot loader" will reboot the board to
> > rockusb mode, this is a very convenient way to get the board
> > to download mode.
> >
> > Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>
> [...]
>
> > @@ -0,0 +1,22 @@
> > +#ifndef __MACH_ROCKCHIP_LOADER_H
> > +#define __MACH_ROCKCHIP_LOADER_H
> > +
> > +/*high 24 bits is tag, low 8 bits is type*/
> > +#define SYS_LOADER_REBOOT_FLAG   0x5242C300
> > +
> > +enum {
> > +     BOOT_NORMAL = 0, /* normal boot */
> > +     BOOT_LOADER,     /* enter loader rockusb mode */
> > +     BOOT_MASKROM,    /* enter maskrom rockusb mode (not support now) */
> > +     BOOT_RECOVER,    /* enter recover */
> > +     BOOT_NORECOVER,  /* do not enter recover */
> > +     BOOT_SECONDOS,   /* boot second OS (not support now)*/
> > +     BOOT_WIPEDATA,   /* enter recover and wipe data. */
> > +     BOOT_WIPEALL,    /* enter recover and wipe all data. */
> > +     BOOT_CHECKIMG,   /* check firmware img with backup part*/
> > +     BOOT_FASTBOOT,   /* enter fast boot mode */
> > +     BOOT_SECUREBOOT_DISABLE,
> > +     BOOT_CHARGING,   /* enter charge mode */
> > +     BOOT_MAX         /* MAX VALID BOOT TYPE.*/
> > +};
> > +#endif
>
> These flags rely on code in the bootloader to actually handle the target
> action. Nowadays this is uboot, but still a rockchip-specific fork. And we're
> actively moving away from that, with the recent rk3288 addition to mainline
> uboot.
>
> So unless you convince uboot people that the _underlying special
> functionality_ behind these flags should be part of uboot, I don't think this
> is going to fly.
>
>
> In a way this is similar to gpu kernel code talking to proprietary userspace
> libs - these are also not eligible for the kernel. (meaning stuff like the
> mali kernel driver not being allowed).

I don't want to comment on what Linux does or does not want. But I can
see this sort of feature being useful for devs at least. So long as it
is defined in a way that is not Rockchip-specific (and the above enum
looks pretty reasonable on that front, I think it makes sense.

Of course it's a bit odd to target a downstream U-Boot with a Linux
feature. But hopefully Rockchip's U-Boot support and development will
move to mainline with time.

>
> [...]
>
> > +static int rockchip_reboot_notify(struct notifier_block *this,
> > +                               unsigned long mode, void *cmd)
> > +{
> > +     u32 flag;
> > +
> > +     rockchip_get_reboot_flag(cmd, &flag);
> > +     regmap_write(regmap, flag_reg, flag);
> > +
> > +     return NOTIFY_DONE;
> > +}
> > +
> > +static struct notifier_block rockchip_reboot_handler = {
> > +     .notifier_call = rockchip_reboot_notify,
> > +     .priority = 150,
> > +};
>
> the restart handlers are meant to really only restart the system, not to
> execute some actions before the restart happens.
>
> See https://lkml.org/lkml/2015/6/3/707 for a similar case.
>
>
> Heiko

Regards,
Simon

  parent reply	other threads:[~2015-09-09 18:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 12:43 [PATCH] ARM: rockchip: add reboot notifier Andy Yan
2015-09-08 12:43 ` Andy Yan
2015-09-08 21:50 ` Alexey Klimov
2015-09-08 21:50   ` Alexey Klimov
2015-09-10 10:48   ` Andy Yan
2015-09-10 10:48     ` Andy Yan
2015-09-08 22:46 ` set rockchip-specific uboot bootmode flags on reboot (was: [PATCH] ARM: rockchip: add reboot notifier) Heiko Stübner
2015-09-08 22:46   ` Heiko Stübner
2015-09-09  1:08   ` set rockchip-specific uboot bootmode flags on reboot Andy Yan
2015-09-09  1:08     ` Andy Yan
2015-09-09 18:05   ` Simon Glass [this message]
2015-09-09 18:05     ` set rockchip-specific uboot bootmode flags on reboot (was: [PATCH] ARM: rockchip: add reboot notifier) Simon Glass
2015-09-09 18:05     ` Simon Glass
2015-09-17 11:07     ` set rockchip-specific uboot bootmode flags on reboot Andy Yan
2015-09-17 11:07       ` Andy Yan
2015-09-17 11:07       ` Andy Yan
2015-09-22 23:16       ` Heiko Stübner
2015-09-22 23:16         ` Heiko Stübner
2015-09-22 23:16         ` Heiko Stübner
2015-09-28  9:56         ` Andy Yan
2015-09-28  9:56           ` Andy Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPnjgZ0n7aNY7FRnoDYUBEnQAtUO1BWKs6DDzaMQyHsg1kQ1Jg@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=andy.yan@rock-chips.com \
    --cc=arnd@arndb.de \
    --cc=heiko@sntech.de \
    --cc=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.