[PATCH] ipq806x: onhub: Enable fstools_partname_fallback_scan
When fstools is unable to parse our root=<...> arg correctly, it can
fall back to scanning all block devices for a 'rootfs_data' partition.
This fallback was deemed wrong (or at least, a breaking/incompatible
change) for some targets, so we're forced to opt back into it with
fstools_partname_fallback_scan=1.
Without this, OnHub devices will use a rootfs-appended loop device for
rootfs_data instead of the intended 3rd partition.
NB: it would be nice to allow this rootfs_data partition by default in
fstools, but in chats with Ansuel, it sounds like it would be
intractable to locate all potentially-breaking targets programmatically.
Perhaps we can reconsider (and leverage DEVICE_COMPAT_VERSION for the
upgrade-incompatible targets) in the future.
While I'm at it, just move all the boot args into the 'cros-vboot'
build rule, instead of using the custom bootargs-append. All cros-vboot
subtargets here are using the same rootwait (to support both eMMC and
USB boot) and root/partition args.
Signed-off-by: Brian Norris
---
This patch is only useful once we commit this (and pull in new fstools):
https://patchwork.ozlabs.org/project/openwrt/patch/20230125062814.2517900-1-computersforpe...@gmail.com/
[fstools] partname: Correct fstools_partname_fallback_scan comparison
.../files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts | 4
.../arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts | 4
target/linux/ipq806x/image/chromium.mk| 4 +++-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
index 5b60ddb04b3f..442bcf19a675 100644
---
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
+++
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
@@ -11,10 +11,6 @@
/ {
model = "ASUS OnHub";
compatible = "asus,onhub", "google,arkham", "qcom,ipq8064";
-
- chosen {
- bootargs-append = " rootwait";
- };
};
_pinmux {
diff --git
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
index 6dd39f0d9584..6adc6be4aec6 100644
---
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
+++
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
@@ -11,10 +11,6 @@
/ {
model = "TP-Link OnHub";
compatible = "tplink,onhub", "google,whirlwind-sp5", "qcom,ipq8064";
-
- chosen {
- bootargs-append = " rootwait";
- };
};
_pinmux {
diff --git a/target/linux/ipq806x/image/chromium.mk
b/target/linux/ipq806x/image/chromium.mk
index 16af6b95ba6c..f908472419d1 100644
--- a/target/linux/ipq806x/image/chromium.mk
+++ b/target/linux/ipq806x/image/chromium.mk
@@ -20,7 +20,9 @@ endef
# (PARTNROFF=1) partition as their rootfs.
define Build/cros-vboot
$(STAGING_DIR_HOST)/bin/cros-vbutil \
- -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+ -k $@ \
+ -c "root=PARTUUID=%U/PARTNROFF=1 rootwait
fstools_partname_fallback_scan=1" \
+ -o $@.new
@mv $@.new $@
endef
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH fstools] partname: Correct fstools_partname_fallback_scan comparison
On Tue, Jan 24, 2023 at 10:28:14PM -0800, Brian Norris wrote:
> We want to return NULL if the param does *not* match 1 -- i.e., a
> non-zero strcmp().
>
> Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
> option")
Hmm, sorry for the quick self-reply, but after rereading, I noticed
there's a second reason commit 1ea5855e980c may be incorrect:
This fallback *used* to (pre-1ea5855e980c) be used for any block device
(eMMC, SATA, etc.) where we *didn't* specify root= in the boot args.
This could perhaps happen with initramfs systems? (Sorry, I'm not
extremely familiar with the openwrt ecosystem.)
So do we need to refactor this again, so that we allow the fallback in
either (or both) of these cases:
(1) no root= arg
(2) root= (where XXX is not a /device/path) +
fstools_partname_fallback_scan=1
?
Anyway, it's probably at least safe to apply my bugfix, but we might
need more.
Brian
> Signed-off-by: Brian Norris
> ---
>
> libfstools/partname.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libfstools/partname.c b/libfstools/partname.c
> index f42322a49d5b..82c723c02097 100644
> --- a/libfstools/partname.c
> +++ b/libfstools/partname.c
> @@ -143,7 +143,7 @@ static struct volume *partname_volume_find(char *name)
> if (!get_var_from_file("/proc/cmdline",
> "fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
> return NULL;
>
> - if (!strcmp("1", rootparam))
> + if (strcmp("1", rootparam))
> return NULL;
>
> /* no useful 'root=' kernel cmdline parameter, find on any
> block device */
> --
> 2.39.0
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH fstools] partname: Correct fstools_partname_fallback_scan comparison
We want to return NULL if the param does *not* match 1 -- i.e., a
non-zero strcmp().
Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
option")
Signed-off-by: Brian Norris
---
libfstools/partname.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libfstools/partname.c b/libfstools/partname.c
index f42322a49d5b..82c723c02097 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -143,7 +143,7 @@ static struct volume *partname_volume_find(char *name)
if (!get_var_from_file("/proc/cmdline",
"fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
return NULL;
- if (!strcmp("1", rootparam))
+ if (strcmp("1", rootparam))
return NULL;
/* no useful 'root=' kernel cmdline parameter, find on any
block device */
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 18:08, Koen Vandeputte wrote:
Hi,
I think our previous mails overlapped a bit as I didn't notice your
previous response :)
I'll send the data tomorrow.
I'm also wondering if adding a sleep before ubiformat in the old way
would influence/break it's behaviour?
possibly yes
Piotr,
Would you have any idea here?
Thanks again for your efforts,
Koen
if your active watchdog device is /dev/MyWatchdog, then...
just before the line:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
-m "$mtdnum"
you could add this to try disable the watchdog:
echo -n V >/dev/MyWatchdog
or else you could tickle the watchdog while flashing like this:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - 2>&1 | tee
/dev/MyWatchdog && ubiattach -m "$mtdnum"
BUT... this is a hack, cause shell option pipefail would be needed to
detect a failure of ubiformat then, as normally only the exit code of
the last piped process gets returned from the pipe expression.
so these are just tests, not fixes.
another dirty thing you could do is doubling the watchdog timeout period
for your platform. this at least could maybe be accepted as a stopgap
band aid in the openwrt tree. but the race condition remains, and it
will bite back sometime. a real fix for the race should be implemented.
BTW your watchdog seems to be:
https://www.kernelconfig.io/config_imx2_wdt
thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
Hi Koen, On 24.01.2023 22:08, Koen Vandeputte wrote: [...] Piotr, Would you have any idea here? Not really, very strange. What makes me wondering is that it doesn't look like a h/w related thing (e.g. watchdog fire or some sudden current consumption spike resulting in reset) and more like a clean 'reboot' but delayed. Smells like some race condition. Could you do a test without USB support installed (just a blind shooting but maybe we could get more clear logs just before the reboot)? -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On Tue, Jan 24, 2023 at 9:46 PM Lanchon wrote:
>
>
>
> On 1/24/23 17:35, Lanchon wrote:
> >
> >
> > On 1/24/23 13:25, Koen Vandeputte wrote:
> >> On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
> >> wrote:
> >>> On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
> hi Koen, thanks again.
>
> i copied your log here for ease of reference:
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
>
>
> first let me say:
>
> - ubinized sysupgrade is not used by any of my devices.
>
> - ubinized sysupgrade happens when when an ubi partition image is
> fed as
> an upgrade file. the image contains the complete set of ubi volumes
> that
> are normally stored within the ubi partition on your device: typically
> kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
> said sysupgrade, the current configuration is first copied to RAM,
> then
> the ubi partition image is written, and finally -if current config is
> kept- the RAM contents are written back to the new overlay volume.
>
> - ubinized sysupgrades were known to be broken by other people at the
> time of my commits, and they wanted to remove the feature altogether
> because it was unused (look it up in the relevant pull request for my
> commits on github). as i remember it, it was broken because some ubi
> volumes within the ubi partition were sometimes mounted or R/O block
> devices were created on top of them (/dev/ubiblock*), locking the ubi
> partition and preventing the upgrade.
>
> - although my devices would normally not use such upgrades, i could
> still take a whole ubi partition backup and then test ubinized
> sysupgrade with it on my devices. in fact, if you restore the ubi
> partition image without conserving the current configuration, then
> this
> procedure is the best way to do a backup/restore of the complete state
> of the router: kernel, rootfs, and overlay are completely saved and
> restored. btw, i think this should be documented. (and this is mostly
> the reason why i added gzip support on sysupgrade: ubinized images of
> backed-up ubi partitions compress like crazy.)
>
> - my tests of ubinized sysupgrade worked after these changes but not
> before. specifically the fix is in: af34733593 base-files: fix
> ubinized
> nand sysupgrade
>
>
> regarding your log:
>
> - nand_do_platform_check succeeds:
> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
>
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
>
>
> - next comes the actual nand_do_flash_file:
> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
>
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
>
>
> - it is determined that passed file is a ubi partition image, so
> nand_upgrade_ubinized is invoked:
> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
>
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
>
>
> nand_upgrade_ubinized is basically a one-liner:
> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - &&
> ubiattach
> -m "$mtdnum"
>
> cat/zcat the image, feeding that to ubiformat -f - which writes it.
>
>
> and the write does take place, but take a look:
>
> ---
>
> + cat /tmp/nandnew.ubi
> + ubiformat /dev/mtd2 -y -f -
> ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
>
> libscan: scanning eraseblock 0 -- 0 % complete
> libscan: scanning eraseblock 1 -- 0 % complete
> libscan: scanning eraseblock 2 -- 0 % complete
> ...
> libscan: scanning eraseblock 1868 -- 97 % complete
>
> libscan: scanning eraseblock
> [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
> 1869 -- 97 % complete
>
> libscan:
> [ 207.883339] usb usb2: USB disconnect, device number 1
> scanning eraseblock 1870 -- 97 %
> [ 207.891238] usb 2-1: USB disconnect, device number 2
> complete
>
> libscan: scanning eras
> [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
> eblock 1871 -- 97 % complete
>
> libscan: scanning eraseblock 1872
> [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
>
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 17:35, Lanchon wrote:
On 1/24/23 13:25, Koen Vandeputte wrote:
On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
wrote:
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
hi Koen, thanks again.
i copied your log here for ease of reference:
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
first let me say:
- ubinized sysupgrade is not used by any of my devices.
- ubinized sysupgrade happens when when an ubi partition image is
fed as
an upgrade file. the image contains the complete set of ubi volumes
that
are normally stored within the ubi partition on your device: typically
kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
said sysupgrade, the current configuration is first copied to RAM,
then
the ubi partition image is written, and finally -if current config is
kept- the RAM contents are written back to the new overlay volume.
- ubinized sysupgrades were known to be broken by other people at the
time of my commits, and they wanted to remove the feature altogether
because it was unused (look it up in the relevant pull request for my
commits on github). as i remember it, it was broken because some ubi
volumes within the ubi partition were sometimes mounted or R/O block
devices were created on top of them (/dev/ubiblock*), locking the ubi
partition and preventing the upgrade.
- although my devices would normally not use such upgrades, i could
still take a whole ubi partition backup and then test ubinized
sysupgrade with it on my devices. in fact, if you restore the ubi
partition image without conserving the current configuration, then
this
procedure is the best way to do a backup/restore of the complete state
of the router: kernel, rootfs, and overlay are completely saved and
restored. btw, i think this should be documented. (and this is mostly
the reason why i added gzip support on sysupgrade: ubinized images of
backed-up ubi partitions compress like crazy.)
- my tests of ubinized sysupgrade worked after these changes but not
before. specifically the fix is in: af34733593 base-files: fix
ubinized
nand sysupgrade
regarding your log:
- nand_do_platform_check succeeds:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
- next comes the actual nand_do_flash_file:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
- it is determined that passed file is a ubi partition image, so
nand_upgrade_ubinized is invoked:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
nand_upgrade_ubinized is basically a one-liner:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - &&
ubiattach
-m "$mtdnum"
cat/zcat the image, feeding that to ubiformat -f - which writes it.
and the write does take place, but take a look:
---
+ cat /tmp/nandnew.ubi
+ ubiformat /dev/mtd2 -y -f -
ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 0 -- 0 % complete
libscan: scanning eraseblock 1 -- 0 % complete
libscan: scanning eraseblock 2 -- 0 % complete
...
libscan: scanning eraseblock 1868 -- 97 % complete
libscan: scanning eraseblock
[ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
1869 -- 97 % complete
libscan:
[ 207.883339] usb usb2: USB disconnect, device number 1
scanning eraseblock 1870 -- 97 %
[ 207.891238] usb 2-1: USB disconnect, device number 2
complete
libscan: scanning eras
[ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
eblock 1871 -- 97 % complete
libscan: scanning eraseblock 1872
[ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
-- 97 % complete
libscan: scan
[ 207.917055] usb usb1: USB disconnect, device number 1
ning eraseblock 1873 -- 98 % comp
[ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
lete
libscan: scanning eraseblo
[ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect
reboot!
ck 1874 -- 98 % complete
libsca
[ 207.942382] reboot: Restarting system
---
while sysupgrade is flashing UBI the partition, the system is
rebooted;
i don't know why.
here are the cleaned-up kernel messages:
[ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
[ 207.883339] usb usb2: USB disconnect, device number 1
[ 207.891238] usb 2-1: USB disconnect, device number 2
[ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
[ 207.910396] ci_hdrc
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 13:25, Koen Vandeputte wrote:
On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
wrote:
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
hi Koen, thanks again.
i copied your log here for ease of reference:
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
first let me say:
- ubinized sysupgrade is not used by any of my devices.
- ubinized sysupgrade happens when when an ubi partition image is fed as
an upgrade file. the image contains the complete set of ubi volumes that
are normally stored within the ubi partition on your device: typically
kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
said sysupgrade, the current configuration is first copied to RAM, then
the ubi partition image is written, and finally -if current config is
kept- the RAM contents are written back to the new overlay volume.
- ubinized sysupgrades were known to be broken by other people at the
time of my commits, and they wanted to remove the feature altogether
because it was unused (look it up in the relevant pull request for my
commits on github). as i remember it, it was broken because some ubi
volumes within the ubi partition were sometimes mounted or R/O block
devices were created on top of them (/dev/ubiblock*), locking the ubi
partition and preventing the upgrade.
- although my devices would normally not use such upgrades, i could
still take a whole ubi partition backup and then test ubinized
sysupgrade with it on my devices. in fact, if you restore the ubi
partition image without conserving the current configuration, then this
procedure is the best way to do a backup/restore of the complete state
of the router: kernel, rootfs, and overlay are completely saved and
restored. btw, i think this should be documented. (and this is mostly
the reason why i added gzip support on sysupgrade: ubinized images of
backed-up ubi partitions compress like crazy.)
- my tests of ubinized sysupgrade worked after these changes but not
before. specifically the fix is in: af34733593 base-files: fix ubinized
nand sysupgrade
regarding your log:
- nand_do_platform_check succeeds:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
- next comes the actual nand_do_flash_file:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
- it is determined that passed file is a ubi partition image, so
nand_upgrade_ubinized is invoked:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
nand_upgrade_ubinized is basically a one-liner:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
-m "$mtdnum"
cat/zcat the image, feeding that to ubiformat -f - which writes it.
and the write does take place, but take a look:
---
+ cat /tmp/nandnew.ubi
+ ubiformat /dev/mtd2 -y -f -
ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 0 -- 0 % complete
libscan: scanning eraseblock 1 -- 0 % complete
libscan: scanning eraseblock 2 -- 0 % complete
...
libscan: scanning eraseblock 1868 -- 97 % complete
libscan: scanning eraseblock
[ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
1869 -- 97 % complete
libscan:
[ 207.883339] usb usb2: USB disconnect, device number 1
scanning eraseblock 1870 -- 97 %
[ 207.891238] usb 2-1: USB disconnect, device number 2
complete
libscan: scanning eras
[ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
eblock 1871 -- 97 % complete
libscan: scanning eraseblock 1872
[ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
-- 97 % complete
libscan: scan
[ 207.917055] usb usb1: USB disconnect, device number 1
ning eraseblock 1873 -- 98 % comp
[ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
lete
libscan: scanning eraseblo
[ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
ck 1874 -- 98 % complete
libsca
[ 207.942382] reboot: Restarting system
---
while sysupgrade is flashing UBI the partition, the system is rebooted;
i don't know why.
here are the cleaned-up kernel messages:
[ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
[ 207.883339] usb usb2: USB disconnect, device number 1
[ 207.891238] usb 2-1: USB disconnect, device number 2
[ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
[ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
[ 207.917055] usb usb1: USB disconnect,
mt76 ac/ax bugs
I have been trying to characterize a very difficult bug in the ac and ax support on a new mt76 product, where for mu-mimo and related, it seems to be generating an invalid or flipped mac address on small (but not large) packets, eventually getting through. This shows up in my flent data as huge swings in delay for tcp + voip or ping - but not packet loss. Has anyone else seen this? On Tue, Jan 24, 2023 at 12:00 PM Peter Naulls wrote: > > On 1/24/23 14:48, Nick wrote: > > Hey, > > We have testing-support for 5.15 in almost all targets, so we may be able to > > release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. > > We > > are using GCC 12 as our default compiler version[2]. Binutils has been > > updated > > to version 2.40. Could we fill out the Release Goals page [3]? > > It would be great to see a new release. > > > > I guess an actual release here is a few months off, and I don't know > anything about the state of 23.x, but I have 2 mt7621 platforms that I should > try and get included sooner rather than later, and probably a 3rd in a few > months. > > > > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz Dave Täht CEO, TekLibre, LLC ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release Goals 23.x?
As far as I know, device support can be backported from master into the release branch. So you are able to add the device support if a release already happened. Bests Nick On 1/24/23 20:56, Peter Naulls wrote: On 1/24/23 14:48, Nick wrote: Hey, We have testing-support for 5.15 in almost all targets, so we may be able to release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We are using GCC 12 as our default compiler version[2]. Binutils has been updated to version 2.40. Could we fill out the Release Goals page [3]? It would be great to see a new release. I guess an actual release here is a few months off, and I don't know anything about the state of 23.x, but I have 2 mt7621 platforms that I should try and get included sooner rather than later, and probably a 3rd in a few months. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release Goals 23.x?
On 1/24/23 14:48, Nick wrote: Hey, We have testing-support for 5.15 in almost all targets, so we may be able to release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We are using GCC 12 as our default compiler version[2]. Binutils has been updated to version 2.40. Could we fill out the Release Goals page [3]? It would be great to see a new release. I guess an actual release here is a few months off, and I don't know anything about the state of 23.x, but I have 2 mt7621 platforms that I should try and get included sooner rather than later, and probably a 3rd in a few months. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Release Goals 23.x?
Hey, We have testing-support for 5.15 in almost all targets, so we may be able to release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We are using GCC 12 as our default compiler version[2]. Binutils has been updated to version 2.40. Could we fill out the Release Goals page [3]? It would be great to see a new release. Bests Nick [0] - https://github.com/openwrt/openwrt/issues/10672 [1] - https://github.com/openwrt/openwrt/pull/11011 [2] - https://github.com/openwrt/openwrt/commit/d9de5252a44e208cecaa1e2edad3d1615b84302c [3] - https://openwrt.org/docs/guide-developer/releases/goals/23.xx ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] odhcpd: Reduce error messages
When there's no network cable connected to LAN, then odhcpd does this: Tue Jan 24 18:32:04 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:20 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:36 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:52 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Accurate, but not very interesting. I think this would be better served as debug. Signed-off-by: Peter Naulls --- --- a/src/odhcpd.c 2023-01-24 13:29:56.080616097 -0500 +++ b/src/odhcpd.c 2023-01-24 13:30:19.284692423 -0500 @@ -207,7 +207,7 @@ ssize_t sent = sendmsg(socket, , MSG_DONTWAIT); if (sent < 0) - syslog(LOG_ERR, "Failed to send to %s%%%s@%s (%m)", + syslog(LOG_DEBUG, "Failed to send to %s%%%s@%s (%m)", ipbuf, iface->name, iface->ifname); else syslog(LOG_DEBUG, "Sent %zd bytes to %s%%%s@%s", ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On Tue, Jan 24, 2023 at 5:49 PM wrote: > > On 24.01.2023 17:13, Lanchon wrote: > > the problem lies elsewhere: on your platform something is rebooting the > > system asynchronously while it is updating. this is very dangerous and must > > be fixed elsewhere in code. > > just a wild guess. faulty power supplies sometimes lead to reboots if the > power supplied does not suffice. maybe a direction to investigate? ..sunny > regards ede > Hi, In this case it should be faulty on all of my 53 boards. Some are powered using a DC supply, others through PoE. I don't think this is the issue here. :-) Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 24.01.2023 17:13, Lanchon wrote: the problem lies elsewhere: on your platform something is rebooting the system asynchronously while it is updating. this is very dangerous and must be fixed elsewhere in code. just a wild guess. faulty power supplies sometimes lead to reboots if the power supplied does not suffice. maybe a direction to investigate? ..sunny regards ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
wrote:
>
> On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
> >
> > hi Koen, thanks again.
> >
> > i copied your log here for ease of reference:
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
> >
> >
> > first let me say:
> >
> > - ubinized sysupgrade is not used by any of my devices.
> >
> > - ubinized sysupgrade happens when when an ubi partition image is fed as
> > an upgrade file. the image contains the complete set of ubi volumes that
> > are normally stored within the ubi partition on your device: typically
> > kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
> > said sysupgrade, the current configuration is first copied to RAM, then
> > the ubi partition image is written, and finally -if current config is
> > kept- the RAM contents are written back to the new overlay volume.
> >
> > - ubinized sysupgrades were known to be broken by other people at the
> > time of my commits, and they wanted to remove the feature altogether
> > because it was unused (look it up in the relevant pull request for my
> > commits on github). as i remember it, it was broken because some ubi
> > volumes within the ubi partition were sometimes mounted or R/O block
> > devices were created on top of them (/dev/ubiblock*), locking the ubi
> > partition and preventing the upgrade.
> >
> > - although my devices would normally not use such upgrades, i could
> > still take a whole ubi partition backup and then test ubinized
> > sysupgrade with it on my devices. in fact, if you restore the ubi
> > partition image without conserving the current configuration, then this
> > procedure is the best way to do a backup/restore of the complete state
> > of the router: kernel, rootfs, and overlay are completely saved and
> > restored. btw, i think this should be documented. (and this is mostly
> > the reason why i added gzip support on sysupgrade: ubinized images of
> > backed-up ubi partitions compress like crazy.)
> >
> > - my tests of ubinized sysupgrade worked after these changes but not
> > before. specifically the fix is in: af34733593 base-files: fix ubinized
> > nand sysupgrade
> >
> >
> > regarding your log:
> >
> > - nand_do_platform_check succeeds:
> > https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
> >
> > - next comes the actual nand_do_flash_file:
> > https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
> >
> > - it is determined that passed file is a ubi partition image, so
> > nand_upgrade_ubinized is invoked:
> > https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
> >
> > nand_upgrade_ubinized is basically a one-liner:
> > ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
> > -m "$mtdnum"
> >
> > cat/zcat the image, feeding that to ubiformat -f - which writes it.
> >
> >
> > and the write does take place, but take a look:
> >
> > ---
> >
> > + cat /tmp/nandnew.ubi
> > + ubiformat /dev/mtd2 -y -f -
> > ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
> > eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
> >
> > libscan: scanning eraseblock 0 -- 0 % complete
> > libscan: scanning eraseblock 1 -- 0 % complete
> > libscan: scanning eraseblock 2 -- 0 % complete
> > ...
> > libscan: scanning eraseblock 1868 -- 97 % complete
> >
> > libscan: scanning eraseblock
> > [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
> > 1869 -- 97 % complete
> >
> > libscan:
> > [ 207.883339] usb usb2: USB disconnect, device number 1
> > scanning eraseblock 1870 -- 97 %
> > [ 207.891238] usb 2-1: USB disconnect, device number 2
> > complete
> >
> > libscan: scanning eras
> > [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
> > eblock 1871 -- 97 % complete
> >
> > libscan: scanning eraseblock 1872
> > [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
> > -- 97 % complete
> >
> > libscan: scan
> > [ 207.917055] usb usb1: USB disconnect, device number 1
> > ning eraseblock 1873 -- 98 % comp
> > [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> > lete
> >
> > libscan: scanning eraseblo
> > [ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
> > ck 1874 -- 98 % complete
> >
> > libsca
> > [ 207.942382] reboot: Restarting system
> >
> > ---
> >
> >
> > while sysupgrade is flashing UBI the partition, the system is
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 12:26, Koen Vandeputte wrote:
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
hi Koen, thanks again.
i copied your log here for ease of reference:
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
first let me say:
- ubinized sysupgrade is not used by any of my devices.
- ubinized sysupgrade happens when when an ubi partition image is fed as
an upgrade file. the image contains the complete set of ubi volumes that
are normally stored within the ubi partition on your device: typically
kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
said sysupgrade, the current configuration is first copied to RAM, then
the ubi partition image is written, and finally -if current config is
kept- the RAM contents are written back to the new overlay volume.
- ubinized sysupgrades were known to be broken by other people at the
time of my commits, and they wanted to remove the feature altogether
because it was unused (look it up in the relevant pull request for my
commits on github). as i remember it, it was broken because some ubi
volumes within the ubi partition were sometimes mounted or R/O block
devices were created on top of them (/dev/ubiblock*), locking the ubi
partition and preventing the upgrade.
- although my devices would normally not use such upgrades, i could
still take a whole ubi partition backup and then test ubinized
sysupgrade with it on my devices. in fact, if you restore the ubi
partition image without conserving the current configuration, then this
procedure is the best way to do a backup/restore of the complete state
of the router: kernel, rootfs, and overlay are completely saved and
restored. btw, i think this should be documented. (and this is mostly
the reason why i added gzip support on sysupgrade: ubinized images of
backed-up ubi partitions compress like crazy.)
- my tests of ubinized sysupgrade worked after these changes but not
before. specifically the fix is in: af34733593 base-files: fix ubinized
nand sysupgrade
regarding your log:
- nand_do_platform_check succeeds:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
- next comes the actual nand_do_flash_file:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
- it is determined that passed file is a ubi partition image, so
nand_upgrade_ubinized is invoked:
https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
nand_upgrade_ubinized is basically a one-liner:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
-m "$mtdnum"
cat/zcat the image, feeding that to ubiformat -f - which writes it.
and the write does take place, but take a look:
---
+ cat /tmp/nandnew.ubi
+ ubiformat /dev/mtd2 -y -f -
ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 0 -- 0 % complete
libscan: scanning eraseblock 1 -- 0 % complete
libscan: scanning eraseblock 2 -- 0 % complete
...
libscan: scanning eraseblock 1868 -- 97 % complete
libscan: scanning eraseblock
[ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
1869 -- 97 % complete
libscan:
[ 207.883339] usb usb2: USB disconnect, device number 1
scanning eraseblock 1870 -- 97 %
[ 207.891238] usb 2-1: USB disconnect, device number 2
complete
libscan: scanning eras
[ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
eblock 1871 -- 97 % complete
libscan: scanning eraseblock 1872
[ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
-- 97 % complete
libscan: scan
[ 207.917055] usb usb1: USB disconnect, device number 1
ning eraseblock 1873 -- 98 % comp
[ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
lete
libscan: scanning eraseblo
[ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
ck 1874 -- 98 % complete
libsca
[ 207.942382] reboot: Restarting system
---
while sysupgrade is flashing UBI the partition, the system is rebooted;
i don't know why.
here are the cleaned-up kernel messages:
[ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
[ 207.883339] usb usb2: USB disconnect, device number 1
[ 207.891238] usb 2-1: USB disconnect, device number 2
[ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
[ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
[ 207.917055] usb usb1: USB disconnect, device number 1
[ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1
[PATCH] sdk: expose PATENTED an NLS build options
From: Tomasz Maciej Nowak Some packages offer functionalities guarded by these options and it'll be impossible to reach them without changing Config-build.in. So allow to toggle these in more friendly way, by exposing them in configuration menu. Signed-off-by: Tomasz Maciej Nowak --- target/sdk/files/Config.in | 18 ++ 1 file changed, 18 insertions(+) diff --git a/target/sdk/files/Config.in b/target/sdk/files/Config.in index 12c0f6a6246c..e0b8160e5dfb 100644 --- a/target/sdk/files/Config.in +++ b/target/sdk/files/Config.in @@ -18,6 +18,24 @@ menu "Global build settings" bool "Cryptographically sign package lists" default y + comment "General build options" + + config BUILD_PATENTED + default n + bool "Compile with support for patented functionality" + help + When this option is disabled, software which provides patented functionality + will not be built. In case software provides optional support for patented + functionality, this optional support will get disabled for this package. + + config BUILD_NLS + default n + bool "Compile with full language support" + help + When this option is enabled, packages are built with the full versions of + iconv and GNU gettext instead of the default OpenWrt stubs. If uClibc is + used, it is also built with locale support. + comment "Package build options" config DEBUG -- 2.39.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
>
> hi Koen, thanks again.
>
> i copied your log here for ease of reference:
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
>
>
> first let me say:
>
> - ubinized sysupgrade is not used by any of my devices.
>
> - ubinized sysupgrade happens when when an ubi partition image is fed as
> an upgrade file. the image contains the complete set of ubi volumes that
> are normally stored within the ubi partition on your device: typically
> kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
> said sysupgrade, the current configuration is first copied to RAM, then
> the ubi partition image is written, and finally -if current config is
> kept- the RAM contents are written back to the new overlay volume.
>
> - ubinized sysupgrades were known to be broken by other people at the
> time of my commits, and they wanted to remove the feature altogether
> because it was unused (look it up in the relevant pull request for my
> commits on github). as i remember it, it was broken because some ubi
> volumes within the ubi partition were sometimes mounted or R/O block
> devices were created on top of them (/dev/ubiblock*), locking the ubi
> partition and preventing the upgrade.
>
> - although my devices would normally not use such upgrades, i could
> still take a whole ubi partition backup and then test ubinized
> sysupgrade with it on my devices. in fact, if you restore the ubi
> partition image without conserving the current configuration, then this
> procedure is the best way to do a backup/restore of the complete state
> of the router: kernel, rootfs, and overlay are completely saved and
> restored. btw, i think this should be documented. (and this is mostly
> the reason why i added gzip support on sysupgrade: ubinized images of
> backed-up ubi partitions compress like crazy.)
>
> - my tests of ubinized sysupgrade worked after these changes but not
> before. specifically the fix is in: af34733593 base-files: fix ubinized
> nand sysupgrade
>
>
> regarding your log:
>
> - nand_do_platform_check succeeds:
> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
>
> - next comes the actual nand_do_flash_file:
> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
>
> - it is determined that passed file is a ubi partition image, so
> nand_upgrade_ubinized is invoked:
> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
>
> nand_upgrade_ubinized is basically a one-liner:
> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
> -m "$mtdnum"
>
> cat/zcat the image, feeding that to ubiformat -f - which writes it.
>
>
> and the write does take place, but take a look:
>
> ---
>
> + cat /tmp/nandnew.ubi
> + ubiformat /dev/mtd2 -y -f -
> ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
>
> libscan: scanning eraseblock 0 -- 0 % complete
> libscan: scanning eraseblock 1 -- 0 % complete
> libscan: scanning eraseblock 2 -- 0 % complete
> ...
> libscan: scanning eraseblock 1868 -- 97 % complete
>
> libscan: scanning eraseblock
> [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
> 1869 -- 97 % complete
>
> libscan:
> [ 207.883339] usb usb2: USB disconnect, device number 1
> scanning eraseblock 1870 -- 97 %
> [ 207.891238] usb 2-1: USB disconnect, device number 2
> complete
>
> libscan: scanning eras
> [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
> eblock 1871 -- 97 % complete
>
> libscan: scanning eraseblock 1872
> [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4
> -- 97 % complete
>
> libscan: scan
> [ 207.917055] usb usb1: USB disconnect, device number 1
> ning eraseblock 1873 -- 98 % comp
> [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> lete
>
> libscan: scanning eraseblo
> [ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
> ck 1874 -- 98 % complete
>
> libsca
> [ 207.942382] reboot: Restarting system
>
> ---
>
>
> while sysupgrade is flashing UBI the partition, the system is rebooted;
> i don't know why.
>
> here are the cleaned-up kernel messages:
>
> [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1
> [ 207.883339] usb usb2: USB disconnect, device number 1
> [ 207.891238] usb 2-1: USB disconnect, device number 2
> [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2
