- 20 Feb, 2017 4 commits
-
-
Cedric Roux authored
Develop integration w07 See merge request !116 Summary of changes: - integration of branch tm4-fixes (feature-59-tm4 + somes fixes) - integration of branch enhancement-199-nas-multi-ue - integration of branch develop-realtime-lts - integration of branch enhancement-211-snapping - various bugfixes
-
Cedric Roux authored
Prior to this commit, the following command failed to build dlsim: ./build_oai --phy_simulators -c Choice has been made to define it in a .h file as a static inline function.
-
Cedric Roux authored
The command line to get the error was: ./build_oai --eNB -w EXMIMO -c
-
Cedric Roux authored
The command line to get the error was: ./build_oai --eNB -w EXMIMO -c
-
- 17 Feb, 2017 20 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
We now have 4 versions of T_HEADER: - bad quality C++ version with time - good quality C version with time - bad quality C++ version without time - good quality C version without time
-
Cedric Roux authored
The compilation line was: ./build_oai --eNB -w USRP The file openairinterface5g/cmake_targets/log/lte-softmodem.Rel10.txt has been checked and all LOG_X (and 'msg') warnings have been fixed.
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
Not sure that it's correct, but those #pragma seem to be of no use for gcc. Let's remove them completely.
-
Cedric Roux authored
When rebuilding oaisim, I had a failure because the target link already exists. The -f flag forces the link to be done.
-
Cedric Roux authored
-
Cedric Roux authored
- some cleanup - thread names to include UE Mod_id - arg of UE_thread_rxn_txnp4 to be struct rx_tx_thread_data again - sync in UE_thread_rxn_txnp4 to use instance_cnt_rxtx again - UE_thread to call itti_send_msg_to_task with UE->Mod_id + NB_eNB_INST instead of INSTANCE_DEFAULT again This may break the softmodem UE, to be tested. The most problematic thing may be the synchronization. I don't think it will impact the processing at all, but I won't bet my shirt on it.
-
Cedric Roux authored
git show -p 58052152 to see what it's about
-
Cedric Roux authored
git show 157707b0 to see what it's about
-
Anta Huang authored
- build script has ability to indicate location for downloading uhd images - one simple wrapper to set environment variables and initiate another program (supposed to be lte-softmodem)
-
Cedric Roux authored
Many variables were changed that should not have been changed.
-
Cedric Roux authored
This reverts commit d31634c3. Laurent Thomas had a problem on one machine with the build_oai way of checking for nettle. The problem with the alternative solution of including nettle/bignum.h is that it is very unclear. The problem with nettle is that the file nettle/config.h does not exist for version 2. It was introduced in version 3. We want to support both versions, but there is an API incompatibility. So we need an #if #else mechanism. The file nettle/bignum.h is present in both versions 2 and 3 and it includes nettle/version.h in the version 3. So by including this file, we can check for the existence of NETTLE_VERSION_MAJOR (that comes from nettle/config.h) in the code. But as you can see, the reasoning is way too complex. So it's better to keep the check in cmake_targets/CMakeLists.txt. As long as we support version 2 this will be the way to go. It is possible to force a given version in specific non-generic customized environments.
-
https://gitlab.eurecom.fr/oai/openairinterface5gChia-Yu Chang authored
Merge branch 'develop' of https://gitlab.eurecom.fr/oai/openairinterface5g into various-l2-fixes-187 Conflicts: openair1/PHY/LTE_TRANSPORT/if4_tools.c targets/ARCH/ETHERNET/USERSPACE/LIB/eth_udp.c targets/ARCH/ETHERNET/USERSPACE/LIB/if_defs.h targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band7.tm1.if4p5.25PRB.lo.conf targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band7.tm1.if4p5.50PRB.lo.conf targets/PROJECTS/GENERIC-LTE-EPC/CONF/rcc.band7.tm1.if4p5.50PRB.usrpb210.conf targets/PROJECTS/GENERIC-LTE-EPC/CONF/rru.band7.tm1.if4p5.25PRB.oaisim.conf targets/PROJECTS/GENERIC-LTE-EPC/CONF/rru.band7.tm1.if4p5.50PRB.oaisim.conf
-
gabrielC authored
Conflicts: targets/RT/USER/lte-enb.c targets/RT/USER/lte-softmodem.c targets/RT/USER/lte-ue.c
-
pyroclaste authored
-
Cedric Roux authored
-
- 16 Feb, 2017 13 commits
-
-
Cedric Roux authored
Memory was allocated which was "lost" because the address of the block was put in a pointer that is overwritten just after. Discussing with Elena, the current commit is the correct way to do things.
-
Cedric Roux authored
Those functions modify a global char array (a string). Let's pass a buffer to those functions, so that it's thread safe. The caller has been modified, with hopefully a buffer big enough (still bigger than what was there before, so should not break more than it did).
-
Cedric Roux authored
command run: dos2unix openair1/SIMULATION/TOOLS/taus.c
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
Conflicts: openair1/SCHED/phy_procedures_lte_ue.c targets/RT/USER/lte-softmodem.c targets/SIMU/USER/oaisim.c targets/SIMU/USER/oaisim_functions.c
-
laurent authored
-
Laurent authored
-
Cedric Roux authored
This commit follows 7d9945e8. lte-softmodem UE in S1 and lte-softmodem UE in noS1 modes behave differently here. This commit fixes the issue for thoses cases. Other cases (eNB S1, eNB noS1, oaisim S1/noS1) have to be checked.
-
Cedric Roux authored
- fix OPc key - clear EHPLMN_LIST, UE does not start the RA procedure when set to be fixed
-
- 15 Feb, 2017 3 commits
-
-
Cedric Roux authored
This commit is a continuation of 614d6bbe (ue_ip: use correct instance). Now in openair2/NETWORK_DRIVER/UE_IP/common.c the 'inst' is not forced to 1 anymore, we take the value 'pdcph_p->inst'. It turns out that 'pdcph_p->inst' is 0 instead of 1 when we run lte-softmodem as an UE. So let's modify PDCP to set 'inst' to 1 where it was set to 0 for the UE softmodem case, and skip the places where it is reset to 0, still for the UE softmodem case. This may break things, I am not sure.
-
Cedric Roux authored
Guess what happens when we return from the function...
-
Florian Kaltenberger authored
-