@Abhishek Maybe you disabled an IMPORTANT WIFI DRIVER?
https://github.com/Outernet-Project/rxOS/commit/1d6557ab1c40b651cbc4d893591b3a7aa4ea10d5
Why doesn’t it compile? There should be a way to ignore an error or reference a different/older compiler…
P.S. I see that you’re working on it, keep up the good work @Abhishek 
that was a wifi driver for a proto board with a test wifi module. Its not longer in use, and it was never in use on any released build.
Flashing Instructions mentions this: The computer must
have hardware virtualization support (Intel VT-x or AMD-v)
Ah, OK my bad. Maybe we could find/make another wifi driver anyways? I think that one of the problems may be that it uses too much power trying to broadcast a lot farther than it can.
On the final lantern, can we have a separate module DEDICATED to being a hotspot?
If we did this, the chip module would be used to only connect to WiFi networks, and the dedicated network module would be only used as a hotspot.
This would also probably solve driver issues, because I’m not sure that the chip WiFi module was made to be a hotspot 
driver is not the issue.
power: power is a problem not cause of wifi, but overall cause we are trying to power a full linux computer and a fairly power-hungry radio/tuner using a tiny microusb connector and crappy microusb power cables. there isn’t much margin, and the power management IC freaks out if the voltage droops too low, which it does whenever the radio powers up or wifi powers up. This does not indicate a issue with drivers or wifi or anything like that. Its a basic V=IR ohms law issue. Use a good thick, high current USB cable and it works fine. Common cheap usb cables and microusb connectors weren’t designed with 1A in mind. Unfortunately microusb is everywhere and its availabilty and convenience out-weigh its current-carrying limitations. If we had a mini-usb connector, for example - finding the right power adapter with mini-usb output would be a struggle for most people.
Re hotspot: the range issue is also not due to the driver. Its simply cause the on-board “chip” antenna that the wifi module has is pretty low gain. And before anyone suggests adding an external antenna: that voids the FCC clearance.
What I am trying to say is: stop worrying about the “driver”! its not relevant in this context.
I’m not sure what happened, but I had to reflash today. I’ve been having to reboot, after no connection was showing on my wifi or as a hotspot daily for the last few days. I though it may be a wifi problem with my network. I also changed to a 2.5 amp power supply, just to be sure.Today, several reboots didn’t help. The CHIP LED’s just stayed solid after the reboots. The config wipe feature didn’t work, again just solid LED’s. I tried to SSH into it with USB, but it didn’t even show up. Reflashed and it’s running normally again. This is one of the newer CHIP’s, not the one which came in the kit.
Maybe this was just a weird glitch. Let’s see if it happens again.
I just flashed to 4.4 and I think there are still “filesystem corruption upon reboot” issues…
Did the flash, started the CHIP and connected the outernet AP to reconfigure the network to client
mode, did apply and reboot, and it came back reconfigured. So far so good.
However, the /var/log/messages file contains a large block of binary zeroes at the beginning and
then continues with the loggings from the second boot. I think it was not properly synced on the
reboot.
It may be that before doing the reboot it is required to sync, delay a while, maybe sync again,
unmount as many filesystems as possible, delay again, before the final reboot happens.
The NAND flash may be behind in actually writing blocks that the filesystem has already synced.
yes, i have found the nulls in var/log/messages as well. unless you also noticed corruption in other files, I am not very sure this is nand corruption. though I don’t have a good theory on what the problem might be.
the writeable filesystem is already mounted with the “sync” option, which dramatically reduces performance (we can do that cause performance of the fs isn’t really a problem in this scenario), and reboot already does unmounting of all writable file systems. So its definitely not that.
That said, both the nand driver and the ubifs code are in flux, and can be expected to be buggy. The main reason I believe its not a nand corruption issue is cause I only see these nulls in /var/log/messages, never in any other file. So a more probable explanation would have to do with logger and how logging is done.
I have seen problems on other flash platforms (with SD card) as well and my theory is that the
layer that writes the large blocks of data to the flash (the flash blocksize is much more than the
fs blocksize) is lagging behind even when sync and unmount have been done. I would suggest
a delay of a few seconds as the last action after all unmounting and before kicking the reset, to
allow this writing to complete.
But, it is just a guess… on other platforms I have sometimes found the system unbootable after
a scripted “apt-get update && apt-get upgrade && reboot”.
Sync mounting the filesystem is not such a good idea, it wears out the flash and can sometimes
worsen the problems. It is probably better to mount async and call sync() or fsync() when file
writes have been done.
@Jacob_Lysinger, and anyone else who might want to help:
I have added a trial version of the flasher, that can be written as an image to a usb stick. Then you can boot from this USB stick to try and flash your CHIP. This might help people who have not had any luck with VirtualBox or do not have a PC with h/w acceleration, or drivers are interfering etc.
The .img is available at We Moved!
It can be written to a usb stick using dd on linux or any standard methods on other OSes. RPI has a guide here:
Note
Instructions are simple:
Let me know if you try and how it fared. @Jacob_Lysinger, thanks for the idea!
while what you say is true of Sdcards - hence the frequent corruption, raw nand, and ubifs don’t work that way. sdcards have this issue cause the OS never sees the underlying flash blocks, and the controller inside the sdcard can lie to the OS about the data being “commited”. But there is no such controller in the case of raw Nand, the OS does it all.
Suggestion:
To make this even easier… Can we do it like a computer BIOS upgrade?
Basically, the FEL mode would read a certain file on a FAT32 formatted USB drive, and use it to upgrade the CHIP.
Then we wouldn’t have to completely disassemble the outernet setup!
I think it would be useful, but I don’t know how feasible this is…
heh, no - that isn’t possible. FEL mode is a very basic mode running entirely out of the SoC built-in rom. Its extremely limited - and its what makes the SoC essentially unbrickable.
Would it not be possible to have some form of “upgrade” function that lets you upload a new
image via the browser (that will be stored in RAM) and then will replace the flash filesystem with
that upgrade and reboot?
When it somehow fails, a fallback to the method used now is always possible. But at least it
would make it easier to do an update in the normal case (where power does not fail halfway).
thats exactly what the OTA is
But this update wasn’t made available as an OTA file…
I thought an OTA maybe could not make major changes like flash partitioning and filesystem formatting
so it was required to do the FEL mode flashing for those.
But couldn’t there be an intermediate form? many products like routers, cameras etc have such an
update feature that does not require disassembly of the unit.
I notice an error in the use of logger in 3 places in the init scripts:
$DAEMON -v 3 | logger 2>&1
This does not redirect stderr of the $DAEMON to the logger, as the 2>&1 operates on the right side
of the pipe. It should be:
$DAEMON -v 3 2>&1 | logger
Bash has the |& operator which is a shortcut for 2>&1 | but this does not work in sh.
sigh. no - it can’t. routers/cameras have very small firmware images. Show me a 150MB+ firmware image that updates like that.
This update wasn’t made available as OTA cause the previous OTA had issues and those had to be fixed. I thought that was self-evident.
Once again - I must remind this is a work in progress. stop expecting features of a final product from it. repeatedly asking for those just distracts from the main work.
could you do a PR on github?
Well ironically a smooth software update procedure is much more required in a work in progress
product than in a final product. Of course it would be best if it is done by the CHIP community
rather than by one of its users who is already overburdened by other work.
I have lots of things going on as well, but when I find time I might see if it is possible to reflash the
CHIP from inside a program running on it.