• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: Problems reflashing UImage, bad blocks  (Read 7363 times)
Blazer
Newbie
*

Karma: 0
Posts: 21


View Profile
« on: April 13, 2009, 03:32:12 PM »

If anyone is interested, I posted pictures on my blog when I first received my unit: http://www.the-ownage.com/?p=830

I am currently having issues with mine, and GlobalScale has thusfar ignored my support request emails.

My issues started when I noticed that upon bootup, the boot partition was reporting lots of bad blocks, both seen on the console at boot-time and can also see in "dmesg". Now I know that bad blocks on NAND flash are not unheard of, and that in fact over time more and more blocks go bad and they are automatically marked bad, but I think its not right to have 20 bad blocks right out of the box. Seeing all the errors is annoying.

So, I had the dumb idea of using the "nandtest" binary on the partition in hopes that it would somehow clear the bad blocks or remap them elsewhere. Well it turns out it is a destructive test, so my root partition was erased.

No problem, I think, just use nandwrite and write the image back onto it....nope! Somehow my root partition is slightly too small for the image to fit!

So now I am stuck on booting it via NFS until I can figure out how to resize mtd paritions. Personally, due to the fact that I have been able to get zero dev work done due to dealing with this, and all the bad blocks, I would prefer an exchange for a new unit, but so far GlobalScale has not acknowledged any of the support questions I submitted, and it has been well over a week.

Code:
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00200000 00020000 "uImage"
mtd2: 1fd00000 00020000 "root"

# nandwrite -p /dev/mtd1 uImage.sheeva.20090319
Image 2106760 bytes, NAND page 2048 bytes, OOB area 2048 bytes, device size 2097152 bytes
Input file does not fit into device
Data was only partially written due to error

Does anyone know how to resize the mtd partitions, or build a smaller uImage image?
« Last Edit: April 13, 2009, 03:35:57 PM by Blazer » Logged

moshiach
Guest
« Reply #1 on: April 13, 2009, 04:21:39 PM »

Please see my posts in  this thread  Your mtdargs environment variable (or if you type in the bootargs by hand) should look like this with the included kernel.

mtdparts=nand_mtd:0x00100000@0x00000000(uBoot)ro,0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)
Logged

kilowatt
Global Moderator
Full Member
*****

Karma: 3
Posts: 106


View Profile
« Reply #2 on: April 13, 2009, 05:33:39 PM »

The problem you are having is the MTD1 partition is 2MB and your image is slightly larger than that.  You don't need to go all the way up to 5MB partition.  You should be able to just go up to 3MB.  I'm using 4MB since that is what almost all the documentation refers to.

In the mtdparts definition the first number is size and the second number is the starting location. So 0x00100000@0x00000000 is 1MB starting at 0.  The second partition should start at the end of the first one so 0x00300000@0x00100000 would give you 3MB or 0x00400000@0x00100000 would give you 4MB.  the third partition should start at the end of the second partition 0x00400000 if you have a 1Mb first partition plus a 3MB second partition or 0x00500000 of 1MB plus 4MB.  The size of the third partition should be 0x20000000 (512MB) minus the size of the first and second partition.  So 0x1fc00000 if the second partition is 3MB or 0x1fb00000 if the second partition is 4MB.

I use:

mtdparts=nand_mtd:0x00100000@0x00000000(uBoot)ro,0x00400000@0x00100000(uImage),0x1fb00000@0x00500000(rootfs)

Which gives me a 4 MB partition for the uImage.

Mark
« Last Edit: April 13, 2009, 05:37:39 PM by kilowatt » Logged

moshiach
Guest
« Reply #3 on: April 13, 2009, 07:09:11 PM »

I like nice round numbers Smiley  Makes it easy to convert in my head from hex to decimal.
Logged

Blazer
Newbie
*

Karma: 0
Posts: 21


View Profile
« Reply #4 on: April 13, 2009, 08:06:32 PM »

Thanks for your advice. I was able to boot NFS with the resized mtd partition (4MB) and reflash it. I am now booting from NAND again :-)

One question:
Code:
root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "uBoot"
mtd1: 00400000 00020000 "uImage"
mtd2: 1fb00000 00020000 "rootfs"

Is it normal for the "erasesize" to show as 2MB?

I also hate all these bad blocks I have on my flash...does anyone else have bad blocks?
Code:
NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 749 at 0x05da0000
Bad eraseblock 767 at 0x05fe0000
Bad eraseblock 827 at 0x06760000
Bad eraseblock 828 at 0x06780000
Bad eraseblock 829 at 0x067a0000
Bad eraseblock 1003 at 0x07d60000
Bad eraseblock 1130 at 0x08d40000
Bad eraseblock 1231 at 0x099e0000
Bad eraseblock 1269 at 0x09ea0000
Bad eraseblock 1462 at 0x0b6c0000
Bad eraseblock 1889 at 0x0ec20000
Bad eraseblock 2773 at 0x15aa0000
Bad eraseblock 3874 at 0x1e440000
Bad eraseblock 3939 at 0x1ec60000
Bad eraseblock 4057 at 0x1fb20000
Bad eraseblock 4061 at 0x1fba0000
Bad eraseblock 4062 at 0x1fbc0000
Bad eraseblock 4063 at 0x1fbe0000
Bad eraseblock 4095 at 0x1ffe0000

 * Loading hardware drivers...                                                  end_request: I/O error, dev mtdblock2, sector 1038208
Buffer I/O error on device mtdblock2, logical block 129776
end_request: I/O error, dev mtdblock2, sector 1038208
Buffer I/O error on device mtdblock2, logical block 129776
end_request: I/O error, dev mtdblock2, sector 1038320
Buffer I/O error on device mtdblock2, logical block 129790
end_request: I/O error, dev mtdblock2, sector 1038320
Buffer I/O error on device mtdblock2, logical block 129790
end_request: I/O error, dev mtdblock2, sector 1038328
Buffer I/O error on device mtdblock2, logical block 129791
end_request: I/O error, dev mtdblock2, sector 1038328
Buffer I/O error on device mtdblock2, logical block 129791
end_request: I/O error, dev mtdblock2, sector 1038328
Buffer I/O error on device mtdblock2, logical block 129791
end_request: I/O error, dev mtdblock2, sector 1038328
Buffer I/O error on device mtdblock2, logical block 129791
end_request: I/O error, dev mtdblock2, sector 1038328
Buffer I/O error on device mtdblock2, logical block 129791
end_request: I/O error, dev mtdblock2, sector 1038328
Buffer I/O error on device mtdblock2, logical block 129791
end_request: I/O error, dev mtdblock2, sector 1038328
end_request: I/O error, dev mtdblock2, sector 1038272
end_request: I/O error, dev mtdblock2, sector 1038320
end_request: I/O error, dev mtdblock2, sector 1038328
end_request: I/O error, dev mtdblock2, sector 1038328
end_request: I/O error, dev mtdblock0, sector 0
end_request: I/O error, dev mtdblock0, sector 8
end_request: I/O error, dev mtdblock0, sector 16
end_request: I/O error, dev mtdblock0, sector 24
end_request: I/O error, dev mtdblock0, sector 0
Logged

kilowatt
Global Moderator
Full Member
*****

Karma: 3
Posts: 106


View Profile
« Reply #5 on: April 13, 2009, 09:17:05 PM »

yes, I seem to have a bunch of them.  I have two Plugs and they both have bad blocks...  Strange.
Logged

finkployd
Newbie
*

Karma: 0
Posts: 4


View Profile
« Reply #6 on: April 14, 2009, 11:15:36 AM »

My plug also has a number of bad blocks as well:

Code:
NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 320 at 0x02800000
Bad eraseblock 2240 at 0x11800000
Bad eraseblock 2241 at 0x11820000
Bad eraseblock 2242 at 0x11840000
Bad eraseblock 2243 at 0x11860000
Bad eraseblock 2244 at 0x11880000
Bad eraseblock 2290 at 0x11e40000

 * Loading hardware drivers...                                                  end_request: I/O error, dev mtdblock0, sector 0
Buffer I/O error on device mtdblock0, logical block 0
end_request: I/O error, dev mtdblock0, sector 8
Buffer I/O error on device mtdblock0, logical block 1
end_request: I/O error, dev mtdblock0, sector 16
Buffer I/O error on device mtdblock0, logical block 2
end_request: I/O error, dev mtdblock0, sector 24
Buffer I/O error on device mtdblock0, logical block 3
end_request: I/O error, dev mtdblock0, sector 0
Buffer I/O error on device mtdblock0, logical block 0

My question is given these are on mtdblock0, if they keep growing wouldn't it eventually corrupt the uBoot image?  Oh and @Blazer, I noticed the erasesize as 2MB for mine as well:

Code:
root@sheeva:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "uBoot"
mtd1: 00400000 00020000 "uImage"
mtd2: 1fb00000 00020000 "rootfs"

Logged

tmk
Newbie
*

Karma: 1
Posts: 40


View Profile
« Reply #7 on: April 15, 2009, 10:10:31 PM »

bunch of bad blocks here as well.

Code:
Scanning device for bad blocks
Bad eraseblock 2050 at 0x10040000
Bad eraseblock 2051 at 0x10060000
Bad eraseblock 2061 at 0x101a0000
Bad eraseblock 2064 at 0x10200000
Bad eraseblock 2067 at 0x10260000
Bad eraseblock 2102 at 0x106c0000
Bad eraseblock 2151 at 0x10ce0000
Bad eraseblock 2202 at 0x11340000
Bad eraseblock 2726 at 0x154c0000

It seems to pause on boot, just after initalizing eth0. It seems like it's scanning the flash or something. Is this normal?

Code:
md: autorun ...
md: ... autorun DONE.
eth0: link up, full duplex, speed 100 Mbps
..... pause ~ 60 seconds .....
Empty flash at 0x0e2b2080 ends at 0x0e2b2800
VFS: Mounted root (jffs2 filesystem).
...

-tmk
Logged

KaiBo
Newbie
*

Karma: 0
Posts: 35



View Profile
« Reply #8 on: April 16, 2009, 06:52:49 AM »

It seems to pause on boot, just after initalizing eth0. It seems like it's scanning the flash or something. Is this normal?

Code:
md: autorun ...
md: ... autorun DONE.
eth0: link up, full duplex, speed 100 Mbps
..... pause ~ 60 seconds .....
Empty flash at 0x0e2b2080 ends at 0x0e2b2800
VFS: Mounted root (jffs2 filesystem).
...

-tmk
Mine does that as well.  For me it not only does this when booting but when doing other stuff as well - I notice it during heavy io-operations (from/to nand/usb/mmc).

Regarding the Bad Blocks: I have 19 of them in total. As long as they have been marked as such it shouldn't be a problem. Bad Blocks on Flash-Devices are, while not convenient, common and hence tolerated and handled accordingly. However, there should not be an increase of Bad Blocks.
Logged

tmk
Newbie
*

Karma: 1
Posts: 40


View Profile
« Reply #9 on: April 17, 2009, 11:28:39 PM »

note to those who may follow the instructions in this thread. I'm not sure that "nandwrite -p" is the right thing.

I accidentally fried my filesystem and needed to reflash the jffs2 image.


nandwrite -p did NOT work and in fact horked up the filesystem when flashing to /dev/mtd2. I rebooted and tried again without the -p flag. worked great.

-tmk
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #10 on: April 18, 2009, 09:21:01 AM »

It seems to pause on boot, just after initalizing eth0. It seems like it's scanning the flash or something. Is this normal?


Mine used to do that, I think it stopped when the kind people on this forum helped my correct the networking syntax I was supplying in bootargs:

console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)rw root=/dev/mmcblk0p1 rw ip=192.168.0.3:192.168.0.4:192.168.0.1:255.255.255.0:DB88FXX81:eth0:none

Before this, I had the gateway and the netmask the wrong way round.
Logged

dg
Newbie
*

Karma: 0
Posts: 14


View Profile
« Reply #11 on: April 18, 2009, 11:42:22 AM »

The occasional delay on boot is JFFS scanning the filesystem --- if it's not unmounted cleanly, it has to scan every block to see whether there's data in it. Which takes ages.

JFFS is unfortunately not a good choice for the SheevaPlug. It works very well, and it compresses data, but it doesn't scale to filesystems this big. YAFFS would be more appropriate. (JFFS also doesn't support writeable mmap(), which is why /var/cache/apt is a tmpfs volume; apt-get uses writeable mmap() to maintain its database.)
Logged

tschaboo
Newbie
*

Karma: 0
Posts: 15


View Profile
« Reply #12 on: June 07, 2009, 02:18:57 PM »

if it's not unmounted cleanly, it has to scan every block to see whether there's data in it. Which takes ages.

Jffs has to read in the whole flash even if the shutdown was clean. Since there's no defined point to look if it was unmounted cleanly (like a journal at a fixed position) that's the only way to find out if everything is okay. It's also stated here: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability
Logged

Pages: [1]
Print
Jump to: