2017.07- 2024.10 U-Boot Kirkwood

Hello,

Until yesterday my NSA320 was running on uboot.2014.07-tld-3.nsa320.bodhi.tar and had no complaint about it (don't need the netconsole, I modded my box with a USB serial TTL port).
I upgraded just for the sake of it to uboot.2014.07-tld-4.nsa320.bodhi.tar and now WOL does not work anymore, at all. At least on tld-3 it worked after system halt (did not work after a full power loss).

I cannot find the image for tld-3 in the first post to do a rollback, can someone please give me a download link?

Thank you,
Vali.

vcheche,

Here is the image download link:

uboot.2014.07-tld-3.nsa320.bodhi.tar
md5
55b2423c02580afe9f265f4887067c87

However, I am curious about this WOL problem. Have you tried to do the WOL with the MAC address that is on the case? or one from the original bootlog? We used to have this problem on the NSA325 because Zyxel changed the original Marvell MAC address to another one in their FW. So it could be the patch for network fix has reset the card in a such a way that you need to use a different MAC address to wake it up.

To see if this is the same issue about the MAC address you were using:

Please post the first 3 or 4 parts of the MAC address (blank out the last 2 part of the address). And try to find out if there is a different one (check original bootlog, or the Zyxel box bottom sticker)

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

The MAC on the box sticker is the same as the one in the original environment, and I kept it the same in my current uboot env.
ethaddr=28:28:5D:16:xx:xx

I don't have the original full bootlog anymore (must have deleted it by accident at some point).

However, in the original printenv, I see some more MAC addresses, don't know what's about them. I'll try now to wol the box with them.
eth1addr=00:19:CB:00:51:82
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
yuk_ethaddr=00:00:00:EE:51:81

vcheche,

> The MAC on the box sticker is the same as the one
> in the original environment, and I kept it the
> same in my current uboot env.
> ethaddr=28:28:5D:16:xx:xx

This is Zyxel MAC address, not Marvell. So it could be that we need the Marvell addr to do WOL.

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

ok, so after testing it looks like it always fails to wol if I issue a 'halt' or if a power loss occurs.

If I shutdown the box with 'shutdown -h now' it will sometimes wake up via wol. with the mac address 28:28:5D:16:xx:xx

If I shutdown the box with 'shutdown -h now' AND a powerloss occurs it failed to wol in all my tries.

The other mac addresses above do not yeld any results.

Thank you for the uboot image, I will download it and try to flash it tonight and see if the results change. So far, I have yet another confirmation that wol is one nightmarish technology. :-( I'll just move my box on the UPS and keep it online. :-))

As a side note, after a power loss, on power restore, while the box is in soft off, the link on the NIC is orange.
If I boot it up and shut it down, no matter the shutdown command the NIC link will become and remain orange+green until the next power-loss

Thank you,
Val.



Edited 1 time(s). Last edit at 09/20/2015 03:42PM by vcheche.

Val,

> Thank you for the uboot image, I will download it
> and try to flash it tonight and see if the results
> change. So far, I have yet another confirmation
> that wol is one nightmarish technology. :-( I'll
> just move my box on the UPS and keep it online.
> :-))

Yup. And I'd bet Zyxel has changed the MAC addr to theirs, so it is sometime a problem for us. We just need to know the right one.


>
> As a side note, after a power loss, on power
> restore, while the box is in soft off, the link on
> the NIC is orange.
> If I boot it up and shut it down, no matter the
> shutdown command the NIC link will become and
> remain orange+green until the next power-loss
>

I think we knew the LED lighting is not correct during testing by pbg4. I just have to remember to fix this :)

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

Oh, wrong LED lights, I must have missed that in the thread. :-)

I mentioned it as I thought it was actually correctly indicating the NIC state (100M or 1G).
About a year ago I noticed on a friends NSA325 and NSA310 that if the NIC was in 100M mode (lowpower) or the patch cord was a 4 wire (forcing the 100M mode) then WOL did not work. I don't remember specifics of what mods and firmware he used and his boxes are long gone on ebay, but this is why I thought it was worth mentioning it.

As for the LED lights, as long as the link works fine, it's just a led light in the back of the cabinet. ;-)

> As for the LED lights, as long as the link works
> fine, it's just a led light in the back of the
> cabinet. ;-)

Yes, and I think you can check dmesg for a more reliable link speed info when the network is up. I recall pbg4 has confirmed that the link was at 1G.

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

vcheche Wrote:
-------------------------------------------------------
> Thank you for the uboot image, I will download it
> and try to flash it tonight and see if the results
> change.


flashed back tld-3 and now the box wakes up no matter what command I shut it down with.
on powerloss (including while box is soft off) wol stops working.

the wol behavoiur is consistent compared with tld-4

Cheers.



Edited 1 time(s). Last edit at 09/20/2015 07:46PM by vcheche.

bodhi Wrote:
-------------------------------------------------------
> Of course it is cooler :)
>
> In any case, here is the binary from my 2014.07
> build.
>
> md5
> c46b7ffa8b164a2017e065ad2582eda2 mkenvimage.tar
>
> Use this command to generate image from
> uboot.environment file.
>
>

> ./mkenvimage  -s 131072 -o uboot.environment.img
> uboot.environment
>

>
>
> The env file should contain the envs in
> name=value format. For example, the one I've
> released:
>
>

Quote

uboot.2014.07-tld-2.environment (the
> content of the default envs in text
> format)

>
> or take the list that you posted above, put them
> inside the uboot.environment text file.


Ty a lot. <3

Hi Bodhi,
i found a small typo in your section D / D.1 Modify U-Boot envs:
you wrote the quotas this way (red marked):

fw_setenv devices ‘usb mmc ide’
fw_setenv bootcmd ‘run bootcmd_uenv; run bootcmd_usb; run bootcmd_mmc; run bootcmd_sata; reset’
fw_setenv bootcmd_uenv ‘run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi’
fw_setenv uenv_import ‘echo importing envs ...; env import -t 0x810000’
fw_setenv uenv_load ‘run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices; do for disknum in 0; do run uenv_read_disk; done; done;’
fw_setenv uenv_read ‘echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 0x810000 /boot/uEnv.txt; then setenv uenv_loaded 1; fi’
fw_setenv uenv_read_disk ‘if test $devtype -eq mmc; then if $devtype part; then run uenv_read; fi; else if $devtype part $disknum; then run uenv_read; fi; fi’
fw_setenv uenv_init_devices ‘setenv init_usb "usb start"; setenv init_ide "ide reset"; setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;’

But they should be " ' "(green marked), please try copy and paste and you will see.

joerg_999



Edited 1 time(s). Last edit at 10/16/2015 10:25AM by joerg_999.

joerg_999 Wrote:
-------------------------------------------------------
> Hi Bodhi,
> i found a small typo in your section D / D.1
> Modify U-Boot envs:
> you wrote the quotas this way (red marked):
>
> fw_setenv devices ‘usb
> mmc ide’
> fw_setenv bootcmd ‘run
> bootcmd_uenv; run bootcmd_usb; run bootcmd_mmc;
> run bootcmd_sata; reset’
> fw_setenv bootcmd_uenv
> ‘run uenv_load; if test
> $uenv_loaded -eq 1; then run uenv_import;
> fi’
> fw_setenv uenv_import
> ‘echo importing envs ...;
> env import -t 0x810000’
> fw_setenv uenv_load ‘run
> uenv_init_devices; setenv uenv_loaded 0; for
> devtype in $devices; do for disknum in 0; do run
> uenv_read_disk; done;
> done;’
> fw_setenv uenv_read ‘echo
> loading envs from $devtype $disknum ...; if load
> $devtype $disknum:1 0x810000 /boot/uEnv.txt; then
> setenv uenv_loaded 1;
> fi’
> fw_setenv uenv_read_disk
> ‘if test $devtype -eq
> mmc; then if $devtype part; then run uenv_read;
> fi; else if $devtype part $disknum; then run
> uenv_read; fi; fi’
> fw_setenv uenv_init_devices
> ‘setenv init_usb "usb
> start"; setenv init_ide "ide reset"; setenv
> init_mmc "mmc rescan"; for devtype in $devices; do
> run init_$devtype;
> done;’
>
> But they should be " '
> "(green marked), please try copy and paste and you
> will see.
>
> joerg_999

Thanks joerg! Mac OSX Yosemite terminal screw up again :) I have to remember to update the post.

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

I've uploaded a new u-boot envs image for Kirkwood. Please see here for download link and instruction.

UPDATE:

This has been incorporated into the new u-boot 2015.10 release in 1st post

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



Edited 1 time(s). Last edit at 11/13/2015 03:54AM by bodhi.

I've uploaded 2015.10-tld-1 U-Boot images. Please see 1st post for download links.

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

What was changed from previous version
?

andsol Wrote:
-------------------------------------------------------
> What was changed from previous version
> ?

Minor changes to keep up with the mainline u-boot. No need to update if you are happy with previous version.

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

And I would like to hear report from users who have installed the following u-boots, so I can update the 1st post:

Quote

Note 1: The NetgearStora, Sheevaplug , NSA320, and NSA310 u-boot have not been tested in actual hardware. Please report your finding if you install (please try UART booting first) one of these images in your box.

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

FYI,

I've forgot to mention that the NSA325 u-boot now has a new capability: Power and Copy buttons are working during boot. Each button can be queried for ON/OFF state, therefore can be scripted to do certain sequence that only executed as requested (pressing the button, realeasing the button). This is a nice addition thanks to davidedg :)

If anybody is interest in this capability for many other boxes that also have buttons (e.g. Pogo V4, iConnect, NSA320, NSA310S/320S, ....), let me know and I will add them in future releases.

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

I'm trying to update uboot on my NSA310. I started by following the steps to be performed before actually updating anything.

The device is a Zyxel NSA310. It does not have the TDC branding. It does have the red USB LED. I am running Arch Linux ARM with kernel 4.3.3 (kirkwood-dt) and I have to use kirkwood-nsa310a.dtb for best results (i.e. get working lm_sensors). I do have access to the serial console. The install uboot version is 1.1.4 (I never upgraded it).

1) 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"

This differs greatly from what it should be (as I understand from the instructions given in the first post). However, I don't know if that would be a problem, as the first partition is still the required minimal size (1MB).

2) /etc/fw_env.config
I created this file with the following content

/dev/mtd0 0xc0000 0x20000 0x20000

If I then run fw_printenv, I get the following output

Warning: Bad CRC, using default environment
bootargs=
bootcmd=
bootdelay=2
baudrate=115200
stdin=serial,cros-ec-keyb
stdout=serial,lcd
stderr=serial,lcd
ethaddr=00:00:11:22:33:44
eth1addr=00:00:11:22:33:45
eth3addr=00:00:11:22:33:46
eth5addr=00:00:11:22:33:47
ipaddr=1.2.3.4
host_boot=if host dev ${devnum}; then setenv devtype host; run scan_dev_for_boot_part; fi
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_script_dhcp=boot.scr.uimg
boot_targets=host1 host0 
boot_extlinux=sysboot ${devtype} ${devnum}:${bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
boot_a_script=load ${devtype} ${devnum}:${bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${bootpart} bootfstype; then run scan_dev_for_boot; fi; done
bootcmd_host1=setenv devnum 1; run host_boot
bootcmd_host0=setenv devnum 0; run host_boot
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
bootm_size=0x10000000
kernel_addr_r=0x1000000
fdt_addr_r=0xc00000
ramdisk_addr_r=0x2000000
scriptaddr=0x1000
pxefile_addr_r=0x2000

If I change /etc/fw_env.config into

/dev/mtd1 0x0 0x20000 0x20000

fw_printenv does not give the "Bad CRC" warning, and the output is the same as when using printenv in actual uboot.


Do I need to take additional steps before I try to upgrade uboot?

EDIT:
I put Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi on a spare HDD and provided uboot.2015.10-tld-1.nsa310.mtd0.kwb via kwboot. The system boots although uboot complains about a bad CRC:

Sending boot image...
  0 % [......................................................................]
...
 99 % [....................................]
[Type Ctrl-\ + c to quit]


U-Boot 2015.10-tld-1 (Nov 06 2015 - 16:19:43 -0800)
ZyXEL NSA310 1-Bay Power Media Server


SoC:   Kirkwood 88F6281_A1
DRAM:  256 MiB (ECC not enabled)
WARNING: Caches not enabled
NAND:  128 MiB
*** Warning - bad CRC, using default environment

Edited 2 time(s). Last edit at 01/03/2016 04:33AM by iweiss.

iweiss Wrote:
-------------------------------------------------------
> I'm trying to update uboot on my NSA310. I started
> by following the steps to be performed before
> actually updating anything.
>
> The device is a Zyxel NSA310. It does not have the
> TDC branding. It does have the red USB LED. I am
> running Arch Linux ARM with kernel 4.3.3
> (kirkwood-dt) and I have to use
> kirkwood-nsa310a.dtb for best results (i.e. get
> working lm_sensors). I do have access to the
> serial console. The install uboot version is 1.1.4
> (I never upgraded it).
>
> 1) 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"
>

>
> This differs greatly from what it should be (as I
> understand from the instructions given in the
> first post). However, I don't know if that would
> be a problem, as the first partition is still the
> required minimal size (1MB).
>
> 2) /etc/fw_env.config
> I created this file with the following content
>

> /dev/mtd0 0xc0000 0x20000 0x20000
>

> If I then run fw_printenv, I get the following
> output
>

> Warning: Bad CRC, using default environment
> bootargs=
> bootcmd=
> bootdelay=2
> baudrate=115200
> stdin=serial,cros-ec-keyb
> stdout=serial,lcd
> stderr=serial,lcd
> ethaddr=00:00:11:22:33:44
> eth1addr=00:00:11:22:33:45
> eth3addr=00:00:11:22:33:46
> eth5addr=00:00:11:22:33:47
> ipaddr=1.2.3.4
> host_boot=if host dev ${devnum}; then setenv
> devtype host; run scan_dev_for_boot_part; fi
> boot_prefixes=/ /boot/
> boot_scripts=boot.scr.uimg boot.scr
> boot_script_dhcp=boot.scr.uimg
> boot_targets=host1 host0 
> boot_extlinux=sysboot ${devtype}
> ${devnum}:${bootpart} any ${scriptaddr}
> ${prefix}extlinux/extlinux.conf
> scan_dev_for_extlinux=if test -e ${devtype}
> ${devnum}:${bootpart}
> ${prefix}extlinux/extlinux.conf; then echo Found
> ${prefix}extlinux/extlinux.conf; run
> boot_extlinux; echo SCRIPT FAILED: continuing...;
> fi
> boot_a_script=load ${devtype}
> ${devnum}:${bootpart} ${scriptaddr}
> ${prefix}${script}; source ${scriptaddr}
> scan_dev_for_scripts=for script in
> ${boot_scripts}; do if test -e ${devtype}
> ${devnum}:${bootpart} ${prefix}${script}; then
> echo Found U-Boot script ${prefix}${script}; run
> boot_a_script; echo SCRIPT FAILED: continuing...;
> fi; done
> scan_dev_for_boot=echo Scanning ${devtype}
> ${devnum}:${bootpart}...; for prefix in
> ${boot_prefixes}; do run scan_dev_for_extlinux;
> run scan_dev_for_scripts; done
> scan_dev_for_boot_part=part list ${devtype}
> ${devnum} -bootable devplist; env exists devplist
> || setenv devplist 1; for bootpart in ${devplist};
> do if fstype ${devtype} ${devnum}:${bootpart}
> bootfstype; then run scan_dev_for_boot; fi; done
> bootcmd_host1=setenv devnum 1; run host_boot
> bootcmd_host0=setenv devnum 0; run host_boot
> distro_bootcmd=for target in ${boot_targets}; do
> run bootcmd_${target}; done
> bootm_size=0x10000000
> kernel_addr_r=0x1000000
> fdt_addr_r=0xc00000
> ramdisk_addr_r=0x2000000
> scriptaddr=0x1000
> pxefile_addr_r=0x2000
>

> If I change /etc/fw_env.config into
>

> /dev/mtd1 0x0 0x20000 0x20000
>

> fw_printenv does not give the "Bad CRC" warning,
> and the output is the same as when using printenv
> in actual uboot.
>
>
> Do I need to take additional steps before I try to
> upgrade uboot?
>
> EDIT:
> I put Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi on
> a spare HDD and provided
> uboot.2015.10-tld-1.nsa310.mtd0.kwb via kwboot.
> The system boots although uboot complains about a
> bad CRC:
>

> Sending boot image...
>   0 %
> [.................................................
> .....................]
> ...
>  99 % [....................................]
> [Type Ctrl-\ + c to quit]
> 
> 
> U-Boot 2015.10-tld-1 (Nov 06 2015 - 16:19:43
> -0800)
> ZyXEL NSA310 1-Bay Power Media Server
> 
> 
> SoC:   Kirkwood 88F6281_A1
> DRAM:  256 MiB (ECC not enabled)
> WARNING: Caches not enabled
> NAND:  128 MiB
> *** Warning - bad CRC, using default environment
>

You are on the right track, almost there. Let me take a closer look.

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

bodhi Wrote:
> You are on the right track, almost there. Let me
> take a closer look.
>
Let me know what additional information I can provide. I'm willing to test whatever I can (the device is not in "productive" use).

iweiss Wrote:
-------------------------------------------------------
> bodhi Wrote:
> > You are on the right track, almost there. Let
> me
> > take a closer look.
> >
> Let me know what additional information I can
> provide. I'm willing to test whatever I can (the
> device is not in "productive" use).

Everything looks fine. U-boot installation has 2 parts: flashing uboot image and uboot env image. Sine you have not got to that point, the env location does not have anything yet, so the CRC error is expected when running new uboot with kwboot.

You could install u-boot without problem from Arch. Your rootfs /etc/fw_env.config needs to have the definition
/dev/mtd0 0xc0000 0x20000 0x20000

so that the envs can be accessed without CRC error.

The mtdparts should remained unchanged as stock.
Remember to follow the instruction exactly (should copy and paste).

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

bodhi Wrote:
-------------------------------------------------------
> Everything looks fine. U-boot installation has 2
> parts: flashing uboot image and uboot env image.
> Sine you have not got to that point, the env
> location does not have anything yet, so the CRC
> error is expected when running new uboot with
> kwboot.
>
> You could install u-boot without problem from
> Arch. Your rootfs /etc/fw_env.config needs to have
> the definition
> /dev/mtd0 0xc0000 0x20000 0x20000
>
> so that the envs can be accessed without CRC
> error.
>
> The mtdparts should remained unchanged as stock.
> Remember to follow the instruction exactly (should
> copy and paste).
Thank you for the help. Uboot is upgraded and working flawlessly.

Hello Bodhi,

I've installed Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi.tar.bz2 on pendrive and I have U-Boot 2015.10-tld-1 (Nov 06 2015 - 16:19:43 -0800) on my Zyxel NSA310. I don't have my original uboot env settings as I've lost them long time ago when I started messing up with my NAS. Recently I've bought a new hard drive and because of that I've upgraded uboot and I now would like to have rootfs on pendrive instead of hdd as it was previously. So far I was able to change uboot env to the point where DTB file, uInitrd and kernel are loaded from usb to ram after reset and kernel starts. It seams I have bootargs set incorrectly as kernel finishes with panic as it cannot mount usb as rootfs. I was trying to use root=LABEL=rootfs as you have in uboot env setting but it doesn't work and I'm still getting kernel panic even though usb is labelled rootfs. Could you please tell me what needs to be set for the kernel to use usb as rootfs? As far as I remember for hdd the setting was root=/dev/sda5

nrg-fv,

WIth the new U-Boot 2015.10-tld-1 default envs image, there is no need to change envs to allow booting a different drive. What you should do is to ensure that the boot drive meets the requirements:

Quote
B. Flashing default u-boot envs image

r1. There must be only one partition among all partitions from all drives that contains the kernel files. The 2 kernel files are /boot/uImage and /boot/uInitrd.
r2. The partition that contains the 2 kernel files must be partition 1 in a disk drive
r3. The partition that contains the rootfs must be labeled rootfs
r4. The rootfs partition is recommended to be type Ext3 (this is not a hard requirement, ext4 should boot OK, but Ext3 will ensure no problem).

So the bottom line is if you have only one rootfs in a single Ext3 partition, which is labeled as rootfs, then you're all set.

If you have changed a few envs while trying to set it up, then pls post the output of

fw_printenv

or

printenv

in serial console. And I'll take a look.

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

Hello,
I have a problem erasing blocks on iomega iconnect:

root@iomega:~# dmesg | grep -i "bad"
[ 0.606393] Scanning device for bad blocks
[ 0.677099] Bad eraseblock 1122 at 0x000008c40000
[ 0.700207] Bad eraseblock 1448 at 0x00000b500000
root@iomega:~# /usr/sbin/flash_erase /dev/mtd0 0xc0000 1
libmtd: error!: bad eraseblock number 6, mtd0 has 6 eraseblocks
flash_erase: error!: /dev/mtd0: MTD get bad block failed
error 22 (Invalid argument)

is it beacuse nand bad blocks?

Emil Wrote:
-------------------------------------------------------
> Hello,
> I have a problem erasing blocks on iomega
> iconnect:
>
> root@iomega:~# dmesg | grep -i "bad"
> [ 0.606393] Scanning device for bad blocks
> [ 0.677099] Bad eraseblock 1122 at
> 0x000008c40000
> [ 0.700207] Bad eraseblock 1448 at
> 0x00000b500000
> root@iomega:~# /usr/sbin/flash_erase /dev/mtd0
> 0xc0000 1
> libmtd: error!: bad eraseblock number 6, mtd0 has
> 6 eraseblocks
> flash_erase: error!: /dev/mtd0: MTD get bad block
> failed
> error 22 (Invalid argument)
>
> is it beacuse nand bad blocks?

No, your bad blocks are way out from mtd0. This error is because your mtd parts definition is not correct. mtd0 should be 1MB in size. Let's get the output of

cat /proc/cmdline
cat /proc/mtd
fw_printenv mtdparts

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



Edited 1 time(s). Last edit at 01/13/2016 08:41AM by bodhi.

Yes, you are right. I think I have messed up something:

root@iomega:~# cat /proc/cmdline
console=ttyS0,115200 \ mtdparts=orion_nand:0xc0000@0x0(uboot),0x20000@0xa0000(env),0x300000@0x100000(zImage),0x300000@0x540000(initrd),0x1f400000@0x980000(boot) root=/dev/sda2 rootdelay=10 3
root@iomega:~# cat /proc/mtd
dev: size erasesize name
mtd0: 000c0000 00020000 "uboot"
mtd1: 00020000 00020000 "env"
mtd2: 00300000 00020000 "zImage"
mtd3: 00300000 00020000 "initrd"
mtd4: 1f400000 00020000 "boot"
root@iomega:~# fw_printenv mtdparts
## Error: "mtdparts" not defined

Emil,

Your mtdparts definition is still a stock definition so you can't flash the new u-boot env image.

To install new u-boot you must redefine mtdparts. And this will disable booting stock OS in NAND. And if you already run the new Debian rootfs on USB then redefine mtdparts before flashing the envs image:

fw_setenv mtdparts 'mtdparts=orion_nand:1M(u-boot),3M@1M(kernel),-@4M(rootfs)'

If you have already flashed new u-boot image without error, keep it that way (it only occupies the the first 512K of this mtd0). Or if you want to make sure, flash it again anyway.

And post the log of your flashing if you need confirmation.

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

Hello bodhi,

Here are my envs

NSA310> printenv
CONTRY_TYPE=FF
FEATURE_BIT=00
MODEL_ID=A203
PRODUCT_NAME=NSA-310
VENDOR_NAME=ZyXEL Communications Corp.
arcNumber=4022
baudrate=115200
bootargs=console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 rootfstype=ext4
bootcmd=run scan_usb; run usb_boot
bootdelay=3
ethact=egiga0
ethaddr=XX:XX:XX:XX:XX:XX
filesize=2bec30
kernel_addr=480000
load_dtb=ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-nsa310.dtb
load_uImage=ext2load usb 0:1 0x800000 /boot/uImage
load_uInitrd=ext2load usb 0:1 0x1100000 /boot/uInitrd
mailline=Linux yes
nandEcc=1bit
nandEnvBase=100000
scan_usb=usb start
stderr=serial
stdin=serial
stdout=serial
usb_boot=run load_dtb; run load_uImage; run load_uInitrd; bootm 0x800000 0x1100000 0x1c00000

Environment size: 756/131068 bytes

I've also noticed you are recommending to use ext3, I've used ext4 could that be a problem?



Edited 1 time(s). Last edit at 01/14/2016 02:18PM by nrg-fv.