libosmocore embedded build

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue May 16 16:27:08 UTC 2017


Dear all,

when we originally moved a lot of generic code from OpenBSC to
libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded'
build of libosmocore, which can use [most of] the library code also in
deeply embedded, OS-less 'bare metal' microcontroller environments.

The ability to build libosmocore this way has been broken for many
years, but I've fixed that in recent libosmocore master.  Below command
works for me [tm]:
./configure	--prefix=/usr/local/arm-none-eabi \
	 	--host=arm-none-eabi \
		--enable-embedded \
		--disable-shared \
		CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs"

What we'd need now is:

1) make sure embedded builds continue to work by building libosmocore
   for embedded as part of the jenkins setup (using gcc-arm-none-eabi
   debian package). Any volunteers?

2) start to use this embedded build from simtrace2 firmware, osmocom-bb
   and the upcoming fimrware for the RFDN[1].  So far,
   * osmocom-bb uses an old clone of libosmocore,
   * simtrace2 is using some copy+pasted fork of some libosmocore files
   * rfdn is using some copy+pasted fork of some libosmocore files
   The above is no longer required.

3) consider if we can shrink the resource requirements of some
   libosmocore parts. One issue coming up are the static buffers in
   osmo_hexdump[] or the like.  If your total processor RAM is 8k or
   16k, then spending 4k on the buffer for hex-dumping is indeed a bit
   excessive.

Any help is appreciated, particularly on the jenkins side.

Regards,
	Harald

[1] (1:8 splitter-combiner with adjustible step attenuators, part of the
    osmo-gsm-tester setup we're building at sysmocom). Code will be
    released as soon as the hardware is validated.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list