It was a busy month, but I finally managed to find a minute and update the rf24boot. Yes, the very thing that can push firmware updates via nRF24L01 wireless modules. Along is a regular bunch of updates to rf24 library in antares. One of the big news I finally took some 20 minutes and layed out a proper programming dongle. Since I didn’t have a cheap stm32 with usb around, and stm32f103ret6 looked like an overkill for this purpose this dongle still uses avr, vusb, but has a 16M (20M is possible as well) crystal. The lengthy changelog’s under the cut, but it’s big.
I had planned on getting a lamination machine to do toner transfers for a long time. Unfortunately, I never came across anything that had manual temperature regulation, so I decided to take whatever was available and try it. As expected, the temperature was NOT enough for toner to even melt, no matter how many times you tried.
Great, time for an upgrade.
That’s it! It’s out. After two years of slow and steady development in my free time. Antares is a free and open source (GPLv2) buildsystem bundled with library code, aimed at bare metal targets. Sounds scary? Well, consider this an arduino for kernel hackers. If you are one – you have all the regular tools here: kconfig, GNU/Make, and no need to write Makefiles from scratch or collect sparse instructions over the web – just bootstrap a project, adjust the config to your needs and go!
0.2-rc1 is the first release that can be considered (more or less) stable for every day use. To find more about what it is and how it works – check out the README in Russian or English
Don’t ask why. I just though it might be a cool idea.
So what’s the catch? Packet writing over CD/DVD-/+RW media is pretty much the same as writing to a block device. The only bad thing is that:
- Writes MUST be aligned
- Writes must be of a fixed packet size
- Before reading you must issue a flush command.
To hide this from the upper level pktcdvd module exists that assembles packets and sends them to the media. Well, this whole pktcdvd machinery reminded me of a NAND device actually, so I wondered if we could actually make an MTD device out of a CD or DVD. AND run UBIFS on top of it. (Or yaffs2. whatever). Details&code under the cut
My home server has a long story. It all started with a Pentium 4, an old 20GB HDD and FreeBSD 6.2 … hell, I don’t even remember the exact year.
Anyway, after a few years, the hardware was finally put to rest, since it died and got resurrected thrice, I got an Intel Atom D410-based miniATX board, switched to linux, first debian, then agilia, then arch… Anyway, it used to be a nice server for personal needs, that crashed only on occasional HAD-effect, so it was… sufficient.
Now, the time has come to move on, to arm. The benefits were simple and straight:
- 10W peak power consumption
- Fully passive cooling
- eMMC for the root partition
- 4 cores!
- Always a serial terminal, starting from uboot phase, so that I don’t have to carry a monitor to the closet where it is stationed.
I picked ODROID-X2 based around Exynos4212 Prime. ODROID-U2 looked worse, since had NAND soldered onboard. eMMC looked easier to replace. And the benchmarks said eMMC was faster.
So, here go my adventures with this hardware.
A usual rant goes towards ST guys for their mindless design*. I don’t really know anyone, who does some heavy app development with no serial terminal for debugging (Or may be I don’t know many of them?). You know, gdb is good, but a good old ‘dmesg’-like stuff is usually even more helpful.
Anyway, while other people are trying to discover traces of sanity of the ST people by reversing STLinkv2 and discovering only huge holes in security so far, I decided to go a different way that works just fine with STLinkV1 and STLinkV2.
My first idea was to stuff the VCP example into the stlink’s uC (which is an STM32F103C8T6) and throw a little wires, but in the end – I didn’t want to ditch STLink completely (It helped me out a few times). Ideas? Sure!
First step. What does STLink do? Right, apart from that breakpoint/step voodoo it writes and reads memory. Sounds good? Good! Enough to do pretty much anything.
Before you declare me an insane old man, I have to say, that I needed it for an embedded board with only 64MiBs of RAM. And (mostly due to the specifics of the tasks), I ended up using bash hooked to lighttpd via cgi. Bringing on heavy artillery (php or python), really complicated the task, since I mostly needed the outputs of different shell utils.
Anyway, I quickly got to the part where I needed to handle POST requests to upload binary files. First, I googled for a solution, and one of them eventually did what I needed. But alas, it had a drawback.
A few posts ago, I wrote about making android’s dnsmasq more usable by turning on local hostname resolution. Since I use my android phone as a pocket server, dnsmasq plays a vital role here.
However, one thing was bad – whenever I used usb tether connection to my PC, the whole dns thingie did not work. Why?
So, a little theory. When I enable the wifi ap mode, an interface called ap0 is brought up with a static ip 192.168.43.1.
Whenever I turn on usb tethering, usb0 pops into the existence with ip 192.168.42.129.
(On other mobile phones these settings can differ)
Fine, so when we resolve our pocket server from within the usb0 network, we want to get 192.168.42.129, and when via a wireless network – 192.168.43.1
I started by adding two distinct entries in /etc/hosts
192.168.43.1 anomalia anomalia.portable git.anomalia p.anomalia 192.168.42.129 anomalia anomalia.portable git.anomalia p.anomalia
Did it work? No! Why?
Okay, this is just a small tip. All newer dongles, instead of having you to undergo some nasty sex with pppd over serial to make them work, have an ethernet interface, like cdc-ncm, sierra_net and etc. So, once you plug those, you usually see an extra interface when doing ifconfig -a.
So, how should we bring up the interface?
It is done via sending
command via the serial interface (it shouldn’t be locked via any pin number whatsoever, if it is – we need to issue AT+CPIN before that).
Newer network-manager takes care of them, but on a headless box or some singleboard embedded device this is a no-go. In my case I use debian on my embedded box, so I threw up this very snipplet to /etc/network/interfaces:
iface wwan0 inet dhcp pre-up echo -ne '\r\nAT^NDISDUP=1,1,"internet"\r\n' > /dev/ttyUSB0 && sleep 15 dns-nameservers 127.0.0.1 18.104.22.168
It gives a 15 second delay, so that the modem can bring up the interface, and adds 127.0.0.1 as a nameserver, since I’m using dnsmasq for local dns stuff. Replace /dev/ttyUSB0 with whatever port you need. Once done – use
To get this interface up and down.
It’s also a good idea to ping google or something once every 5 to 10 seconds, because after a few hours of inactivity the modem drops the connection, and while now there is no mechanism in cdc_ncm except for a note in dmesg that the connection has been dropped.
I’m not a psychopath, I’m just very creative.
(c) Harry Potter and the Methods of Rationality
Taking part in competitions like “eurobot”, where you have to do some coding in extreme conditions, on/under a table, on the floor, etc. and a few other trips like that convinced me that I should definitely make something more of my cell phone. Something, that will help me out in this case.
So, we have:
- A dumb brick called ‘HD7 Pro’ from china, with android 2.3.5. One and a half years old.
- A few hours of free time
What we want to get:
- A portable server with lighttpd, ssh, git, etc
- WiFi AP with local dns, internet tethering (if we’re not roaming!)