Best posts made by Scott G

Hi All,

I've put together a board design that (hopefully) powers an Omega over Power-over-Ethernet (IEEE 802.3af).
This is the standard that powers many wireless access points and VoIP desk phones using 48 VDC over standard network cables, with up to 15 watts in the initial 802.3af version of the standard.

My board is the smallest thing I could make has electrical isolation from the PoE supply, while supplying 12V@1A, 5V@2A, and 3.3V@2A. Of course, it also connects the Ethernet communications to the Omega, and has an expansion header, as well as 12V and 48V power headers. I specifically designed it for 12V to support powering external hardware, such as 12V LED lighting strips.

The design files are up on Github, and I've just ordered parts for the whole thing. At this point, it's an untested design, so I'll have to wait several weeks to get one in my hands to see if it works.

If anyone is interested in something like this, let me know, and I'll keep you posted about how it goes. There's a non-zero possibility of a group buy if this design works.

Woohoo! It works!

A few more images at https://github.com/zeroping/OmegaPoE.

Known issues to work on:

• I got one resistor wrong (560 kohm != 560 ohm)
• I need a pull-down on the line that enables the 12V output - right now, it's on at boot
• The flyback converter has some instability that I don't like, and it happens to be at ~16 kHz, which means you can hear it. I want to get to the bottom of that.
• I want to test it with some stacking headers, rather than direct-soldering like the first one
• I want to see if I can modify a devicetree to set up the Ethernet LEDs and tactile switch correctly

But hey, I now have the silliest Ethernet-controlled light:

https://photos.app.goo.gl/YS3vjE3wA9x9WqXG7

Hi all,

I recently made some hardware that made me want to modify my Omega2's device tree. It was a bit of a mess. While I finally got something that worked, the steps had looked like this:

(Hint: these are probably the instructions you want)

• Following the instructions to get the LEDE build system here
• Building a system image using those instructions and then discovering that is has almost no packages installed
• Update feeds:
  ./scripts/feeds update -a
• Install all packages:
  ./scripts/feeds install -a
• Tweaking anything I want in the image config:
  make menuconfig
• Tweaking anything I want in the kernel config:
  make kernel_menuconfig
• Copying in my modified device tree fragment:
  cp modified_OMEGA2.dtsi ./target/linux/ramips/dts/OMEGA2.dtsi
• Pre-downloading package sources:
  make download
• Trying to build:
  make -j 8
• Fixing and poking and recompiling or outright disabling packages that don't build:
  make package/{packagename}/{clean,compile,install} V=s
• Finally getting an image for sysupgrade:
  ls ./bin/targets/ramips/mt7688/lede-ramips-mt7688-omega2p-squashfs-sysupgrade.bin

All that just to make the LEDs on my Ethernet port blink! (using kernel LED triggers from Ethernet traffic)

There seems to almost be a better way. From what I can tell, there's a few places with patches enable allow runtime modification of the device tree, as well as loading of those device tree fragments in /sys/kernel/config.

I believe this is how the Beaglebone cape manager system works, and it looks like the Raspberry Pi people are using a similar system too to support hardware variants. It seems to have been adopted for some SoC's with FPGA's, as the hardware can change while you're booted.

Does anyone know why this isn't in the mainline kernel yet? Or in the Onion's kernel? It seems like it would be really useful for any time you add hardware that has existing kernel support, and it looks like it's been around for a couple of years.

Is there some other (better) way to do this? Had anyone had success with device tree overlays in the bootloader on the Omega?

I admit that I tried patching this in myself (the configfs device-tree modification is the specific part that's missing), and I had lots of failures. Can anyone can point to a concise patchset that does it? I'd be interested in trying again. Has anyone else gotten this working?

Reviving an old thread to post what I found:

On my Omega 2+, the uboot environment seems to start at 0x2000 in /dev/mtd1, and runs to 0x5fff, thus my /etc/fw_env.config files looks like:

# Configuration file for fw_(printenv/saveenv) utility.
# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors
/dev/mtd1               0x2000          0x4000          0x1000

@brolly759 I'm curious to see your design - I think mine is a bit overkill.

I opted for up to 15W power, and I wanted a 12V line, meaning I have a 3.3V, a 5V, and a 12V converter. I also wanted to do electrical isolation, as I think you're supposed to for IEEE 802.3af devices that can come into contact with a person. The electrical isolation means the giant flyback transformer, as well as optoisolation and the associated passives to (hopefully) filter the opto feedback loop.

That said, yeah, it ends up being expensive. It's still working well though, and I think I'll get more boards assembled for my own use at some point.

I've been impressed by how much cheaper the RJ45 jacks with integrated magnetics have gotten. There are even some (harder to find) with built-in rectifier diodes, which saves even more components.

@peanut Oh, they're not connected in any fancy way at all. Since the Omega has the PHY, and since there's no broken-out pins specifically for the LEDs, I wired them up to GPIO15 and GPIO16. They function in that I can light them up by flipping them high as GPIO's, but I haven't gone farther than that yet.

My understanding is that I can tweak the device tree a bit to say "No, this isn't a GPIO pin, it's an LED that is controlled by a GPIO" and then "This isn't just an LED, it's an LED that needs to be connected to an LED trigger that comes from the eth0 link status". The kernel handles it from there.

There are LED's in many routers connected in the same way, it's just a matter of messing with it, and since the DTB appears to be baked into the firmware, I think that means rebuilding the firmware. Pretty low on the list of things to do at the moment.

In case you're wondering, there are two other LEDs. One is just a general-purpose indicator. The other comes on when the 12V output MOSFET is turned on. I left that one unpopulated, but I had a little room there, and wanted to play with a reverse-mounted LED shining through the FR-4 circuit board. If you look carefully, there's text in the layers of the board, which should get silhouetted by the LED.

Place on Github that has schematic PDF (and I don't know why I can't direct-link to the PDF)

@Aurélien-Fi At the end of the day, the MT7688 chip in the Omega2 is really targeted in in a router, access point, or similar. It's good at connectivity (Wifi AP and client, ethernet), but not at things like cameras or displays.

The chip in a Raspberry Pi is the opposite - note that a Pi Zero doesn't have any way to connect Ethernet, but has HDMI, a camera interface, and USB device support.

My point here is that different processors have built-in hardware support that will make some things easier than others. The Pi Cameras are only so cheap because of the dedicated hardware in Pi.

So, this isn't something the Omega2 will be really great at doing. That said, there are ways. The main issue is one of bandwidth - I2C isn't that fast, so I'd look at SPI, UART, or especially USB. I think the Omega2S even breaks out PCIe, which opens lots of possibilities.

The little Arduinos don't have much connectivity for cameras either, so solutions for them might work out. For example: http://www.arducam.com/arducam-mini-released/

Is there any reason u-boot couldn't be configured to pass root=/dev/mmcblk0p1 to the kernel and driectly boot a Debian system? Or maybe someone has already done such?

@Earl-Baugh I don't want to them not be for sale, but that doesn't mean that I necessarily want to be the one to sell them.

My big driver is that they're darned expensive to get manufactured in small quantities (like $100 for 1, $85 for 2), but they're affordable if you make several hundred (~$30). I want to be able to buy several for my own use, and I want to hardware design to be open, so I'd be delighted if there were a group buy that made it cheaper for me.

The catch is that, well, I already have a job. I don't really want a second job. Manufacturing these and selling them sounds like a second job. An ideal situation for me would be if some company wanted to take care of all of the annoying business details, run a group buy, and I got the boards I wanted cheaper (Here's looking at you, Onion Corporation!).

If someone knows of an assembly house that makes things like this easy, speak up. I'm getting my first ones assembled by Macrofab, but if there's enough interest, I will probably check out a place like CircuitHub or Seeed Studio.

Anyone have any other recommendations?

That said, this will all have to wait for my first four to arrive, so I can find out if I've totally botched the design or not.