Sudomaker LoShark L1 is a USB dongle with Semtech SX1262/SX1268 LoRa transceiver and a Linux-capable Ingenic X1501 MIPS processor with 8MB on-chip memory that serves as a LoRa debug tool that can use a JavaScript interface to access to all SX126x chip registers.
The LoShark L1 USB key offers both LoRa connectivity and debugging capabilities such as packet capture (hence the reference to WireShark) and can operate either independently (standalone) or in conjunction with a PC as shown below with a mini laptop.
LoShark L1 specifications:
- SoC – Ingenic X1501 MIPS processor @ 1 GHz with 8MB DRAM, 2200+ CoreMark,
- Memory – Optional 8MB PSRAM (Lyontek LY68L6400SLIT)
- Storage – 4GB MLC or 256 MB SLC NAND flash
- Wireless connectivity
- HJSIP HJ-68LR LoRa module based on Semtech SX1262/SX1268 with TCXO
- Support for 433 MHz, 868 MHz, and 915 MHz bands
- SMA-F antenna connector
- USB – 1x USB Type-A male port for power and data
- Misc – EPSON RX8900CE RTC or compatible, supercapacitor
- Power Supply – 5V via USB port
- Dimensions – TBD
It’s not the first MIPS device by Sudomaker (aka Reimu NotMoe), as they designed the tiny 16x16mm X1501 Pico SoM last year together with an evaluation board (EVB) with the same Ingenic X1501 MIPS processor which is expected to launch on Crowd Supply in the future. It also happens to power the LoShark L1 USB adapter as we can clearly on the photo above.
Sudomaker released the PDFs of schematics and component placement on the PCB, a buildroot script to build a complete image with a rootfs, mainline Linux kernel, and U-Boot bootloader, as well as the USB firmware update tool on GitHub. There’s less information about JavaScript support, but we’re told the Resonance runtime support a JavaScript ES2015 interface.
The LoShark L1 can be purchased now for $49.99 with 256MB flash, or $59.99 with 256MB flash, PSRAM, an RTC, and a supercapacitor. Stocks are limited for the first batch as only 30 pieces have been assembled.
Via Hackster.io
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
What mini laptop is that, does anyone know?
Just chipping in to answer my own question 🙂
https://gpd.hk/gpdpocket2
Having a 1.2 MB patch against linux-6.1 does not really count as “mainline Linux kernel”.
I took a look at what they changed, this is the diffstat: https://pastebin.com/raw/n0AdwF0q
Not much interesting in that patch set, side maybe the list of other devices in that tree, and the way they have a custom block device driver for the psram rather than having it memory mapped or as a spi-nor device.
Having only 8MB RAM of course makes this mostly useless for running generic Linux userland.
The mainline kernel will boot right on the X1501 using X1000 as a target but some of the drivers are buggy and missing. I would count it as “runs mainline Linux kernel”. We are maintaining our own kernel because the upstream was refusing to merge our changes. They claimed that everything we did was wrong, without having a single X1000/X1501 board in their hands. And we can do nothing about this.
The X1501 is more like an alternative to high-end MCUs and never intended to run a “generic Linux userland” that requires can do almost nothing with 64MB RAM. You can try getting a Linux SBC that runs a “generic Linux userland” into RAM standby and it will still use more than 100mW power. X1501 is only 18mW.
Also, a PSRAM is not a NOR flash because it doesn’t need to “erase” that data inside it. If you read my patches carefully you’ll see there’s also a mtd-ram driver. Then what? Thanks to the overhead and the fixed 512b blocksize of mtdblock layer, it’s much slower than a plain block device. More bloat from spi-mem? No thanks.
If you can get any serial I/O device memory mapped from thin air without special hardware support, I would love to hear how.
Raspberry Pi started from maintaining their own kernel as well and they’re still doing this. I’m sure that other chips will be mainlined more easily if the kernel mailing list is as friendly as 10 years ago.