Running on ARM Linux boards (Raspberry Pi Zero)

[linfan68]

I'm exploring a new chip for a project—the RV1106, an ARM Cortex-A7 32-bit processor. This chip is quite robust, boasting about 1.2 GHz and a decent amount of memory, roughly in the ballpark of the Raspberry Pi Zero in terms of performance.

I'm curious about your thoughts on using Moddable for embedded programming on this chip. It runs Linux, so one approach could obviously be developing with NodeJS. However, I feel like Moddable could potentially offer some advantages, especially in terms of efficiency and interacting with native C code—like faster startup times and avoiding JIT compilation.

Do you think it's a good idea to go with Moddable on this chip? And if so, would starting with the existing Linux build target be the right move?

[phoddie]

It is perfectly reasonable to use the Moddable SDK on that class of devices. In our Node-RED MCU work, we often hear developers say that Node-RED itself (built on Node.js) can feel heavy on a Raspberry Pi class hardware. Node-RED MCU Edition (built on the Moddable SDK) running on the same hardware is very light.

The Linux port should work as-is. You'll likely need to create some native modules for your specific purposes, but you have plenty of experience doing that.

FWIW – depending on your project goals, Compartments are another unique feature of the Moddable SDK, so you can sandbox untrusted code.

[linfan68]

Sounds good! I may need a few pointers to get started:

1. What’s the bare minimum example to run moddable in Linux? If I run mcconfig with Linux target, it starts the emulator (which I don’t need)… There should be an executable somewhere?
2. I need cross compile to generate the binary for the target board, which involves some make file magic I guess?

[phoddie]

What’s the bare minimum example to run moddable in Linux? If I run mcconfig with Linux target, it starts the emulator (which I don’t need)… There should be an executable somewhere?

mcconfig on Linux builds a shared library. The simulator is launched with the shared library as a command line argument. You may not need the simulator as-is but you do need some application to load and launch the shared library. Probably the best way to generate that is to start with the simulator and strip out what you don't need (mostly Piu and the GTK window). Some of the infrastructure is necessary for things like sockets, timers, and workers, as I recall.

I need cross compile to generate the binary for the target board, which involves some make file magic I guess?

Not my expertise. Maybe @mkellner can advise.

[linfan68]

@phoddie Thanks for your advise!
I'm following down to "strip down simulator" path, and found there is an x-lin target type (executable Linux I guess?), which is used by the simulator.

So I copied the simulator code, and got the "minimal" cli project working.

code

ONLY 3 files needed

manifest.json

{
  "build": {
    "NAME": "hello-x-lin"
  },
  "creation": {
  },
  "modules": {
    "*": ["./*"]
  }
}

main.js

trace('Hello World!!!\n')

main.c

and the heavy lifting part (from #850, adn adopted to latest code)

#include "xsAll.h"
#include "mc.xs.h"
#include "xs.h"
#include "xsHost.h"

extern txPreparation* xsPreparation;

static txMachine _root;

int main(int argc, char* argv[]) {
  printf("%s\n", "Starting Server");
  
  int error = 0;
  txMachine* the = &_root;
  txPreparation* preparation = xsPreparation();

  c_memset(the, 0, sizeof(txMachine));
  the->preparation = preparation;
  the->keyArray = preparation->keys;
  the->keyCount = (txID)preparation->keyCount + (txID)preparation->creation.initialKeyCount;
  the->keyIndex = (txID)preparation->keyCount;
  the->nameModulo = preparation->nameModulo;
  the->nameTable = preparation->names;
  the->symbolModulo = preparation->symbolModulo;
  the->symbolTable = preparation->symbols;
  
  the->stack = &preparation->stack[0];
  the->stackBottom = &preparation->stack[0];
  the->stackTop = &preparation->stack[preparation->stackCount];
  
  the->firstHeap = &preparation->heap[0];
  the->freeHeap = &preparation->heap[preparation->heapCount - 1];
  the->aliasCount = (txID)preparation->aliasCount;

  the = fxCloneMachine(&preparation->creation, the, "tool", NULL);

#if mxInstrument
  fxDescribeInstrumentation(the, 0, NULL, NULL);
#endif
  xsBeginHost(the);
  {
    xsVars(2);
#if mxInstrument
  fxSampleInstrumentation(the, 0, NULL);
#endif
    {
      xsTry {
        xsResult = xsAwaitImport("main", XS_IMPORT_NAMESPACE);
      }
      xsCatch {
        xsStringValue message = xsToString(xsException);
        fprintf(stderr, "### %s\n", message);
        error = 1;
      }
    }
    GMainContext* main_context = g_main_context_default();
    GMainLoop* main_loop = g_main_loop_new(main_context, FALSE);
    g_main_loop_run(main_loop);
  }
  xsEndHost(the);
  xsDeleteMachine(the);

  return error;
}

void fxAbort(xsMachine* the, int status) {
  exit(status);
}

Build

mcconfig -i -m -p x-lin

Run

$MODDABLE/build/bin/lin/instrument/hello-x-lin

Starting Server
instruments key: Chunk used,Chunk available,Slot used,Slot available,Stack used,Stack available,Garbage collections,Keys used,Modules loaded,Parser used,Floating Point,Promises settled
instruments: 0,32768,896,65504,0,12288,0,0,0,0,0,0
Hello World!!!

[mkellner]

@linfan68, Could you please direct me to the support site for the RV1106?
A site with toolchain setup documentation, BOM information and firmware deployment tools?

Thank you.

[linfan68]

The official SDK is not publicly distributed by the chip manufacturer, but here is a dev board vendor’s wiki:

https://wiki.luckfox.com/Luckfox-Pico/Luckfox-Pico-SDK

[mkellner]

Thank you for the link.

I think that an embedded linux target is different enough from the lin host platform build that it merits its own base platform - say linarm. Similar to the qca4020, nrf52 and pico, there is some infrastructure that will have to be modified to support the new base platform.

If you are interested in pursuing this device, we can start a porting discussion like we did for pico #568

[mkellner]

Last part first:

We could use linemb for linux embedded - I'd like for the name to be small, but descriptive.
Then within the manifest.json for the various targets, we could add CPU like:

"build": {
    "CPU": "x86"
},

Then within the linemb.make.mk, we can case for the ARCH and GXX_PREFIX like we do with the ESP32_SUBCLASS in esp32.make.mk.

For the targets, I was thinking it would be something like linemb/rv1106 (at $MODDABLE/build/devices/linemb/targets/rv1106/ where specific pins are defined, etc. There would probably need to be some special kernel and device config files for the particular board (like we do with sdkconfig directories in esp32 targets).

---

1. Looking at fxCreate/DeleteMachinePlatform for the various devices in xs/platforms/nnn/xsPlatform.c, I see it is used to create a mutex for debugging and cleanup of debugging fragments, etc. I think that going with a pthreads implementation would probably be good.

We'll need to have a xs/platform/linemb with the xsPlatform.[ch] and xsPlatform.[ch]. I think that starting with the xs/platform/pico and replacing the pico specific calls with the linux equivalent.

The Time code in xsHost.c should map to POSIX calls.

Flash code can be stubbed out until it is time to implement.

Note: I chose the pico platform because its API is pretty simple. Most of the device code follows a similar pattern. esp, esp32, nrf52 and pico are actively being developed and can be examined for further examples.

2. timer:

I think you might be able to use the mc version. The underlying functions must be implemented - they'll be in the xs/platform/linemb/* files.

3. The main loop:

We will want to have a $MODDABLE/build/devices/linemb/ directory to contain device specific setup and configuration files and the various subplatform target files.

In $MODDABLE/build/devices/pico/base/ are some device specific support files including main.c. For pico, it does some simple setup then calls xs_setup() to start the virtual machine.

In xsmain.c:xs_setup(), we set up the debugger (if it's a debug build) and the main loop follows.

In debugger.c are implementations of setupDebugger, ESP_putc and ESP_getc which should be used to configure the serial port, put a character and get a character. This is the interface to xsbug.

[linfan68]

@mkellner following your suggestions, this is what I got:

1. It seems like this xs/platforms/xsPlatform.h is very close to what we need, the only modification I need is to make #define mxMachinePlatform compatible to the mc/xsHosts.c version, as well as mxUse*** defines needs to be addjusted a little. So I add a file called xs/platforms/linemb/xsPlatform_linemb.h,

#undef mxLinux
#define mxLinux 1
#define XS_FUNCTION_NORETURN __attribute__((noreturn))
	
#include <ctype.h>
#include <float.h>
#include <math.h>
#include <setjmp.h>
#include <stdarg.h>
#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

#include <arpa/inet.h>
#include <pthread.h>
#include <unistd.h>
#define mxUseGCCAtomics 1
#define mxUsePOSIXThreads 1

#define mxMachinePlatform \
	uint8_t *heap; \
	uint8_t *heap_ptr; \
	uint8_t *heap_pend; \
	void *msgQueue; \
	void *dbgQueue; \
	void *queues; \
	void *task; \
	void* waiterCondition; \
	void* waiterData; \
	void* waiterLink; \
	mxMachineDebug \
	mxMachineInstrument

#define mxUseDefaultMachinePlatform 1
#define mxUseDefaultBuildKeys 0
#define mxUseDefaultChunkAllocation 0
#define mxUseDefaultSlotAllocation 0
#define mxUseDefaultFindModule 0
#define mxUseDefaultLoadModule 0
#define mxUseDefaultParseScript 0
#define mxUseDefaultQueuePromiseJobs 1
#define mxUseDefaultSharedChunks 1
#define mxUseDefaultAbort 1
#define mxUseDefaultDebug 1

#ifdef mxDebug // TODO
	#define mxMachineDebug 
#else
	#define mxMachineDebug
#endif

#ifdef mxInstrument
	#define mxMachineInstrument \
		void *instrumentationTimer; \
		void *instrumentationCallback;
#else
	#define mxMachineInstrument
#endif
	
#define modCriticalSectionDeclare
#define modCriticalSectionBegin() // TODO
#define modCriticalSectionEnd() // TODO

extern void modTimersExecute(void);
extern int modTimersNext(void);

and added it to the C_DEFINES:

C_DEFINES = \
	-DINCLUDE_XSPLATFORM \
	-DXSPLATFORM=\"xsPlatform_linemb.h\" \

(similar to the usage of this file: xs/platforms/lin_xs.h)

Aslo xs/platforms/xsHost.h is used, the only issue is that I've to fix a typo in this file (the uleep should be usleep ):

moddable/xs/platforms/xsHost.h

Line 74 in 4bb475e

#define modDelayMilliseconds(ms) uleep((ms) * 1000)

And the following declarations need to be added into xsPlatform_linemb.h

#define modCriticalSectionDeclare
#define modCriticalSectionBegin() // TODO
#define modCriticalSectionEnd() // TODO

extern void modTimersExecute(void);
extern int modTimersNext(void);

Then, for the main.c file:

int main(int argc, char *argv[])
{
  xsMachine *the = NULL;
  while (true) {
    the = modCloneMachine(NULL, NULL);

    modRunMachineSetup(the);
    while (true)
    {
      modTimersExecute();
    }
  }
  return 0;
}

And that's pretty much it! I got my main.js with timer running now:

import Timer from "timer"

trace("Hello, Linux Embedded!!!\n")

Timer.set(id => trace("immediate\n"))

Timer.set(id => trace("oneshot\n"), 1000)

let count = 0
Timer.repeat(id => {
	trace(`repeat ${count} \n`)
	5 == ++count && Timer.clear(id)
}, 1000)

root@orangepi3-lts:~# ./hello-linemb
Hello, Linux Embedded!!!
immediate
oneshot
repeat 0
repeat 1
repeat 2
repeat 3
repeat 4

[mkellner]

Great progress.

[linfan68]

I've forked current public branch and created a demo here:
https://github.com/linfan68/moddable/tree/linemb-demo

This is the commit:
90e1336

and a very minimal document:
https://github.com/linfan68/moddable/blob/linemb-demo/documentation/devices/linemb.md