All of lore.kernel.org
 help / color / mirror / Atom feed
* Install Yocto image and backup
@ 2020-11-02  1:02 ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: Jupiter @ 2020-11-02  1:02 UTC (permalink / raw)
  To: linux-mtd; +Cc: Yocto discussion list

Apology if it is an off topic, I could not find proper mailing lists
to ask questions.

I built Yocto Linux kernel and installed Yocto image to MTD NAND
storage in an iMAX6 device, because we designed RO for the kernel and
root file system, RW for applications, we can update applications OTA
but we cannot update kernel and root file system OTA. My supervisor
asked if we need to have a dual NAND storage to backup the kernel and
root file image, if the NAND bad sector occurred in the primary image,
it can be booted from the secondary backup image. I understand where
the concerns come from, but I am not clear if it is necessary or if it
is a common practice to perform NAND backup storage, appreciate your
insight advice.

Thank you very much.

Kind regards,

- jupiter

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Install Yocto image and backup
@ 2020-11-02  1:02 ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: JH @ 2020-11-02  1:02 UTC (permalink / raw)
  To: linux-mtd; +Cc: Yocto discussion list

Apology if it is an off topic, I could not find proper mailing lists
to ask questions.

I built Yocto Linux kernel and installed Yocto image to MTD NAND
storage in an iMAX6 device, because we designed RO for the kernel and
root file system, RW for applications, we can update applications OTA
but we cannot update kernel and root file system OTA. My supervisor
asked if we need to have a dual NAND storage to backup the kernel and
root file image, if the NAND bad sector occurred in the primary image,
it can be booted from the secondary backup image. I understand where
the concerns come from, but I am not clear if it is necessary or if it
is a common practice to perform NAND backup storage, appreciate your
insight advice.

Thank you very much.

Kind regards,

- jupiter

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Install Yocto image and backup
  2020-11-02  1:02 ` JH
  (?)
@ 2020-11-02  8:40 ` Alexander Dahl
  2020-11-02  9:16     ` JH
  -1 siblings, 1 reply; 12+ messages in thread
From: Alexander Dahl @ 2020-11-02  8:40 UTC (permalink / raw)
  To: linux-mtd; +Cc: Yocto discussion list, Jupiter

Hei hei,

Am Montag, 2. November 2020, 02:02:09 CET schrieb Jupiter:
> I built Yocto Linux kernel and installed Yocto image to MTD NAND
> storage in an iMAX6 device, because we designed RO for the kernel and
> root file system, RW for applications, we can update applications OTA
> but we cannot update kernel and root file system OTA. My supervisor
> asked if we need to have a dual NAND storage to backup the kernel and
> root file image, if the NAND bad sector occurred in the primary image,
> it can be booted from the secondary backup image. I understand where
> the concerns come from, but I am not clear if it is necessary or if it
> is a common practice to perform NAND backup storage, appreciate your
> insight advice.

In my opinion two things are common practice: 

1) Using a layer on top of raw NAND, like UBI/UBIFS nowadays, so bad blocks 
can be handled properly in a layer below your rootfs.

2) Using an A/B scheme for updating and using a well tested framework for that 
(instead of self written shell scripts).  You don't need another NAND chip for 
that, just multiple partitions.  You can still have your kernel/rootfs read-
only at runtime.

Greets
Alex




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Install Yocto image and backup
  2020-11-02  8:40 ` Alexander Dahl
@ 2020-11-02  9:16     ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: Jupiter @ 2020-11-02  9:16 UTC (permalink / raw)
  To: Alexander Dahl; +Cc: Yocto discussion list, linux-mtd

Hi Alexander,

Thanks for your advice.

> In my opinion two things are common practice:
>
> 1) Using a layer on top of raw NAND, like UBI/UBIFS nowadays, so bad blocks
> can be handled properly in a layer below your rootfs.

Yes, the UBI/UBIFS is used in NAND partitions, I guess you alluded
there is no need use the backup, right?

> 2) Using an A/B scheme for updating and using a well tested framework for
> that  (instead of self written shell scripts).  You don't need another NAND chip
> for that, just multiple partitions.  You can still have your kernel/rootfs read-only at runtime.

If I do need to use a backup, it won't need another NAND chip, it will
be another UBI/UBIFS partition. But I would like as simple as possible
if no backup is a common practice.

Thank you very much.

Kind regards,

-  jupiter

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Install Yocto image and backup
@ 2020-11-02  9:16     ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: JH @ 2020-11-02  9:16 UTC (permalink / raw)
  To: Alexander Dahl; +Cc: linux-mtd, Yocto discussion list

Hi Alexander,

Thanks for your advice.

> In my opinion two things are common practice:
>
> 1) Using a layer on top of raw NAND, like UBI/UBIFS nowadays, so bad blocks
> can be handled properly in a layer below your rootfs.

Yes, the UBI/UBIFS is used in NAND partitions, I guess you alluded
there is no need use the backup, right?

> 2) Using an A/B scheme for updating and using a well tested framework for
> that  (instead of self written shell scripts).  You don't need another NAND chip
> for that, just multiple partitions.  You can still have your kernel/rootfs read-only at runtime.

If I do need to use a backup, it won't need another NAND chip, it will
be another UBI/UBIFS partition. But I would like as simple as possible
if no backup is a common practice.

Thank you very much.

Kind regards,

-  jupiter

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] Install Yocto image and backup
  2020-11-02  9:16     ` JH
  (?)
@ 2020-11-02  9:47     ` Matthias Schoepfer
  2020-11-02 10:05       ` JH
  -1 siblings, 1 reply; 12+ messages in thread
From: Matthias Schoepfer @ 2020-11-02  9:47 UTC (permalink / raw)
  To: yocto

Hi!

On 11/2/20 10:16 AM, JH wrote:
> If I do need to use a backup, it won't need another NAND chip, it will
> be another UBI/UBIFS partition. But I would like as simple as possible
> if no backup is a common practice.

The A/B partitioning is very common and I would argue, it is the 
simplest way if you want you OTA Update to be safe in regards of any 
errors (user unplugging etc.) that may happen during write / switching 
to new software. If you can spare the extra partitions on your NAND, my 
advice would be to do it exactly that way, and use a common tool for 
that (i.e. swupate, rauc, ... ).

Regards,

   Matthias


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] Install Yocto image and backup
  2020-11-02  9:47     ` [yocto] " Matthias Schoepfer
@ 2020-11-02 10:05       ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: JH @ 2020-11-02 10:05 UTC (permalink / raw)
  To: matthias.schoepfer; +Cc: yocto

Thanks Matthias,

> The A/B partitioning is very common and I would argue, it is the
> simplest way if you want you OTA Update to be safe in regards of any
> errors (user unplugging etc.) that may happen during write / switching
> to new software. If you can spare the extra partitions on your NAND, my
> advice would be to do it exactly that way, and use a common tool for
> that (i.e. swupate, rauc, ... ).

We don't have OTA update for RO kernel and rootfs yet, I'll take the
advice for running OTA A/B partitioning when the requirement is
coming.

Thank you all for your kind responses.

Kind regards,

- jupiter

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Install Yocto image and backup
  2020-11-02  9:16     ` JH
  (?)
  (?)
@ 2020-11-03  8:16     ` Alexander Dahl
  2020-11-03  9:17         ` JH
  -1 siblings, 1 reply; 12+ messages in thread
From: Alexander Dahl @ 2020-11-03  8:16 UTC (permalink / raw)
  To: linux-mtd; +Cc: Yocto discussion list, Jupiter

Hei hei,

Am Montag, 2. November 2020, 10:16:58 CET schrieb Jupiter:
> Hi Alexander,
> 
> Thanks for your advice.
> 
> > In my opinion two things are common practice:
> > 
> > 1) Using a layer on top of raw NAND, like UBI/UBIFS nowadays, so bad
> > blocks
> > can be handled properly in a layer below your rootfs.
> 
> Yes, the UBI/UBIFS is used in NAND partitions, I guess you alluded
> there is no need use the backup, right?

If your kernel and rootfs partition is just one UBIFS in a bigger UBI volume, 
then no. Single bad blocks affecting the UBIFS partitions would be handled by 
the underlying UBI. You should however consider using ubihealthd or something 
similar to become aware of badblocks over time and handle them before it's too 
late and you can not boot from the rootfs anymore, especially if it is read 
only and not touched for writing in normal operation.

> > 2) Using an A/B scheme for updating and using a well tested framework for
> > that  (instead of self written shell scripts).  You don't need another
> > NAND chip for that, just multiple partitions.  You can still have your
> > kernel/rootfs read-only at runtime.
> If I do need to use a backup, it won't need another NAND chip, it will
> be another UBI/UBIFS partition. But I would like as simple as possible
> if no backup is a common practice.

I don't think backup is the right term here. Backup would be something you 
make based on a running system.

I just looked briefly over the documentation of RAUC [1]. This is no explicit 
recommendation, there are other update frameworks, but you can find a lot of 
ideas and concepts in there frequently used in the embedded world for updates.

Your original question implied you want some kind of redundancy, but never 
update kernel and root filesystem, right? That's rather unusual at least if 
your device is somehow connected to a network. So what I suggested was having 
two rootfs partitions. One is active and the device boots from it (A), and the 
other one acts as inactive (B). When you update, write the new rootfs to the 
inactive partition and then just switch over and boot B instead. You might add 
a third partition for recovery or factory reset. Only the active partition 
would be used in the running system and can still be readonly there.

Alex

[1] https://rauc.readthedocs.io/



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Install Yocto image and backup
  2020-11-03  8:16     ` Alexander Dahl
@ 2020-11-03  9:17         ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: Jupiter @ 2020-11-03  9:17 UTC (permalink / raw)
  To: Alexander Dahl; +Cc: Yocto discussion list, linux-mtd

Hi Alexander,

Thanks for your clarification.

> If your kernel and rootfs partition is just one UBIFS in a bigger UBI volume,
> then no. Single bad blocks affecting the UBIFS partitions would be handled
> by  the underlying UBI. You should however consider using ubihealthd or
> something  similar to become aware of badblocks over time and handle them before it's
> too  late and you can not boot from the rootfs anymore, especially if it is read only and not
> touched for writing in normal operation.

Yes, I use one UBIFS for 4 partitions, RO rootfs, RO kernel, RO DTB
and RW application, no write for RO partitions, that should be safe, I
feel relieved.

> your device is somehow connected to a network. So what I suggested was having
> two rootfs partitions. One is active and the device boots from it (A), and the
> other one acts as inactive (B). When you update, write the new rootfs to the
> inactive partition and then just switch over and boot B instead. You might add
> a third partition for recovery or factory reset. Only the active partition
> would be used in the running system and can still be readonly there.

The reason we don't update kernel and rootfs because the size of
kernel and rootfs is too large, it is hard to download 60MB image OTA
via 4G CAT M1. If we are going to change to use 4G CAT1 or higher
speed, I'll use either RAUC or SWUpdate, which one is the most popular
for embedded system using uboot and UBFIS?

Thank you very much.

Kind regards,

- jupiter

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Install Yocto image and backup
@ 2020-11-03  9:17         ` JH
  0 siblings, 0 replies; 12+ messages in thread
From: JH @ 2020-11-03  9:17 UTC (permalink / raw)
  To: Alexander Dahl; +Cc: linux-mtd, Yocto discussion list

Hi Alexander,

Thanks for your clarification.

> If your kernel and rootfs partition is just one UBIFS in a bigger UBI volume,
> then no. Single bad blocks affecting the UBIFS partitions would be handled
> by  the underlying UBI. You should however consider using ubihealthd or
> something  similar to become aware of badblocks over time and handle them before it's
> too  late and you can not boot from the rootfs anymore, especially if it is read only and not
> touched for writing in normal operation.

Yes, I use one UBIFS for 4 partitions, RO rootfs, RO kernel, RO DTB
and RW application, no write for RO partitions, that should be safe, I
feel relieved.

> your device is somehow connected to a network. So what I suggested was having
> two rootfs partitions. One is active and the device boots from it (A), and the
> other one acts as inactive (B). When you update, write the new rootfs to the
> inactive partition and then just switch over and boot B instead. You might add
> a third partition for recovery or factory reset. Only the active partition
> would be used in the running system and can still be readonly there.

The reason we don't update kernel and rootfs because the size of
kernel and rootfs is too large, it is hard to download 60MB image OTA
via 4G CAT M1. If we are going to change to use 4G CAT1 or higher
speed, I'll use either RAUC or SWUpdate, which one is the most popular
for embedded system using uboot and UBFIS?

Thank you very much.

Kind regards,

- jupiter

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] Install Yocto image and backup
  2020-11-03  9:17         ` JH
@ 2020-11-03  9:48           ` Richard Weinberger
  -1 siblings, 0 replies; 12+ messages in thread
From: Richard Weinberger @ 2020-11-03  9:48 UTC (permalink / raw)
  To: JH; +Cc: Alexander Dahl, Yocto discussion list, linux-mtd

On Tue, Nov 3, 2020 at 10:17 AM JH <jupiter.hce@gmail.com> wrote:
> The reason we don't update kernel and rootfs because the size of
> kernel and rootfs is too large, it is hard to download 60MB image OTA
> via 4G CAT M1. If we are going to change to use 4G CAT1 or higher
> speed, I'll use either RAUC or SWUpdate, which one is the most popular
> for embedded system using uboot and UBFIS?

You don't need a full download.
In the past I've used binary diffs with great success.

So if the update size is your biggest concern, the tradeoff of
computing and applying
the binary diff might be worth it.

-- 
Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] Install Yocto image and backup
@ 2020-11-03  9:48           ` Richard Weinberger
  0 siblings, 0 replies; 12+ messages in thread
From: Richard Weinberger @ 2020-11-03  9:48 UTC (permalink / raw)
  To: JH; +Cc: Alexander Dahl, linux-mtd, Yocto discussion list

On Tue, Nov 3, 2020 at 10:17 AM JH <jupiter.hce@gmail.com> wrote:
> The reason we don't update kernel and rootfs because the size of
> kernel and rootfs is too large, it is hard to download 60MB image OTA
> via 4G CAT M1. If we are going to change to use 4G CAT1 or higher
> speed, I'll use either RAUC or SWUpdate, which one is the most popular
> for embedded system using uboot and UBFIS?

You don't need a full download.
In the past I've used binary diffs with great success.

So if the update size is your biggest concern, the tradeoff of
computing and applying
the binary diff might be worth it.

-- 
Thanks,
//richard

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2020-11-03  9:50 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-02  1:02 Install Yocto image and backup Jupiter
2020-11-02  1:02 ` JH
2020-11-02  8:40 ` Alexander Dahl
2020-11-02  9:16   ` Jupiter
2020-11-02  9:16     ` JH
2020-11-02  9:47     ` [yocto] " Matthias Schoepfer
2020-11-02 10:05       ` JH
2020-11-03  8:16     ` Alexander Dahl
2020-11-03  9:17       ` Jupiter
2020-11-03  9:17         ` JH
2020-11-03  9:48         ` [yocto] " Richard Weinberger
2020-11-03  9:48           ` Richard Weinberger

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.