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