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.

Writing kernel/fs partition from linux can damage another partition ?

Guru 20755 points

Hello,

I would like to ask a general question about flash partitions in linux.

Is it possible that writing flash parition of kernel or filesystem, can cause damage to the startup of u-boot ? (The startup of bootloader is related to another partition)

Regards,

Ran

  • Hi Ran,

    The damaging of kernel of file system flash partition should not be expected on a system with stable hardware and software when writing on the boot partition BUT:
    If the flash is initialized with unstable (different then recommended by manufacture) timings each operation in some moment could cause crash.
    If the hardware is correct the mount/unmount procedure is possible to damage the flash.

    BR
    Tsvetolin Shulev
  • In my understanding, it won't behave like that if you are partitioned the flash correctly.

    If its behaving like that, then please make sure that you are not overlapping the partitions with other one.

    If partition list is, u-boot -> Linux kernel -> rootfs -> secondary rootfs (backup)

    Always, leave some space after u-boot , so that we can make sure Linux kernel is not overlapped with u-boot.
    And also have some 2 to 3 copies of u-boot, if one copy is lost or corrupted, we can try to load other one (its possible if your RBL or UBL supports)

    Provide your flash partition list and offset & start address of each and every partition.
  • Hi Titus, Tsvetolin ,

    Thank you very much for the insights and comments.

    The question is related to issue we observed with dm365, in which some products after one time programming are than at some random time (can even be several months !) ,

    get stuck in boot (ubl) or u-boot.

    I am trying to have some understanding what can cause such behaviour. I know that ubl 1.5 had some flash related bug, which has caused it to calculate ecc wrong and get stuck.

    If I'm correct upgrading the ubl should fix this issue, I just wanted to be sure it there is no some other flash issue here, becuase this whole procedure is problematic, so I want to do it once and correct:

    This is the procedure I am intend to do:

    1. replace ubl with jtag

    2. testing that the issue is fixed - now here I have a problem: here is no way to do that because it is a random issue.....

    3. and then getting all products and flash program them with jtag ( the product only have ethernet connection without serial, so there is no way to update the items without jtag........)

    Thanks for your feedback,

    Ran

  • As you said, problem seems to be ECC issue.
    I have also faced the same problem in DM355 which is very similar to DM365.

    If uboot is not working then it might have chance of ECC issue in UBL source.
    If kernel is not booting and getting boot error then it might have chance of ECC issue in u-boot source.

    Please refer to the following e2e post.
    e2e.ti.com/.../236870