I already did that yesterday... ( https://forum.doozan.com/read.php?4,54044,134611#msg-134611 )

mtd7 is irrelevant while kernel booting. Break the boot command into individual steps.

Double check the syntax of this

help nboot

And

nboot 61000000 0 440000
bootm 61000000

And note to remind: this NAND flash block size should be 128K.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I don't see mtd7 in the DTS

/usr/src/linux-5.4.224-oxnas/arch/arm/boot/dts/ox820-stg212.dts

&nandc {
        status = "okay";

        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_nand>;

        nand@0 {
                reg = <0>;
                #address-cells = <1>;
                #size-cells = <1>;
                nand-ecc-mode = "soft";
                nand-ecc-algo = "hamming";

                partition@0 {
                        label = "stage1";
                        reg = <0x00000000 0x00040000>;   # 256KB 
                };

                partition@40000 {
                        label = "u-boot";
                        reg = <0x00040000 0x00380000>;  # 3.5MB
                };

                partition@3c0000 {
                        label = "u-boot-env";
                        reg = <0x003c0000 0x00080000>; # 512KB
                };

                partition@440000 {
                        label = "kernel";
                        reg = <0x00440000 0x009c0000>; # 9.75 MB
                };

                partition@e00000 {
                        label = "ubi";
                        reg = <0x00e00000 0x07200000>;
                };
        };
};

And the kernel is at mtd3.

So that GitHub has a different MTD layout. It probaly stock MTD. The DTS is OpenWrt flavor.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/07/2023 05:21PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> mtd7 is irrelevant while kernel booting. Break the
> boot command into individual steps.

Good to know.

> Double check the syntax of this
>

> help nboot
>

> And
>

> nboot 61000000 0 440000
> bootm 61000000
>

You mean after tftp Debian uImage? I guess so... Need some sleep first. Tomorrow is a new day! ;-)

> And note to remind: this NAND flash block size
> should be 128K.

Whatever this means... :-D

> And the kernel is at mtd3.
>
> So that GitHub has a different MTD layout. It
> probaly stock MTD. The DTS is OpenWrt flavor.

Stock MTD is definitely different. MTD7 is sysdisk on stock. Then i would somehow need mtd1, mtd2 and mtd3 from openwrt as backup for flashing directly to NAND? But where to get that from? :-?

> You mean after tftp Debian uImage? I guess so...

No. After you flashed the stock kernel (i.e. mtd3 backup) to NAND. No tftp involved.

> > And note to remind: this NAND flash block size
> > should be 128K.
>
> Whatever this means... :-D

Meant to answer Schnee's speculation previously.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

Stock MTD is definitely different. MTD7 is sysdisk on stock. Then i would somehow need mtd1, mtd2 and mtd3 from openwrt as backup for flashing directly to NAND? But where to get that from? :-?

Should be mtd0, mtd1, mtd2, mtd3.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Once more i tried a different approach by unsquashing rootfs of openwrt-15.05.1 to (rescue) SSD root "rootfs" and loading belonging zImage and openwrt-oxnas-stg212.dtb into ram. booting results in the usual decompressing failure. i referred to http://blog.qnology.com/p/openwrt-on-pogoplug-v3oxnas-proclassic.html . Did i miss something in the envs to refer to right rootfs? shouldn't there be no Linux decompression, if rootfs is already decompressed on different device (IDE)? in before mentioned tutorial the rootfs gets written into and booted from NAND instantly. That's what i wanna try to, to prevent decompression to RAM or will starting kernel always lead to uncompressing Linux?

U-Boot SPL 2013.10-ga72eb8f-dirty (Feb 19 2014 - 15:21:12)
  Boot device: SATA
Attempting to set PLLA to 800 MHz ...
  plla_ctrl0 : 0000030a
  plla_ctrl1 : 00400000
  plla_ctrl2 : 007f0068
  plla_ctrl3 : 00000193

PLLA Set
Bus 0: OK
  Device 0:
reading bootargs.bin
reading u-boot.img
reading u-boot.img


U-Boot 2015.10-tld-2 (Oct 21 2017 - 22:00:02 -0700)
OXNAS OX820

DRAM:  128 MiB
NAND:  128 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   dwmac.40400000
Hit any key to stop autoboot:  0

OX820> ide reset

Reset IDE: Bus 0: OK
  Device 0: Model: Crucial_CT275MX300SSD1 Firm:  M0CR070 Ser#: 17251799E2D8
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 262321.6 MB = 256.1 GB (537234768 x 512)

OX820> setenv bootargs 'console=ttyS0,115200n8 root=dev/sda2 rw rootfstype=ext2 rootdelay=3'

OX820> ext2load ide 0:2 0x60500000 /boot/zImage
1671992 bytes read in 217 ms (7.3 MiB/s)

OX820> ext2load ide 0:2 0x62c00000 /boot/openwrt-oxnas-stg212.dtb
7224 bytes read in 4 ms (1.7 MiB/s)

OX820> bootz 0x60500000 - 0x62c00000
Kernel image @ 0x60500000 [ 0x000000 - 0x198338 ]
## Flattened Device Tree blob at 62c00000
   Booting using the fdt blob at 0x62c00000
   Loading Device Tree to 67e22000, end 67e26c37 ... OK

Starting kernel ...

Uncompressing Linux...

XZ-compressed data is corrupt

 -- System halted

> . Did i miss something in the envs to refer to
> right rootfs? shouldn't there be no Linux
> decompression, if rootfs is already decompressed
> on different device (IDE)?

No. You misunderstood kernel decompression. It has nothing to do with the rootfs.

The kernel file such as zImage, or vmlinuz is a compressed image, with the decompression code embedded inside. So it does not matter where it is stored (eg. NAND, tftp server, USB, HDD,....). Once it is loaded into RAM, and the bootm/bootz command starts the kernel, everything is running in RAM. And then the kernel starts decompressing itself. The decompression process coulld result in the kernel reclocating the binary to another higher RAM location if needed (if it was loaded it too close to the base address). But at the end, this uncompressed kernel is at 60008000. Hence the image was created as such:

Load Address: 60008000
Entry Point:  60008000

For other kernel such as Kirkwood or MVBU the base address is 0x0 so their load and entry point addresses are

Load Address: 00008000
Entry Point:  00008000

====
bodhi's edit: typo

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/08/2023 02:33PM by bodhi.

thanks for clearing that too. in the end it means, no matter what i do, as long as RAM may be broken, nothing will fix that error...

i now wrote stock mdt1, mtd2 and mtd3 again. as mtd4 i used "openwrt-15.05-oxnas-stg212-u-boot-initramfs.bin". then i extended stock envs with second stage bootloader (as it was back then and in earlier openwrt days) and everything starts at least to that point, that second stage envs want to be written to ubi. now i somehow need to find out, what creates and writes the openwrt ubifs...

Stage-1 Bootloader Tue Aug  9 16:44:00 CST 2011
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
PLLA Set

Setup memory, testing
Reading NAND, Image 0
  Hdr len: 0x0001A94C
  Hdr CRC: 0xF0019DAC
 OK


U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)

U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x440000, size 0x90000
 589824 bytes read: OK
## Starting application at 0x64000000 ...


U-Boot 2014.10 (Jan 02 2016 - 08:13:37) for OXNAS

DRAM:  128 MiB
NAND:  128 MiB
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 114 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 911, bad PEBs: 1, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/1, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 888, total reserved PEBs: 23, PEBs reserved for bad PEB handling: 19
Volume ubootenv not found!

** Unable to read env from ubi:ubootenv **
Volume ubootenv2 not found!

** Unable to read redundant env from ubi:ubootenv2 **
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   dwmac.40400000
Error: dwmac.40400000 address not set.

IDE:   SATA PHY not ready for device 0
SATA PHY not ready for device 1
ide_preinit failed
Hit any key to stop autoboot:  0
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Saving Environment to UBI...
UBI: detaching mtd1 from ubi0
UBI: mtd1 is detached from ubi0
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 114 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 911, bad PEBs: 1, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/1, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 888, total reserved PEBs: 23, PEBs reserved for bad PEB handling: 19
Writing to redundant UBI... Volume ubootenv2 not found!

** Unable to write env to ubi:ubootenv2 **
Read 0 bytes from volume kernel to 62000000
Volume kernel not found!

NAND read: device 0 offset 0x4e0000, size 0x400000
 4194304 bytes read: OK
## Loading kernel from FIT Image at 62000000 ...
   Using 'config@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  ARM OpenWrt Linux-3.18.23
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x620000e4
     Data Size:    3143016 Bytes = 3 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x60008000
     Entry Point:  0x60008000
     Hash algo:    crc32
     Hash value:   5c99867d
     Hash algo:    sha1
     Hash value:   3af23f88b007fb19e48e2e04af79d82689226b6d
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 62000000 ...
   Using 'config@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  ARM OpenWrt stg212 device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x622ff77c
     Data Size:    7224 Bytes = 7.1 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   da9a5725
     Hash algo:    sha1
     Hash value:   10938dfaafa6afb63e238032eaa4bdc5db736a0a
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x622ff77c
   Loading Kernel Image ... OK
   Loading Device Tree to 67e1c000, end 67e20c37 ... OK

Starting kernel ...

Uncompressing Linux...

XZ-compressed data is corrupt

 -- System halted

OX820 # printenv
autoload=no
baudrate=115200
boot_dhcp=run load_kernel_dhcp && run boot_kernel;
boot_kernel=bootm 0x62000000;
boot_rescue=run load_kernel_rescue && run boot_kernel;
boot_ubi=run load_kernel_ubi && run boot_kernel;
bootargs=console=ttyS0,115200n8 earlyprintk=serial
bootcmd=run firstboot;
bootdelay=1
console=console=ttyS0,115200n8 earlyprintk=serial
ethact=dwmac.40400000
firstboot=bootm 0x640a0000; setenv bootcmd run normalboot; setenv firstboot; saveenv; run bootcmd;
ipaddr=192.168.50.100
load_kernel_dhcp=dhcp 0x62000000 oxnas-rescue.bin;
load_kernel_rescue=nand read 0x62000000 0x4e0000 0x400000;
load_kernel_ubi=ubi readvol 0x62000000 kernel;
mtdids=nand0=41000000.nand
mtdparts=mtdparts=41000000.nand:14m(boot),-(ubi)
normalboot=run boot_ubi; run boot_rescue; run boot_dhcp;
serverip=192.168.50.59
stderr=serial
stdin=serial
stdout=serial

seems that fallback to rescue_boot is working, tries to start kernel and then crashes again. not sure if investigating the struture and content of openwrt ubifs makes sense then, when everything seems to break caused by faulty RAM!?

The images are OK.

NAND read: device 0 offset 0x4e0000, size 0x400000
 4194304 bytes read: OK

## Loading kernel from FIT Image at 62000000 ...
   Using 'config@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  ARM OpenWrt Linux-3.18.23
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x620000e4
     Data Size:    3143016 Bytes = 3 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x60008000
     Entry Point:  0x60008000
     Hash algo:    crc32
     Hash value:   5c99867d
     Hash algo:    sha1
     Hash value:   3af23f88b007fb19e48e2e04af79d82689226b6d
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 62000000 ...
   Using 'config@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  ARM OpenWrt stg212 device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x622ff77c
     Data Size:    7224 Bytes = 7.1 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   da9a5725
     Hash algo:    sha1
     Hash value:   10938dfaafa6afb63e238032eaa4bdc5db736a0a
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x622ff77c
   Loading Kernel Image ... OK
   Loading Device Tree to 67e1c000, end 67e20c37 ... OK

So must be the RAM.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

last step i took (instead of flashing stock mtd4[stock kernel])...

OX820> ext2load ide 0:3 61000000 /19.07.5/openwrt-19.07.5-oxnas-ox820-mitrastar_stg-212-initramfs-uImage
5698471 bytes read in 729 ms (7.5 MiB/s)
OX820> nand write 61000000 440000 56F3A7

NAND write: device 0 offset 0x440000, size 0x56f3a7
 5698471 bytes written: OK

Stage-1 Bootloader Tue Aug  9 16:44:00 CST 2011
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
PLLA Set

Setup memory, testing
Reading NAND, Image 0
  Hdr len: 0x0001A94C
  Hdr CRC: 0xF0019DAC
 OK


U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)

U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0

Loading from device 0: 128MiB 3,3V 8-bit (offset 0x440000)
   Image Name:   ARM OpenWrt Linux-4.14.209
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5698407 Bytes =  5.4 MB
   Load Address: 60008000
   Entry Point:  60008000
## Booting image at 60500000 ...
   Image Name:   ARM OpenWrt Linux-4.14.209
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5698407 Bytes =  5.4 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

at least no decompression error! ;-) some tutorials in here say, that this is the last step one sees, before ssh to openwrt ip... if only i knew if it's stuck or not. investigations say, that "stock" openwrt initramfs is usually ssh'd to ip 192.168.1.1/24. thats my last hope!

Try to press the ram chip hard and boot again ... If there's a contact problem, that might solve it.

Quote

at least no decompression error! ;-) some tutorials in here say, that this is the last step one sees, before ssh to openwrt ip... if only i knew if it's stuck or not. investigations say, that "stock" openwrt initramfs is usually ssh'd to ip 192.168.1.1/24. thats my last hope!

Not so fast! If this kernel openwrt-19.07.5-oxnas-ox820-mitrastar_stg-212-initramfs-uImage has no earlyprintk and/or you did not pass the bootargs earlyprintk=serial then the decompression error will not be printed out. It will just hang at that point.

Besides, you have serial console. So if the kernel booted then there should be kernel log printed out.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/08/2023 03:11PM by bodhi.

> Try to press the ram chip hard and boot again ...
> If there's a contact problem, that might solve it.

Yes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

just took it apart as good as possible, but they soldered a heat shield over the whole area of cpu and ram... would need to desolder like 12 pins first to get access to ram chip(s)... hell yeah, time to give up on this project, i guess.

it's not reachable via ssh or browser through 192.168.1.1 or 192.168.50.100 - so i guess it's stuck at booting kernel again.

$ printenv bootargs
bootargs=console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 earlyprintk=serial mem=128M poweroutage=yes

Stage-1 Bootloader Tue Aug  9 16:44:00 CST 2011
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
PLLA Set

Setup memory, testing
Reading NAND, Image 0
  Hdr len: 0x0001A94C
  Hdr CRC: 0xF0019DAC
 OK


U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)

U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0

Loading from device 0: 128MiB 3,3V 8-bit (offset 0x440000)
   Image Name:   ARM OpenWrt Linux-4.14.209
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5698407 Bytes =  5.4 MB
   Load Address: 60008000
   Entry Point:  60008000
## Booting image at 60500000 ...
   Image Name:   ARM OpenWrt Linux-4.14.209
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5698407 Bytes =  5.4 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

so i guess the stock old u-boot doesn't support that command?

> so i guess the stock old u-boot doesn't support
> that command?

No, it is the OpenWrt kernel that does not have earlyprintk. That bootarg earlyprintk=serial is just a string u-boot passes to the kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I guess our journey ends here.. :'(

But many thanks again for your patience and explanations. I've learned quite a lot, especially the last days with erasing and writing to NAND as well as partitioning ubi or the expressions of loading adresses...

well, now the search begins for a cheap but reliable alternative storage, that provides my music collection to my network as well (Linux with minimserver and bubbleuppnp server). maybe western digital my cloud home will do the job, as after their recent cloud disaster it may become quite cheap and getting Debian on it should be possible too. ;-)

It's a pity that Ctera C200-V1 is much more expensive on eBay now. Otherwise it's a good choice for NAS.

https://forum.doozan.com/read.php?2,128064,128254

I'll have a look, but first one week vacation after all this mess and intensive learnings at late nights... :-D



Edited 1 time(s). Last edit at 04/08/2023 05:08PM by alexinc.

alexinc,

Don't throw it away. Keep it in the closet in case I think of something new to try.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I will! :-) Maybe I'll try the one or other thing from time to time. But everything I've read about decompression error leads to faulty RAM. :-/

There are still some things i could try after vacation. First of all it would be interesting to find out how and what to create in ubi partition. I know there were some volumes like rootfs, kernel, uboot_env and uboot_env2... That's what uboot stage 2 is missing right now - possibility to write to uboot_env volumes.

The other option is unsquashing openwrt--ubifs-sysupgrade.tar, which leaves 3 files control, kernel and root. Maybe these files (kernel and root) written to the right ubi partition (boot and ubi) throught nand write may create/include the right file and folder structure!?

Just caught a new unused one at eBay for a few bucks, as Ctera isn't available over here in Germany and price range is not attractive when importing. So after getting it and doing the official firmware upgrade, I'm up for everything... Should backup the whole system then and still not sure if going with Debian or OpenWRT. Any hints what i should try before flashing it in regards of using that information for the bricked (broken?) device? *never stop playing* :-D

Latest news:

got my new P89625 today and as it came with latest/last firmware i first started nanddump everything with some little differences in mtd file size afterwards, compered to the dumps i used earlier. then i started nandwriting mtd1 till mtd7 from scratch (after nand erase.chip) on my old device. everything went smooth so far and environment included ethaddr from my newly aquired device - so i was sure nanddump and nandwrite was working as expected. after changing ethaddr and reset, the old device was booting and starting decompressing linux with the typical crc compression error... which underlines that a hardware issue is most likely.
i then did nand write mtd0 (what is expected to be a complete system dump) or better i tried to nandwrite, as it's still writing for a pretty long time now - for now i'm guessing it won't finish caused by some hardware failure again...

upcoming: flashing new device to openwrt! keeping the dumps, envs, cat /proc/mtd and dmesg, but i think there is no reason to keep it stock anymore. be quick, if you still wanna know something about or need something from stock device. will start in some hours. ;-)



Edited 2 time(s). Last edit at 04/19/2023 07:58AM by alexinc.

alexinc,

So the new box has no problem. Now you should try to boot the new box with Debian on USB.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

for now i already installed openwrt. wanted to make nanddump too (for nandwriting on old box as a last attempt), but there it says:

root@OpenWrt:/tmp/sda1/tools# ls -l
-rwxr-xr-x    1 root     root       1616492 Nov 15  2010 busybox
-rwxr-xr-x    1 root     root        787036 Jun 20  2011 e2fsck
-rwxr-xr-x    1 root     root         25632 Jun 30  2014 flash_erase
-rw-r--r--    1 root     root           329 May 17  2016 fw_env.config
-rwxr-xr-x    1 root     root        668497 May 17  2016 fw_printenv
-rwxr-xr-x    1 root     root         26548 Jun 30  2014 nanddump
-rwxr-xr-x    1 root     root         29644 Jun 30  2014 nandwrite

root@OpenWrt:/tmp/sda1/tools# ./nanddump --noecc --omitoob -f mtd0 /dev/mtd0
-ash: ./nanddump: not found

any idea what i'm missing? also copied nanddump to /usr/sbin without any success.



Edited 2 time(s). Last edit at 04/19/2023 09:23PM by alexinc.

> root@OpenWrt:/tmp/sda1/tools# ./nanddump --noecc
> --omitoob -f mtd0 /dev/mtd0
> -ash: ./nanddump: not found
> [/code]
> any idea what i'm missing? also copied nanddump to
> /usr/sbin without any success.

Try

mkdir -p /mnt/sda1
mount /dev/sda1 /mnt/sda1
cd /mnt/sda1/tools
./nanddump --noecc --omitoob -f mtd0.stg210 /dev/mtd0

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

i found out that i had to install nand-utils from openwrt, not the ones provided in this forum. everything worked as expected. just have to get home to nandwrite on old device - not that i'm expecting miracles, but afterwards i've tried every possible combination i could imagine. ;-)



Edited 1 time(s). Last edit at 04/19/2023 10:40PM by alexinc.