NSA325v2 flashing uboot.2013.10-tld-1.nsa325.mtd0.kwb

Hello :)

I am trying to flash a NSA325v2 with testing u-boot uboot.2013.10-tld-1.nsa325.mtd0.kwb, the uart-version is working fine. I am using debian wheezy on a pluged usb-stick. Problem is that I want to use the new device tree features and
original u-boot (1.1.4) does not include support for DT. Actually I can not flash because I have bad blocks. What can I do?

regards

Here are some informations about the device:

[ 22.160966] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1
[ 22.187173] Bad eraseblock 100 at 0x000000c80000
[ 22.197458] Bad eraseblock 200 at 0x000001900000
[ 22.258447] 0x000000000000-0x000000100000 : "uboot"
[ 22.264276] 0x000000100000-0x000000180000 : "uboot_env"
[ 22.270331] 0x000000180000-0x000000200000 : "key_store"
[ 22.276468] 0x000000200000-0x000000280000 : "info"
[ 22.282079] 0x000000280000-0x000000c80000 : "etc"
[ 22.287615] 0x000000c80000-0x000001680000 : "kernel_1"
[ 22.293565] 0x000001680000-0x000004640000 : "rootfs1"
[ 22.299437] 0x000004640000-0x000005040000 : "kernel_2"
[ 22.305390] 0x000005040000-0x000008000000 : "rootfs2"

root@debian:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "uboot"
mtd1: 00080000 00020000 "uboot_env"
mtd2: 00080000 00020000 "key_store"
mtd3: 00080000 00020000 "info"
mtd4: 00a00000 00020000 "etc"
mtd5: 00a00000 00020000 "kernel_1"
mtd6: 02fc0000 00020000 "rootfs1"
mtd7: 00a00000 00020000 "kernel_2"
mtd8: 02fc0000 00020000 "rootfs2"
root@debian:~#

root@debian:~/u-boot-utils# cat /etc/fw_env.config
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd0 0xc0000 0x20000 0x20000

bootargs_stock=console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw init=/init

bootargs_linux=console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=LABEL=rootfs loglevel=8

bootcmd_linux=setenv bootargs $(bootargs_linux); mw.l f1010100 0020c000; usb reset; ext2load usb 0:1 $(loadaddr) /boot/uImage; ext2load usb 0:1 0x01100000 /boot/uInitrd; bootm $(loadaddr) 0x1100000

balou1974,

Your bad blocks are way out, not in first 1M. You can upgrade u-boot.

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

Well I tried it. Does not let me write ...

root@debian:~/u-boot-utils# ./flash_erase /dev/mtd0 0 4
File open error

balou1974 Wrote:
-------------------------------------------------------
> Well I tried it. Does not let me write ...
>
> root@debian:~/u-boot-utils# ./flash_erase
> /dev/mtd0 0 4
> File open error

Your mtd0 is probably protected by the kernel. Which kernel are you running?

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

Easy to say :) self compiled 3.16.1 with patch from archlinuxarm to support sata leds. If it is protected than there must be an option to change, maybe for compiling? I can post my config if would help?!
By the way, is there any u-boot for Qnap TS-219 P ?

Thanks a lot for your great work!

balou1974,

The Arch patch should contain the nsa-325_setup.c file. In that you can find the mtd parts definition, and the mtd0 writeable flag was masked. Remove the mask and it will be writeable. Pls post it here if you're not sure.

I don't have the Qnap TS-219 P so don't know off-hand if its u-boot can be built. If you'd like, remind me in about 3 weeks when I get back home.

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

Thanks again! I will compile the kernel with changed options should be no problem. But how about flashing with uart u-boot? is this possible?

Off-topic:
You can look all QNAP - Sources (including U-Boot + Kernel + Applications) here if it helps you porting newer u-boot to that device:

http://sourceforge.net/projects/qosgpl/

Flashing u-boot worked like a charm!!! Thanks again!

Changed a line in the file ./arch/arm/mach-kirkwood/nsa325-setup.c as you said:

static struct mtd_partition nsa325_nand_parts[] = {
{
.name = "uboot",
.offset = 0,
.size = SZ_1M,
/* .mask_flags = MTD_WRITEABLE */
}, {


I compiled a new zImage, added mach-file before zImage and created a new uImage. Only replaced the kernel on NSA325 and rebooted. Flash was writeable!

Still a few problems, I tried to setup u-boot enviroment like before but I found out a few commands changed (bootm).
I got uImage and uintrd loaded but when I start the kernel with 'bootm start $(loadaddr) 0x1100000' 'bootm go' it will
show 'Starting kernel ...' and thats it ...

balou1974 Wrote:
-------------------------------------------------------
> Still a few problems, I tried to setup u-boot
> enviroment like before but I found out a few
> commands changed (bootm).
> I got uImage and uintrd loaded but when I start
> the kernel with 'bootm start $(loadaddr)
> 0x1100000' 'bootm go' it will
> show 'Starting kernel ...' and thats it ...

loadaddr should be 0x800000, and

For Debian:

bootm $loadaddr 0x1100000
boot

For Arch:

bootm $loadaddr
boot

$loadaddr or ${loadaddr} should work the same way for this u-boot.

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

Uuuh, found out that the brackets like "ext2load usb 0:1 $(loadaddr) /boot/uImage" will result in a Kernel that reside on address 0x0000000 but it should be 0x800000 or old way 0x02000000. If I say "ext2load usb 0:1 $loadaddr /boot/uImage" I will get an error saying " ** File not found 0x0800000 ** " . So the meaning of the brackets is obsolet?!
Something changed ... Its the same with bootm, brackets do not work the old way :)

Can it be that the brackets are changed from () to {} ??? Checked the wiki at denx and they use "{}"-brackets for scripting?

Edit: Testet u-boot with "{}"-brackets and it seems like that was my mistake ;)



Edited 1 time(s). Last edit at 01/08/2015 03:19AM by balou1974.

Up and running !!! There are still a few in the OLD (1.1.4 Marvell) u-boot I do not understand:

to_stock=setenv mainlineLinux no; setenv bootcmd \'run bootcmd_stock\'; saveenv; reset
to_linux=setenv mainlineLinux yes; setenv bootcmd \'run bootcmd_linux\'; saveenv; reset

I do not know how to rewrite this for the new u-boot but at the moment my machine booted up with less settings ;)
I think I will never use stock so it is okay :)

Next step will be using Linux 3.18.1 with device tree blob.

regard and thank you a lot!!!



Edited 1 time(s). Last edit at 01/08/2015 03:38AM by balou1974.

Cool:)

Btw, I am waiting for an important 3.18 bug to resolve before releasing kernel 3.18.x.

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

I tried 3.18.1 for TS-219 already but it did not boot. Combined TS-219 zImage with dtb as the mach-support in 3.18.1 is very limited and tried that with a very old u-boot (2009 1.1.4). Maybe I had to include a kernel command line or something else was wrong ...

Which important bug do you mean? I may wait, too, if it is to dangerous ....

I think you mean the lockup problems starting with 3.17.x and not solved since today (3.18.x). Well 3.16.1 is quite okay for a while ;)

balou1974 Wrote:
-------------------------------------------------------
> I think you mean the lockup problems starting with
> 3.17.x and not solved since today (3.18.x). Well
> 3.16.1 is quite okay for a while ;)

Yes, indeed that is the big bug. Last I've learned, it's close to be resolved.

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

The good thing is they found a bunch of other heavy bugs while investigating that bug ;)

Today, I tried a second unit (new one). Everything seems fine except this:

[ 20.982092] end_request: I/O error, dev mtdblock5, sector 0
[ 20.987690] Buffer I/O error on device mtdblock5, logical block 0
[ 20.993992] __nand_correct_data: uncorrectable ECC error
[ 20.999334] __nand_correct_data: uncorrectable ECC error
[ 21.004848] __nand_correct_data: uncorrectable ECC error
[ 21.010190] __nand_correct_data: uncorrectable ECC error
[ 21.015705] __nand_correct_data: uncorrectable ECC error
[ 21.021822] __nand_correct_data: uncorrectable ECC error
[ 21.032083] __nand_correct_data: uncorrectable ECC error
[ 21.037419] __nand_correct_data: uncorrectable ECC error
[ 21.046795] __nand_correct_data: uncorrectable ECC error
[ 21.052213] __nand_correct_data: uncorrectable ECC error
[ 21.057753] __nand_correct_data: uncorrectable ECC error
[ 21.063123] __nand_correct_data: uncorrectable ECC error
[ 21.068691] __nand_correct_data: uncorrectable ECC error
[ 21.074025] __nand_correct_data: uncorrectable ECC error
[ 21.079566] __nand_correct_data: uncorrectable ECC error
[ 21.084910] __nand_correct_data: uncorrectable ECC error
[ 21.090454] __nand_correct_data: uncorrectable ECC error
[ 21.095791] __nand_correct_data: uncorrectable ECC error
[ 21.101316] __nand_correct_data: uncorrectable ECC error
[ 21.106646] __nand_correct_data: uncorrectable ECC error
[ 21.112169] __nand_correct_data: uncorrectable ECC error
[ 21.117503] __nand_correct_data: uncorrectable ECC error

can this be solved?

Found out another thing:

!!! NEVER FORGET TO SET THE HARDWARE-CLOCK :) !!!

you will run into problems for sure :)

balou1974,

mtdblock5 is where your bad blocks were dectected in the first NSA325v2:

[ 22.187173] Bad eraseblock 100 at 0x000000c80000 
[ 22.197458] Bad eraseblock 200 at 0x000001900000

Are you sure this was 2nd unit? if it was, then where are the bad blocks in dmesg from that 2nd unit?

dmesg | grep -i bad

You could fix these (possible), but if you're not going to use stock FW then there is no need to. If the errors messages bother you, then remove mtd5 from the mtdparts definition. In the future when you want to use the whole nand (e.g flashing kernel/rootfs on it), then fix them that time.

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

Thanks again! You are right!

I simply cloned everything (u-boot, u-boot-env, and the debian system and simply changed ethaddr) ...
Is there a easy way to clean that up (marking new bad blocks for the new device)?

By-the-way, kernel 3.18.2 was released yesterday - many things have been fixed as it looks like the big lockup, too



Edited 1 time(s). Last edit at 01/09/2015 10:11AM by balou1974.

balou1974 Wrote:
-------------------------------------------------------
> Thanks again! You are right!
>
> I simply cloned everything (u-boot, u-boot-env,
> and the debian system and simply changed ethaddr)
> ...

You can't clone the bad blocks, though. Bad blocks could show up in the same region, but probably at different locations. You could compare dmesg output between the 2 and see where they are.

It is not simple procedure: basically, you could flash a known good rootfs or kernel to the same region, and in the process the bad locks should be skipped. Or you could repartition the mtds around them.

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

Problems are magically gone! I am running 4 kirkwood devices using linux kernel 3.18.2 now but only Dns320 with dt-blob and kernel. The rest is still with mach-kernel Ts-219, 2x Nsa325 all with Patches from archlinuxarm.

Thanks a lot!

Regards balou

balou1974,

> By-the-way, kernel 3.18.2 was released yesterday -
> many things have been fixed as it looks like the
> big lockup, too

I did not see the bug fix was included in 3.18.2.

> Problems are magically gone! I am running 4 kirkwood devices using linux kernel 3.18.2 now but only Dns320 with dt-blob and kernel. The rest is still with mach-kernel Ts-219, 2x > Nsa325 all with Patches from archlinuxarm.

Cool!

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

wasn't it a problem with rtc and hpet? Don't know for sure but I have not run into problems for now ;) hopefully they fixed it finally ...