Ticket #419 (closed defect: fixed)
dfu download doesn't clean jffs2 partition
| Reported by: | mickey@… | Owned by: | laforge@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | u-boot | Version: | unspecified |
| Severity: | major | Keywords: | |
| Cc: | buglog@…, werner@…, hns@…, spamisevil@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
I have a jffs2 file that breaks completely (lots of errors during mount of
jffs2) when flashed using dfu-upload U-Boot 1652 while flashing the same file
using U-Boot 1364.
Change History
comment:1 Changed 6 years ago by mickey@…
- Summary changed from dfu upload broken in newer U-Boots to dfu download doesn't clean jffs2 partition
comment:3 Changed 6 years ago by alphaone@…
- Severity changed from normal to major
Upping the priority because this can lead to all kinds of strange errors from
panic on boot to erratic behavior on some of the apps.
comment:4 Changed 6 years ago by laforge@…
mh, when was this bug last observed? I haven't seen this bug reproduce on my
system[s] so far. Can you please elaborate on which u-boot version?
comment:5 Changed 6 years ago by alphaone@…
I just observed it on May 21st when I tried to flash a new rootfs. Behavior was
that ipkg configure didn't seem to run through on the first boot and so
/etc/gtk/gdk-pixbuf.loaders didn't exist which lead to a really ugly theme.
I flashed with
u-boot-gta01bv4-r7_70124c2602ae2d4c5d3dba05b482d91548242de8_0_1961.bin and later
also with u-boot-gta01bv4-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2041.bin.
After I executed "nand erase rootfs" on the bootloader the problems were gone.
comment:7 Changed 6 years ago by werner@…
I looked a few obvious causes (mis-alignment or off-by-one errors), but
nothing of that sort seems to be happening. Then I attempted to retrieve
the partition content before and after a download, just to find that I
was getting garbage. I've postponed this now until I've made myself better
tools. Will try again later this week.
comment:9 Changed 6 years ago by laforge@…
- Status changed from new to closed
- Resolution set to fixed
I seem to have finally found the bug in question.
The calculation for the size of the to-be-erased tail of the partiton was wrong.
So while in principle it worked, the last 0x2e4000 bytes (roughly 3MB) were
never erased.
So i suspect only people who ever ended up using all/most of the rootfs
partition and actually had non-0xff data in the last 3MB would see the problem.
Fixed in SVN rev. 2632
comment:10 Changed 6 years ago by alphaone@…
- Cc hns@… added
* Bug 719 has been marked as a duplicate of this bug. *
comment:11 Changed 6 years ago by spamisevil@…
- Cc spamisevil@… added
* Bug 726 has been marked as a duplicate of this bug. *
Changing the title of the bug, because after manually cleaning the jffs2 from
u-boot command line and reflashing the same file it worked.
So it looks like dfu download doesn't clean the jffs2 partition, hence it only
works if you write a jffs2 file that's larger than the previous one.