Topics created by cas

@cas several years ago a google engineer released some review on usb-c type plugs/cables that revealed just how many of them were faulty, seemed incorrect/bad resistors being most common. google engineer Benson Leung published a list of ok cables/adapters on his google+ page which ceased to exist recently and someone else created this posting of his findings, https://bensonapprovedcom.wordpress.com/ google sells some models on their store but they are pricey. at least much more than in 2016. i bought off that list on amazon and spent ~$12US for a kit that had a usb-c male to usb-a male cable [for attach a android phone to win 10 box] plus a usb-a female to usb-a female to create the needed usb-a female host port for OTG. ebay has some also, usually cheaper.

And going.... root@Omega-FA93:~# uptime 07:33:38 up 727 days, 13:49, load average: 0.00, 0.00, 0.00 root@Omega-FA93:~#

@Andres-Santos A more recent set of steps can be found here. There's not a huge difference, basically clean the feeds before updating and installing them and symlink to the preferred .config.

@luz Yes, that's what I would be hoping too. One of the hurdles to the other IP holders even contemplating open source would be the proprietary MIPS situation and NDA's etc. With that barrier overcome, it should be easier down the line to release code openly. But it would have to make business sense first of course.

@cas @György-Farkas Thanks for the input! I've moved this topic to the Technical FAQs

@opti-gregor @Artem-Reznikov The solution I used was to build a custom firmware with USB support compiled in and with the omega dts file modified such as to enable the u-boot and u-boot-env partitions as read/write. Then with the O2+ in a mini-dock and dumps of the u-boot and u-boot-env from my kickstarter O2+ on a USB, I flashed the O2+ with the modified firmware and just wrote the kickstarter copies to the relevant partitions. It was a total hack, so I have no idea whether this worked by design or I was just lucky that it worked. Note, the officially sanctioned way to replace the bootloader is via an ethernet expansion installed in an expansion dock as documented here Firmware Flashing With Web Recovery Mode and I'd recommend anyone try that first before doing what I did. Further, note this useful clarification regarding the documented procedure by @Pavel-Metrokhin in Bootloader for Omega2S and Omega2S+ Building the Onion software at the time I did this (Feb 2018) was a hit and miss affair, which is why I did it the way I did. @Artem-Reznikov Apologies for the late reply, somehow I managed to miss your question in the past.

The underlying issue here has been covered many times before. The Omega 2+ has an ill-chosen flash chip, which cannot expose its full capacity unless operated in a 4 byte mode which is incompatible with the configured expectation at boot. There is no actual working poweroff command, and there never has been one. However, programs that reboot without putting the flash chip back in a boot compatible mode end up hanging in a tight loop at boot, giving the impression of being sort of "off". Also note that unexpected reboots, such as triggered by a watchdog will also result in a hang, rather than a successful boot. As the Omega 2 (non +) flash chip fits entirely in 3-byte addressing mode, it should not experience this problem. Flash chip commands can be found in the relevant data sheets, as well as the U-Boot and Linux Kernel sources.

@Cezane Our wifi warp core is a pre-compiled wifi driver that you can use to build your own image. We released it in March, see this post for more details. Our build system is available on GitHub and we have a Docker image on DockerHub with the environment setup and ready to go. Happy hacking!

@Douglas-Kryder Yes, I remember skimming through them at the time, but now they're gone. Anyway, I'd hazard a guess that the journey starts somewhere with learning MIPS programming at least. The closest I got to baremetal programming was x86 assembler on MS-DOS +/- 25 years ago, so I guess I'll try and reacquaint myself with that while I wait for my "See MIPS Run, 2nd edition" to arrive....

@Maximilian-Gerhardt said in Omega2 GPIO input voltage: So, the schematic is wrong. Have fixed it and added a warning note to the photo and submitted a pull request in github.

@cas said in Omega2+ losing power / powering off unexpectedly: The pin pad underneath: <photo> "Thermal pad is connected to GND layer through vias (recommend 4X4 pins and the aperture is 10mil)." /active-semi/ These holes are (thermal conducting) vias between the top and the bottom copper layers of the PCB. The bottom of the dock was very hot to the touch, so I suspect I burnt out the ACT2801 which appears to have a pin pad underneath. Actually upon closer inspection of the pin pad, one if the holes appears to be blocked with a silver substance and I can't help wondering if that's solder (if that's at all possible). Spot the mistake.... It's a "perfect" solder material "bead" / "ball" - it's OK here - no problem. I don't have Power Dock - so I'm speculating based on active-semi's ACT2801 data sheet and Onion's schematics only. VIN Input Voltage nom. +5V (range +4.5 ... 5.5V), Absolute Max. +6.5V VIN_OVP Over Voltage Protection typ. +6.0v (range +5.5 ... 6.5V) So 5.4V was OK. The IC has an Input Current limiter. ILIM Input Current Limit - Omega's setting is R2=2.4kΩ about 1A - so the input current couldn't have been more than 1A. (It was 1.8A / 1.9A!) Please try to recall. You might have done something else or something else might have happened. Or simply this is one of those cases where Murphy's Law happened to be working.

A very high resolution board picture would help a lot.

I came across this thread while trying to solve this problem and found the above answer not to work for me. 'ethtool' is not installed by default and is not found in the opkg package manager. I wish to avoid installing packages if avoidable anyway. I hope my solution is useful to someone. My solution: ifconfig | grep 'eth0 ' | cut -d ' ' -f 11 How it works: On my Omega2, ifconfig returns a set of information about 4 network interfaces, br-wlan, eth0, eth0.1 and lo. I chose to extract the MAC address of 'eth0'. The output of ifconfig is piped into the grep command which extracts only lines containing 'eth0 ' (note the space on the end, it eliminates 'eth0.1'). The output of grep is only one line and it contains the search term, the MAC address we're looking for and other information we do not need. This is piped into 'cut' with arguments to make it to treat space characters as column delimiters and return only the 11th column. Limitations: I had hoped to come up with a cross platform solution but this has certain expectations of the output of ifconfig. For instance, it doesn't work on MacOS. If you're hoping to develop on another machine and test on the Omega2, you might want to use some kind of platform detection.

@Allison-K Thanks. I figured that in all likelihood it's all going to come from the docs github repo eventually, so I already fixed something in the docs and sent a pull request a few days back. Am waiting for it to be actioned. I'll do a ticket re the pdf generation frequency though.