NSA325 unbricked but with corrupted UBoot environment

[psychokiller]

Hi all!
while tinkering with a Zyxel NSA325 with stock UBoot and a working Arch Linux ARM installation, I tried to update UBoot to latest version using
$this->bbcode_second_pass_code('', 'pacman -S uboot-nsa325')
and I quickly discovered that the package installation isn't working as described here https://archlinuxarm.org/forum/viewtopic.php?f=53&t=8857&start=50#p48421.
So I quickly switched to trying to installed as described here https://archlinuxarm.org/forum/viewtopic.php?f=53&t=8857&start=50#p48437 but I almost surely forgot to execute the command
$this->bbcode_second_pass_code('', ' mtdparts=orion_nand:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)')
and once rebooted the NSA325 was bricked: no signal on the serial console.

I downloaded and unpacked uboot-nsa325 package and did a UART Boot with kwboot like described here https://forum.doozan.com/read.php?3,12381,17420#msg-17420 (but with UBoot from the ALARM package.
Once the NSA325 booted and from UBoot I used a FAT formatted USB key with the same UBoot to flash it to the NAND using fatload and nand write (do not remember exact commands anymore).

UBoot was finally restored and working, but missing environment and showing the
$this->bbcode_second_pass_code('', '*** Warning - bad CRC, using default environment')
message when powering up.
I ignored that and, on a laptop with XUbuntu I worked my way through this steps:

- inserted a USB key
- formatted with a single primary partition with ext2 (actually tried ext4 first but ALARM UBoot didn't like it )
- mounted it under /tmp
- unpacked boot image and rootfs taken from here http://fl.us.mirror.archlinuxarm.org/os/nsa3x0/ onto the key
- inserted into one of the rear NSA325 ports
- switched NSA325 on
- watched NSA325 loading boot image and then booting root fs

Everything seemed fine, but the missing UBoot environment means ethaddr isn't set and the booted ALARM does not get an ip address since the eth0 MAC address is 00:00:00:00:00:00 as shown by the "ip addr" command output:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether [color=#FF0000][b]00:00:00:00:00:00[/b][/color] brd ff:ff:ff:ff:ff:ff
')

Now I actually have no idea how to sort things out and get things properly set: anyone willing to help?

Thanx for your support!
Paolo

[summers]

The original should kept the env variables in a different offset. So by changing the order we should be able to read the original variables and recover the Mac address. I'll give the commands tomorrow, as need to check carefully.

[summers]

OK first off check in dmesg the mtd partitions that have been defined. Mine are:
$this->bbcode_second_pass_code('', '[ 2.152563] 10 cmdlinepart partitions found on MTD device orion_nand
[ 2.158952] Creating 10 MTD partitions on "orion_nand":
[ 2.164201] 0x000000000000-0x0000000c0000 : "uboot"
[ 2.169485] 0x0000000c0000-0x000000100000 : "uboot_env"
[ 2.175051] 0x000000100000-0x000000180000 : "old_uboot_env"
[ 2.180950] 0x000000180000-0x000000200000 : "key_store"
[ 2.186507] 0x000000200000-0x000000280000 : "info"
[ 2.191606] 0x000000280000-0x000000c80000 : "etc"
[ 2.196662] 0x000000c80000-0x000001680000 : "kernel_1"
[ 2.202133] 0x000001680000-0x000004640000 : "rootfs1"
[ 2.207624] 0x000004640000-0x000005040000 : "kernel_2"
[ 2.213103] 0x000005040000-0x000008000000 : "rootfs2"
')
Yours probably won't look like this - I ensured I kept all the original partitions, bit picky of me - but I wanted to keep them. What this means is that you can see that there are two uboot env variables areas:
0xc0000 (length 0x40000) - this is the area for the more recent uboot to use. For me its on /dev/mtd1
0x100000 (length 0x80000) - this is what the original uboot on stock used. For me this is on /dev/mtd2

Now yours will probably be in different partitions - but think to note is the offset. Thats where the env variables are.

So install uboot-tools it will give the commands fw_printenv and fw_setenv.

Then change /etc/fw_env.config to point to the two locations above. So for me:

/dev/mtd1 0x0 0x20000 0x20000

or

/dev/mtd2 0x0 0x20000 0x20000

as my env variables are at the beginning of the mdt1 and mtd2 partitions, yours may be different.

Then hopefully "fw_printenv" will give the env variables - and you can access the mac address.

If you can't get hold of fw_printenv, well just grab a copy of the relevent /dev/mtd filesystems, e.g. use "dd" or the like.

Then in an editor you can easily find the env variables and extract the ethaddr variable, which contains the mac address.

[psychokiller]

OK summers. Thanx for your support. Will check later and give feedback.
I can add that restoring MAC address isn't top priority, since there is a sticker on the rear of NSA325 with what I think is the original MAC address along with a bar code.

Setting MAC in the UBoot environment and having a clean UBoot env is the top priority, along with checking things in general, since my badly gone attempt to flash, leading to bricked NSA325 might have left everything in a bad state.. or not?

Another thing is that right now I cannot install anything from the ALARM installation I can boot, since eth0 has no MAC address, does not get an ip (nor can set any manually) and pacman cannot reach any repository. I might install require packages by downloading them on a different host and install on NSA325 by trasnferrig them with a USB key... uboot-tools absolutely necessary?

I will anyway read your instructions carefully later and will be back with the results.
Paolo.

[summers]

Thought you could set the mac address on an interface, at least my beagle farm, which just has ethernet across USB OTG, which has no native address - just sets a random address. e.g.
$this->bbcode_second_pass_code('', 'ip link set dev interface address XX:XX:XX:XX:XX:XX')

Packages you can download on another computer, and transfer via USB, but should be able to do everything via usb e.g.
$this->bbcode_second_pass_code('', 'dd if=/dev/mtd1 of=/tmp/mtd1')
Then move the /tmp/mtd1 file via usb to another computer - where you can open the file in an editor (note it will have a lot on null char in it - so your editor need to be able to handle). Or could use:
$this->bbcode_second_pass_code('', 'strings /tmp/mtd1')
To just see the strings, which is enough to get the environment variables.

uboot-tools would mainly be of help, if you want to set the ethaddr variable from a running linux. Yes you can do the same if you have a uart through to uboot.

[psychokiller]

So, according to dmesg mtd partitions are just two:
$this->bbcode_second_pass_code('', '
[ 21.782114] 2 cmdlinepart partitions found on MTD device orion_nand
[ 21.788419] Creating 2 MTD partitions on "orion_nand":
[ 21.793586] 0x000000000000-0x000000100000 : "u-boot"
[ 21.798962] 0x000000100000-0x000008000000 : "rootfs"
')
So it seems no uboot env variables areas are present anymore...

I probably messed things up when flashing the ALARM UBoot after UART boot.

I managed to set a MAC address for eth0, brought eth0 down and then up to have it get an ip with dhcp, and finally installed uboot-tools directly from the repositories.

What would be the best way to restore an environment? Do I have to change mtd partitions?

[summers]

Actually that looks like how arch would set up the flash - its what I changed on my set up, I changed mine to show what that partitions are, and keep the original firmware on the flash.

So what it says is that for you, the env variables for new uboot will be on the end of /dev/mtd0 and the stock env variables will be on the start of /dev/mtd1. So says they two things to try in /etc/fw_env.config are:
$this->bbcode_second_pass_code('', '/dev/mtd0 0xc0000 0x20000 0x20000') and $this->bbcode_second_pass_code('', '/dev/mtd1 0x0 0x20000 0x20000')
Hopefully one or both should give you access to the old or new env varaibles.

To create again what the new uboot needs, I'd just redo what the install does. So unpack the pacman file, then from the install instructions: https://archlinuxarm.org/packages/arm/uboot-nsa325/files/uboot-nsa325.install do $this->bbcode_second_pass_code('', '
flash_erase /dev/mtd0 0xc0000 1
nandwrite -s 0xc0000 /dev/mtd0 /boot/uboot-nsa325.env') and then write the mac address:
$this->bbcode_second_pass_code('', ' echo '/dev/mtd0 0xc0000 0x20000 0x20000' > /etc/fw_env.config
fw_setenv ethaddr ${mac}').

Your mac address should start $this->bbcode_second_pass_code('', 'ethaddr=5C:F4:AB:xx:xx:xx') - the first three bytes point to the manufacturer - so we know those, then rest are unique for the device, but you should hopefully be able to get them from /dev/mtd1.

It odd, looking at that install script for nsa325, reminds me of how much I hated it - it assumes so much on how your machine is set up, which often isn't true. I wrote a script that probed the machine far more intelligently, but looks like its not used. If I can find it again I'll give it as a link ....

My script for probing the hardware can be found here:
https://archlinuxarm.org/forum/viewtopic.php?f=53&t=10499&p=52403#p52478
If you look at it carefully, you can see what it assumes for how to set up uboot and the flash.

[moonman]

If you still don't have U-Boot flashed (or have the old version that came with the initial instructions script) then download and install uboot-nsa325 with pacman. It will prompt you if you want to flash it, but because it won't be able to find mac address it will actually stop and fail.

You will need to flash u-boot manually:
$this->bbcode_second_pass_code('', 'cd /boot
flash_erase /dev/mtd0 0 4
flash_erase /dev/mtd0 0xc0000 1
nandwrite /dev/mtd0 /boot/uboot-nsa325.kwb
nandwrite -s 0xc0000 /dev/mtd0 /boot/uboot-nsa325.env')

Make sure you've uncommented the line for "dockstar" in /etc/fw_env.config

Then set your MAC address (it probably says what it is on the bottom of the devices):
$this->bbcode_second_pass_code('', 'fw_setenv ethaddr xx:xx:xx:xx:xx:xx')

It should be good to go now in terms of u-boot. If I remember correctly, this new U-Boot expects the standard kirkwood partition layout (i.e. kernel and rootfs on first partition).

Edit: I guess I was typing this message when summers posted his. He's got you covered

[moonman]

$this->bbcode_second_pass_quote('summers', '
')It odd, looking at that install script for nsa325, reminds me of how much I hated it - it assumes so much on how your machine is set up, which often isn't true. I wrote a script that probed the machine far more intelligently, but looks like its not used. If I can find it again I'll give it as a link ....

$this->bbcode_second_pass_quote('', 't')o summers: