You are here

Is there any way to try out a nightly build on Loco M2 XW?

8 posts / 0 new
Last post
Is there any way to try out a nightly build on Loco M2 XW?
I'm unable to downgrade (from 5.6) to 5.5.10 get "Wrong Firmware version is uploaded. Please upload the correct version and try again."
If I try to upload a nightly build for the XW I get "invalid firmware" error.   

Do I have any options to try this out on this hardware?  


I finally got it to go.  
I finally got it to go.  
Had to flash it from 5.6   

I did not have any luck flashing from 6.04 like the instructions mentioned with the nightly builds.
Kept beating my head against the wall trying and trying to downgrade to 5.5 and trying "unsigned" versions of 6
that would not allow me to flash the nightly build.   

I'm up & running now.  

For future reference:
For future reference:

​Use TFTP to do the upload not the Web UI. This is a new requirement with the latest AirOs versions.
Please explain a bit further.
Please explain a bit further. 

Does this only apply to certain newer versions and not 5.5 or 5.6?   
​Or if flashing betas released candidates or nightly builds?

Also Can you refer me to *which* TFT process should be followed?  
On the web there are different variations some say to use -e and -f to allow bootloader overwrite and some do not.  
​Some instruct to simply just upload the image file and you're done.
Others say immediately after flashing and resetting to stop the boot and

mtdparts default
On startup before letting it boot the new system.   

​Which of these apply and when? to TFTP flashing Aredn and not using the web interface?   

Moving forward all AirOs GUI
Moving forward all AirOs GUI flashing will be deprecated due to the restraints put on by the new checks in their system, TFTP currently allows a higher reliability and a better chance of success.

The normal TFTP install steps are documented in the AirOs manual and on the AREDN website here:  under the section "Recovery installation of AREDN firmware via TFTP "

All the other methods you have heard of that require entering commands are deep level recovery when all else fails to get a piece of hardware back (should only happen in REALLY extreme cases.) In a normal install and recovery state you should be able to do it all with just the button on the device or power brick.

Can you detail or tell me what you know in terms of what combinations or actions (that people do) would cause the loss of the radio calibration data (Intersil called it the PDA when it was built into the chipset)? 

PDA = Private Data Area  (or something like that).  

Here's an OLD reference if you are wanting some entertainment..

And OH YES!!  Good 'ol Genesis Mode!!!  LOL   

Yuck!  I'm Old now.   

Destroying the caldata on the
Destroying the caldata on the devices AREDN currently supports on Ubiquiti ( I recall TPLink is similar but would have to verify all details before I say it follows all of these details) is actually very hard.

Most common method I understand is that high voltage surges fry the chip, usually from an ungrounded node ‘near’ a lightning strike and the build up of voltage on the pairs of the network cable.

After that you get into developers just plain making mistakes that ends up overwriting the data. This isn’t easy to do in the current system, the boot loader protects the config portions and the images created by the build system current tag the config space as reserved read only. This makes it pretty darn hard for us to mess and somehow damage the chip data, we can’t do it without messing up at a very very low level,..

Next method would be something in the bootloader system, it has a concept of data and config portions and shouldn’t  (thought I haven’t tested it) let you damage the  config table in just a firmware flash via the reset button with TFTP. It has some low level commands when you are plugged onto the serial port that can read and write arbitrary data and they could probably be used to write raw data to the partition that holds the config, but these are not commands that would be ordinarily used either. If you manipulate some of the saved environment details you could make all of the above dangerous but again that requires a conscious act to change these variables.

An extension of the bootloader and th developer mistakes is also possible where honestly I can’t say how but between a combination of bad code and what seems to be the bootloader messing up (possibly because of the bad code) I know we really thrashed a few devices during some recent testing,

I want to say from memory we might of erased caldata on at least one unit (TpLink) but we were also asserting some manual control over some chip pins accidentally that we have no clue where they went. I don’t recall off hand any Ubiquiti devices loosing caldata as part of the recent major changes, I know we knocked the bootloader around and got into some very funky states but I can’t off hand recall us not being able
to recover the units after, but there have been so many tests it’s possible/probable I’m forgetting an incident.

So ultimately it’s not impossible, but it’s not the easiest thing to break either. If we get other devices that might change, but at least with current Ubiquiti that’s where we are.
Thank you I appreciate you
Thank you I appreciate you answering and sharing.   
​I am interested in the low level stuff.  
And playing around with it.   
Not that much of a developer yer but very interested especially around the network and low level RF chipset stuff.  
I'll share here what I learn.  



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer