Terminus Tech 7 port usb 2 “high speed” hub teardown

7 port usb 2.0 “high speed” hub, with per port power switches and leds. Only shows up as full speed in lsusb. Leds on ports are very bright, power switches only cut vbus line, rather flaky construction, shaking or bumping can cause disconnects. Seems to consume too much power, without external 5V (not included) vbus can be very low. Available on ebay, tmart, dx.com… http://www.ebay.com/itm/371304833792

The fe1.1s chips are meant to support high speed, so…?

Update: When I had it open, connected to a different computer, it showed up reliably as high speed. Back on the original computer, disassembled, still high speed. Case closed up again, it would show up normally as full speed fallback, and only occasionally as high speed. Further testing indicated that the front panel usb socket is the actual cause. Connecting this hub to another high speed hub showed up reliably as high speed.

The sexy input cap is 200uF, 10V. The rocker switches are KCD11, rated 3A 250VAC, or 6A, 125VAC! The crystal is umarked, but must be 12Mhz from the datasheet.




version control of tools – part 2

Oh look! again! Remember kids, it’s not just compilers that you should keep around, but libc/binutils, and all libraries you’re ever going to use.

Today it’s avr-libc, and this gem:

In file included from ../../common/FreqCounter.h:17:0,
                 from ../../common/FreqCounter.c:35:
/usr/avr/include/util/delay.h: In function '__vector_21':
/usr/avr/include/util/delay.h:246:2: error: __builtin_avr_delay_cycles expects a compile time integer constant

Apparently it was always actually a requirement in the notes, but everyone did it anyway. Now, you need to write a wrapper function like this sort of shit:

void do_what_I_say_delay_us(int us) {
     while (us-- > 0) {

Hooray, isn’t that better for everyone! See http://nongnu.org/avr-libc/user-manual/group__util__delay.html for more information, if you can read carefully enough :)

version control of tools

Ahh, it’s always the right thing to do, but normally it’s so heavy to check in things like GCC/Binutils versions into every project. It’s the sort of thing you do if you’re a big serious company, working on big serious things, with big serious support. Besides, I’m not relying on anything weird or esoteric right?


../../common/pjrc/usb_debug_only.c:96:45: error: variable 'device_descriptor' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
static uint8_t PROGMEM device_descriptor[] = {

Thanks for nothing avr-gcc updates. I understand what you’re getting at, but still, this used to compile, and put things in PROGMEM. Now it fails the compile. GCC bug in question is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643, or at least, that’s where it came from. A nice case of, “everybody’s using this code, but it was never actually meant to work, so let’s make it fail for them all, like it was meant to anyway.”

Compilers are awesome.

Installing Eagle 7.3 on fedora 21 x64

So, as before, you need to symlink libssl and libcrypto, but this time, you need to do the symlinking in the normal 64bit lib path.

/usr/lib64$ sudo ln -s libssl.so.1.0.1k libssl.so.1.0.0
/usr/lib64$ sudo ln -s libcrypto.so.1.0.1k libcrypto.so.1.0.0

This is despite the eagle installer saying that it needs the 32bit libraries installed!

mosquitto in OpenWrt which versions are where

With more and more versions of OpenWrt and mosquitto being released with more dependencies and features, here’s a quick overview of what versions are available where.

This is the out of the box versions. An extra packages feed, https://github.com/remakeelectric/owrt_pub_feeds is available for running mosquitto and it’s dependencies on older OpenWrt releases, should you need that functionality. At the time of writing, this feed contains mosquitto version 1.4.2, and libwebsockets 1.3.x.

I should clarify, this is what you get if you build your own images out of the box. Not the version that was available at release day.

Openwrt Backfire (10.03)

Attitude Adjustment (12.09)

Barrier Breaker (14.07)

Chaos Calmer (15.05)


Mosquitto version unavailable 0.15 1.3.5 1.4.2 1.4.2
libwebsockets n/a n/a n/a 1.3.x 1.4.x

Carlo Gavazzi EM210 coupled display panel teardown

The Carlo Gavazzi EM210 series [1] of 3 phase energy meters have a rather neat feature. You can mount them on a DIN rail or panel mount, with the same unit, and the display portion is simply detachable, and plugs back in on the reverse side. This is neat tech, and probably saves on inventory in a few distributor places at least, though I don’t imagine it makes any real difference for the end user, who will mount it once and leave it. Still, the display piece has the control buttons and the LCD display, no batteries, and no contacts. So I pulled it apart :)

I don’t know how it works really, it’s presumably the same method as NFC, by modulating the power draw from a capacitively or inductively coupled connection. It’s cool though. ATMega169 for the LCD control and buttons. Not entirely sure what the crystal is for, it’s marked “KDS3C” but I didn’t look further for a speed marking. Presumably you need a proper crystal to be able to synchronize the coupled connection properly? I don’t believe it’s an RTC crystal, as this is the detachable display portion. I always like seeing cutouts mid PCB for inserting big components.

The trimpot is an interesting idea. It’s used as a “lock”. With it turned all the way one way, the device is considered locked, and this screw access is on the back of the display portion. This portion also has tags for tamper seals, so I guess that’s one way of doing it on the cheap? Presumably just an ADC input to determine lock status.

The oddly slanted through hole parts on the left are the front panel buttons, nice alignment :)

ATMega169 for LCD control, coupled connection

ATMega169 for LCD control, coupled connection

[1] I’d link to them, but their website is junk and doesn’t let you link to products, and requires sign up to get a datasheet, that uses old names. The same sort of stupid games with redirecting you to different websites for different markets for the same device and all the usual terrible product management choices that lead engineers to ignore your products.

SELinux is teh suck – I’ve given up.

I tried, I really did. I let the selinuxtroubleshooter run, I added exceptions, I tried to do it’s bidding and be a joyful comrade marching forwards to a secure perfect future. I’ve given up. Fuck this shit. The last straw was installing nginx, to serve up a few virtual hosts in the form of /home/domain/subdomain/{site,logs}
Errors in the journal like SELinux is preventing /usr/sbin/nginx from getattr access on the file . and then how to run grep on a log and feed it an audit tool that generates exceptions. Oh yes, that’s actually how you’re meant to do things. From past experience I knew it would only allow the first layer of the onion to unpeel and I’d have to keep adding exceptions, so I looked into what it was really complaining about.

Missing labels on THE ENTIRE WEBROOT labelling them as “httpd_sys_content_t” Right. Go fuck yourself SELinux. chcon -Rt httpd_sys_content_t /home/blah/wop No. No. No. I get it, you were only trying to stop me from inadvertently starting a webserver and…. serving web content… Actually, no, that’s not it. I was very fucking explicitly trying to start a webserver. I’d installed nginx, I’d added configs for the virtual hosts, and restarted nginx. That’s pretty damn explicit.

So, I gave up, I set SElinux to “permissive” so I could maybe see logs, and maybe feel inclined to work with it again in the future. But to avoid rebooting, I then did the old “echo 0 > /sys/fs/selinux/enforce” and then restarted nginx again. Now nginx works, but… now the journal is full of “detected unhandled Python exception in ‘/usr/sbin/setroubleshootd'” and stack traces following. So it’s over SELinux. You’re beyond dead to me, and I really, really tried to make it work.

Rum Balls for christmas

Surprise cooking post! Rum balls are somewhat common in some families in Australia around christmas, but about the only thing many of them have in common is being mostly chocolatey, mostly with some sort of alcohol flavour, and normally somewhat ball shaped, and rolled in coconut. Here’s the original recipe copied out of my handwritten recipe book, copied from my mother’s hand written recipe book.


  • 220g sweet biscuits, crumbled
  • 2 tbsp cocoa
  • 1/2 cup coconut
  • 1/2 powdered milk
  • 1/2 glazed cherries
  • 400g tin of condensed milk

Now, that’s the original in the book. I’m sure it’s lovely, but mine are a little different. Firstly, what are “sweet biscuits” ?! In Australia we would use “Scotch finger” biscuits. Here in Iceland, I use “Marie” biscuits. Anything plainish but still sweet is what you’re looking for. In Iceland, at least this year, Marie biscuits come in twin pack tubes, 2x200g. Don’t worry about the 20g :)

Next up, “2 tbsp” In Australia, at least when the recipe was written, that’s a tablespoon, not a desertspoon. (And not a teaspoon) I use 3 regular food eating spoons. (It won’t make much difference in this recipe, but it will in some others)

Powdered milk is an odd product too, but very important in this sort of thing. Skim milk or whole milk doesn’t make an awful lot of difference in this recipe. In Iceland, the only place selling this as of December 2014 that I’m aware of is Fjarðarkaup. MS manufacturers it, but only in 25kg bags. In other countries this is often readily available.

Condensed milk is also unusual. This is most definitely not evaporated milk, don’t even try. In Iceland, this is available in most of the asian groceries, I get it at Mai Thai on Laugavegur. Nestle makes and sells it worldwide, but there’s other brands too. In Singapore for instance, this stuff is used instead of milk in coffee. (It’s a wonderful product, worthy of further mention)

Glazed cherries can be replaced with whatever you prefer, or as I do, simply omitted. (I find the 1/2 cup in the original far too much at least, and as they’re somewhat difficult to find (notice a theme?) here, I just don’t use them)

Finally, notice that there’s no rum in that recipe. I use a good 2-3 shots or so. You want dark rum, but I’d avoid spiced stuff. Austalians would use Bundaberg, here in Iceland I’ve used “Old Navy”, and really any of the dark unspiced carribean rums. It doesn’t have to be fancy stuff.

Ok, ingredients in hand, hopefully. Now what? You just mix them all up. Crumbling biscuits can be tedious. A food processor works really well for this. Once it’s all mixed up evenly, put it in a covered container in the fridge overnight. The next day, (later that week, etc) you fill up a bowl with further coconut, spoon out chunks of the mixture, roll it out to a smooth ball between your hands, then drop it in the coconut and roll it around to coat it. Here’s some pictures of making them

Pile up all this coated balls back into a box and keep them in the fridge. Yummy. A lot easier than it sounds, once you’ve got the ingredients together :)

Rust on OpenWrt – baby steps

Well, it works, at least hello world. I followed the steps here: http://www.cnblogs.com/yido9932/p/3980362.html but had to make a few changes. First, I’m using the old atheros target, so I used “mips-unknown-linux-gnu” instead of mipsel. I still had to make symlinks into the STAGING_DIR path, because rust required the compiler to be with a certain name, and the target triplets don’t line up with OpenWrt.

./configure --target=mips-unknown-linux-gnu --disable-docs --prefix=/home/karlp/dummylib

I also had to remove the -mno-compact-eh flags from [rustroot]/mk/platform.mk in a couple of places. This is an unknown option in gcc as far as I can tell, it appears to be only in CodeSourcery/Mentor’s hacked up version? Then to actually compile the code I needed a few more incantations…

LD_LIBRARY_PATH=/home/karlp/dummylib/lib ~/dummylib/bin/rustc --target=mips-unknown-linux-gnu -C linker=mips-linux-gnu-gcc -L /home/karlp/dummylib/lib/rustlib/mips-unknown-linux-gnu/lib hicore.rs 

And, there’s been a rust language change since that blogpost was made. Using the sample code from that article, you’ll get an error on the “hicore.rs” example about error: language item required, but not found: `fail_fmt`, so you need to add an extra magic line into your sample code,

#[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} }

This is outlined on: http://doc.rust-lang.org/guide-unsafe.html

All in all, somewhat neat, maybe, I guess. But the rust std library is huge, as noted in the google translation of the chinese article linked above. And writing it all in “unsafe” code sounds kinda pointless. So, maybe not so interesting for OpenWrt at this point, but it runs at least.

linux mainline: minix neo x5 mini: USB works!

yay, progress. (by other people in the mainline community, I’m just enabling sections in devicetree files and building and testing.)

So, if you’ve built a kernel, and you think it should work, but you’re getting errors in syslog that look like this…

Jan  1 00:00:28 linaro-developer kernel: usb 2-1: new full-speed USB device number 3 using dwc2
usb 2-1: device v1a86 p7523 is not supported
usb usb2-port1: unable to enumerate USB device
Jan  1 00:00:29 linaro-developer kernel: usb 2-1: device v1a86 p7523 is not supported
Jan  1 00:00:29 linaro-developer kernel: usb usb2-port1: unable to enumerate USB device
Jan  1 00:00:59 linaro-developer kernel: usb 2-1: new high-speed USB device number 4 using dwc2
usb 2-1: device v0fce p5171 is not supported
usb usb2-port1: unable to enumerate USB device
Jan  1 00:01:52 linaro-developer kernel: usb 2-1: Dual-Role OTG device on HNP port
Jan  1 00:01:52 linaro-developer kernel: usb 2-1: device v0fce p5171 is not supported
Jan  1 00:01:52 linaro-developer kernel: usb usb2-port1: unable to enumerate USB device

This is actually a problem with your USB OTG config. Make sure that both CONFIG_USB_OTG_WHITELIST and CONFIG_USB_OTG_FSM are not set

A quick rebuild and reflash and presto…

Jan  1 00:00:32 linaro-developer kernel: usb 2-1: new full-speed USB device number 2 using dwc2
usb 2-1: device v1a86 p7523 is not supported
Jan  1 00:00:32 linaro-developer kernel: usb 2-1: device v1a86 p7523 is not supported
Jan  1 00:00:32 linaro-developer kernel: ch341 2-1:1.0: ch341-uart converter detected
Jan  1 00:00:32 linaro-developer kernel: usb 2-1: ch341-uart converter now attached to ttyUSB0

It’s still “not supported”, but I’m led to believe that means it’s not supported as a gadget in some manner.

The only additions to the device tree for the minix board were…

&usb_host {
       status = "okay";

&usb_otg {
       status = "okay";

Unfortunately, “only” these additions means there’s no power control for vbus. So the usb devices only work on the second port, if you have the funky A-A recovery cable plugged into the dual mode OTG/Host port used for recovery. Working out more pins is an ongoing project.
Thanks as always to the kindly people of #linux-rockchip