On Tue, Jan 28, 2020 at 11:40 AM JH <jupiter....@gmail.com> wrote:

> Hi Gabriele,
>
> On 1/28/20, Gabriele Zampieri <gabbla.mal...@gmail.com> wrote:
> > HI JH,
> >
> > - Can you stop on uboot and try "nand bad"? This will list the bad blocks
> > on your device.
> => nand bad
>
> Device 0 bad blocks:
>
>
> > - How do you flash your ubi partition(s)?
>
> I boot zImage-initramfs kernel to Linux user space, then run:
> ubidetach -p /dev/mtd5
> ubiformat /dev/mtd5 -y
> ubiattach -m 5
> ubimkvol /dev/ubi0 -s 160MiB -N rootfs_data
> mount -t ubifs ubi0:rootfs_data /mnt
> cp -adr /yocto_rootfs/* /mnt
>
> Ok this sounds good.

> > - During boot, does ubifs layer complain about the partition is it trying
> > to mount? It will in case of corrupted metadata and may result in a read
> > only mount.
>
> There is no partition involved during the boot, all partitions start
> in user space after booting.
>
>
Actually the kernel needs a series of module (both built in or loadable)
when mounting the partitions (read from fstab for example), so, in case of
ubifs:
- Mtd partitions are recognized (usually from dtb)
- The ubi layer is attached to the corresponding mtd partition (ubiattach)
- ubifs is mounted on top of ubi partition (mount)
If ubifs layer detects malformed nodes/corrupted data, it will complain.
You may want to check dmesg | grep -i ubi

> - It's pretty weird that busybox has gone and the partition is intact.
> > Didn't you messed with any script? Can you replicate on another board?
>
> I don't think it was bad block problem, because it is a new version
> hardware, which has some problem in power supply, could unstable or
> insufficient power supply cause MTD / NAND crash?
>
No bad block here, as reported by  uboot.
Sure, unstable power may result in power cuts and data loss. If power rails
are unstable the nand may not work properly.
Be sure to match your silicon vendor design.

> Thank you Gabriele,
>
> Kind regards,
>
> - jh
>
> >
> > On Tue, Jan 28, 2020 at 7:25 AM JH <jupiter....@gmail.com> wrote:
> >
> >> On 1/27/20, Quentin Schulz <quentin.sch...@streamunlimited.com> wrote:
> >> > Hi JH,
> >> >
> >> > On Mon, Jan 27, 2020 at 10:13:37PM +1100, JH wrote:
> >> >> Hi Andy,
> >> >>
> >> >> Thanks for the response.
> >> >>
> >> >> On 1/27/20, Andy Pont <andy.p...@sdcsystems.com> wrote:
> >> >> > JH wrote...
> >> >> >
> >> >> >>That the same problem of missing busybox was not just occurred
> >> >> >> during
> >> >> >>the device running in the middle of operation, it was also occurred
> >> >> >>during booting image from NAND, I saw several times that the first
> >> >> >> and
> >> >> >>second cycles of booting image from NAND were working well, then
> >> >> >> some
> >> >> >>following booting process would be crashed by missing busybox, then
> >> >> >>could not run whole shell commands. I have been pondering if it
> >> >> >> could
> >> >> >>be caused by NAND issue or network virus / fishy? Appreciate any
> >> >> >>clues.
> >> >> > The first step is for us to understand what “missing” means?  Have
> >> >> > you
> >> >> > got any mechanism (U-Boot, SD card boot, etc.) that will allow you
> >> >> > to
> >> >> > mount and look at the contents of the NAND file system?
> >> >>
> >> >> Means that busybox was not there anymore, it mysteriously lost, all
> >> >> shell commands would no longer available. It cannot to run mount or
> >> >> any shell commands. There was two scenarios when that happened:
> >> >>
> >> >> - In the middle of running, the device all of certain could not run
> >> >> shell commands and failed mysteriously
> >> >>
> >> >> - During the u-boot booting kernel process, there were full errors of
> >> >> failing shell commands. Let me make it clear,  that booting error did
> >> >> not occur in the first or second kernel booting after the new image
> >> >> installation, it happened in the following kernel booting, but there
> >> >> was nothing to delete busybox accidentally, busybox was just
> >> >> mysteriously disappeared. Because I could not run ls, I did not know
> >> >> if there are other things missing. If you ask how I could know the
> >> >> busybox was missing, I ran the zImage-initramfs to boot the linux in
> >> >> RAM, then mount the ubi0 to find  out busybox was gone.
> >> >>
> >> >>
> >> >> > If you look at the /bin directory (ls -la /bin/busy*) what do you
> >> >> > see?
> >> >> > Have the files been deleted? Truncated? Zero length?
> >> >>
> >> >> Could not run ls or any shell commands when the busybox was missing.
> >> >>
> >> >
> >> > /bin/ls -la /bin/busy* ?
> >> >
> >> > Maybe something is messing with the PATH environment variable. Or
> >> > something is removing the symlinks from some binaries to busybox.
> >>
> >> No, could not run /bin/ls as it was  linked to  /bin/busybox.nosuid,
> >> the /bin/busybox.nosuid was damaged for some reason.
> >>
> >> >> > What file system are you using on the NAND flash?  How are the
> >> >> > devices
> >> >> > being reset during the various boot cycles?  If it is a hardware
> >> >> > reset
> >> >> > then some file systems are less resilient to it than others but I
> >> would
> >> >> > expect in that case more fundamental boot issues.
> >> >>
> >> >> UBIFS, most device reset or boot cycles were calling halt or reboot,
> >> >> but it sometime it could just use power cycle.
> >> >>
> >> >
> >> > IIRC, UBIFS is safe from power cycles.
> >>
> >> Good to know. Thank you.
> >>
> >> > Quentin
> >> >
> >> 
> >>
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48175): https://lists.yoctoproject.org/g/yocto/message/48175
Mute This Topic: https://lists.yoctoproject.org/mt/70128245/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to