Alternative OS

Lets start with the notion that it is a nice feature that the embedded modems can be programmed in c and it is relatively easy to get something going. A major problem is larger projects and maintance/bugs. It would be welcome if seperate tasks can be isolated, to name a few, ftp server, http server, telnet, snmp, lua, some data collection process and openat itself and interact by named pipes, filesystem etc. Seperated as in an own heap, stack and preferably memory protection and dynamic loading.

Now the “feature request” is not to ask SiWi to implement this, on the contrary, as seen by the number of bugs reported on this forum and the number of bugs encountered I would prefer to have the sources and rely as little as possible on SiWi code. The request is the opposite, I would appreciate it if there was a choice not to rely on SiWi binaries as far as possible, so the openat firmware implements the GSM stack and the application can do all/most other things.

In order to get some basic things running the following would be welcome

  • option to set an address which is called in low level interrupt with unmodified user register or ability to get the state before the exception (including lr).
  • ability to add protection to RAM (if there is a MPU…)
  • software interrupt to perform (inter process) communication (without the added RAM protection / ability to disable them) with access to user registers
    A single interrupt should be enough, I guess, a register can carry details I presume.

To make it a bit interesting

  • Provide a region of flash which can be directly accessed. (direct erase, write etc), so the a&d calls / recompact and friends can be avoided.
  • Provide info to use the UARTS and a call to stop openat from using the UARTs.
  • direct access to IO pins…

I don’t think this would actually be possible.

Remember: the Open-AT application is sharing the processor with the GSM Stack. So, to achieve certification, SiW need to be able to guarantee that the stack will continue to meet all the GSM requirements in the presence of any arbitrary user application - including ill-behaved user applications.

Therefore they cannot grant the application unfettered access to the underlying processor hardware - it has to go through an API layer.

Or just the “traditional” approach of separate microcontroller and GSM “engine”…

Do you remember the old, so-called “Basic”, Open-AT interface…?

Regarding some specific issues:

Absolutely!

Have you looked at the IRQ service?

I think there is an MPU - which is why you get exceptions when you try an invalid memory access?

Have you looked at the Direct (or “Open”) UART access service?

See AT+WMFM

I don’t know the requirements for a GSM stack. However I think the context switch can be done in the existing user mode low level interrupt, by altering the current mode and setting the program counter to the point where it wants to resume. The caller (OpenAT) should then be able to cope with the interrupt not returning. To swap out an application task, the registers and program counter before the interruption must be known (if an application task was running). The interrupted task is already known, since there is an adl call for it.

For pheriphal access; I don’t know how protection is implemeneted in ARM. But let rephrase it then, especially for flash; it would be nice if sufficient low level flash access api calls are available so a (albeit simplistic, limited) file system can be added.

Yes, well stangely enough it is actually the reason for this request. Since seriously debugging a Fasttracks / FXT is virtually impossible / at least very time consuming I made a simple pc project using lwIP savannah.nongnu.org/projects/lwip/ and “talk” to the modem. lwIP supports PPP and can setup tcp/ip connections over GPRS. The data can then be saved to a file / send by a named pipe by to Wireshark etc, making things allot more fun. lwIP has dedicated memory pools, it optionally support BSD sockets (which is of course interesting since allot of open code can then be used. lwIP itself has a BSD type of license). So I really like the idea of replacing WIP with lwIP. The sockets require blocking / wait operations and hence I looked at the context services.

However those require preconfigured “tasks”, share all memory and can’t be started, “killed” / removed. The semaphore service traps if you try to increment semaphores etc etc. So I wondered if a more common / tested code could not be used. There are many (tiny) OS-es publically available, like FreeRTOS e.g. which support lwIP again (ucIP? as well but don’t know that one) (and a filesystem, but don’t know which).

To make it reliable it must be preemptive and not collaberative or the system would still fail on the first failing task. In the exception handler, it can then dump, and kill the offending “task”, but keep the device running to obtain logs / traces by ftp / xmodem etc. (like Awneil encountered, I still can’t decode exceptions

So in short i think it could be done…

  • user land switching can be done if SiWi provides the required info to do so (copy of interrupted context and expects / tolerates not to return)

  • replacing the current current context (user) can be done, but might require some head scratching

  • an alternative OS might then be installed

  • newlib can be ported (currently codesourcery.com/ is shipped, but printf() snprintf(“%f”) don’t work since the stubs are not implemented)

  • a filesystem could be added, but preferably without adl_ad…

  • adding a tcp stack is then rather simple, since lwIP is e.g. ported to FreeRTOS (and shipped with it)

  • on top of that loads of software could be run…

  • and as a bonus, a pc can be easily setup to look exactly the same as the modem / using local tcp/ip or talking to the modem, serial, making development ALLOT easier…

  • tcp / ip is available in the modem [and logs could easily be stored if a filesystem is present]

  • software talking to / embedded in the modem is (almost) the same.

Yes, and the Low Level Interrupt does know which context is interrupted. However since the callback is called by c function the registers and lr (link register, containing the original program counter [well +8?]) are modified by the OpenAt handler serving the interrupt and do not reflect the interrupted context.

I guess so too, but there might be a mmu and the OpenAT memory addresses being unregistered, don’t know…

For completeness, the request is to add more restrictive rules to protect “tasks”, not to remove OpenAT restrictions. The " Application software interrupt" should remove the added restriction but can still be called in OpenAT restrictions / user mode (but not expected to return).

yes, and ran away… [perhaps just the mood?]

Have you found any good documentation on doing that?

The LwIP Wiki page on the subject is, effectively, blank: lwip.wikia.com/wiki/PPP :frowning:

I sympathise - see: Q2686 UART2 write Issue - #2 by awneil

No documentation is not something the lwIP people seem to excel in (, nor making decent looking websites).
But there is a contrib zip file at download.savannah.gnu.org/releases/lwip/ with example code.
I used the Windows port, and added some glue to use a real com-port instead of a named pipe (guess they run it in virtualbox or the like, sio.c).

The Windows example has PPP support (might need some defines), I altered startup to:

sio_fd_t ppp_sio;
	ppp_sio = sio_open(6);	// com port number
	if (ppp_sio != NULL)
	{
		printf("pppInit\n");
		pppInit();
		pppSetAuth(PPPAUTHTYPE_ANY, "Vodafone", "Vodafone");
		printf("pppOpen\n");
		sio_write_string(ppp_sio, "ATE0\r\n");
		sio_expect_string(ppp_sio, "OK\r\n");

		sio_write_string(ppp_sio, "AT+CGDCONT=1,\"IP\",\"office.vodafone.nl\"\r\n");
		sio_expect_string(ppp_sio, "OK\r\n");

		sio_write_string(ppp_sio, "ATD*99***1#\r\n");
		sio_expect_string(ppp_sio, "CONNECT 115200\r\n");

		do_sleep(1000);
		pppOpen(ppp_sio, pppLinkStatusCallback, NULL);
	}

SIO GLUE stolen from:
metsahovi.fi/~jwagner/iBob/g … etif/sio.c

I see three contrib files:

contrib-0.7.1-20040319
contrib-1.3.0
contrib-1.4.0.rc1

Not immediately obvious which of the examples illustrates the PPP…?
Or do they all?

Update:
Just done a better grep of the sources, and found lots to look at this time…