Skip to content

Tag: mips

Low Cost Localtalk to Ethernet Bridge (AKA low-end embedded Linux) – Part 2 OpenWRT MIPS

In the previous post I looked at the aims of the project and the shortlisted hardware. This post will explore OpenWRT and bringing it up on the HLK-7621 Evaluation Board.


This is a series of blog posts exploring how embedded Linux works (especially OpenWRT) to build an Apple LocalTalk to Ethernet bridge. This is the second part, in what I plan to be a small series of posts.

The HLK-7621 is built as a router module. It comes pre-installed with what looks like a MediaTek version build of OpenWRT. It is already supported by OpenWRT so the work needed to bring things up is minimal.

I was able to download a pre-compiled Sysupgrade from OpenWRT and "upgrade" the firmware to the current snapshot version OpenWRT out of the box!

By default, OpenWRT will bring up a bridge LAN containing the switch ports and eth0 on 192.168.1.1. It will also run a DHCP server. This is probably not what you want out of the box. To change the interface we'll need to either change our IP, or use the serial console to set the IP address manually.

The evaluation board has a CH340 onboard to provide console access. J4 on the board allows the selection of RX/TX each UART to be connected to the CH340, which is a nice touch. Out of the box it is jumpered to UART0, which is how OpenWRT is configured. All we need to do is plug a micro-USB cable in and we can get console access.

Terra-term bootup

Once in we can set the IP Address of the device. I used 192.168.0.21. We can use uci to configure out IP address and disable DHCP.

uci set network.lan.proto="static"
uci set network.lan.ipaddr="192.168.0.21"
uci set network.lan.netmask="255.255.255.0"
uci set network.lan.gateway="192.168.0.1"
uci set network.lan.dns="8.8.8.8"
uci commit network
uci set dhcp.lan.ignore="1"
uci commit dhcp
service network restart

With this we can log SSH into the device, or log in the Luci web-UI.

Time to UART

For my aim of building a LocalTalk adaptor I need to use one of the extra UARTs on the MT7621.

Easy peasy right? I installed a dumb-terminal emulator:

$ apk add picocom

... and ran it:

$ picocom /dev/ttyS1
picocom v3.1

port is        : /dev/ttyS1
flowcontrol    : none
baudrate is    : 9600
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

FATAL: failed to add port: Cannot get the device attributes: I/O error

I tried each tty device, just in case it was weirdly mapped with no luck. It was as if the UARTs just weren't there.

Customising the device tree

I checked the datasheet and saw the following page on "Pin Sharing":

MT7621 Datasheet on PinSharing

UART 2 & 3's pins can either be set as a UART or GPIO. But where is it set? Checking OpenWRT's device Tech Data page there's a link to the commit which added support for the board.

The commit had two files: a make file and a DTS file. The DTS file turns out to be a device tree definition file.

A device tree is a data structure that describes the hardware components of an embedded system, allowing the kernel to dynamically configure itself to work with the specific hardware present on a given board. It provides a standardized way to describe hardware, decoupling hardware configuration from the kernel source code.

In this case, the DTS file described the buttons, SPI Flash Layout, labelled the WAN port, configured the switch and PCIE adaptor support. What it didn't show was how the UARTS are configured!

However, the it looks like the device tree can be inherited from other trees. In this case, the MT7621 device tree. Looking through I could see the UART configuration, so why didn't it work?

UART Definitions

I needed to know more about device trees, and stumbled upon this excellent guide to Device Trees by Yasir Khan.

Enabling/disabling a device
To enable/disable a device, the status property inside a devicetree node is used.

To enable a device, it should be set as status = "okay"
To disable a device, it should be set as status = "disabled"

Could it be that simple?

I pulled the code for OpenWRT and followed the build setup and build system instructions.

I then modified the HLK-7621 DTS file and added:

&uartlite2 {
    status = "okay";
};

&uartlite3 {
    status = "okay";
};

I rebuilt the image and uploaded the sysupgrade to the device! After resetting the IP address I re-added picocom and tried again.

$ picocom /dev/ttyS1
picocom v3.1

port is        : /dev/ttyS1
flowcontrol    : none
baudrate is    : 9600
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready

Success! I jumpered the RX and TX together on the board, and had my text echoed back to me.

One thing I didn't know was whether I could connect at the 1 megabaud needed for TashTalk. The datasheet suggests a maximum baud rate of 345,600 baud.

Only one thing to try:

$ picocom --baud 1000000 /dev/ttyS1
picocom v3.1

port is        : /dev/ttyS1
flowcontrol    : none
baudrate is    : 1000000
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready

Success! I also tried connecting UART2 & 3 together and was able to send characters to each other without issue at 1,000,000 buad.

Hooking up TashTalk

The great thing about TashTalk is it's simplicity. It is really just a PIC, an RS485 bus transeiver and a couple of passives.

TashTalk Breadboard.

TashTalk Breadboard connected to the HLK-7621

I grabbed the latest hex file and flashed it on to the PIC with a PikKit (don't forget to set the circuit voltage option!), and put it together on a breadboard. I connected it a Mac Classic and to the UART and CTS pins on the HLK-7621.

I installed Python on to OpenWRT:

$ apk add python3`

and copied over tashtalkd from the Tashtalk repo to /tmp.

I crossed my fingers and ran the code:

$ python3 tashtalkd --device /dev/ttyS1

I ran a LToUTP build of Mini vMac and opened chooser on the Mac Classic.

A Macintosh Classic running System 6 showing Chooser and a mounted share from an emulated System 7 machine. The machine is connected via TashTalk to the emulated Macintosh.

Success! 🎉 The Mac Classic is able to see the emulated System 7 machine running under Windows, via TashTalk running on a HLK-7621.

Recap

In this post we:

  1. flashed a device with the latest snapshot of OpenWRT
  2. customised the device tree to enable UART
  3. built and tested a TashTalk

We're not quite building a full bridge yet, but we've validated the hardware and software side can do what we need (at least with this board).

Next Steps

Now that we've got it working on one board, can we get lucky and do the same with the Luckfox Pico Plus?

Leave a Comment

Low Cost Localtalk to Ethernet Bridge (AKA low-end embedded Linux) – Part 1 The Hardware

I recently stumbled upon TashTalk, a bitbanged implementation of LocalTalk to UART on a PIC12. I thought it might be fun to try and get a low-cost Linux board with the TashTalk embedded, thus began journey down the rabbit hole of low-cost, Chinese made SBCs.


This is a series of blog posts exploring how embedded Linux works (especially OpenWRT) to build an Apple LocalTalk to Ethernet bridge. This is the first part, in what I plan to be a small series of posts.

Aim

The ultimate aim of the project is to build an all-in-one solution for bridging 68K and early PPC Macintosh computers with the modern world. Realistically though, I hope to learn how to build embedded Linux images, cross-compile code, and a bit about u-boot.

From a hardware perspective, I want something that could:

  1. Integrate a Local Talk -> Ethernet Bridge with TashTalk and MultiTalk

  2. Provide NAS-like functionality via USB storage to AppleShare (Netatalk), SMB, FTP and HTTP clients.

  3. Provide ADB device emulation (eg keyboard and mouse) from USB devices, building on ADB-Test-Device.

  4. Provide SCSI device emulation via optional RA-SCSI/PI-SCSI software and hardware support.

  5. Audio-out for CD-ROM emulation (or some other audio thing, eg re-implement the Lacie FM radio!?).

  6. Optional: run off POE so an external power-pack isn't required, drop it in your network and be done.

  7. Be self-contained, turn-key like. No custom config, no external SD card, etc.

Hardware

The hardware requirements for this solution are not substantial.

  • ~700-1Ghz CPU - likely much slower would be fine.
  • 128-256MB RAM - though 64MB might be fine if we don't use Python.
  • Ethernet (at least 100Mbps - ideally GBE)
  • Ideally inbuilt storage, doesn't have to be huge (~64MB should be enough). SD cards just add extra cost.
  • UART - at least 3: 1 for console, one for LocalTalk, one for ADB - both need to support a 1Mhz rate and have CTS/RTS.
  • [Optiona] USB Host support (USB 2.0 minimum)
  • Ideally enough GPIO/Peripherals to handle a SCSI interface and sound output (~25 PINS)
  • Cost < $10USD - otherwise just use a RaspPi.
  • Availability: not just a fly-by-night TaoBao item

Evaluation

When looking at the items they'll be assessed on:

  1. Availability - how hard is to order a module, is there more than 1 supplier? Can we order the SOC on its own (eg to breakout more IO?).
  2. Software Support - can I bring up OpenWRT quickly? Is it a mainlined Kernel - does OpenWRT support it?
  3. Documentation - can I get the docs, including programming manuals?

These aren't hard and fast rules, but go a long way to getting where I need to go.

Why not the Raspberry PI?

The Raspberry PI is a great product, but I'm deliberately not targeting it. The pricing of PIs is still significant ($45USD, a long way from the $20USD they started at), availability can still be difficult (especially in quantity), and the low-end compute modules and Zero boards don't have any Ethernet capabilities.

The candidates

After looking at a bunch of different items, I narrowed it down to the following:

... and ordered some boards.

Software

I ideally want to use OpenWRT for this project. OpenWRT is already designed for resource constrained environments, has native support for MIPS and ARM (maybe RISCV ?), package management and a Web UI.

It's anticipated that at least a few changes to OpenWRT and custom packages will need to be created to get a workable image. In no particular order:

  • A board definition with whatever bespoke config I end up going with. Will require alternate mode of various devices to enable enough GPIO.
  • Potentially patches to the MT7621 UART config to support a 1Mhz option (while not documented, it looks like the UART register accepts custom clock dividers, so getting to 1Mhz should be doable)
  • Building out MultiTalk as a package (hopefully the Go runtime isn't too big!)
  • Patching Ra/PiSCSI to use different GPIO ports, memory address (looks like this has been virtualised a bit).
  • Building a PiSCSI package
  • Building an ADB keyboard & mouse device

The Boards

Embedded Boards - 
Left to Right:
Luckfox Pico Plus, MilkV Duo in dev-holder, HLK-7621 Dev Board.

Left to Right:

Luckfox Pico Plus, MilkV Duo in dev-holder, HLK-7621 Dev Board.

HLK-7621

The HLK-7621 Evaluation Board

Out of the shortlisted options, on paper the HLK-7621 module looks to be the winner. It is supported by OpenWRT, has some very nice features, is available as a module, a decent dev-board and more features than I need.

The HLK-7621 "stamp"

I was able to bring it up quiclky with the pre-built images from OpenWRT. I was also able to modify the board definition files to enable the additional UART and successfully build and flash the image (see next post). Despite the claim of being "UART lite" in the datasheet, CTS/RTS are exposed and I was able to connect at 1Mbps to the UART.

Luckfox Pico Plus

Luckfox Pico Plus
There's a lot to like about the Luckfox board. It has an integarated Ethernet port, built in Flash storage and the series scales up to 256MB of Flash and RAM. The Pico Plus board I ordered is the lowest end part with built-in Ethernet and Flash. It consists of 64MB of RAM and 128MB of Flash.

I was able to Flash it with the pre-built buildroot images from Luckfox, as well as boot Ubuntu 22 from SD Card.

As a dev-target, I think the Pro Max is the better board - 64MB is just too restrictive as a development tool.

Milk-V Duo

Milk V Duo and carrier board

This is an odd series. The entire chipset changes completely as you go up. I bought the lowest end "Duo" which consists of:

  • CVITEK CV1800B SoC
  • 2x RISC V cores, C906@1Ghz + C906@700Mhz
  • 64MB RAM
  • No built in storage
  • Ethernet Phy

Side Note
It looks like there's a "stamp" like module that I wasn't aware of when looking; the Duo-Module-01. This one is $15 USD which is a bit outside the target price range of this project, but might be a good contender for future projects.

Comparison

Feature HLK-7621 Luckfox Pico Plus Milk-V Duo
Web https://www.hlktech.net/index.php?id=436 https://www.luckfox.com/Luckfox-Pico/EN-Luckfox-Pico-Plus https://milkv.io/duo
SoC Mediatek MT7621A Rockchip RV1103 CVITEK CV1800B
Instruction Set Dual MIPS ARM RISC V
RAM 256MB 64MB 64MB
Storage 32MB 128MB SD
Ethernet 2xGBE / 5 port switch 10/100 Ethernet (built-in) 10/100 Ethernet PHY
UART 3x UART "lite" 4x UART 4x UART
GPIO Lots! "up to" 25 "up to" 25
USB Yes - 1x USB 3 + 1x USB 2.0 or 2x USB 2.0 1 USB-C 2.0 1x USB-C 2.0
Other 3x PCIE Host
Price ~$12USD ~$10USD ~$9USD

Of interest, both the Luckfox Pico and DuoV boards have the same form factor as the Raspberry PI Pico.
Luckfox Pico Plus, MilkV Duo and a Raspberry PI Pico. Each share the same form factor.

Next

Building OpenWRT and/or Linux for each of these devices, enabling the UART and getting TashTalk up and running.

Leave a Comment