connect's addrlen should be sizeof(local), not the contained path's length.
With the previous code, on OS X connect() will fail with ENOENT.
This permits layer23 to work on OS X using the pl2303 driver,
/dev/tty.usbserial , MacPorts arm-elf-gcc and RANLIB=arm-elf-ranlib
Signed-off-by: Harald Welte <laforge@gnumonks.org>
There are two occurrences of "413" in the 04.12 header file.
These are probably typos; correct them to "412".
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
Tune to the ARFCN specified on the commandline (-a). Then, if
a CBCH Channel Description IE is found in System Information Type 4,
switch to dedicated mode on that particular channel to receive
the CBCH.
Append $(HOST_CONFARGS) to ./configure scripts for 'host' applications.
This allows e.g. cross-compiling on an x86 build system for an OpenMoko
gta0x host, using an invocation such as:
$ make HOST_CONFARGS="--host=arm-angstrom-linux-gnueabi"
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
Don't assign to the variable given as argument. This prevents
clobbering the local 'reg' variables in uart_reg_{read,write}(),
which would in turn prevent the latch bits from being restored
correctly.
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
Store old_lcr only when switching to LCR == 0xBF. We don't want
to clobber old_lcr when switching back, otherwise we can't restore
the previous LCR value.
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
Beacons with the default 50 mS interval are too far apart to
be picked up by the OpenMoko gta0x Calypso chip. Make them
configurable via a -i commandline argument.
As recommended in the OpenMoko wiki[1], an interval of 13 mS works.
[1] http://wiki.openmoko.org/wiki/GSM/Flashing (-od fluid argument)
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
All functions for handling mobile instances and mobile relevant parts are
moved to mobile/app_mobile.c, the mobile/main.c and mobile/mncc.c become a
simple out-of-the-box mobile application. (making calls)
The mobile/main.c can be replaced easily by a different application now.
this application may have it's own call control implementation (layer 4).
Full configurations via VTY is still possible and required in this case.
This has two benefits:
- All people calling osmo_panic() will have the backtrace
- It makes the thing build in 'target' mode in osmocom-bb
And one downside:
- The osmo_panic handler is now in the backtrace
(I can live with that :)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
To create another instance: 'ms <name> create'
To remove an instance: 'no ms <name>'
If no instance exists, 'ms 1' is created automatically on startup.
Each instance can be enabled / disabled by using 'shutdown' or
'no shutdown'. Multiple instances may share the same layer2 socket (same
phone hardware), but in this case only one instance can be enabled at the
same time. This makes it much easier to select different settings without
modifying them.
A 'shutdown' initiates the IMSI detach procedure before shutdown is
completed. A 'shutdown force' will immidiately shutdown.
There is no need to restart the software anymore, if fundamental settings
are changed. In this case, a 'shutdown' followed by a 'no shutdown' will
do the job.
If you already have an old osmocom.cfg, you need to "no shutdown" it.
Everything else behaves as before.
This works for both the default ROM bootloader and for our
custom one.
This will allow to implement easy patch loading.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Harald Welte
David Wilson
Sylvain Munaut