Welcome! Log In Create A New Profile

Advanced

edit mtd from debian pogoplug pro oxnas

Posted by jay 
jay
edit mtd from debian pogoplug pro oxnas
May 11, 2016 10:33PM
hi,
is there a list of packages/instructions to mount the original pogoplug pro flash from debian?

jay
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 01:46AM
jay
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 12:24PM
hi,
i want to use the stock firmware as a rescue system...

jay
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 02:13PM
jay,

I could not find in my logs. So I'll have to write new ones and try it on my V3.

In the mean time, you should get these info in Debian:

uname -a
cat /proc/cmdline
cat /proc/mtd
ls -l /dev/mtd*
dmesg | grep '"'

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
jay
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 02:36PM
hi,
i already installed the mtd-tools and already have mtd0, mtd0ro and mtdblock0 in dev, same fpr mtd1
and the mtd structure is the same as in stock.
i also can boot the stock fw already.
i just want to edit some settings and scripts...

so i only want to mount mtd1 (and maybe 0) in debian...

it seems that debian not knows the jffs2, or the pogo fs isnt...

jay

ps:
root@debian:/# uname -a
Linux debian 3.17.0-oxnas-tld-1 #1 SMP PREEMPT Sat Oct 25 15:59:43 PDT 2014 armv6l GNU/Linux
root@debian:/# cat /proc/cmdline
console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=41000000.nand:14m(boot),-(data)
root@debian:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00e00000 00020000 "boot"
mtd1: 07200000 00020000 "data"
root@debian:/# ls -l /dev/mtd*
crw------- 1 root root 90, 0 Dec 31 1969 /dev/mtd0
crw------- 1 root root 90, 1 Dec 31 1969 /dev/mtd0ro
crw------- 1 root root 90, 2 Dec 31 1969 /dev/mtd1
crw------- 1 root root 90, 3 Dec 31 1969 /dev/mtd1ro
brw-rw---- 1 root disk 31, 0 Dec 31 1969 /dev/mtdblock0
brw-rw---- 1 root disk 31, 1 Dec 31 1969 /dev/mtdblock1
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 04:33PM
jay,

So you are familiar with this, then should try ubifs

mkdir /tmp/pogoroot
mknod /dev/mtdblock1 b 31 1
mount -t ubifs -o ro /dev/mtdblock1 /tmp/pogoroot/

And keep it RO until you are sure it looks ok. Warning: make a backup with nanddump first before mounting RW (emphasis: even just mounting alone could screw up the file system)

Another warning: fs systems setting could be different between stock u-boot and latest Debian. So modifying it in Debian sometimes causes problem booting stock later.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner



Edited 1 time(s). Last edit at 05/12/2016 04:37PM by bodhi.
jay
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 05:39PM
hi bodhi,

> So you are familiar with this, then should try
> ubifs

just rudimentary...

ubifs sounds good, but:

UBIFS error (pid 1150): ubifs_mount: cannot open "/dev/mtdblock1", error -22

> And keep it RO until you are sure it looks ok.
> Warning: make a backup with nanddump first
> before mounting RW (emphasis: even
> just mounting alone could screw up the file
> system)
>
> Another warning: fs systems setting could be
> different between stock u-boot and latest Debian.
> So modifying it in Debian sometimes causes problem
> booting stock later.

thanks for warnings. so maybe its better to see this as a dead end?

jay
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 06:54PM
jay Wrote:
-------------------------------------------------------
> hi bodhi,
>
> > So you are familiar with this, then should try
> > ubifs
>
> just rudimentary...
>
> ubifs sounds good, but:
>
> UBIFS error (pid 1150): ubifs_mount: cannot open
> "/dev/mtdblock1", error -22
>
> > And keep it RO until you are sure it looks ok.
> > Warning: make a backup with nanddump first
> > before mounting RW (emphasis:
> even
> > just mounting alone could screw up the file
> > system)
> >
> > Another warning: fs systems setting could be
> > different between stock u-boot and latest
> Debian.
> > So modifying it in Debian sometimes causes
> problem
> > booting stock later.
>
> thanks for warnings. so maybe its better to see
> this as a dead end?
>
> jay

Not a dead end. Either you connect serial console and log in, or I or somebody upload their nand roofs for you. I think Leggo did it for us. Let me check my PM.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
May 12, 2016 10:14PM
> Not a dead end. Either you connect serial console
> and log in, or I or somebody upload their nand
> roofs for you. I think Leggo did it for us. Let me
> check my PM.

No, the backup from Leggo was only for u-boot. Not sure if I saved the original NAND rootfs somewhere. Will have to look.

Worse case, I'll nanddump it and provide it as a modded OS image for rescue. Let's wait a couple days to see anybody has the orginal to upload.

Anybody has the original stock OS rootfs mtd backup?

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Dretechnl
Re: edit mtd from debian pogoplug pro oxnas
June 12, 2016 07:12AM
I am also interested in the nand en rootfs for the pogplug pro.
Re: edit mtd from debian pogoplug pro oxnas
June 12, 2016 07:07PM
bodhi Wrote:
-------------------------------------------------------

>
> Anybody has the original stock OS rootfs mtd
> backup?


How to retrieve from stock plug and stock cli? Please provide instructions.

LeggoMyEggo's Google Plus Profile
Re: edit mtd from debian pogoplug pro oxnas
June 12, 2016 10:58PM
Verify the MTD definition which should indicate that the mtd1 is the rootfs (in pure stock, the rootfs is defined as mtd2, but we simplified it during new u-boot installation to have only 2 MTD partitions).

~ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00e00000 00020000 "boot"
mtd1: 07200000 00020000 "rootfs"

Then dump the rootfs
nanddump --noecc --omitoob -f mtd1.stock_pogo_v3_rootfs  /dev/mtd1

The NAND rootfs file mtd1.stock_pogo_v3_rootfs should be 114M in size.

NOTE: if you have logged in to the stock OS before: before dumping NAND, be sure to reset its root password back to "root" if it was changed during that time.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
June 14, 2016 08:45PM
Where am I dumping the file to, an attached USB flash drive? That's the part (no pun intended) I don't understand. If FD, should it be ext3 partition or is FAT ok?

LeggoMyEggo's Google Plus Profile
Re: edit mtd from debian pogoplug pro oxnas
June 14, 2016 09:08PM
LeggoMyEggo Wrote:
-------------------------------------------------------
> Where am I dumping the file to, an attached USB
> flash drive? That's the part (no pun intended) I
> don't understand. If FD, should it be ext3
> partition or is FAT ok?


Any disk would be fine. nanddump outputs a binary file so Linux does not care.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
June 14, 2016 09:31PM
bodhi Wrote:
-------------------------------------------------------
> Any disk would be fine. nanddump outputs a binary
> file so Linux does not care.

I see why I was confused. You are assuming doing the nand dump from within a running bodhi Debian rootfs which runs off a USB drive which has plenty of space to dump the file to. I was assuming doing the dump from the stock Cloud Engines command line using serial console and (obviously) needing external storage to dump the file to.

So provided I followed your instructions verbatim for loading your u-boot, the stock rootfs should still exist in mtd1 and I should be able to create the file using your instructions above? Is it that simple?

Sorry for my mild case of mental disability as it relates to this en devour.................

LeggoMyEggo's Google Plus Profile
Re: edit mtd from debian pogoplug pro oxnas
June 14, 2016 09:42PM
LeggoMyEggo Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > Any disk would be fine. nanddump outputs a
> binary
> > file so Linux does not care.
>
> I see why I was confused. You are assuming doing
> the nand dump from within a running bodhi Debian
> rootfs which runs off a USB drive which has plenty
> of space to dump the file to. I was assuming
> doing the dump from the stock Cloud Engines
> command line using serial console and (obviously)
> needing external storage to dump the file to.
>
> So provided I followed your instructions verbatim
> for loading your u-boot, the stock rootfs should
> still exist in mtd1 and I should be able to create
> the file using your instructions above? Is it
> that simple?
>
> Sorry for my mild case of mental disability as it
> relates to this en devour.................

:)) I see. Yes, I was thinking Debian. But if you are dumping from stock then, yes mount a USB drive with Ext3 to dump it to.

Also, mtd1 is never touched by flashing u-boot, so it would be intact in Debian as a raw MTD partition. So I would dump it in Debian, much simpler.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner



Edited 2 time(s). Last edit at 06/14/2016 09:46PM by bodhi.
Re: edit mtd from debian pogoplug pro oxnas
June 28, 2016 01:42AM
Re: edit mtd from debian pogoplug pro oxnas
January 31, 2017 03:53PM
Thanks LeggoMyEggo & bodhi for the stock root image!

I received a mis-flashed pogoplug pro recently (i think mtd0 and mtd1 went through a flasherase). It can't boot on its own but works from sata. So i started to reflash mtd0 following http://forum.doozan.com/read.php?3,16017 (this went fine)

now i tried to reflash mtd1 with the above image with nandwrite -n /dev/mtd1 mtd1.stock_pogo_v3_rootfs and it works fine, but on reboot i receive a lots of ECC errors, even if i boot from sata.

If i erase /dev/mtd1 then sata boot is fine (no errors).

Is the above way is the correct way to flash mtd1? Is there any other file to flash?

[    1.570572] ubi0: attaching mtd1                                            
[    1.574266] ubi0: fixable bit-flip detected at PEB 0                        
[    1.579325] ubi0 warning: scan_peb: valid VID header but corrupted EC header
 at PEB 0                                                                      
[    1.587335] ubi0: fixable bit-flip detected at PEB 1                        
[    1.592491] ubi0 warning: scan_peb: valid VID header but corrupted EC header
 at PEB 1                                                                      
[    1.600453] ubi0: fixable bit-flip detected at PEB 2                        
[    1.605570] ubi0: fixable bit-flip detected at PEB 3                        
[    1.610695] __nand_correct_data: uncorrectable ECC error                    
[    1.615997] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 3:512, read only 512 bytes, retry                            
[    1.627601] __nand_correct_data: uncorrectable ECC error                    
[    1.633146] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 3:512, read only 512 bytes, retry                            
[    1.644730] __nand_correct_data: uncorrectable ECC error                    
[    1.650055] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 3:512, read only 512 bytes, retry                            
[    1.661611] __nand_correct_data: uncorrectable ECC error                    
[    1.666908] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 512
 bytes from PEB 3:512, read 512 bytes                                          
[    1.677153] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.38-oxnas-tld-5 #1 
[    1.680158] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)          
[    1.690219] Hardware name: PLXTECH NAS782X SoC (Flattened Device Tree)      
[    1.696742] [<c0010c4c>] (unwind_backtrace) from [<c000cf70>] (show_stack+0x
10/0x14)                                                                       
[    1.704468] [<c000cf70>] (show_stack) from [<c02cef00>] (dump_stack+0x84/0xa
0)                                                                             
[    1.711672] [<c02cef00>] (dump_stack) from [<c03ace78>] (ubi_io_read+0x118/0
x2f4)                                                                          
[    1.719129] [<c03ace78>] (ubi_io_read) from [<c03ad4c4>] (ubi_io_read_vid_hd
r+0x48/0x234)                                                                  
[    1.727275] [<c03ad4c4>] (ubi_io_read_vid_hdr) from [<c03b1f00>] (ubi_attach
+0x184/0x1578)                                                                 
[    1.735508] [<c03b1f00>] (ubi_attach) from [<c03a6ed0>] (ubi_attach_mtd_dev+
0x5e8/0xb70)                                                                   
[    1.743572] [<c03a6ed0>] (ubi_attach_mtd_dev) from [<c0829a48>] (ubi_init+0x
1b0/0x288)                                                                     
[    1.751462] [<c0829a48>] (ubi_init) from [<c00097a4>] (do_one_initcall+0x80/
0x1dc)                                                                         
[    1.759004] [<c00097a4>] (do_one_initcall) from [<c080fd88>] (kernel_init_fr
eeable+0x11c/0x1e4)                                                            
[    1.767677] [<c080fd88>] (kernel_init_freeable) from [<c0603728>] (kernel_in
it+0x8/0xec)                                                                   
[    1.775744] [<c0603728>] (kernel_init) from [<c000a508>] (ret_from_fork+0x14
/0x2c)                                                                         
[    1.783534] ubi0 warning: scan_peb: valid VID header but corrupted EC header
 at PEB 3                                                                      
[    1.783623] ata1.00: ATA-8: INTEL SSDSA2BW160G3L, 4PC10302, max UDMA/133    
[    1.783636] ata1.00: 312581808 sectors, multi 1: LBA48 NCQ (depth 0/32)     
[    1.804805] ata1.00: configured for UDMA/133                                
[    1.805061] ubi0: fixable bit-flip detected at PEB 4                        
[    1.805173] ubi0: fixable bit-flip detected at PEB 4                        
[    1.805255] ubi0: fixable bit-flip detected at PEB 5                        
[    1.805432] ubi0: fixable bit-flip detected at PEB 6                        
[    1.805606] ubi0: fixable bit-flip detected at PEB 7                        
[    1.805783] ubi0: fixable bit-flip detected at PEB 8                        
[    1.805957] ubi0: fixable bit-flip detected at PEB 9                        
[    1.806133] ubi0: fixable bit-flip detected at PEB 10                       
[    1.806238] ubi0: fixable bit-flip detected at PEB 10                       
[    1.806318] ubi0: fixable bit-flip detected at PEB 11                       
[    1.806494] ubi0: fixable bit-flip detected at PEB 12                       
[    1.806671] ubi0: fixable bit-flip detected at PEB 13                       
[    1.806776] __nand_correct_data: uncorrectable ECC error                    
[    1.806789] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 13:512, read only 512 bytes, retry                           
[    1.806906] __nand_correct_data: uncorrectable ECC error                    
[    1.806919] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 13:512, read only 512 bytes, retry                           
[    1.807029] __nand_correct_data: uncorrectable ECC error                    
[    1.807042] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 13:512, read only 512 bytes, retry                           
[    1.807150] __nand_correct_data: uncorrectable ECC error                    
[    1.807162] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 512
 bytes from PEB 13:512, read 512 bytes                                         
[    1.807175] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.38-oxnas-tld-5 #1 
[    1.807180] Hardware name: PLXTECH NAS782X SoC (Flattened Device Tree)      
[    1.807211] [<c0010c4c>] (unwind_backtrace) from [<c000cf70>] (show_stack+0x
10/0x14)                                                                       
[    1.807232] [<c000cf70>] (show_stack) from [<c02cef00>] (dump_stack+0x84/0xa
0)                                                                             
[    1.807255] [<c02cef00>] (dump_stack) from [<c03ace78>] (ubi_io_read+0x118/0
x2f4)                                                                          
[    1.807272] [<c03ace78>] (ubi_io_read) from [<c03ad4c4>] (ubi_io_read_vid_hd
r+0x48/0x234)                                                                  
[    1.807290] [<c03ad4c4>] (ubi_io_read_vid_hdr) from [<c03b1f00>] (ubi_attach
+0x184/0x1578)                                                                 
[    1.807306] [<c03b1f00>] (ubi_attach) from [<c03a6ed0>] (ubi_attach_mtd_dev+
0x5e8/0xb70)                                                                   
[    1.807326] [<c03a6ed0>] (ubi_attach_mtd_dev) from [<c0829a48>] (ubi_init+0x
1b0/0x288)                                                                     
[    1.807344] [<c0829a48>] (ubi_init) from [<c00097a4>] (do_one_initcall+0x80/
0x1dc)                                                                         
[    1.807360] [<c00097a4>] (do_one_initcall) from [<c080fd88>] (kernel_init_fr
eeable+0x11c/0x1e4)                                                            
[    1.807383] [<c080fd88>] (kernel_init_freeable) from [<c0603728>] (kernel_in
it+0x8/0xec)                                                                   
[    1.807400] [<c0603728>] (kernel_init) from [<c000a508>] (ret_from_fork+0x14
/0x2c)                                                                         
[    1.807416] ubi0 warning: scan_peb: valid VID header but corrupted EC header
 at PEB 13                                                                     
[    1.807498] ubi0: fixable bit-flip detected at PEB 14                       
[    1.807605] ubi0: fixable bit-flip detected at PEB 14                       
[    1.807682] ubi0: fixable bit-flip detected at PEB 15                       
[    1.807790] ubi0: fixable bit-flip detected at PEB 15                       
[    1.807866] ubi0: fixable bit-flip detected at PEB 16                       
[    1.807969] __nand_correct_data: uncorrectable ECC error                    
[    1.807982] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 16:512, read only 512 bytes, retry                           
[    1.808094] __nand_correct_data: uncorrectable ECC error                    
[    1.808110] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 16:512, read only 512 bytes, retry                           
[    1.808217] __nand_correct_data: uncorrectable ECC error                    
[    1.808230] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 5
12 bytes from PEB 16:512, read only 512 bytes, retry                           
[    1.808340] __nand_correct_data: uncorrectable ECC error                    
[    1.808353] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 512
 bytes from PEB 16:512, read 512 bytes 
Re: edit mtd from debian pogoplug pro oxnas
January 31, 2017 05:34PM
schnee,

Quote

now i tried to reflash mtd1 with the above image with nandwrite -n /dev/mtd1 mtd1.stock_pogo_v3_rootfs and it works fine, but on reboot i receive a lots of ECC errors, even if i boot from sata.

Does this mean the flashing works fine, or boot fine?


The error could be that:

1. The rootfs tarball is bad
2. The kernel does not recognize the UBI form version in this rootfs. This could be due to a mismatch in the driver versions (one used in create, one from the kernel you are running).

And you did not show how you flashed the mtd1 rootfs, so I can't know for sure.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
February 01, 2017 03:20PM
Quote

bodhi Wrote:
-------------------------------------------------------
> Does this mean the flashing works fine, or boot fine?
nandwrite finished without errors. It still can't boot from the flash, but boots from the sata drive, but spams with the mtd1 ecc errors and ubi erros


Quote

>
>
> The error could be that:
>
> 1. The rootfs tarball is bad
Which rootfs tarball? The one shared by LeggoMyEggo?

I have an other pogoplug around, which afaik still have an original rootfs in flash. What is the correct way to back it up with nanddump?

Quote

> 2. The kernel does not recognize the UBI form version in this rootfs. This could be due to a mismatch in the driver versions (one used in create, one from the kernel you are running).
>
> And you did not show how you flashed the mtd1 root fs, so I can't know for sure.

used:
flash_erase /dev/mtd1 0 912
nandwrite -n /dev/mtd1 ./mtd1.stock_pogo_v3_rootfs
Re: edit mtd from debian pogoplug pro oxnas
February 01, 2017 03:35PM
schnee,

> Which rootfs tarball? The one shared by LeggoMyEgg
> o?

That one. But I am sure that it is good. LeggoMyEggo did a good job of dumping it.

> flash_erase /dev/mtd1 0 912
> nandwrite -n /dev/mtd1 ./mtd1.stock_pogo_v3_rootfs

Note the original nanddump used by Leggo was:
nanddump --noecc --omitoob -f mtd1.stock_pogo_v3_rootfs  /dev/mtd1

When you write it back, make sure the options match. Don't rely on the default, unless it does not provide the explicit option. So it should be

nandwrite  --noecc /dev/mtd1 ./mtd1.stock_pogo_v3_rootfs

In any case, if you have access to an orginal mtd1 already then you can use the above 2 commands to dump and restore.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
February 01, 2017 04:28PM
afaik nandwrite -n /dev/mtd1 ./mtd1.stock_pogo_v3_rootfs is the same as nandwrite --noecc /dev/mtd1 ./mtd1.stock_pogo_v3_rootfs

root@schnee:~/tools# cat /proc/mtd                                              
dev:    size   erasesize  name                                                  
mtd0: 00e00000 00020000 "boot"                                                  
mtd1: 07200000 00020000 "data"


Here is the output of the nandwrite command:
root@schnee:~/tools# ./nandwrite --noecc /dev/mtd1 ./mtd1.stock_pogo_v3_rootfs  
Writing data to block 0 at offset 0x0                                           
Writing data to block 1 at offset 0x20000                                       
Writing data to block 2 at offset 0x40000                                       
Writing data to block 3 at offset 0x60000                                       
Writing data to block 4 at offset 0x80000                                       
Writing data to block 5 at offset 0xa0000                                       
Writing data to block 6 at offset 0xc0000                                       
Writing data to block 7 at offset 0xe0000                                       
Writing data to block 8 at offset 0x100000                                      
Writing data to block 9 at offset 0x120000                                      
Writing data to block 10 at offset 0x140000                                     
Writing data to block 11 at offset 0x160000                                     
Writing data to block 12 at offset 0x180000                                     
Writing data to block 13 at offset 0x1a0000

....

Writing data to block 899 at offset 0x7060000                                   
Writing data to block 900 at offset 0x7080000                                   
Writing data to block 901 at offset 0x70a0000                                   
Writing data to block 902 at offset 0x70c0000                                   
Writing data to block 903 at offset 0x70e0000                                   
Writing data to block 904 at offset 0x7100000                                   
Writing data to block 905 at offset 0x7120000                                   
Writing data to block 906 at offset 0x7140000                                   
Writing data to block 907 at offset 0x7160000                                   
Writing data to block 908 at offset 0x7180000                                   
Writing data to block 909 at offset 0x71a0000                                   
Writing data to block 910 at offset 0x71c0000                                   
Writing data to block 911 at offset 0x71e0000                                   
root@schnee:~/tools#

after reboot the boot log is full with ECC errors again

[    1.835545] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 108:0, read 64 bytes
[    1.835555] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.38-oxnas-tld-5 #1
[    1.835560] Hardware name: PLXTECH NAS782X SoC (Flattened Device Tree)
[    1.835581] [<c0010c4c>] (unwind_backtrace) from [<c000cf70>] (show_stack+0x10/0x14)
[    1.835596] [<c000cf70>] (show_stack) from [<c02cef00>] (dump_stack+0x84/0xa0)
[    1.835612] [<c02cef00>] (dump_stack) from [<c03ace78>] (ubi_io_read+0x118/0x2f4)
[    1.835630] [<c03ace78>] (ubi_io_read) from [<c03ad284>] (ubi_io_read_ec_hdr+0x44/0x23c)
[    1.835645] [<c03ad284>] (ubi_io_read_ec_hdr) from [<c03b1eac>] (ubi_attach+0x130/0x1578)
[    1.835660] [<c03b1eac>] (ubi_attach) from [<c03a6ed0>] (ubi_attach_mtd_dev+0x5e8/0xb70)
[    1.835676] [<c03a6ed0>] (ubi_attach_mtd_dev) from [<c0829a48>] (ubi_init+0x1b0/0x288)
[    1.835691] [<c0829a48>] (ubi_init) from [<c00097a4>] (do_one_initcall+0x80/0x1dc)
[    1.835706] [<c00097a4>] (do_one_initcall) from [<c080fd88>] (kernel_init_freeable+0x11c/0x1e4)
[    1.835724] [<c080fd88>] (kernel_init_freeable) from [<c0603728>] (kernel_init+0x8/0xec)
[    1.835740] [<c0603728>] (kernel_init) from [<c000a508>] (ret_from_fork+0x14/0x2c)
[    1.835852] ubi0: fixable bit-flip detected at PEB 108
[    1.835929] ubi0: fixable bit-flip detected at PEB 109
[    1.836037] ubi0: fixable bit-flip detected at PEB 109
[    1.836113] ubi0: fixable bit-flip detected at PEB 110
[    1.836218] __nand_correct_data: uncorrectable ECC error
[    1.836231] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 110:512, read only 512 bytes, retry
[    1.836344] __nand_correct_data: uncorrectable ECC error
[    1.836357] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 110:512, read only 512 bytes, retry
[    1.836464] __nand_correct_data: uncorrectable ECC error
[    1.836477] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 110:512, read only 512 bytes, retry
[    1.836587] __nand_correct_data: uncorrectable ECC error
[    1.836600] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 110:512, read 512 bytes
[    1.836608] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.38-oxnas-tld-5 #1
[    1.836613] Hardware name: PLXTECH NAS782X SoC (Flattened Device Tree)
[    1.836633] [<c0010c4c>] (unwind_backtrace) from [<c000cf70>] (show_stack+0x10/0x14)
[    1.836648] [<c000cf70>] (show_stack) from [<c02cef00>] (dump_stack+0x84/0xa0)
[    1.836666] [<c02cef00>] (dump_stack) from [<c03ace78>] (ubi_io_read+0x118/0x2f4)
[    1.836682] [<c03ace78>] (ubi_io_read) from [<c03ad4c4>] (ubi_io_read_vid_hdr+0x48/0x234)
[    1.836700] [<c03ad4c4>] (ubi_io_read_vid_hdr) from [<c03b1f00>] (ubi_attach+0x184/0x1578)
[    1.836715] [<c03b1f00>] (ubi_attach) from [<c03a6ed0>] (ubi_attach_mtd_dev+0x5e8/0xb70)
[    1.836730] [<c03a6ed0>] (ubi_attach_mtd_dev) from [<c0829a48>] (ubi_init+0x1b0/0x288)
[    1.836748] [<c0829a48>] (ubi_init) from [<c00097a4>] (do_one_initcall+0x80/0x1dc)
[    1.836764] [<c00097a4>] (do_one_initcall) from [<c080fd88>] (kernel_init_freeable+0x11c/0x1e4)
[    1.836782] [<c080fd88>] (kernel_init_freeable) from [<c0603728>] (kernel_init+0x8/0xec)
[    1.836797] [<c0603728>] (kernel_init) from [<c000a508>] (ret_from_fork+0x14/0x2c)
[    1.836810] ubi0 warning: scan_peb: valid VID header but corrupted EC header at PEB 110
[    1.836820] ubi0 error: ubi_add_to_av: two LEBs with same sequence number 2
[    1.836823] eraseblock attaching information dump:
[    1.836828]  ec       -1
[    1.836830]  pnum     1
[    1.836833]  lnum     1
[    1.836838]  scrub    1
[    1.836840]  sqnum    2
[    1.836846] Volume identifier header dump:
[    1.836848]  magic     55424921
[    1.836853]  version   1
[    1.836856]  vol_type  1
[    1.836858]  copy_flag 0
[    1.836864]  compat    5
[    1.836869]  vol_id    2147479551
[    1.836871]  lnum      1
[    1.836876]  data_size 0
[    1.836879]  used_ebs  0
[    1.836884]  data_pad  0
[    1.836887]  sqnum     2
[    1.836892]  hdr_crc   7beff9af
[    1.836894] Volume identifier header hexdump:
[    1.837207] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22


Will try to dump the mtd0 from my other pogo tomorrow probably, but tbh i expect the same result
Re: edit mtd from debian pogoplug pro oxnas
February 01, 2017 05:19PM
Hi schnee,

>
> Will try to dump the mtd0 from my other pogo tomor
> row probably, but tbh i expect the same result

You meant mtd1?


These errors would go away if the new kernel is not trying to read the mtd1. So if you post output of fw_printenv here, I could show you how set it so that the kernel does not try reading it. I also need to see the entire dmesg output, too.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
February 02, 2017 12:16PM
bodhi Wrote:
-------------------------------------------------------
> Hi schnee,
>
> >
> > Will try to dump the mtd0 from my other pogo tom
> or
> > row probably, but tbh i expect the same result
>
> You meant mtd1?
>
Hi bodhi!

yes i meant mtd1

Attached the complete boot log to the message (pogoBoot.log)

printenv.log has the uboot variables.

Thanks
Attachments:
open | download - pogoBoot.log (144.8 KB)
open | download - printenv.log (2 KB)
Re: edit mtd from debian pogoplug pro oxnas
February 02, 2017 01:43PM
schnee,

I see. The problem is you did not set the bootargs env explicitly. You are relying on the internal bootargs. That's not a very good approach. Because you had to partition your disk the way this bootargs specifies where your rootfs is (i.e. /dev/sda2). If you define the bootargs in the envs, then the rootfs partition could be any where you want it to be. You can use the lable rootfs for that partition and kernel will mount it correctly.

setenv bootargs 'console=ttyS0,115200n8 root=LABEL=rootfs rootfstype=ext4'

The problem with the UBI error is most likely because the argument ubi.mtd=data,512. So remove that as the setenv bootargs above shown.
[    0.000000] Kernel command line: console=ttyS0,115200n8 root=/dev/sda2 rootfstype=ext4 ubi.mtd=data,512

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
February 02, 2017 03:18PM
bodhi Wrote:
-------------------------------------------------------

>
>
> setenv bootargs 'console=ttyS0,115200n8 root=LABEL
> =rootfs rootfstype=ext4'
>
>

Tried your suggestion but it did not work. Boot started but ended with kernel panic. See attached log.

Filesystem labels look good:
root@xxxxxx:~# ls -l /dev/disk/by-label
total 0
drwxr-xr-x 2 root root 100 Jan  1  1970 .
drwxr-xr-x 6 root root 120 Jan  1  1970 ..
lrwxrwxrwx 1 root root  10 Jan  1  1970 BOOT -> ../../sda1
lrwxrwxrwx 1 root root  10 Jan  1  1970 home -> ../../sda3
lrwxrwxrwx 1 root root  10 Jan  1  1970 rootfs -> ../../sda2

Maybe the whole uboot enviroment needs an update. I will have to dig into it, as i am not an expert. Can you suggest some good documentation?


EDIT: Looking into the logs, maybe the uboot is too old and does not understand the LABEL parameter?

[    1.766760] VFS: Cannot open root device "LABEL=rootfs" or unknown-block(0,0): error -6
[    1.774845] Please append a correct "root=" boot option; here are the available partitions:
[    1.783265] 1f00           14336 mtdblock0  (driver?)
[    1.788311] 1f01          116736 mtdblock1  (driver?)
[    1.793433] 0800       156290904 sda  driver: sd
[    1.798033]   0801           16384 sda1 00008000-01
[    1.802926]   0802        10485760 sda2 00008000-02
[    1.807820]   0803       145787736 sda3 00008000-03

EDIT2: Replacing the =LABEL=rootfs with /dev/sda2 did make the device boot without the memory errors



Edited 2 time(s). Last edit at 02/02/2017 04:10PM by schnee.
Attachments:
open | download - kernel.log (15.2 KB)
Re: edit mtd from debian pogoplug pro oxnas
February 02, 2017 04:46PM
Hi schnee,

> Maybe the whole uboot enviroment needs an update.
> I will have to dig into it, as i am not an expert.
> Can you suggest some good documentation?

Look at my u-boot release thread (it's u-boot 2015.10 now). The new default u-boot envs automate everything. But your own build for 2013 u-boot does not necessary have all the features as in 2015.10, so you can only use part of the new default envs.

>
>
> EDIT: Looking into the logs, maybe the uboot is to
> o old and does not understand the LABEL parameter?
>

No, the bootargs is whatever we make it, u-boot only passes it along to the kernel.

> EDIT2: Replacing the =LABEL=rootfs with /dev/sda2
> did make the device boot without the memory errors

I see the error now in the envs.

You are not booting with uInitrd, only uImage and DTB were used in booting. That's why the LABEL=rootfs did not work. The initrd is responsible to find that partition (using the label) for the kernel to mount. Is it intentional or an oversight?

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
February 03, 2017 02:21PM
bodhi Wrote:
-------------------------------------------------------

> You are not booting with uInitrd, only uImage and
> DTB were used in booting. That's why the LABEL=roo
> tfs did not work. The initrd is responsible to fin
> d that partition (using the label) for the kernel
> to mount. Is it intentional or an oversight?

I have minimal knowledge about uboot. I simply use a version from warheadSE, with some modifications -> so it is not intentional. I will look into your uboot envs to understand and modify mine. Is there any good source for uboot documentation it would be very usefull for me?
Re: edit mtd from debian pogoplug pro oxnas
February 03, 2017 03:59PM
schnee,

> I have minimal knowledge about uboot. I simply use
> a version from warheadSE, with some modifications
> -> so it is not intentional.

In that case, you should install the new u-boot 2015.10:

http://forum.doozan.com/read.php?3,16017

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: edit mtd from debian pogoplug pro oxnas
February 06, 2017 03:08PM
bodhi Wrote:
-------------------------------------------------------

> In that case, you should install the new u-boot 20
> 15.10:
>
> http://forum.doozan.com/read.php?3,16017
Thanks for the suggestions!

I looked into the uboot thread already. Now i modified my uboot envs, based on the one posted there. See the result below. As on my setup everything is on the sata drive i still have to figure out if and how can i place the new uboot on the drive

ide - IDE sub-system

Usage:
ide reset - reset IDE controller
ide info  - show available IDE devices
ide device [dev] - show or set current device
ide part [dev] - print partition table of one or all IDE devices
ide read  addr blk# cnt
ide write addr blk# cnt - read/write `cnt' blocks starting at block `blk#'
    to/from memory address `addr'
4566440 bytes read in 909 ms (4.8 MiB/s)
3046158 bytes read in 689 ms (4.2 MiB/s)
7067 bytes read in 215 ms (31.3 KiB/s)
## Booting kernel from Legacy Image at 60500000 ...
   Image Name:   Linux-4.4.38-oxnas-tld-5
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4566376 Bytes = 4.4 MiB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 60e00000 ...
   Image Name:   initramfs-4.4.38-oxnas-tld-5
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    3046094 Bytes = 2.9 MiB
   Load Address: 60000000
   Entry Point:  60000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 62c00000
   Booting using the fdt blob at 0x62c00000
   Loading Kernel Image ... OK
   Loading Ramdisk to 67b43000, end 67e2aace ... OK
   Loading Device Tree to 67b3e000, end 67b42b9a ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0

Now the system is booting as long as i use 3.17, 3.18 or 4.0 kernel. If i use 4.1 or the latest 4.4.38 in hangs during the boot

[    2.935418] Key type encrypted registered
[    3.070003] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[    3.087119] ata1.00: ATA-9: INTEL SSDSC2BF180A4L, LADi, max UDMA/133
[    3.093496] ata1.00: 351651888 sectors, multi 16: LBA48 NCQ (depth 0/32)
[   18.100001] ata1.00: qc timeout (cmd 0xef)
[   18.104084] sata_oxnas: resetting SATA core
[   18.460001] ata1.00: failed to set xfermode (err_mask=0x5)
[   18.969999] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   33.990005] ata1.00: qc timeout (cmd 0xef)
[   33.994086] sata_oxnas: resetting SATA core

I am positng this issue with my findings to the kernel forum thread
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: