11 Apr
2016
11 Apr
'16
5:20 p.m.
I am the project lead for the SHAKTI open source processor project.
See bitbucket.org/casl
This is a large Indian processor development effort that aims to develop
a range of processors (from uController to high end servers) based
on the RISCV ISA. We work closely with UCB and Cambridge as part of this
effort.
As part of our processor family, we have just started on a mobile SoC.
The goal is to have an octa core SoC with the performance of a
snapdragon 820 or the Apple A9. the CPU core is pretty much under
control but we are exploring the DSP needed for running the lower levels
of the 3G/LTE stack.
Another group does LTE stacks and so we have complete testing equipment
available to test for compliance.
I am basically looking for co-conspirators who can help identify the
components
I can use from the osmocom stack and figure out what else we need to
develop.
Then of course we need to develop the DSP core. We are currently reusing
the UCB vector processor and we are trying to figure out if a vector thread
processor or
a conventional DSP will do the trick.
Our goal is to have am SoC that will the functionality of a basic smart
phone
but we do not intend to focus only on a basic phone with voice/data
ca[ability but with basic display (even 4 line display is OK). Plan to use
the
AD SDR board for the SDR section. So it will be a large board that is
not optimized for size.
Any comments, thoughts appreciated . In case you are wondering, yes we
realize
this a mammoth task but we are well funded ! This is part of the India
processor project. And most importantly all our work will be patent free
open source. HW will be BSD, SW will be GPL3/2
--
Regards,
Madhu
11 Apr
11 Apr
5:35 p.m.
I forgot to add. Since the first variant will be on an altera or xilinx
board, the first cut design will use the
DSP blocks on the FPGA. Cores will be the quad core A53 that is found in
the new FPGAs.
We can use our cores in the FPGA variants but soft cores will not be as
fast as the hard cores.
Our SoC development will proceed in parallel.
On Mon, Apr 11, 2016 at 8:50 PM, Madhu Macaque Labs <madhu(a)macaque.in>
wrote:
I am the project lead for the SHAKTI open source
processor project.
See bitbucket.org/casl
This is a large Indian processor development effort that aims to develop
a range of processors (from uController to high end servers) based
on the RISCV ISA. We work closely with UCB and Cambridge as part of this
effort.
As part of our processor family, we have just started on a mobile SoC.
The goal is to have an octa core SoC with the performance of a
snapdragon 820 or the Apple A9. the CPU core is pretty much under
control but we are exploring the DSP needed for running the lower levels
of the 3G/LTE stack.
Another group does LTE stacks and so we have complete testing equipment
available to test for compliance.
I am basically looking for co-conspirators who can help identify the
components
I can use from the osmocom stack and figure out what else we need to
develop.
Then of course we need to develop the DSP core. We are currently reusing
the UCB vector processor and we are trying to figure out if a vector thread
processor or
a conventional DSP will do the trick.
Our goal is to have am SoC that will the functionality of a basic smart
phone
but we do not intend to focus only on a basic phone with voice/data
ca[ability but with basic display (even 4 line display is OK). Plan to use
the
AD SDR board for the SDR section. So it will be a large board that is
not optimized for size.
Any comments, thoughts appreciated . In case you are wondering, yes we
realize
this a mammoth task but we are well funded ! This is part of the India
processor project. And most importantly all our work will be patent free
open source. HW will be BSD, SW will be GPL3/2
--
Regards,
Madhu
--
Regards,
Madhu
15 Apr
15 Apr
10:06 p.m.
Hi Madhu,
On Mon, Apr 11, 2016 at 08:50:17PM +0530, Madhu Macaque Labs wrote:
I am the project lead for the SHAKTI open source
processor project.
Thanks a lot for introducing yourself, your extremely ambitious project
and for reaching out to us. I can hardly grasp the complexity of your
enormous task, and I think it would still be extremely challenging if
you would only focus on the cellular side of things, ignoring the
application processor side.
snapdragon 820 or the Apple A9. the CPU core is
pretty much under
control but we are exploring the DSP needed for running the lower levels
of the 3G/LTE stack.
I am not aware of anyone having done any free software work on the MS/UE
side of GPRS, EDGE, UMTS or HSPA, so I think you will have to start from
scratch there - not only ergarding the DSP performance/capability
requirements, but also regarding the actual implementation.
There's the OsmocomBB work that focusses on classic circuit-switched GSM
only, and there is srsUE (see below) for LTE. But everything in between
is a big gap. You might be able to extend and re-use OsmocomBB Layer3
for UMTS circuit-switched NAS, but that's just a very small fraction of
the problem.
Most of the other Osmocom wokr has been focusing on the netwokr side of
the protocol stacks, so we have GSM, GPRS and partial EDGE support for
all of the network side (PHY to RAN to CN), and we are working on the
core-network parts of UMTS/HSPA at this point. But that's of very
little use for UE side work, at least on anything beyond message
encoding/decoding, some definitions.
Another group does LTE stacks and so we have complete
testing equipment
available to test for compliance.
I would seriously have a look at the excellent work been done at
Software Radio Systems on their srsUE implementation of LTE. They
implemented a full LTE UE from PHY via AS to NAS as free software under
AGPLv3. They are running all of this on an Intel Core i7 CPU, but I'm
sure you could re-implement the performance criticla SDR part of the PHY
in your DSP and re-use everything on top.
FOSS is abut collaboration and not re-inventing the wheel, after all :)
I am basically looking for co-conspirators who can
help identify the
components I can use from the osmocom stack and figure out what else
we need to develop.
I personally would love to be involved, but I am already working what
other people would consider two full time jobs and there is absolutely
no time left to engage in any additional projects without long-term
scheduling and planning, sorry. Maybe there are others in Osmocom who'd
have more time and interest.
In any case, it would be great if you could keep us posted in some way
about your progress.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
16 Apr
16 Apr
9:38 a.m.
On Sat, Apr 16, 2016 at 1:36 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
There seem to be a few openLTE efforts including UE stacks. Looking at
those.
Fortunately we have a full fledged LTE lab on campus with all the necessary
test equipment.
Hi Madhu,
On Mon, Apr 11, 2016 at 08:50:17PM +0530, Madhu Macaque Labs wrote:
We have in fact decided to split the work into two projects. I have no
option
but to do the AP and other server SoCs since that is the core project. But
we now
have a separate LTE/5G modem effort. Focus will be more on programmability
than the lower power core. The turbo encoder/decoder is tricky. But then
I have a lot of Mater's students at my disposal !
I am the project lead for the SHAKTI open source
processor project.
Thanks a lot for introducing yourself, your extremely ambitious project
and for reaching out to us. I can hardly grasp the complexity of your
enormous task, and I think it would still be extremely challenging if
you would only focus on the cellular side of things, ignoring the
application processor side.
snapdragon 820 or the Apple A9. the CPU core is
pretty much under
control but we are exploring the DSP needed for running the lower levels
of the 3G/LTE stack.
I am not aware of anyone having done any free software work on the MS/UE
side of GPRS, EDGE, UMTS or HSPA, so I think you will have to start from
scratch there - not only ergarding the DSP performance/capability
requirements, but also regarding the actual implementation.
There's the OsmocomBB work that focusses on classic circuit-switched GSM
only, and there is srsUE (see below) for LTE. But everything in between
is a big gap. You might be able to extend and re-use OsmocomBB Layer3
for UMTS circuit-switched NAS, but that's just a very small fraction of
the problem.
Most of the other Osmocom wokr has been focusing on the netwokr side of
the protocol stacks, so we have GSM, GPRS and partial EDGE support for
all of the network side (PHY to RAN to CN), and we are working on the
core-network parts of UMTS/HSPA at this point. But that's of very
little use for UE side work, at least on anything beyond message
encoding/decoding, some definitions.
Have looked at it. Trying to figure out how complete it will be.
It is a circular problem. Want to co-design the DSP along with the stack
and not dump a DSP on the SW team. My only problem is that our language
of choice is Bluespec and not everybody has the toolchain for it.
It is a high level HW desgn language (actually a Haskell derivative).
Would love to have other enhancing our RTL too. Fortunately the tool
is free for open source developers.
Another group does LTE stacks and so we have
complete testing equipment
available to test for compliance.
I would seriously have a look at the excellent work been done at
Software Radio Systems on their srsUE implementation of LTE. They
implemented a full LTE UE from PHY via AS to NAS as free software under
AGPLv3. They are running all of this on an Intel Core i7 CPU, but I'm
sure you could re-implement the performance criticla SDR part of the PHY
in your DSP and re-use everything on top.
FOSS is abut collaboration and not re-inventing the wheel, after all :)
That is OK. Just spread the work around. The key is to get a completely
open LTE
HW platform that can be the basis for many commercial implementations. I
already have
two major phone OEMs signed up for using our modem (when it arrives !).
I am basically looking for co-conspirators who
can help identify the
components I can use from the osmocom stack and figure out what else
we need to develop.
I personally would love to be involved, but I am already working what
other people would consider two full time jobs and there is absolutely
no time left to engage in any additional projects without long-term
scheduling and planning, sorry. Maybe there are others in Osmocom who'd
have more time and interest.
In any case, it would be great if you could keep us
posted in some way
about your progress.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)
--
Regards,
Madhu
12:54 p.m.
Madhu,
On Mon, Apr 11, 2016 at 6:20 PM, Madhu Macaque Labs <madhu(a)macaque.in> wrote:
Plan to use the AD SDR board for the SDR section. So
it will be a large board that is
not optimized for size.
Just curious - which exact transceiver chip are you planing to use?
Would be great to have more open-source SDR designs out there for
different use cases.
We've developed open-source SDR based on LMS6, but it targets network
side and is too power hungry for an MS. Otherwise I would offer our
help, as I appreciate your effort. This a really amazing project and I
hope you'll be able to pull it off.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Subscribe to Fairwaves news: http://eepurl.com/baL_pf
2:23 p.m.
We do plan to have large PCIe card type format to test the UE side, so we
will probably end up
using your setup first. W are also using the ADR xcvr for our GPS/IRNSS
design.
For MS apps, we are evaluating the various parts used in mid range handsets.
Will select the one that has the most open documentation. No sure how
open silicon motion is.
I have no illusions about the difficulty of our project ! But high speed
digital design is
our bread and butter, so hopefully we should be able to make progress. L1
processing is the
tricky part. The main RISCV CPU core is already developed and online in our
repository.
Probably 2-4 cores with
a vector processor accelerator will suffice for the L2/L3 stack. Will use a
ringbus or a crossbar
as the interconnect.
It would help if folks in this forum had any opinions on the UCB VP. See
hwacha.org.
On Sat, Apr 16, 2016 at 4:24 PM, Alexander Chemeris <
alexander.chemeris(a)gmail.com> wrote:
Madhu,
On Mon, Apr 11, 2016 at 6:20 PM, Madhu Macaque Labs <madhu(a)macaque.in>
wrote:
--
Regards,
Madhu
Plan to use the AD SDR board for the SDR section.
So it will be a large
board that is
not optimized for size.
Just curious - which exact transceiver chip are you planing to use?
Would be great to have more open-source SDR designs out there for
different use cases.
We've developed open-source SDR based on LMS6, but it targets network
side and is too power hungry for an MS. Otherwise I would offer our
help, as I appreciate your effort. This a really amazing project and I
hope you'll be able to pull it off.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Subscribe to Fairwaves news: http://eepurl.com/baL_pf
23 May
23 May
4:21 p.m.
New subject: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb?
The place where I normally play with osmocom-bb has pretty bad 2G coverage and I was
wondering if I could make a signal booster/repeater with a couple of osmocom phones?
Also wondering if 3G would require totally different hardware than the old Calypso
motorola phones or if it could be achieved with firmware+DSP changes?
I have a 3G cell spot that boost that signal so just trying to find a way to make an
osmocom-bb phone work well in my place.
Thanks,Craig
5:45 p.m.
New subject: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb?
Short answer: no & no
1 - A gsm repeater is an analog device. With osmocom-bb phones you would
need to demodulate/remodulate bursts.
This will mess with timing advance, and you won't be able to send bursts in
the same frame/timeslot they were received.
2 - Calypso don't/won't support 3G.
Regards
On Mon, May 23, 2016 at 4:21 PM, Craig Comstock <craig_comstock(a)yahoo.com>
wrote:
The place where I normally play with osmocom-bb has
pretty bad 2G coverage
and I was wondering if I could make a signal booster/repeater with a couple
of osmocom phones?
Also wondering if 3G would require totally different hardware than the old
Calypso motorola phones or if it could be achieved with firmware+DSP
changes?
I have a 3G cell spot that boost that signal so just trying to find a way
to make an osmocom-bb phone work well in my place.
Thanks,
Craig
20 Jun
20 Jun
9:32 p.m.
New subject: Sv: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb?
Does anybody know if it would be possible to use some of the old vodaphone-femtocells
together with openbsc/osmo-bts?
RegardsErich
Den Mandag, 23. mai 2016 11.46 skrev etienne . <etiennehelluy(a)gmail.com>om>:
Short answer: no & no
1 - A gsm repeater is an analog device. With osmocom-bb phones you would need to
demodulate/remodulate bursts.
This will mess with timing advance, and you won't be able to send bursts in the same
frame/timeslot they were received.
2 - Calypso don't/won't support 3G.
Regards
On Mon, May 23, 2016 at 4:21 PM, Craig Comstock <craig_comstock(a)yahoo.com> wrote:
The place where I normally play with osmocom-bb has pretty bad 2G coverage and I was
wondering if I could make a signal booster/repeater with a couple of osmocom phones?
Also wondering if 3G would require totally different hardware than the old Calypso
motorola phones or if it could be achieved with firmware+DSP changes?
I have a 3G cell spot that boost that signal so just trying to find a way to make an
osmocom-bb phone work well in my place.
Thanks,Craig
21 Jun
21 Jun
12:53 p.m.
New subject: Sv: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb?
Hi,
Those femtocells use ipsec to which the keys are not available (yet). The ones that were
not automatically upgraded by Vodafone and therefore expose a serial shell might be used,
but that requires some more investigation (and sadly not much of un-upgraded versions
exists...also downgrading isn't an option if I'm correct because they do this
inside the IPsec tunnel).
Maybe Kevin has more memories about them :).
Other femtocells (e.g. SFR) that use EAP-SIM should be easily connected to an open core
network by simply using SIM cards with known keys.
Cheers,
Domi
2016. jún. 20. dátummal, 21:36 időpontban Erich Dachleger <edachleger(a)yahoo.com>
írta:
Does anybody know if it would be possible to use some
of the old vodaphone-femtocells together with openbsc/osmo-bts?
Regards
Erich
Den Mandag, 23. mai 2016 11.46 skrev etienne . <etiennehelluy(a)gmail.com>om>:
Short answer: no & no
1 - A gsm repeater is an analog device. With osmocom-bb phones you would need to
demodulate/remodulate bursts.
This will mess with timing advance, and you won't be able to send bursts in the same
frame/timeslot they were received.
2 - Calypso don't/won't support 3G.
Regards
On Mon, May 23, 2016 at 4:21 PM, Craig Comstock <craig_comstock(a)yahoo.com> wrote:
The place where I normally play with osmocom-bb has pretty bad 2G coverage and I was
wondering if I could make a signal booster/repeater with a couple of osmocom phones?
Also wondering if 3G would require totally different hardware than the old Calypso
motorola phones or if it could be achieved with firmware+DSP changes?
I have a 3G cell spot that boost that signal so just trying to find a way to make an
osmocom-bb phone work well in my place.
Thanks,
Craig
3297
days inactive
3368
days old
baseband-devel@lists.osmocom.org
9 comments
7 participants
participants (7)
-
Alexander Chemeris -
Craig Comstock -
Erich Dachleger -
etienne . -
Harald Welte -
Madhu Macaque Labs -
Tomcsányi, Domonkos