[OpenWrt-Devel] Cannot flash UBNT Loco M2

[Matthias Schiffer]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20160312/00fd772d/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel