TFTP status 2016.05 U-Boot Kirkwood - GoFlexNet

I've been loading env variables via dhcp / tftp from an OpenWrt router:

setenv preboot 'dhcp $uenv_addr boot/preboot.u-boot && env import -t $fileaddr $filesize && run uenv_run'

This has the nice combination of getting ip addresses, netconsole setup and other variables all from a common server. Unfortunately, the return status of the dhcp or tftp command doesn't reflect the case where dhcp succeeded, but the file was not loaded. This happens for example, when the flash drive is unplugged from the router. This leads to unexpected behaviour.

On success, status is true:

GoFlexNet> if dhcp $uenv_addr loadthis; then echo loaded ok; else echo loaded bad; fi
DHCP client bound to address 192.168.1.3 (3 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: #
	 10.7 KiB/s
done
Bytes transferred = 11 (b hex)
loaded ok

On dhcp failure, status is false:

GoFlexNet> if dhcp $uenv_addr loadthis; then echo loaded ok; else echo loaded bad; fi
No link on egiga0
loaded bad

On tftp failure, status is true!

GoFlexNet> if dhcp $uenv_addr loadthis; then echo loaded ok; else echo loaded bad; fi
DHCP client bound to address 192.168.1.3 (5 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: *
TFTP error: 'file /mnt/horou/loadthis not found' (1)
Not retrying...
loaded ok

Workaround on success, status is true:

GoFlexNet> setenv filesize; if dhcp $uenv_addr loadthis && printenv filesize; then echo loaded ok; else echo loaded bad; fi
BOOTP broadcast 1
DHCP client bound to address 192.168.1.3 (4 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: #
	 10.7 KiB/s
done
Bytes transferred = 11 (b hex)
filesize=b
loaded ok

Workaround on dhcp failure, status is false:

GoFlexNet> setenv filesize; if dhcp $uenv_addr loadthis && printenv filesize; then echo loaded ok; else echo loaded bad; fi
No link on egiga0
loaded bad

Workaround on tftp failure, status is false:

GoFlexNet> setenv filesize; if dhcp $uenv_addr loadthis && printenv filesize; then echo loaded ok; else echo loaded bad; fi
BOOTP broadcast 1
DHCP client bound to address 192.168.1.3 (5 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: *
TFTP error: 'file /mnt/horou/loadthis not found' (1)
Not retrying...
loaded bad

The results are similar for the TFTP command instead of the DHCP command. This is not what I expected, but the workaround seems to be fine.

As a related question, is there anything that prevents tftp from loading a file that is too large? I don't think that should be an issue, I just thought about it while I was working on this.

edit: I found another workaround is to clear fileaddr and filesize before calling tftp. This makes the subsequent env import fail and prevents it from reloading variables from a previous tftp call. It's important to clear both fileaddr and filesize otherwise env import doesn't return false.

On success, status is true:

GoFlexNet> setenv fileaddr; setenv filesize; if dhcp $uenv_addr loadthis && env import -t $fileaddr $filesize; then echo loaded ok; else echo loaded bad; fi
BOOTP broadcast 1
DHCP client bound to address 192.168.1.3 (4 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: #
	 11.7 KiB/s
done
Bytes transferred = 12 (c hex)
loaded ok

On dhcp failure, status is false:

GoFlexNet> setenv fileaddr; setenv filesize; if dhcp $uenv_addr loadthis && env import -t $fileaddr $filesize; then echo loaded ok; else echo loaded bad; fi
No link on egiga0
loaded bad

On tftp failure, status is false!

GoFlexNet> setenv fileaddr; setenv filesize; if dhcp $uenv_addr loadthis && env import -t $fileaddr $filesize; then echo loaded ok; else echo loaded bad; fi
BOOTP broadcast 1
DHCP client bound to address 192.168.1.3 (4 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: *
TFTP error: 'file /mnt/horou/loadthis not found' (1)
Not retrying...
loaded bad

Eureaka! I realized that clearing both fileaddr and filesize makes dhcp return the correct status:

GoFlexNet> setenv fileaddr; setenv filesize; if dhcp $uenv_addr loadthis; then echo loaded ok; else echo loaded bad; fi
BOOTP broadcast 1
DHCP client bound to address 192.168.1.3 (3 ms)
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.3
Filename 'loadthis'.
Load address: 0x810000
Loading: *
TFTP error: 'file /mnt/horou/loadthis not found' (1)
Not retrying...
loaded bad

I tested this on the other cases as well, and I believe this is the winner!



Edited 2 time(s). Last edit at 10/14/2017 05:27AM by plasticassius.

plasticassius,

Which version of u-boot? at serial console:

ver

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

GoFlexNet> ver
U-Boot 2016.05-tld-1 (Jun 12 2016 - 13:27:19 -0700)
Seagate GoFlex Net
gcc (Debian 4.9.2-10) 4.9.2
GNU ld (GNU Binutils for Debian) 2.25

plasticassius,

I am not sure about the strange network behavior that you saw. I would have to try it myself when I have a chance.

File size should not be a problem for kernel files (which are quite small). But of course you can't load file that are too big (any thing close to the RAM size).

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

bodhi,

Thanks for looking this over. My guess is that tftp is checking the values of fileaddr and/or filesize to determine the status that it returns. If they are deleted, then false is returned, else true. However, when tftp fails, they are not deleted, rather they still contain the values from a previous call. This makes it work correctly for the first call to tftp since fileaddr and filesize are deleted at that point; however, for any subsequent call that fails, they retain the value from before.

At this point, I am deleting fileaddr and filesize before each call to tftp, and the status I'm getting from tftp is always correct. So, my problem is solved.

plasticassius,


> At this point, I am deleting fileaddr and filesize
> before each call to tftp, and the status I'm
> getting from tftp is always correct. So, my
> problem is solved.

Cool!

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

Thanks for the great stuff!

bodhi,

Are you interested in fixing the U-Boot bug that prevents booting from flash drives? I'll explain why I think it's a U-Boot bug.

Out of about 10 flash drives including Kingston, Verbatim and Transcend of various models, I've only had 3 not produce the following failure:

GoFlexNet> load usb 0 0x800000 /boot/uImage
load usb 0 0x800000 /boot/uImage
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
 ** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **

GoFlexNet> ver
U-Boot 2016.05-tld-1 (Jun 12 2016 - 13:27:19 -0700)
Seagate GoFlex Net
gcc (Debian 4.9.2-10) 4.9.2
GNU ld (GNU Binutils for Debian) 2.25

Of the 3 that worked, 2 were Kingstons and 1 was Transcend; however, I've tried other Kingstons without success. Also the Transcend only works when unpartitioned (notice load usb 0 above), not when it has a partition table. Also, these drives work flawlessly in every other way, so I don't believe they're of low quality.

The thing that convinced me that this is due to a U-Boot bug is that if I load uImage, uInitrd and kirkwood-goflexnet.dtb by tftp, all of the flash drives I've tried then go on to boot when they have rootfs on them. This means that the only thing that's failing is the usb read done by U-Boot. Debian has no problem with that same flash drive plugged in to that same unit. All of this happens in the same fashion on two different GoFlexNet units. I guess that (but haven't verified) they would boot as well if I had U-Boot read it's files from a SATA drive.

I do want to have my rootfs on a flash drive since it's the only way I've found to reliably spin down the hard drives. Otherwise, Debian periodically spins them up again. The main reason why I started to boot by tftp in the first place is that I didn't think it was possible to find any more working flash drives. Now, they all work.

plasticassius,

> I'll explain
> why I think it's a U-Boot bug.

It is a really a lack of resilient USB driver in u-boot (this "EHCI timed out on TD" is a known behavior)). It is well known that u-boot booting is picky about the types of flash drives. If you use Sandisk brand, I don't think you will have problem at all. Other types of flash drives are some good, some bad (due to the same hardware quirk). I tried virtually all models of Sandisk flash drives on these plugs. The only one that is bad for booting: Ultra Fit USB 3.0 32GB, which works perfectly as rootfs.

Note that all "bad" drives can be used as rootfs without problem, since Linux kernel driver is quite good in dealing with those brands.

But I do have a newly rebased u-boot 2017.07 for all Kirkwood boxes that I supported in the u-boot thread. This version incorporated a patch from one of our forum members that will hopefully allow all marginal brands of flash drives to boot. I have a lot of confidence in this patch (excellent works).

I just have not had enough time to release the new u-boot. But I will soon, no ETA, though :)

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



Edited 1 time(s). Last edit at 10/16/2017 03:45AM by bodhi.

That's great news about the flash drives patch. I'll be looking forward to the release.