Nand replacement

duggy · Aug 31, 2015

Just noticed that patch is in the duo dir, i'm working with UNO so it might not be relevant anyway...

dpeddi · Sep 1, 2015

http://www.linuxquestions.org/quest...s]-vtbl_check-too-large-reserved_pebs-885385/
In case someone has the same problem... the solution is to...
Edit the Makefile that runs mkfs.ubifs so that it uses the right setting for the "-e" option, which is computed by this formula:

LEB_size = PEB_size - ((Subpage_size + Page_size)) / Page_size) * Page_size
(In the division, keep the integer part)

Also make sure you use the right setting for "-c" ("Amount of eraseblocks")In ubi.cfg, make sure you use a "vol_size" that's smaller than the actual size of the partition on the NAND to leave room for Ubifs internal data. With "vol_type=dynamic", Ubifs will end up using the whole space automatically

http://lists.infradead.org/pipermail/linux-mtd/2011-June/036338.html
Perhaps insufficiente to configured the right -e parameter. You should be near to success..

duggy · Sep 1, 2015

dpeddi said:
http://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/[ubifs]-vtbl_check-too-large-reserved_pebs-885385/
In case someone has the same problem... the solution is to...
Edit the Makefile that runs mkfs.ubifs so that it uses the right setting for the "-e" option, which is computed by this formula:

LEB_size = PEB_size - ((Subpage_size + Page_size)) / Page_size) * Page_size
(In the division, keep the integer part)

Also make sure you use the right setting for "-c" ("Amount of eraseblocks")In ubi.cfg, make sure you use a "vol_size" that's smaller than the actual size of the partition on the NAND to leave room for Ubifs internal data. With "vol_type=dynamic", Ubifs will end up using the whole space automatically

http://lists.infradead.org/pipermail/linux-mtd/2011-June/036338.html
Perhaps insufficiente to configured the right -e parameter. You should be near to success..

Thanks, i just reflashed the working arabic image so that i could telnet in a dump mtd info. going to see if based on the output i can figure this out, wish me luck

dev: size erasesize name
mtd0: 07200000 00080000 "rootfs"
mtd1: 00400000 00080000 "kernel"
mtd2: 00400000 00080000 "boot"
mtd3: 00200000 00080000 "splash"
mtd4: 00100000 00080000 "cfe"
mtd5: 00080000 00080000 "mac"
mtd6: 00080000 00080000 "env"
mtd7: 00100000 00080000 "nvm"

nanddump -p /dev/mtd1ro 2>&1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 524288, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00400000...
0x00000000: 1f 8b 08 08 cc 5b 94 4e 00 03 76 6d 6c 69 6e 75
......

Broadcom STB NAND controller (BrcmNand Controller)
i=0, CS[0] = 0
NAND_CS_NAND_XOR=00000001
Enable XOR on CS#0
brcmnand_probe: CS0: dev_id=01f1001d
After: NandSelect=40000101, nandConfig=15142200
NAND Config: Reg=35142200, chipSize=128 MB, blockSize=512K, erase_shift=13
busWidth=1, pageSize=2048B, page_shift=11, page_mask=000007ff
timing1 not adjusted: 5363444f
timing2 not adjusted: 00000fc6
BrcmNAND mfg 1 f1 SPANSION_S30ML01GP_08 128MB

Found NAND: ACC=f7ff1010, cfg=35142200, flashId=01f1001d, tim1=5363444f, tim2=00000fc6
BrcmNAND version = 0x0302 128MB @00000000
brcmnand_probe: CS0: dev_id=01f1001d
After: NandSelect=40000101, nandConfig=35142200
Found NAND chip on Chip Select 0, chipSize=128MB, usable size=128MB, base=0x
brcmnand_scan: B4 nand_select = 40000101
brcmnand_scan: After nand_select = 40000101
ACC_CONTROL for SLC NAND: f7ff1010, eccLevel=15
SLC flash: ACC_CONTROL = f7ff1010
page_shift=11, bbt_erase_shift=19, chip_shift=27, phys_erase_shift=19
Brcm NAND controller version = 3.2 NAND flash size 128MB @18000000
mtd->oobsize=64, mtd->eccOobSize=16
brcmnand_scan: mtd->oobsize=64
brcmnand_scan: oobavail=50, eccsize=512, writesize=2048
brcmnand_scan, eccsize=512, writesize=2048, eccsteps=4, ecclevel=15, eccbytes=3
brcmnand_default_bbt: bbt_td = bbt_main_descr
Bad block table found at page ff00, version 0x01
Bad block table found at page fe00, version 0x01
brcmnandCET: Not enough space to store CET, disabling CET
brcmnand_scan: CET not created
numchips=1, size=8000000
nandinfo->brcmnand.CS[0] = 0
bcm7XXX_nand_parts=80336f08, bcm7XXX_new_partition=80336bb8, bcm7XXX_old_partition=80336d50
numParts=8
Part[0] name=rootfs, size=7200000, offset=0
Part[1] name=kernel, size=400000, offset=7200000
Part[2] name=boot, size=400000, offset=7600000
Part[3] name=splash, size=200000, offset=7a00000
Part[4] name=cfe, size=100000, offset=7c00000
Part[5] name=mac, size=80000, offset=7d00000
Part[6] name=env, size=80000, offset=7d80000
Part[7] name=nvm, size=100000, offset=7e00000
Creating 8 MTD partitions on "bcm7xxx-nand.0":
0x0000000000000000-0x0000000007200000 : "rootfs"
0x0000000007200000-0x0000000007600000 : "kernel"
0x0000000007600000-0x0000000007a00000 : "boot"
0x0000000007a00000-0x0000000007c00000 : "splash"
0x0000000007c00000-0x0000000007d00000 : "cfe"
0x0000000007d00000-0x0000000007d80000 : "mac"
0x0000000007d80000-0x0000000007e00000 : "env"
0x0000000007e00000-0x0000000007f00000 : "nvm"

duggy · Sep 1, 2015

dpeddi said:
http://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/[ubifs]-vtbl_check-too-large-reserved_pebs-885385/
In case someone has the same problem... the solution is to...
Edit the Makefile that runs mkfs.ubifs so that it uses the right setting for the "-e" option, which is computed by this formula:

LEB_size = PEB_size - ((Subpage_size + Page_size)) / Page_size) * Page_size
(In the division, keep the integer part)

Also make sure you use the right setting for "-c" ("Amount of eraseblocks")In ubi.cfg, make sure you use a "vol_size" that's smaller than the actual size of the partition on the NAND to leave room for Ubifs internal data. With "vol_type=dynamic", Ubifs will end up using the whole space automatically

http://lists.infradead.org/pipermail/linux-mtd/2011-June/036338.html
Perhaps insufficiente to configured the right -e parameter. You should be near to success..

Hi i think I know the right values to use, but i cant find the file i need to edit/adjust. Can you tell me which file I need to use for the updated values?. I dont think there is a "mkfs.ubifs" in openvuplus environment ?

There are thousands of files so finding the right one to update is very hard

dpeddi · Sep 2, 2015

http://git.vuplus-community.net/?p=...3ffab048ee3475c0d01015f38800767241e02;hb=HEAD

dpeddi · Sep 2, 2015

However you should mtdinfo mtd0 (rootfs) and you should modify the eraseblock of previous bb file with the one you get from the working image. If speculation are correct, after new image build you should be able to boot your box.

duggy · Sep 3, 2015

At work now but when i get home i'll try this..... so excited! :thanks:

duggy · Sep 5, 2015

after lots and lots of compiling I'm still struggling

I was unable to find that fille in the openvuplus repo but i DID find it in the openvix repo.

So i cloned that and it wouldn't work because my paths were too long, I fixed that too and finally able to build an image but I cant finish the compile because of the PEB size issue

The image that boots has no mtd_info app

but here is contents of /proc/mtd

root@vuuno:~# cat /proc/mtd
dev: size erasesize name
mtd0: 07200000 00080000 "rootfs"
mtd1: 00400000 00080000 "kernel"
mtd2: 00400000 00080000 "boot"
mtd3: 00200000 00080000 "splash"
mtd4: 00100000 00080000 "cfe"
mtd5: 00080000 00080000 "mac"
mtd6: 00080000 00080000 "env"
mtd7: 00100000 00080000 "nvm"
root@vuuno:~# mtd_debug info /dev/mtd0
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_WRITEABLE
mtd.size = 119537664 (114M)
mtd.erasesize = 524288 (512K)
mtd.writesize = 2048 (2K)
mtd.oobsize = 64
regions = 0

Linux vuuno 2.6.18-7.3 #1 SMP Wed Jun 22 11:46:26 KST 2011 7405d0-smp GNU/Linux
root@vuuno:~# arch
-sh: arch: not found

Now I tried to make an image with 288 PEB as per output from latest image but the compile fails

ERROR: Error: The image creation script '/oe-alliance/builds/openvix/release/vuuno/tmp/work/vuuno-oe-linux/openvix-image/openvix-image-3.2-r20150905160443/temp/create_image.ubi' returned 255:
Error: max_leb_cnt too low (561 needed)

I searched internet for ANYONE with ANY system (just just a STB) with this nand and I found this (this is NOT my system, but it is useful to see info about this chip I fitted)

[ 1.880000] -----------------------------
[ 1.880000] NAND Flash Device Information
[ 1.880000] -----------------------------
[ 1.890000] Manufacturer : Spansion (0x01)
[ 1.890000] Device Code : 0xf1
[ 1.900000] Cell Technology : SLC
[ 1.900000] Chip Size : 128 MiB
[ 1.900000] Pages per Block : 64
[ 1.910000] Page Geometry : 2048+64
[ 1.910000] ECC Strength : 1 bits
[ 1.910000] ECC Size : 512 B
[ 1.920000] Data Setup Time : 20 ns
[ 1.920000] Data Hold Time : 10 ns
[ 1.930000] Address Setup Time: 10 ns
[ 1.930000] GPMI Sample Delay : 6 ns
[ 1.930000] tREA : 20 ns
[ 1.940000] tRLOH : 5 ns
[ 1.940000] tRHOH : 15 ns
[ 1.940000] Description : S34ML01G1
[ 1.950000] -----------------
[ 1.950000] Physical Geometry
[ 1.950000] -----------------
[ 1.960000] Chip Count : 1
[ 1.960000] Page Data Size in Bytes: 2048 (0x800)
[ 1.960000] Page OOB Size in Bytes : 64
[ 1.970000] Block Size in Bytes : 131072 (0x20000)
[ 1.970000] Block Size in Pages : 64 (0x40)
[ 1.980000] Chip Size in Bytes : 134217728 (0x8000000)
[ 1.980000] Chip Size in Pages : 65536 (0x10000)
[ 1.990000] Chip Size in Blocks : 1024 (0x400)
[ 1.990000] Medium Size in Bytes : 134217728 (0x8000000)
[ 2.240000] UBI: attaching mtd3 to ubi0
[ 2.250000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 2.250000] UBI: logical eraseblock size: 126976 bytes
[ 2.260000] UBI: smallest flash I/O unit: 2048
[ 2.260000] UBI: VID header offset: 2048 (aligned 2048)
[ 2.270000] UBI: data offset: 4096
[ 3.400000] UBI: attached mtd3 to ubi0
[ 3.410000] UBI: MTD device name: "gpmi-nfc-general-use"
[ 3.410000] UBI: MTD device size: 119 MiB
[ 3.420000] UBI: number of good PEBs: 951
[ 3.420000] UBI: number of bad PEBs: 1
[ 3.430000] UBI: max. allowed volumes: 128
[ 3.430000] UBI: wear-leveling threshold: 4096
[ 3.440000] UBI: number of internal volumes: 1
[ 3.440000] UBI: number of user volumes: 1
[ 3.450000] UBI: available PEBs: 21
[ 3.450000] UBI: total number of reserved PEBs: 930
[ 3.460000] UBI: number of PEBs reserved for bad PEB handling: 9
[ 3.460000] UBI: max/mean erase counter: 2/1
[ 3.470000] UBI: image sequence number: 0
[ 3.470000] UBI: background thread "ubi_bgt0d" started, PID 900

They have no PEB than me with the same chip, must be calulated based on values passed to mkubifs. So I am stuck now, cant make an image with "-c 288" as it wont compile

duggy · Sep 6, 2015

managed to run mtdinfo on the working original vu nfi.. here is output

root@vuuno:/tmp# ./mtdinfo -a
Count of MTD devices: 8
Present MTD devices: mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7
Sysfs interface supported: no

mtd0
Name: rootfs
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 228 (119537664 bytes, 114.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd1
Name: kernel
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 8 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd2
Name: boot
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 8 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd3
Name: splash
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 4 (2097152 bytes, 2.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd4
Name: cfe
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 2 (1048576 bytes, 1024.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd5
Name: mac
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 1 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd6
Name: env
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 1 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

mtd7
Name: nvm
Type: nand
Eraseblock size: 524288 bytes, 512.0 KiB
Amount of eraseblocks: 2 (1048576 bytes, 1024.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: unknown
OOB size: 64 bytes
Bad blocks are allowed: true
Device is writable: true

root@vuuno:/tmp#

duggy · Sep 6, 2015

HUGE UPDATE! (good news)...

I have almost a fully working system. I can make an image that boots fully, i can ssh in and everythingm problem is there is a background process that starts to clean up the nand, and that process breaks the box

Still this is a HUGE step forward

while the system is working (and before that background process messes up the nand) I got MTD info native on the box running ...

output from "mtdinfo -a" attached (mtd.txt)
dmesg attached (for more juicy info) ...lol

duggy · Sep 6, 2015

Time to edit message expire....anyway the final issue to resolve.. there is a repeated message I'm unsure how to resolve, this is the repeated block constantly on the serial console. Any ideas what its telling me?

brcmnand_handle_false_read_ecc_unc_errors: Uncorrectable error at offset 64ba800
Data:

0000: 31181006 10086160 30080100 00000000 00000000 00000000 c0200000 00000000
0020: 00000000 00000000 45000000 00000000 00000000 00000000 60726c44 00000000
0040: 21100004 00000000 20500000 00000000 00000000 00000000 00000000 00000000
0060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0100: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0120: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0140: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0180: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
01a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
01c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
01e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Spare Area
ffffffff ffff0568 0affffff ffffffff
brcmnand_post_mortem_dump at offset 64ba800
Call Trace:
[<805e8b0c>] dump_stack+0x8/0x34
[<803cc5c8>] brcmnand_post_mortem_dump+0x54/0x11c
[<803ccc50>] brcmnand_ctrl_posted_read_cache+0x548/0x92c
[<803c9e74>] brcmnand_read_page+0xe0/0x250
[<803cbf74>] brcmnand_do_read_ops+0xdc/0x278
[<803cc4e8>] brcmnand_read+0xc8/0x154
[<803a40b4>] part_read+0x60/0xcc
[<803a12b0>] mtd_read+0x7c/0xd4
[<803df77c>] ubi_io_read+0xe0/0x3ec
[<803dc834>] ubi_eba_read_leb+0x1b0/0x49c
[<803db548>] ubi_leb_read+0xd4/0x16c
[<8026e0dc>] ubifs_leb_read+0x34/0xac
[<8026ffd4>] ubifs_read_node+0xbc/0x2b8
[<80291764>] ubifs_tnc_read_node+0x5c/0x168
[<8027142c>] tnc_read_node_nm+0xdc/0x1f4
[<80275b30>] ubifs_tnc_next_ent+0x170/0x1cc
[<802671ac>] ubifs_readdir+0x3b8/0x500
[<800dc5e8>] vfs_readdir+0xa8/0xd8
[<800dcb6c>] sys_getdents64+0x70/0x124
[<8000e228>] stack_done+0x20/0x44

NAND registers snapshot

00002800: 00000302 01000000 00000000 1e4ba800
00002810: 00000000 40000101 00000001 00000000
00002820: ffffffff ffff0568 0affffff ffffffff
00002830: ffffffff ffffffff ffffffff ffffffff
00002840: f7ff1010 00000000 35142200 00000000
00002850: 5363444f 00000fc6 00000000 00000000
00002860: 01f1001d 01f1001d 00000000 f00000e0
00002870: 00000000 00000000 00000000 1e4ba800
00002880: 00000000 00000001 00000000 00000000
00002890: 00000000 1e4ba800 00000000 1e4bae00
000028a0: 00000000 00000000 00000000 1cd80000
000028b0: 00000000 1fc00010 00000000 00000000
000028c0: 00000000

duggy · Sep 6, 2015

actually maybe that background process is not the problem or the process that is going "bad", something else is? (notice free space cleanup completes)

UBI: background thread "ubi_bgt0d" started, PID 50
ata2: SATA link down (SStatus 4 SControl 300)
UBIFS: parse sync
UBIFS: background thread "ubifs_bgt0_0" started, PID 51
UBIFS: start fixing up free space
UBIFS: free space fixup complete

...

also errors always seem to happen in same upper range.

[user@server vu_uno]$ grep "brcmnand_handle_false_read_ecc_unc_errors" teraterm_working.txt |sort|uniq
brcmnand_handle_false_read_ecc_unc_errors: Uncorrectable error at offset 64ba800
brcmnand_handle_false_read_ecc_unc_errors: Uncorrectable error at offset 65a0000
brcmnand_handle_false_read_ecc_unc_errors: Uncorrectable error at offset 65ca000
brcmnand_handle_false_read_ecc_unc_errors: Uncorrectable error at offset 6620000
brcmnand_handle_false_read_ecc_unc_errors: Uncorrectable error at offset 663a800

duggy · Sep 15, 2015

Feast your eyes on this!

Ladies and gentlemen, the box is FULLY recovered and using the new Spansion nand

The problem is that the vu kernel is working out the eraseSize incorrectly. I've hacked the openvix code and hardcoded the right value in the src code. Its working great now

Maybe this will help someone in the future...

curt_nedim · Sep 16, 2015

Very big Respect i like you, but it's not just because you did it, it's because you don't gave up!
I know how it feels when you never did such H/W related things, after every little successes the next problem comes across.
I had big problem's and almost got crazy at a simpler thing, desoldering and reprogramming an EEPROM with a corrupt bootloader.. it was a total nightmare for me!
You have all rights to be proud on you

duggy · Sep 16, 2015

duggy said:
Ladies and gentlemen, the box is FULLY recovered and using the new Spansion nand

The problem is that the vu kernel is working out the eraseSize incorrectly. I've hacked the openvix code and hardcoded the right value in the src code. Its working great now

Maybe this will help someone in the future...

curt_nedim said:
Very big Respect i like you, but it's not just because you did it, it's because you don't gave up!
I know how it feels when you never did such H/W related things, after every little successes the next problem comes across.
I had big problem's and almost got crazy at a simpler thing, desoldering and reprogramming an EEPROM with a corrupt bootloader.. it was a total nightmare for me!
You have all rights to be proud on you

hahah yes. i didnt have the heart to throw away the box. Its not a new box, its not the latest box but I knew the faulty part was so cheap < 5 euro that it seemed crazy to throw the box away. Lots of learning, and lots of reading. Baby steps and a VERY BIG help on how to compile the Kernel in Linux from a helpful user on the openpli forum (betacentauri) who show'd me how i compile just the kernel (in the openvix build environment). I hacked the source for myself. Not pretty but it works

The problem is that the linux kernel from vu that gets pulled down as part of the oe-alliance build has a file that determines how to use the nand. I inittially went about this wrong trying to fix the openvix distro to work with 512K pages, until recently I decided that was the wrong way, the right way was to fix the linux kernel to detect the chip right. I'm not skilled enough to fix the source code correctly so did a dirty hack in the source code, it works fine so thats all that matters.

Had to also learn how to remove and fit a TSOP48, also had to learn about using BBS3 to program CFE to the blank chip. If ANYONE needs help doing any of this, I am here and happy to help and answer all questions

IF anyone has the same box and the same problem, you need to replace the samsung nand with spansion S34ML01G100TFI000. It cost me £12.77 delivered for 7 units (i only needed 1 but they don't sell singles). This is from RS if you in are the UK, their part number is 8096961

I also had to buy a hot air rework station, but you can probably do this with Just a soldering iron, but I wouldn't advise it.

You also need a cypress FX2LP board to talk to the broadcom SOC to program the CFE on the blank. chip , this is £4.50 on ebay

"EZ-USBFX2LPCY7C68013A-56 USB2.0 Develope Board Module Logic Analyzer EEPROM"

curt_nedim · Sep 16, 2015

Like a wise man said, "Everything is possible"
All the things you did and all the little pieces together are part of your your success..
It doesn't matter was it the "right" or "wrong" way you have chosen to follow!
At the end everything that forced you to nearly give up is on the other side the main thing that pushed you up and gave you more and more reasons to MAKE IT..

That's how I feel about such challenges and I'm pretty sure that @duggy feels the same

You solved yours, it's time that i solve mine.. Getting ready fight

Nand replacement

duggy

Vu+ Newbie

dpeddi

Administrator

duggy

Vu+ Newbie

duggy

Vu+ Newbie

dpeddi

Administrator

dpeddi

Administrator

duggy

Vu+ Newbie

duggy

Vu+ Newbie

Attachments

duggy

Vu+ Newbie

duggy

Vu+ Newbie

Attachments

duggy

Vu+ Newbie

duggy

Vu+ Newbie

duggy

Vu+ Newbie

curt_nedim

Vu+ Newbie

duggy

Vu+ Newbie

curt_nedim

Vu+ Newbie