Dear Members,
I incidentally see your development of linux drivers for
MT6235/6140 chipset(the sciphone G2), and wanna share my 50 cents: The
year 2009 released AP+BB monolithic chip MT6156 from mediatek is an
ARM9 AP + ARM7 BB (the old MT6235 is ARM9 AP, MT6140 is ARM7 BB),
considering the timeline of mediatek processors, it should be
conjectured that MT6516 is a combination of these two chips. They
already have Windows mobile 6.5 drivers mature for MT6516, and they
have android drivers (not only driver but the whole system image),
which might be an important referenece for developing MT6235 linux
drivers. So I believe it's a good idea to ask MTK for its MT6516
linux driver and see what can be ported.
Best for all,
Duane
On Tue, Dec 07, 2010 at 08:16:06PM +0200, Alex Badea wrote:
> On 12/07/2010 06:36 PM, Hermann Gausterer wrote:
> >Small typo in the second Serial Number Octet
> >
> >Signed-off-by: Hermann Gausterer<libosmocore-2010(a)mrq1.org>
>
> Good catch, thanks!
>
> You should send this patch to baseband-devel(a)lists.osmocom.org such
> that one of the maintainers can apply it.
>
> Thanks,
> Alex
Hi list,
Last days I was focused on getting self-built code running from NAND memory and finally I got it working.
You can find short demo which actually covers all the functionality which is currently working on Sciphone:
http://www.youtube.com/watch?v=w_Iwsckm7Ko
Here is the list of functionalities which are already working:
* NAND memory driver with HW ECC control and MTK's ECC layout (ECC layout is important for loading SPL, creating dumps of firmware and restoring it).
NAND driver also supports all the NAND memories found so far on Sciphone G2 (small page and large page).
* SD/MMC card support
* LCD driver (automatically detects LCD controller, so far identified two different LCD controllers mounted in G2: ILI9331 and ILI9325)
* tool for creating bootable image from given binary file (should work on all MT62xx chips).
It doesn't need to be SPL (from U-Boot), it can be self-built binary which will be run by IPL on the phone (not bigger than 64kB).
* automatic detection of RAM memory in SPL (two configurations checked) - this will be added by Steve to osmocon loader as well
* BBT and ENV can be saved in NAND (BBT in NAND is disabled by default, as deletes last two NAND blocks, and most people are running from RAM)
I also updated wiki with informations about new features added:
http://bb.osmocom.org/trac/wiki/SciphoneDreamG2
Open issues:
* LCD controller is using the same data lines as NFI (NAND) controller. Currently it's not possible to use NAND when LCD is enabled.
* vibrator in SPL code - vibrator will be turned on in SPL when it'll start reading NAND and turned off when it'll finish,
thanks to that user will know that SPL code has started (short code which doesn't change SPL size).
* boot process from NAND has been tested only on small page NAND device - I'll create dump of my second phone
and try this process on large page NAND device as well
I recommend to create full NAND dump before playing with new software.
There is already driver for NAND running and you can erase/write NAND easily by mistake.
I turned on define CONFIG_ENV_IS_IN_NAND, which will not erase/write NAND at start, but when you execute "saveenv" command it'll do so.
Please, make NAND dump first.
The problem with NAND dump is that I haven't found built-in functionality in U-Boot that sends dump of RAM memory (where NAND will be read) to PC/SD card.
Dump also has to be created in chunks, as there is less RAM memory than NAND. I'm planning to create dump/restore commands which will save/restore dumps using SD card, but I didn't start it yet.
Currently the easiest way is to create dump in FlashTool.
I checked that restoring of phone using dump created in FlashTool works, so going back to previous firmware is possible.
Unfortunatelly code for LCD driver is not yet in git as my coleague didn't manage to finish it today. Hopefully it'll be available during weekend or beginning next week.
Now I'm going to switch to Linux kernel side and start writing drivers there...
Other good new is that Andrew has reported last week that he successfully run our code on E1000 chinese phone which is also based on MT6235.
There was no need to make any changes.
Here is how E1000 phone looks like:
http://triray.en.made-in-china.com/product/kbYJeomynHhs/China-N97-WiFi-Java…
BR,
Marcin
Hello all,
I'm going to be giving a presentation about free software GSM
implementations at the FSFE's Berlin meeting on December 9th, 2010. It
will be very elementary and newcomer-friendly. I'm planning to go
over OsmocomBB, OpenBTS and OpenBSC, and discuss their security and
practical implications.
The talk will start at 19:30 in Newthinking Store Tucholskystr. 48,
10117 Berlin. You can find more about it on
http://aligunduz.org/blog/free_gsm_talk_next_week.html
Considering I'm not an expert on GSM myself, it would be nice to have
people more familiar with it in attendance.
Ali Gündüz
Hello Ton,
On Sun, 28 Nov 2010 23:09:59 +0100, "Ton Slewe" <ton.slewe(a)gmail.com> wrote:
>
> I have tracked down the error to sim.c. I tried to push it to the GIT
> repository which does not seem to work (credentials?). Maybe somebody
> can patch it in their version and then push it. Or otherwise please
> point me in the direction to get it fixed in the repository.
You have take the version from Sylvain's testing branch (Sylvain, please
correct me if the extended SIM driver is no longer there) ?
I ask because there is already a fixed version with several improvments
which is supposed to work in this branch (at least for those SIM task
required to access a real network).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I have trying the osmocom apps today (firmware). One of the apps,
simtest, did not seem to work well.
I have tracked down the error to sim.c. I tried to push it to the GIT
repository which does not seem to work (credentials?). Maybe somebody
can patch it in their version and then push it. Or otherwise please
point me in the direction to get it fixed in the repository.
Some of the variables on top of the file are not declared as volatile
(they should be because they are modified in an Interrupt Service
Routine). I changed all the variables on top of the file into volatile:
static volatile int sim_rx_character_count = 0; /* How many bytes have
been received by calypso_sim_receive() */
static volatile int sim_tx_character_count = 0; /* How many bytes have
been transmitted by calypso_sim_transmit() */
static volatile int sim_tx_character_length = 0; /* How many bytes have
to be transmitted by calypso_sim_transmit() */
static volatile uint8_t *rx_buffer = 0; /* RX-Buffer that is issued by
calypso_sim_receive() */
static volatile uint8_t *tx_buffer = 0; /* TX-Buffer that is issued by
calypso_sim_transmit() */
Now simtest is working as expected.
Kind regards,
Ton
Hi,
This patch series adds layer23 support for receiving SMSCB messages.
Patches 1/3 and 2/3 add common layer2 code for reassembling blocks and
sending them up to L3. Patch 3/3 is an addition to cell_log for logging
cell-info-display-type SMSCB messages, if available.
This series requires patches[1][2][3] to libosmocore protocol headers.
Cheers,
Alex
[1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000827.html
[2] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000830.html
[3] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000831.html
Alex Badea (3):
layer23: introduce SMSCB framework
layer23 smscb: reassemble blocks and pass them up to L3
layer23 cell_log: log CBCH cell info
src/host/layer23/include/osmocom/bb/common/lapdm.h | 2 +
src/host/layer23/include/osmocom/bb/common/smscb.h | 28 +++
src/host/layer23/src/common/Makefile.am | 2 +-
src/host/layer23/src/common/lapdm.c | 7 +
src/host/layer23/src/common/smscb.c | 211 ++++++++++++++++++++
src/host/layer23/src/misc/cell_log.c | 107 ++++++++++-
6 files changed, 354 insertions(+), 3 deletions(-)
create mode 100644 src/host/layer23/include/osmocom/bb/common/smscb.h
create mode 100644 src/host/layer23/src/common/smscb.c
This is particularly useful if a layer23 app exists uncleanly; the next
app would not be able to synchronize at all.
Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com>
---
More to the point, I'd get stuck on the CBCH ;) I'm not sure if this
would negatively impact other FULL reset use-cases, hence the RFC.
Thanks,
Alex
src/target/firmware/layer1/l23_api.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c
index 19838f1..82b86d7 100644
--- a/src/target/firmware/layer1/l23_api.c
+++ b/src/target/firmware/layer1/l23_api.c
@@ -381,6 +381,7 @@ static void l1ctl_rx_reset_req(struct msgb *msg)
switch (reset_req->type) {
case L1CTL_RES_T_FULL:
printf("L1CTL_RESET_REQ: FULL!\n");
+ l1s.dedicated.type = GSM_DCHAN_NONE;
l1s_reset();
l1s_reset_hw();
audio_set_enabled(0);
--
1.7.0.4
