This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/DRA726: Disk VFAT lost after a few crashes

Part Number: DRA726

Tool/software: Linux

Custom board with DRA726, using Industrial SDK 3.03 for test with customized u-boot and kernel linux based on those available in said SDK.

After a few crashes the device is no longer recognized and cannot be mounted. At first I thought that it was just unmountable because of the dirty bit.

It was not the case, it didn't even appear on the dev directory. Most of the time clearing the bit while on linux with fsck.vfat -a /dev/sdc1 would fix the problem but for one of the disk it was no luck. I formatted a Micro SD with ext4, copied the content of the failing disk and it worked.

The micro SD in question are Sandisk no 4 16GB devices formated FAT32 cost vary between $100 to $200 depending on quantity. It is unlikely that Navionics would agree to have their devices using ext4, we'll try but I think that they may charge extra for that.

Michel Catudal

ACTIA Corp

  • Hi Michel,

    The recommended but not mandatory filesystem for "boot" partition is FAT32 and ext4 for "rootfs". But if your board works properly with different filesystem types it is not a problem.
    Also are you test with different SD cards?

    BR
    Tsvetolin Shulev
  • That device is not for boot. In the particular situation the code is running of eMMC. The micro SD is used to read Navionics proprietary mapping information. It just turns out that the disk is not seen when the problem starts, it is not even seen as a dev. I connect it to the pc and it is recognized. The partition is set as FAT32 with no boot flag set.

    Michel

  • HI Michel,


      If the device is not shown in the "/dev" directory it usually means the device is not enumerated as expected and possibly hit an error ocndition while enumerating.

    1. Provide the full boot log of a failure case without any additional changes?

    2. Enable CONFIG_MMC_DEBUG in kernel config and share the logs for failure case.

    This will help us to uinderstand the issue better.

    Regards,

    RK