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/baseband-devel@lists.osmocom.org/.
☎ Max.Suraev at fairwaves.ru19.10.2012 09:57, Sylvain Munaut пишет: > He's talking about this structure : > > struct mframe_sched_item { > const struct tdma_sched_item *sched_set; > uint16_t modulo; > uint16_t frame_nr; > uint16_t flags; > }; > Yes, exactly. Pardon for being unclear. > > However I don't see the gain of space as really that much of an > advantage vs the potential time lost looking for bugs when playing > with non-standard multiframes. > I agree. Btw, is this non-standard multiframes experimentation available in some public repo? Would love to have a look at the code. > The fact that we are currently almost full memory is just because we > still use the compal loader. We should just deprecate that and > oompletely and only compile the chain loader and loader with that > constrained memory layout. > Indeed - I've got error about rssi.compalram.elf file which is too big to be used without chainloading anyway. Maybe we can make this configurable via something like ./configure --enable-compalram-rssi ./configure --enable-chainload-rssi etc. -- best regards, Max, http://fairwaves.ru