Hi again techies.
Thanks for your advises and schemas. I already bought what was announced and
illustrated as a mot t191 cable at a french company but it turned to be a
"flash cable" with possibly wrong pinout and voltage. If you look at
http://www.cellcorner.com/xshp/unlock-phone-codes/motorola-t190-t191-t193-u…,
it's looks exactly the same one as I have. Did someone buy this one and used
it successfully? I measured 4 volts when putting positive pin of my
voltmeter to rx and negative pin on ground of the 2.5mm jack.. As said
before, don't want to fry my moto. No cable, no project:( Sorry for my
noobie question on this high level mailing list...
Hi, List,
I heard through the grape vine that you are considering using NuttX. I don't want to influence your decision, but if the decision is final, I would like to offer any support to the project that I can give.
> Indeed. The TI C5471 DSP/ARM chip seems to be virtually a predecessor of the Calypso.
I have quite a bit of experience working with these TI dual core chips and would be happy to help out as much as possible. With the ARM7/c5 family, I have developed OS support (uClinux) for the C5471, DSC21, DSC24, and DM270. Also the DM320 (ARM9/c5, Linux).
I founded this business in Costa Rica (http://www.ridgerun.com, also once called Cadenux). But have not been involved with the more recent ARM11/Cortex A8/c6 chips.
> I'm already working on the IRQ subsystem and took a look at the UART.
> But there are open questions, see above...
There is a porting guide here may be helpful to you: http://nuttx.sourceforge.net/NuttxPortingGuide.html.
But it does a some "To be provided" sections -- particulary in the IRQ section.
> I have a c5 DSP bridge driver somewhere around on my backup disks as
> well. I never released it into NuttX because there was never any
> need. Perhaps that could be useful now.
These DSP bridge drivers present interfaces to load programs into the DSP and to support an integrated, seamless messaging system between the ARM7 and the DSP.
The DSP interfaces differ from chip to chip and the drivers that I was referring were targeted for uClinux. However, if that is something you are interested in, I would be happy to do the port a driver and integrate DSP messaging with the NuttX messaging.
Greg
Hello Stefan,
On Tue, 17 May 2011 00:09:13 +0200, "l--putt" <ichgeh(a)l--putt.de> wrote:
>
> Saving power
> Having everything on and at maximum clock drains the battery _fast_!
> With the ULPD, we actually have the appropriate solution build into the
> Calypso. I guess other chipsets have something similar.
> It is neat to get the timing and power sequence right. But since the
> TDMA timing is affected, Layer 1 must be aware of those clock/power
> changes or at least tolerate to be turned on and off. Does anybody right
> away have ideas how to approach this?
A few notes, I don't remember the details: The basic idea is to only
receive in idle mode when its necessary. This means listening only for
the paging group of the IMSI and doing the neighbour cell measurements.
During the other time the processor can be stopped. There are different
levels to which extend the clock is stopped, for saving the most power
only the 32 kHz crystal remains active. However this requires some
calibration, otherwise the TDMA frames could be missed after sleeping.
Most of this calibration can be done with the help of the hardware,
its always done before switching to 32 kHz.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi list!
Some time ago Harald suggested to create a complete phone, at least with
minimal features. Since this hasn't been covered yet and we will have to
rewrite some parts during RTOS porting anyway, I think we should
consider some kind of power management:
Saving power
Having everything on and at maximum clock drains the battery _fast_!
With the ULPD, we actually have the appropriate solution build into the
Calypso. I guess other chipsets have something similar.
It is neat to get the timing and power sequence right. But since the
TDMA timing is affected, Layer 1 must be aware of those clock/power
changes or at least tolerate to be turned on and off. Does anybody right
away have ideas how to approach this?
Charger
The C155 has a dedicated chip which you probably just have to turn on.
On the C123, it's a bit more complex but the algorithms don't seem to be
too complex. Has anybody tried this already?
State-of-Charge
For the usual concepts on batteryuniversity.com, a random book from the
university lib, and some papers, we would need some means to measure the
discharge current. No Compal phone provides this since the voltage
regulators are connected directly to the battery. The gta02 avoids this
with a dedicated Coulomb-counting chip. The gta01 doesn't care!? Maybe
the battery voltage and temperature is sufficient for reasonably correct
estimates. If not, we could try to model the current. However, this
requires some kind of central power management that knows activated
devices, their clocks, etc.
I would volunteer for the latter and C155-charging. However, I lack a
C123 for tests and don't want to be responsible for exploding phones ;)
Integration of the ULPD is a bit more GSM-related. Might turn out to be
interesting...
Cheers,
Stefan
Hi Wolfram,
I hit the following linking error in the current
LD board/mt62xx/loader_mtk.mtkram.elf
arm-elf-ld: address 0x400050ec of board/mt62xx/loader_mtk.mtkram.elf
section .text is not within region LRAM
make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1
I'm not familiar with those bits, any clue on what's wrong? Thanks.
Hi,
some quick notes on the MacOSX build. Current git builds fine using the
perbuilt GNUARM MacOS toolchain except that GCC 3.3 does not support the
option -Wextra.
There are also some issues building mtk firmware but this seems to be a
more general issue.
Cheers
Klaus
diff --git a/src/target/firmware/Makefile.inc
b/src/target/firmware/Makefile.inc
index 1f54031..c8f4323 100644
--- a/src/target/firmware/Makefile.inc
+++ b/src/target/firmware/Makefile.inc
@@ -12,7 +12,7 @@ OBJCOPY=objcopy
DEBUGF=dwarf-2
CFLAGS=-mcpu=arm7tdmi $(INCLUDES)
-CFLAGS += -Wall -Wextra -Wcast-align -Wimplicit -Wunused
+CFLAGS += -Wall -Wcast-align -Wimplicit -Wunused
CFLAGS += -Wswitch -Wredundant-decls -Wreturn-type -Wshadow
-Wnested-externs
CFLAGS += -Wbad-function-cast -Wsign-compare -Waggregate-return
CFLAGS += -Os -ffunction-sections
Hi
I try to compile osmocom in Ubuntu, I have gcc 4.4.3 and I installed binutils
2.20 for ARM successfully and I have arm-elf-* binaries in PATH directory
when I run make in src folder of osmocom, I get error: unknown instruction "ror
xor" something something....
What's problem, do I missing something?
Thanks
