Community

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.

alt text

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.

Scott G

Woohoo! It works!
Working board

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

Scott G

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?

Scott G

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

Scott G

@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.

Scott G

@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)

Scott G

@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/

Scott G

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?

Scott G

@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.

Scott G

@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.

Scott G

Double-check that you have RX and TX connected correctly - they're easy to get swapped, as the usual convention is to connect TX of one device to RX of another.

Also, you can check that you're getting bits by cating /dev/ttyS1, or using a terminal program like minicom or screen.

Scott G

@Maximilian-Gerhardt When I was looking at the datasheet, I was wondering if the PWM hardware would by capable of running addressable LEDs, as the hardware is capable of much more than just a square wave. It's really awesome that you got it working!

Did you tackle trying to make it into an OpenWRT package?

Scott G

Well, I have some related sadness: I just spent several days of free time getting a utility to control the PWM hardware to work well, and getting it packaged in the Openwrt build system.

Don't get me wrong - this integration with the kernel build system is a better solution than userspace programs that randomly poke memory, but it is a bummer to have a few hours of work totally invalidated.

Scott G

What all can it do? By the looks of it, it's maybe a quad-half H--bridge, good for driving two DC motors or one stepper? And the other connector is for power input? What's the main IC?

I think I want one! I have no idea what to do with it, but I think I want one anyway!

Scott G

@peanut I got the Ethernet jack LEDs working.
relevant thread here

The specific bit of device-tree magic was to add my new gpio-leds:

gpio-leds {
	compatible = "gpio-leds";
	system_led: system {
		gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
	};
       user_led: user {
		gpios = <&gpio0 0x11 GPIO_ACTIVE_LOW>;
	};
       eth_y_led: eth_y_led {
		gpios = <&gpio0 0x10 GPIO_ACTIVE_HIGH>;
	};
       eth_g_led: eth_g_led {
		gpios = <&gpio0 0x0F GPIO_ACTIVE_HIGH>;
	};
};

Note that they're on GPIO0.

And something like this:

echo netdev > /sys/class/leds/eth_y_led/trigger
echo eth0 >/sys/class/leds/eth_y_led/device_name
echo "link tx rx" >/sys/class/leds/eth_y_led/mode
echo 20 >/sys/class/leds/eth_y_led/interval

That said, it wasn't really worth it

After I got it working, I realized that the only thing it could tell me is that there were packets. The most important part of link lights is usually to know that there's link, but it's pretty unusual (but not impossible) to get Power over Ethernet without also getting, well, Ethernet. This means that on my PoE board, the Ethernet link light is only very slightly different than a power LED, which we already have. And until I get default values into the device tree, it doesn't come up until I turn it on from userspace anyways.

Still, it's nice to know how to turn GPIOs into LEDs, allowing a wide range of triggers. If this thing were in a box, I might use those ethernal Ethernet link LEDs as a heartbeat, or as an disk activity indicator.

Scott G

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?

Scott G

Alright, just a little more of a status update:

The boards are working great! The 12V output works for running ~12 watts of strip LED, and the Omega can control it as expected. The 5V and 3.3V lines look great, even with some load, and the Omega's running without any issues. The whole thing is even pretty efficient - with a strip of LEDs, the Omega is putting out more heat than the converter.

There was a bit of a hiccup where I failed to recalculate a resistor value when I scaled the design from 3.3V output to 12V output. That was throwing the compensation loop out of whack, causing the 16 KHz ringing. After a bit of learning about feedback compensation and some circuit modeling, I calculated the correct value, and it's much happier now - no more audible whine, no more 16 KHz ripple in the 12V line. I'm now willing to declare that this design works!

I've even fixed the rest of my boards. Aside from the first one, which gave it's life for that resistor value fix, the other three work great.

I'm eager to go make something cool with this set up, but I know I got some people interested in a group buy. If I'm going to make that happen, I have a few questions for everyone:

I've soldered the Omega down to my boards, but it should also be possible to put 2mm headers under them. Digikey is currently out of stock of the headers that are known to work, but I have some alternatives coming in a few days. The headers are only a few bucks, and only add ~4mmm of height. How many people would prefer to solder their Omega's down permanently?
There's always going to be some ripple in the 12V line when it's under full 15W load - how much ripple is acceptable to you? I'm aiming for <150 mV, but I'm going to have to add a capacitor to get that. Am I the only one who cares? I might just leave an unpopulated pad for people to add a capacitor if they need it.
We could save a few bucks if we decided
I have the 12V output header controlled by a MOSFET, controlled by a GPIO. That GPIO, however, floats on startup, causing the 12V output header to be unpredictable. I want to add a resistor to hold it either high or low during power-up. So, 12V on by default, or off?
If I run a group buy of these, how many are people interested in? They get cheaper the more that I order at once. $100 for 1, $78 for 4, $65@10, $60@40, $45@100 (approximate)... What kind of price range would people be interested in? How many?

P.S.: If anyone who works for Onion is reading, and wants to order and sell these so that I don't have to, that would be great! I'd love for my design to be the official PoE dock, and I wouldn't mind avoiding the trouble of running a group buy.

Scott G