[Resolved] uboot install on E02 fails

[bodhi]

@nwestfal,
If you're sure that U-boot image was flashed OK without error, then it is not bad at all. Serial console would be the easy path to get it booting from power on. No need for JTAG.

@moonman,
With that bad block, fw_setenv will not work.

[nwestfal]

I did confirm that fw_setenv does not work with the bad block.

@bodhi,
When I dump the image and compare with md5sum it seems okay:

$this->bbcode_second_pass_code('', '
-bash-3.2# mkdir new
-bash-3.2# cd new
-bash-3.2# /tmp/nanddump -nol 0x80000 -f /tmp/new/uboot-pogo_e02.kwb /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
-bash-3.2# cp ../uboot-pogo_e02.kwb.md5 .
-bash-3.2# ls -l
-rw-r--r-- 1 root root 524288 Jan 1 14:07 uboot-pogo_e02.kwb
-rw-r--r-- 1 root root 53 Jan 1 14:09 uboot-pogo_e02.kwb.md5
-bash-3.2# md5sum -cs uboot-pogo_e02.kwb.md5
-bash-3.2#
')

I'll have to rig up a serial cable. I don't have a usb to ttl adapter. Will a usb to db9 work? I'm sure I can dig up an old cdrom audio cable and I have some female db9 connectors.

[pepedog]

$this->bbcode_second_pass_quote('', 'I')'ll have to rig up a serial cable. I don't have a usb to ttl adapter. Will a usb to db9 work? I'm sure I can dig up an old cdrom audio cable and I have some female db9 connectors

[nwestfal]

@pepedog
Yeah, I gathered that after seeing some db9 RS232 to ttl converters online. Looks like I'll have to order a usb to ttl converter.

[nwestfal]

As an alternative, would it be a good idea to re-flash the original stock uboot image? It doesn't look like the script saves the original anywhere during the process, so does someone have an original E02 stock uboot image?

Does stock uboot use 0xc0000 for environment? (I would guess not since it worked fine with stock)

[nwestfal]

@bodhi,
In my poking around, I found similar issue in a thread on another forum where you interact with user chackoc. His seems to have been the same issue, with bad block 6 preventing writing out the environment. He even had black E02 like mine.

Based on some info in that thread, I was able to create /etc/fw_env.config, containing:

$this->bbcode_second_pass_code('', '
-bash-3.2# cat /etc/fw_env.config
/dev/mtd0 0xe0000 0x20000 0x20000
-bash-3.2#
')

Then I did:

$this->bbcode_second_pass_code('', '
-bash-3.2# /tmp/flash_erase /dev/mtd0 0xe0000 1
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xe0000 done
-bash-3.2# /tmp/nandwrite -s 0xe0000 /dev/mtd0 uboot-pogo_e02.env
Writing data to block 7 at offset 0xe0000
-bash-3.2# /tmp/blparam | grep ethaddr | cut -d= -f2
00:xx:xx:xx:xx:xx
-bash-3.2# /tmp/fw_setenv ethaddr 00:xx:xx:xx:xx:xx
-bash-3.2#
-bash-3.2# ./fw_printenv
baudrate=115200
bootcmd=usb start; setenv letter 9;for type in usb; do for disk in 0 1 2 3; do if ${type} part ${disk};then setexpr letter $letter + 1;run load;fi;done;done;
bootdelay=3
bootm=echo Booting from ${disk} ...; run setargs; bootm ${loadaddr};
bootz=echo Booting from ${disk} ...; run setargs; bootz ${loadaddr} - ${fdt_addr};
console=ttyS0
fdt_addr=0x800000
fdt_file=/boot/dtbs/kirkwood-pogo_e02.dtb
importbootenv=echo Importing environment (uEnv.txt)...; env import -t $loadaddr $filesize
load=echo Attempting to boot from ${type} ${disk}:1...;if run loadbootenv; then run importbootenv;fi;echo Checking if uenvcmd is set ...;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;echo Running default loadzimage ...;if run loadzimage; then run loadfdt;run bootz;fi;echo Running default loaduimage ...;if run loaduimage; then run bootm;fi;
loadaddr=0x810000
loadbootenv=load ${type} ${disk}:1 ${loadaddr} /boot/uEnv.txt
loadfdt=load ${type} ${disk}:1 ${fdt_addr} ${fdt_file}
loaduimage=load ${type} ${disk}:1 ${loadaddr} ${uimage}
loadzimage=load ${type} ${disk}:1 ${loadaddr} ${zimage}
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),-(rootfs)
setargs=setenv bootargs console=${console},${baudrate} ${optargs} root=/dev/sd${letter}1 rw rootwait ${mtdparts}
uimage=/boot/uImage
zimage=/boot/zImage
ethaddr=00:xx:xx:xx:xx:xx
-bash-3.2#
')

But I gather from the above thread that it is an exercise in futility, as chackoc found that uboot env is hard coded at 0xc0000 and when he rebooted it didn't recognize the env at 0xe0000. He also noted that when he rebooted the device showed up in his router with a random MAC address.

What was interesting was that he was able to boot back to stock just by removing his USB device. Will this current uboot do that?

Also he noted later in the thread after he hooked up serial console that Arch was in fact booting but something screwy with the networking was going on that he was able to fix by changing some networking settings. It gives me hope that I may be able to get it working after I get a serial console going. Unfortunately it will be a couple of weeks until I receive the usb to ttl converter that I just ordered.

In the meantime, is there a stock uboot image available that I could flash back to? Or is it too risky?

Update:
On further reflection I think I may be in good shape. I took a look at pogo_e02.h, and noted that the contents of CONFIG_EXTRA_ENV_SETTINGS is identical to the output from "./fw_printenv"

I'm thinking all I need to do is create /boot/uEnv.txt on my root filesystem and add:

$this->bbcode_second_pass_code('', '
ethaddr=00:xx:xx:xx:xx:xx
')

I'm a n00b of course, but if it works the way I think it does, when uboot encounters the bad block at 0xc0000 it will use the defaults in CONFIG_EXTRA_ENV_SETTINGS, boot the USB device, then import any environment settings from /boot/uEnv.txt.

Can anyone confirm?

[bodhi]

@nwestfal,

Yes, you are in good shape. Except that ethaddr. Whether it will generate a random local ethaddr for you, I'm not sure.

[nwestfal]

@bodhi
Well that's not my actual MAC. I just replaced the actual bytes with xx's since I didn't want to post my real MAC.

[bodhi]

@nwestfal,

I know, I meant I'm not sure you can reboot without setting the MAC addr (whether this U-boot does generate random ethaddr).

[nwestfal]

I was able to solve this, even without having a serial cable.

First, having successfully flashed the new uboot, but of course still unsuccessful flash of the uboot environment at 0xc0000, I decided to go ahead and try rebooting. Unfortunately the /boot/uEnv.txt didn't help, as it didn't pick up the ethaddr from it. So that's a no go as an alternative. But I did note that I had activity on the external usb hard drive, and the light on the front of the E02 turned green after awhile, so I surmised that Arch was at least booting up.

Since I didn't have a serial cable to see what was happening during the boot process, I decided to plug the usb drive into my OpenSUSE desktop to mount the alarm parition and take a look at the journal. Assuming your Arch partition is mounted on /mnt/alarm, You can view the journal from the Arch installation on the USB drive with the following command:

$this->bbcode_second_pass_code('', '
journalctl -D /mnt/alarm/var/log/journal --no-pager
')

I saw the following lines:

$this->bbcode_second_pass_code('', '
Jul 03 18:46:23 alarm systemd-networkd[119]: lo : gained carrier
Jul 03 18:46:23 alarm systemd-networkd[119]: eth0 : link configured
Jul 03 18:46:23 alarm systemd[1]: Started Network Service.
Jul 03 18:46:23 alarm systemd-networkd[119]: eth0 : could not bring up interface: Cannot assign requested address
')

At this point it is pretty clear that Arch is booting fine. I am providing addtional troubleshooting steps I used below. For anyone having this problem, the ultimate solution was a pretty simple fix, which you can skip down to if you want.

I decided to do a little more troubleshooting. I wanted to see the output of ifconfig and dmesg, so I enabled an rc.local script:

Create file /usr/lib/systemd/system/rc-local.service with the following contents:
$this->bbcode_second_pass_code('', '
[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
')

Then to enable the service you have to create a symlink:

$this->bbcode_second_pass_code('', '
cd /mnt/alarm/etc/systemd/system/multi-user.target.wants/
ln -s /usr/lib/systemd/system/rc-local.service rc-local.service
')

This enables use of an /etc/rc.local file to execute any commands we want to. There is probably a better alternative that is more systemd compliant, but it gets the job done.

Then I created /etc/rc.local with the following contents:

$this->bbcode_second_pass_code('', '
#!/usr/bin/bash
/root/info.sh > /root/info.txt
')

This just runs a script in root's home directory and redirects output to a text file so that I could view the file later mounted in the desktop machine again.

The contents of /root/info.sh were:

$this->bbcode_second_pass_code('', '
ifconfig -a
echo "========"
dmesg
echo "========"
journalctl --no-pager
')

Dont forget to grant execute permission on both /etc/rc.local and /root/info.sh

You can put whatever other troubleshooting commands you want to in there as well. I was mainly interested in the output of ifconfig. So with all that in place, I plugged the drive back into the E02 and powered it on, let it boot up and waited for the light on the E02 to turn green. After waiting a sufficient amount of time, I powered it off again and mounted the drive on the desktop machine again. I checked the contents of /root/info.txt and saw from the ifconfig output that the MAC address was all zeroes:

$this->bbcode_second_pass_code('', '
eth0: flags=4098<BROADCAST,MULTICAST> mtu 1500
inet6 fe80::24b:5bfc:8a9e:b148 prefixlen 64 scopeid 0x20<link>
ether 00:00:00:00:00:00 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 11
')

And this of course was preventing the eth0 interface from being configured properly.

Here is the ultimate fix. We need to assign a MAC address to the eth0 interface before the networking comes up. This can be done by editing /usr/lib/systemd/system/systemd-networkd.service and adding the following line to the [Service] section:

$this->bbcode_second_pass_code('', '
ExecStartPre=/sbin/ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
')

The command "/sbin/ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx" sets the hardware address of the eth0 interface.

(the actual address to use can be found on the label affixed to the bottom of the E02)

So my systemd-networkd.service looks like this:

$this->bbcode_second_pass_code('', '
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

[Unit]
Description=Network Service
Documentation=man:systemd-networkd.service(8)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
After=dbus.service network-pre.target systemd-sysusers.service
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
Wants=network.target

[Service]
Type=notify
Restart=always
RestartSec=0
ExecStartPre=/sbin/ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
ExecStart=/usr/lib/systemd/systemd-networkd
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_CHOWN CAP_DAC_OVERRIDE C
AP_FOWNER
ProtectSystem=full
ProtectHome=yes
WatchdogSec=1min

[Install]
WantedBy=multi-user.target
')

After making the above change, I plugged the drive back into the E02, powered it on and low and behold, it shows up in my router with the correct MAC address and I can ping it and ssh into it!

An alternative to using "/sbin/ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx" is to use the macchanger utility, but since that is not installed by default, that's a bit more difficult to do since you would have to install the files from the package manually. That was going to to be my next attempt if the above didn't work, but happily the ifconfig workaround worked just fine.

A possible gotcha could be if a system update ever overwrites the file /usr/lib/systemd/system/systemd-networkd.service. A solution to this could be to just replace the symlink under /etc/systemd/system/multi-user.target.wants/ with the actual systemd-networkd.service file.

UPDATE: I did a system update with "pacman -Syu", which installed a new version of systemd, and it did indeed clobber my modifed /usr/lib/systemd/system/systemd-networkd.service. I've been experimenting with trying to set up a separate systemd service to run the command, so far unsuccessful. For now I just replaced the symlink with a copy of the systemd-networkd.service file.

UPDATE - 9/9/2014 - I discovered that instead of modifying the file systemd-networkd.service, another (arguably better) way to fix the MAC address is with the use of a .link file placed under /etc/systemd/network/.

I created a file /etc/systemd/network/98-fix-no-hw-address.link which contains:

$this->bbcode_second_pass_code('', '
[Match]
MACAddress=00:00:00:00:00:00

[Link]
MACAddress=00:xx:xx:xx:xx:xx
')

This means any interface that comes up with hardware address 00:00:00:00:00:00 will have it's hardware address set to 00:xx:xx:xx:xx:xx. The file name is prefixed with "98" in order to supercede the default link file in /usr/lib/systemd/network/99-default.link.