On 26/07/2012, at 8:42 PM, Luka Perkov wrote:
> On Thu, Jul 26, 2012 at 11:58:48PM +0100, Tim Fletcher wrote:
>> On 26/07/12 00:43, Frank Horowitz wrote:
>>> The device needs to be powered off and back on to come back from this
>>> hang.
>>>
>>> I've setup the environment above to be able to boot into the still
>>> stock iconnect firmware (other than the re-flashed u-boot and my
>>> environment, of course) using the command "run flashload". This works
>>> after setting another environment variable "setenv machid 692" so
>>> that I can get into the stock iconnect firmware. Strangely enough,
>>> the usb disk is NOT found by linux even in this environment!
>>>
>>> I haven't re-created my entire old u-boot environment variable
>>> setings yet, but am suspicious that this anomalous usb behavior (even
>>> when booted) is somehow related to u-boot.
>>>
>>> Incidently, without getting access to that disk, it will not be
>>> simple for me to find my (hopefully correct) version of the old,
>>> stock, u-boot binary. Is that lying around anywhere on the net?
>>>
>>> Any advice as to how best to proceed would be greatly appreciated!
>>
>> I have an iconnect with the new uboot on too, and the usb does seem
>> more picky about some usb storage devices.
>>
>> The disk should work in any other linux system and the way that I
>> have recovered from this is to copy the uImage and uInitrd off on to
>> a tftp server and just boot it with tftp.
>>
>> When this happened to me I found that cleaning and reseating the usb
>> connection helped but that might just be coincidence, I always use
>> the single usb port for the boot device too this might make no
>> difference mind.
>
> Frank, did kwboot work on your device?
>
> I do not have iConnect device. I just cleaned up the code and prepared
> it for upstream.
I didn't try kwboot because it uses the older 1.1 version of the ROM code (from
my fading memory of a thread on this list) which was claimed to not work. I
just gritted my teeth and flashed u-boot from a copy on the (same, now
misbehaving) USB drive. Strangely enough, I couldn't get tftp to work in the
old stock version of u-boot either, even after trying from both an OSX and a
Linux (Ubuntu) implementation. Do you think it is worth a try now, with the new
u-boot version in flash?
Further to the usb problems, I've been reading through a bit of the u-boot usb
mass-storage code, and it appears that the READ_CAP ERROR *might* be due to a
timing issue/race condition, since there is magic number of "3" iterates
through a retry loop upstream of the place that prints the error message.
Also, I noticed that the "usb storage" and "usb part" commands give an
incorrect display (storage) and produces a hang (part). I'm beginning to have
my doubts about the the robustness of the USB stack here. A pity, really, since
the iomega is actually a pretty decent little debian box.
I've just retried a boot into the orginal stock firmware, and attempting to
mount my usb disk. No go. Dmesg doesn't even show the disk being found, even
usb mass storage is apparently built-in to the kernel. Does something about
u-boot mess up the usb controller even after booting into linux? I'm
suspicious, because this disk used to be fine under the old u-boot. (The main
reason I keep the original firmware in flash is to serve as a "rescue floppy".)
I'm happy to test anybody's new version of u-boot, but this bug is well and
truly beyond me!
Frank Horowitz
[email protected]
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
