Onion just released a .dxf drawing for the Omega2S footprint, and a .pcb file presumably containing a footprint (but not in KiCAD format), see here.
Comparing the .dxf with my Omega2S footprint (which I designed for manual soldering), the pads are smaller and reach a bit more under the Omega2S. This requires extremely precise placement because of the very close proximity of the non-masked shield housing contacts to pins C24/B24. If the part is only a fraction of a mm shifted right or left, C24 or B24 gets shorted to GND (shorting C24/XTAL_FREQ_SEL is particularily interesting, because then the Omega starts up, but with a wrong frequency, so console has a weird baud rate, and everything else depending on timing does not work. That's how I learnt to pay attention to these pads...)
So I think the official footprint is probably ok for automatic placement, but mine is safer for hand-soldered prototypes.
Voila, you got working SDK buildroot for ramips MT7688 (Omega2) Rest is the same as all others cross-compile buildroots (export env STAGING_DIR as $BUILDROOT/staging_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.16/bin/, export PATH with STAGING_DIR as first in chain, etc).
If using e.g. make, remember to use variables for corss-compile:
Notice how the printed MAC on the Onion does not match the output of the program. That's because the sticker is actually wrong
The sticker probably isn't wrong. The board has two network interfaces, and as a result it has two MAC addresses.
They're related by a simple numerical substitution rule in one of the startup scripts.
is actually 40:A3:6B:C1:17:FF for br-wlan0
The above is the formally assigned address
and 42:A3:6B:01:17:FD for apcli0
Whiel that is a self-assigned address derived from the above via a substitution rule. Note the "2" in the first octet, which indicates it is a "locally administered" (vs unique-in-the-world) MAC address.
As for why the lowest octet in br-wlan0 is FF and not FD as assigned, that might be some sort of bug or odd decision in the startup code - seems like it wouldn't be a sequencing mistake at the factory, or the locally administered address would show it too.
If you poke around in the first few MTD partitions you can probably find what is actually saved in the flash chip.
@Stephane-Foloppe i'm not sure if you know that for the most part this is a user to user community forum. some admins from onion post every once in awhile but they have not had a large presence. but there are some really knowledgeable people [i'm not one] who will help you out best that they can. but yes, i think many of us agree that it's a disappointment.
I agree with your view with regard to the security of IoT. Although this blog I've come across (6 Reasons Why the IoT is the future of Industrial Organizations is only just an overview of IoT's future, it does tell a lot how we should be more concerned of how secure should we be when the time comes — since one does not need to get closer in order to do something harmful.
Yeah, having it in a simpler way would be more desirable sincere there are persons who aren't that much into technology. Anyway, thanks for initiating this thread. Got a lot of ideas from it!
you could try downloading & installing a fresh copy of b160 firmware. there is something amiss in the current install/package. you can spend many hours trying to find the problem or get a new copy of the firmware and see if that works.
Looks like your connection to Onion Community was lost, please wait while we try to reconnect.