Domino.io Module Tips and Tricks

Domino.io Module Tips and Tricks

Comments 0 Comment

Some basic instructions/ramblings to get started (as the documentation for the Domino module isn’t currently complete)

To connect your Domino to a WiFi network using a GUI:

Plug in your Domino Pi/Qi/base module and use your phone or laptop to connect to the “Domino-***” Wifi. The default password is “goodlife”. Navigate to http://192.168.1.1/ to access the web interface. Change your device’s hostname and password on the web interface and click “Okay, Reset”. Reconnect using your new password, navigate again to http://192.168.1.1/ and log in using your new password, and you will have access to the web interface.

The basic interface (“Domino Web Panel”) is mobile-friendly; the “LUCI” tab, however, is still formatted for larger screens.

To connect to your local wireless network, choose “LUCI”, then “Network”, “WiFi”. Click “Scan” beside “Generic Wireless” and click “Join Network” next to your WiFi. Enter your password and hit “Submit”. Scroll to the bottom of the page and select “Save and Apply”. You can now access http://domino.local/ from your network.

To connect your Domino to a WiFi network using the command line:

Connect your domino by USB and open a terminal to it (/dev/ttyUSB0 on Linux or whichever COM port Windows assigns) at 115,200 bps. You will have root access just like any OpenWRT implementations. You will want to change the wifi-iface block in /etc/config/wireless to look something like the following (modify to suit your needs):

config wifi-iface
option network ‘wwan’
option ssid ‘yourwifinamehere’
option encryption ‘psk2’
option device ‘radio0’
option mode ‘sta’
option bssid ‘ma:ca:dd:re:ss:he:re’
option key ‘yourpasswordhere’

Mount points / Storage:

With the 3x USB + MicroSD expansion:
/mnt/sda1 is your microSD card
/mnt/sdb1 is your USB,
/mnt/sdc1 is your internal Flash storage

Getting a terminal on the Domino Qi (Arduino Yun Clone):

  1. Upload the YunSerialTerminal sketch over USB
  2. Connect to the Qi at 115200 8N1 and send ~2 to set it to 115200 (Otherwise you’ll just get garbage)

More goes here as I play around with it…

WiiMu A01 (Work in Progress)

WiiMu A01 (Work in Progress)

Comments 0 Comment

This is an information dump of the WiiMu A01 in hopes of instituting audio control with the OpenWRT firmware.

PCB Silkscreen:

MVSILICON& WiiMu A01 V2.0 2013.03

Default firmware:

Kernel:

Busybox Linux 2.6.21, built from the Ralink SDK

Modules:

printk, 8250, rt_rdm, rt2860v2_ap, block2mtd, ohci_hcd, snd_timer, snd_seq_oss, snd_soc_core, nf_nat_ftp, rcupdate, rd, ppp_async, scsi_mod, usbcore, usb_storage, snd_pcm, snd_seq, nf_conntrack, iptable_filter, n_hdlc, loop, pppopptp, sg, ehci_hcd, snd, snd_pcm_oss, snd_seq_dummy, nf_conntrack_ftp, tcp_cubic

Libs:

  • libintl.so
  • libresolv-0.9.28.so
  • libintl-0.9.28.so
  • libnsl-0.9.28.so
  • libuClibc-0.9.28.so
  • libpthread.so
  • libnsl.so
  • libcrypt.so
  • libm-0.9.28.so
  • libnvram.so.0
  • libintl.so.0
  • libupnp.so.1.3.1
  • libutil-0.9.28.so
  • libm.so
  • libntfs-3g.so.26
  • libutil.so.0
  • libresolv.so
  • libcrypt-0.9.28.so
  • libc.so
  • libdl-0.9.28.so
  • libutil.so
  • libiw.so.29
  • libixml.so.1.3.1
  • libcrypt.so.0
  • libm.so.0
  • libnvram-0.9.28.so
  • libc.so.0
  • libdl.so
  • libnvram.so
  • libnsl.so.0
  • libdl.so.0
  • libthreadutil.so.1.3.1
  • libpthread-0.9.28.so
  • ld-uClibc-0.9.28.so
  • libpthread.so.0
  • libresolv.so.0
  • ld-uClibc.so.0
  • 2.6.21/kernel/drivers/net/wireless/rt2860v2_sta/rt2860v2_sta.ko
  • 2.6.21/kernel/drivers/char/hw_random/rng-core.ko

Unpacking the root_uImage upgrade:

Using binwalk, specifically

binwalk -Me root_uImage

I was able to extract the root_uImage

Audio DAC

My unit had the DAC markings sanded off, but from /proc/asound/cards, DAC appears to be an Everest Semiconductor ES8155. According to their product sheet, it is a 2-channel DAC in QFN-28 package.

  • SNR: 96 dB
  • THD+N: -85 dB
  • Headphone Amp: Yes
  • Line Driver: Yes
  • PLL: Yes
  • Additional Function: 3-band PEQ
  • Supply Voltage: 1.5 to 3.6 V
  • Low Power: 7 mW
Driving a WS2811 RGB LED Strip with an Arduino

Driving a WS2811 RGB LED Strip with an Arduino

Comments 0 Comment

I recently purchased a WS2811 RGB LED strip for PC case modding purposes. I will be making an ATMega-based controller for it, so I decided to use an Arduino for testing and prototyping.

I found two libraries capable of driving this strip:

Plus many great links regarding the WS2811 at the Noisebridge Wiki.

I recommend trying out funkboxing’s FastSPI2 effects as great examples of using the FastSPI2 library. You will need to use the line LEDS.addLeds<WS2812, 13, GRB>(leds, NUM_LEDS); to properly initialize the code.

Writing a BeagleBone Cape’s EEPROM from UBoot

Writing a BeagleBone Cape’s EEPROM from UBoot

Comments 0 Comment

eeprom -d /dev/i2c-3 -a 0x54 -f foo

vi foo
<Escape> and :%!xxd
Edit the hex portion to your heart’s content
<Escape> and :%!xxd -r
Save and quit vi

To convert your eeprom.bin for upload via BusPirate

cat eeprom.bin | hexdump -v -e ‘8/1 “0x%02X “‘ -e ‘”\n”‘> eeprom.ascii

Upload using the method shown here.

Thanks to “Kev’s Site” for the tip on using VI as a hex editor

Pager-Controlled Thermostat Teardown (Work in Progress)

Pager-Controlled Thermostat Teardown (Work in Progress)

Comments 0 Comment

After installing a new furnace and thermostat, I was left with an old thermostat that was controllable by the power company to allow them to shut off the A/C remotely during high-load time, and allows users access to set their thermostat online

The Cannon Technologies Inc “ExpressStat” board (Rev M) has:

  • a Renesas H8/3937 non-roaming FLEX decoder, with on-chip 60-kbyte ROM and 2-kbyte RAM,
  • a Ramtron FM24CL64 “F-RAM array” (similar to an EEPROM),
  • an Infrared TX/RX pair,
  • a Texas Instruments TIR1000
  • a pager sub-board, including pager motor and beeper/buzzer, antenna and receiver circuitry
  • an 8-pin header to the thermostat’s mainboard

Attachments:

EExtractor: An (EE)PROM-Extracting Arduino Shield (Beta)

EExtractor: An (EE)PROM-Extracting Arduino Shield (Beta)

Comments 0 Comment
Attachment: Click for related file download

Purpose: EExtractor is an Arduino-compatible Shield that allows a user to dump (or download) the contents of a ROM chip (ROM, PROM, EPROM, EEPROM, etc). 

Hardware Method: The EExtractor uses two SOIC MCP23S17 ICs to control the 31 (32 minus ground) pins of the ZIF Socket. This (ideally) allows the user to address any size or pinout of PROM IC up to, and including, 32 pins. Headers are broken out to allow for direct powering of PROM pins from the Arduino’s +5V port (if needed).

Software Method: The Arduino (or compatible) software will correctly configure pins (inputs/outputs, Hi-Z, pull-ups, etc) to allow for proper reading of the IC’s data. The software will then proceed sequentially through each byte of the PROM, outputting it along with a verification or checksum.

(The code is still under construction at this time.)

Availability: PCBs will be available once testing is complete.


EExtractor was made using the Open-Source gEDA suite of tools, including gschem, pcb, etc, and, as always, a little symbol and footprint help from gedasymbols.org.

All materials, schematics (.sch), PCB Layout (.pcb), and related derivatives such as PCB renderings, schematic renderings, .ps, .pdf, .gbr and .cnc files, or other Gerber-format files and PCB boards produced with them, collectively known as v1.0 Beta 1, are released under the CC BY-SA 2.5 Canada license.

*EExtractor is not sponsored or otherwise supported by Arduino. The Arduino name used only to signify compatibility.

OpenWRT on the DIR-615 Rev. A1 (Marvell 88F5181L) [Work In Progress]

OpenWRT on the DIR-615 Rev. A1 (Marvell 88F5181L) [Work In Progress]

Comments 1 comment

This article will document the process of making OpenWRT work on the DIR-615 rev. A1.

In its dmesg, the stock firmware reports this board as “Marvell Development Board (LSP Version 0.0.102)– RD-88F5181L-VOIP-FE”.

In the GPL’d source code available from D-Link [FTP], in DIR-615A1-GPL.tgz (inside the downloaded file), in Noahsark/platform/MVL5181/linux/arch/arm/mach-mv88fxx81/Board/boardEnv/DB_88FXX81/mvBoardEnvSpec.h, a search for “RD-88F5181L-VOIP-FE” reveals a list of constants that pertain to the board. (See attached .XLS file)

I created Board ID# 4262 at the ARM Linux website to describe this board.(This document from Nas-Central.org explains why this needs to be done, and goes into detail about how to get support for your particular Orion board type in the mainline Linux kernel. This only ever needs to be done once for each type of board defined on the ARM Linux site, so consider it “already done” for the D-Link DIR-615 and/or the Marvell RD-88F5181L-VOIP-FE reference board.)

Update (25-Jul-2012): I just received my Dangerous Prototypes Bus Blaster to allow me to use JTAG with either OpenOCD or urjtag, among others. It seems that the resistor and capacitor footprints beside the JTAG header need to be populated to allow JTAG access. Proper SMD resistors and caps are part of my next DigiKey order.

Unbricking a D-Link DIR-615 Rev A1

Unbricking a D-Link DIR-615 Rev A1

Comments 0 Comment

I have managed to unbrick a D-Link DIR-615 Rev A1 back to D-Link firmware (1.00) from firmware 1.10. Allow me to describe the situation:

  • Given a direct connection to my laptop, the router does not respond to HTTP requests on either WAN or LAN, does not assign DHCP IP addresses, cannot ping or respond to pings, but does show up on the laptop in the ARP tables (arp -an). (This same setup has worked for numerous non-bricked routers, so it seems that some busybox functionality is corrupt.)
  • Over serial, the uBoot bootloader cannot connect to a TFTP server (and does not have the ability to flash over serial).

Attached to this article is a log of one of these so-called “failboots”. It can be easily identified as it only one block of text following the BusyBox ash shell:

BusyBox v1.1.0 (2007.07.26-06:29+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ # pc : [<40146968>] lr : [<400ca0b8>] Not tainted
sp : befaf8a0 ip : 00000002 fp : 40079bf8
r10: 00000003 r9 : 40079bb8 r8 : 00050500
r7 : befb5c75 r6 : 00026740 r5 : befb5c74 r4 : 0002674a
r3 : 00000065 r2 : 0000000a r1 : 00026741 r0 : 400ca0b7
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: A005317F Table: 01DF0000 DAC: 00000015

A successful bootup (log also attached) is followed by much more serial chatter, such as bringing up interfaces, mounting flash, etc.

BusyBox v1.1.0 (2007.01.24-07:26+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ # cp -f /etc/nvram.default /var/etc
mount -t jffs2 /dev/mtdblock2 /flash
cp -f /flash/nvram.conf /var/etc
brctl addbr br0
brctl stp br0 off
brctl setfd br0 0
brctl addif br0 eth1
device eth1 entered promiscuous mode
[... etc ...]

To recover your device:
(Warning: This might damage your device; however, if you are in need of these instructions, I don’t think it’s possible to damage it any more.)

1) Solder on serial headers to CON5 (on the side opposite of the mini-PCI slot)

2) With an Ethernet cable, connect the DIR-615’s WAN port to one of the LAN ports of another router, as it doesn’t play well otherwise. (It seems to need an intermediary to handle ARP tables for it while bricked like this)

3) Power it on, let it boot up, and over the serial connection to the router, run “ipconfig eth0 192.168.1.25” or some other memorable IP address that’s in the same subnet as your computer

4) Again, over serial connection to the router, run “tftpd”

5) On your computer, download the firmware from DLink: ftp://ftp.dlink.com/Gateway/dir615/Firmware/dir615_firmware_100.bin

6) And with a tftp client (See Installing OpenWRT via TFTP (Bootloader contains TFTP Server)), upload the .bin file to the router.

The router will flash itself, then reboot, and erase the (dirty) NVRAM. It will set itself to the default 192.168.0.1.

The key, I believe, lies in installing a version of firmware that is not currently installed, so as to erase all NVRAM settings. If you try to reinstall the same firmware, it will not clear the device’s (faulty) settings. In other words, there may be a much easier way to debrick the device, however with the limited (and possibly corrupt) BusyBox commands, I took the first viable option I could get.

I hope this works for you as it did for me, but as usual, ‘no promises’.