uboot 2016.09-1 whats new

[moonman]

You can do it using a switch/router. It tells you eth0 does not exist, so run ifconfig or ip addr and see what your NIC comes up as.
Yoy don't need to change subnets for every device, that's why you create an alias with a different ip to listen on

[summers]

Tried it on my NSA25 last night, had to log on the router and set up 10.10.10.0/24 routing by hand. By default only 192.168.2.0/24 propagated on the lan.

[moonman]

Never had a problem on my network with dd-wrt or openwrt routers. Wireless is a hit or miss usually. Definitely works with just a plain switch or crosswired cable.

[summers]

Ah - yes I was going out over the wifi to collect the 10.10.10.* data.

IIRC my router is a very minimal openwrt set up, at least its a standard linux kernel with standard ip routing, ip tables etc.

Adding the route was a simple:

$this->bbcode_second_pass_code('', '~ # ip route show
195.166.130.140 dev ppp0 proto kernel scope link src 80.189.236.80
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1
default via 195.166.130.140 dev ppp0
~ # ip route add 10.10.10.0/24 dev br0
~ # ip route show
195.166.130.140 dev ppp0 proto kernel scope link src 80.189.236.80
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1
10.10.10.0/24 dev br0 scope link
default via 195.166.130.140 dev ppp0 ')

[hfrjkse]

This is what happens when I plug in an regular FAT32 USB flash drive:

U-Boot 2016.05-1 (Jun 20 2016 - 02:00:11 -0600) Arch Linux ARM
Pogo E02
gcc (GCC) 6.1.1 20160602
GNU ld (GNU Binutils) 2.26.0.20160501
Hit any key to stop autoboot: 0
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
scanning usb for storage devices... EHCI timed out on TD - token=0x80128d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x80008d80
...
...
...
and so on...

[hfrjkse]

Any solution?

[summers]

Can't say for sure, but looks like a USB hardware fault.

As you've grabbed das uboot output, I guess you have a serial term attached to the UART. So what I'd be tempted to do is to interrupt das uboot, and type the boot commands by hand. You should soon be able to see what is failing. Hopefully you can find enough up to boot into linux, and for them should be easier to dig into whatever the fault is.

Know this isn't much help, but seems the best i can say remotely ...

[hfrjkse]

No, I just used lan terminal as suggested by moonman. I wouldn't say that it's flashdrive hardware fault as I does boot every time when you use terminal to issue "reboot" command, but it does not reboot after powering up. Seems to me that there is something wrong with timing in uboot - cold start needs more time for flashdrive to initialize. I'm only guessing though.

@moonman - if you need me to do some further tests, let me know.
Flashdrive: Kingston GT101 G2 8GB

[summers]

OK - from what i can see on the pogo e02, you have fw_printenv and fw_setenv; so if you can boot into arch in any way, you can set the uboot env variables.

So get familiar with what the uboot env variables do to boot the machine (examine with fw_printenv).

Then taken from http://lists.denx.de/pipermail/u-boot/2016-April/252524.html
http://git.denx.de/?p=u-boot.git;a=commit;h=319418c01c95f3c6a0d37a4d82740b437aa23b0e

try adding:

$this->bbcode_second_pass_code('', 'setenv usb_pgood_delay 10000')

Note you'll need to make sure this command gets run before the USB is probed - so you'll have to modify some of the other env variables that get run ...

Hassle is i think you'll need to do it via the fw_* commands and not via uEnv.txt - as your uboot isn't getting as far as reading the uEnv.txt ...

N.B. What I should have added, is the command above I believe extends the USB time out to 10s. I think the error you have see, in the past has be caused by USB timeouts - so increasing the timeout (beyond USB specs) has solved on other hardware. It also explains why a warm reboot works ....

[hfrjkse]

Sounds reasonable. I'd have to install some extra package though? Otherwise setenv is not reconized. I'd like to also know what is the default delay (getenv?) and change it gradually, not necessarily straightaway to 10s.