[OpenWrt-Devel] Cannot flash UBNT Loco M2

[John Crispin]

On 12/03/2016 14:53, Matthias Schiffer wrote:
> On 03/12/2016 02:08 PM, John Crispin wrote:
>>
>>
>> On 11/03/2016 15:28, Matthias Schiffer wrote:
>>> On 03/11/2016 02:46 PM, Joseph Marlin wrote:
>>>> We certainly haven't. I've tried applying these patches - http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/39001
>>>>
>>>> to no avail. I still get hit by a "Error code 2 - Firmware Check Failed". 
>>>>
>>>> I'm really suspecting this comes down to an intentional check by Ubiquiti to prevent us from flashing, as described on this list and in this comment on the ticket - https://dev.openwrt.org/ticket/20982#comment:16
>>>>
>>>> I have not yet had a chance to change the image header and CRC to look like a Ubiquiti image, nor do I know how to offhand, but I hope to give it a shot soon.
>>>
>>> Hi,
>>> there is a lot of misinformation about this issue going around, in
>>> particular, the wiki is plain wrong (I'll fix that some time soon.)
>>>
>>> Here's what's going on:
>>>
>>> * OpenWrt had wrong partition sizes in its UBNT AirMax firmware for a long time
>>> * Old AirOS and the corresponding U-boot version had a bug that made U-boot
>>> ignore the partition sizes defined in the firmware image. This made OpenWrt
>>> work with the old U-boot despite its broken partition sizes
>>> * The new AirOS has been fixed in this regard (but contains a new bug).
>>> This also means that the broken OpenWrt images don't work anymore and can
>>> cause even more breakage
>>> * The new U-boot/AirOS did *not* change the flash layout. Both AirOS 5.5.x
>>> and 5.6.x use the same flash layout, the changed flash layout reported in
>>> the wiki is caused by broken OpenWrt images!
>>> * The OpenWrt trunk since r48829 and the CC branch since r48849 are fixed,
>>> meaning they define the correct partition sizes
>>> * The "Newly-erased block contained word ..." messages are a consequence of
>>> a missing patch in CC that has been backported as r48849 (the new U-boot
>>> doesn't remove flash protection, so the flash is just read-only from
>>> OpenWrt; TFTP recovery is the only way to upgrade in this state)
>>> * AFAIR "Error code 2 - Firmware Check Failed" is the consequence of a bug
>>> in the new U-boot: after flashing an image with broken (smaller) partition
>>> sizes, the recovery doesn't accept images with the original partition sizes
>>> anymore
>>>
>>> Getting out of this state is not easy: you have a U-boot on your device
>>> that doesn't accept correct images, and an OpenWrt version that doesn't
>>> allow writing to the flash.
>>>
>>> Through a serial console, you can try fixing the settings in U-boot; when I
>>> tried this the last time, I wasn't able to do so, but maybe I did something
>>> wrong. The U-boot console has a few interesting settings (I forgot the
>>> exact commands, but the "help" command should tell you everything you need
>>> to know):
>>>
>>> * You can reset the MTD layout to the defaults. This makes the recovery
>>> accept correct images again. Unfortunately, in my experiments, this setting
>>> was not permanent even when I saves the environment after resetting the
>>> layout. In the hindsight, I remember there being a setting to disable flash
>>> protection, maybe that would made have the environment saving effective.
>>>
>>> In the end, I fixed this by creating a patched OpenWrt image that allowed
>>> me to write to the uboot and uboot-env partitions; this allowed me to write
>>> back backups I had made of the uboot and uboot-env before I broke the flash
>>> layout by flashing OpenWrt. Obviously, this does not work if you don't have
>>> backups...
>>>
>>> * If you don't plan to ever go back to AirOS again, it might be okay to
>>> just ignore the broken MTD layout in the U-boot settings. Get into the
>>> U-boot console, reset the MTD layout, start recovery, and flash an OpenWrt
>>> version after trunk r48829 or CC r48849.
>>>
>>>
>>> I hope this helps. I'd be interested if you find a way to parmanently reset
>>> the MTD layout from the U-boot console; unfortunately, I don't have a test
>>> device available at the moment.
>>>
>>> Regards,
>>> Matthias
>>>
>>
>> Hi Matthias
>>
>> looking at a US and EU image i see only 1 bit changed in the header. and
>> reading what you wrote above it sound like a small change to our image
>> generation process will make EU unit flashable again ? if so do we have
>> a patch or could you tell me which unit to order on amazon.de that has
>> the latest uboot with this bug fix so i can fix the regression in trunk.
>> sound like a lot of trouble and all caused by a small regression that is
>> easy to fix or did i miss something here ?
>>
>> 	John
> 
> I don't known anything about the differences between the EU and US
> versions, but I expect that my analysis is valid for both.
> 
> AFAICT, OpenWrt did define the XM layout incorrectly from the beginning
> (~2009), this was fixed by my patch series 2 weeks ago (r48828 - r48830).
> As OpenWrt is fixed now, the trunk snapshots should just work.
> 
> In CC, these have been backported as r48846 - r48848 (and r48849, which is
> also necessary so OpenWrt works with the new U-boot version), so 15.05.1
> will also contain the fix, whenever it is released.
> 
> The problem is that flashing the broken images on devices with the new
> U-boot will break the MTD layout in a way that U-boot's TFTP recovery will
> not accept the fixed images after that. I don't know of a way to fix this
> without a serial console (and even with one, this is not trivial.) I could
> try creating a "fix image" that can be flashed through recovery even
> without a console and fixes the MTD layout...
> 
> Matthias
> 

mixed up 2 things, the images i looked at were tplink, i'll backport
those fixes you mentioned.

	John
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel