baseband-devel February 2012

baseband-devel@lists.osmocom.org

30 participants
37 discussions

[PATCH 2/2] osmocon: Option -a runs program/script on upload

by Christian Vogel

The program option "-a program" runs the specified program or script after a ACK from the phone has been received. This can be used to trigger uploading the second-stage firmware with osmoload after the osmocom loader has successfully been run on the phone. --- src/host/osmocon/osmocon.c | 76 ++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 74 insertions(+), 2 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index b3eaedb..eefbed2 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -30,6 +30,7 @@ #include <stdint.h> #include <fcntl.h> #include <errno.h> +#include <signal.h> #include <termios.h> #include <sys/ioctl.h> #include <sys/types.h> @@ -178,6 +179,19 @@ struct dnload { static struct dnload dnload; static struct osmo_timer_list tick_timer; +/* Information needed for callback on successful program upload to mobile. + * Only active if ack_prog_info.progname != NULL. */ + +#define ACK_PROG_TIMER_DELAY 2000000 +static struct osmo_timer_list ack_prog_timer; +struct ack_prog_info { + char *progname; + char *sockname; + char *serialdev; + char * const *envp; +}; +static struct ack_prog_info ack_prog_info = { NULL }; + /* Compal ramloader specific */ static const uint8_t phone_prompt1[] = { 0x1b, 0xf6, 0x02, 0x00, 0x41, 0x01, 0x40 }; static const uint8_t dnload_cmd[] = { 0x1b, 0xf6, 0x02, 0x00, 0x52, 0x01, 0x53 }; @@ -823,6 +837,9 @@ static int handle_read(void) dnload.write_ptr = dnload.data; dnload.expect_hdlc = 1; + if(ack_prog_info.progname) + osmo_timer_schedule(&ack_prog_timer,0,ACK_PROG_TIMER_DELAY); + /* check for romloader chainloading mode used as a workaround * for the magic on the C139/C140 and J100i */ if (dnload.chainload_filename != NULL) { @@ -1202,6 +1219,7 @@ dnload_mode_to_str(enum dnload_mode mode){ "\t\t [ -m {c123,c123xor,c140,c140xor,c155,romload,mtk} ]\n" \ "\t\t [ -c /to-be-chainloaded-file.bin ]\n" \ "\t\t [ -i beacon-interval (mS) ]\n" \ + "\t\t [ -a program-to-be-run-after-upload-ack ]\n" \ "\t\t file.bin\n\n" \ "* Open serial port /dev/ttyXXXX (connected to your phone)\n" \ "* Perform handshaking with the ramloader in the phone\n" \ @@ -1401,7 +1419,46 @@ void parse_debug(const char *str) } } -int main(int argc, char **argv) +/* timer callback function that gets triggered after ACK + * for successful program upload has been received from the phone + */ + +void +ack_prog_callback(void *p) +{ + pid_t chld; + char *argv[]={ + ack_prog_info.progname, + ack_prog_info.sockname, + ack_prog_info.serialdev, + (char*)dnload_mode_str[dnload.mode], + dnload.filename, + NULL + }; + int i; + + signal(SIGCHLD,SIG_IGN); + + if((chld=fork()) != 0){ /* ---- in parent ---- */ + if(chld == -1) + perror("fork()"); + else + fprintf(stderr,"Running %s on ack.\n", + ack_prog_info.progname); + return; + }; + + /* ---- in child ---- */ + for(i=3;i<1024;i++) + close(i); + + execve(ack_prog_info.progname,argv,ack_prog_info.envp); + perror(ack_prog_info.progname); + exit(1); +} + +int +main(int argc, char **argv,char **envp) { int opt, flags; uint32_t tmp_load_address = ROMLOAD_ADDRESS; @@ -1414,7 +1471,7 @@ int main(int argc, char **argv) dnload.previous_filename = NULL; dnload.beacon_interval = DEFAULT_BEACON_INTERVAL; - while ((opt = getopt(argc, argv, "d:hl:p:m:c:s:i:v")) != -1) { + while ((opt = getopt(argc, argv, "d:hl:p:m:c:s:i:va:")) != -1) { switch (opt) { case 'p': serial_dev = optarg; @@ -1444,6 +1501,9 @@ int main(int argc, char **argv) case 'i': dnload.beacon_interval = atoi(optarg) * 1000; break; + case 'a': + ack_prog_info.progname = optarg; + break; case 'h': default: usage(argv[0]); @@ -1451,12 +1511,23 @@ int main(int argc, char **argv) } } + if (argc <= optind) { dnload.filename = NULL; } else { dnload.filename = argv[optind]; } + if(ack_prog_info.progname){ + fprintf(stderr,"Will run %s on successful upload.\n", + ack_prog_info.progname); + ack_prog_info.sockname = (char*)loader_un_path; + ack_prog_info.serialdev = serial_dev; + ack_prog_info.envp = envp; + ack_prog_timer.cb = ack_prog_callback; + ack_prog_timer.data = &ack_prog_info; + } + dnload.serial_fd.fd = osmo_serial_init(serial_dev, MODEM_BAUDRATE); if (dnload.serial_fd.fd < 0) { fprintf(stderr, "Cannot open serial device %s\n", serial_dev); @@ -1520,3 +1591,4 @@ int main(int argc, char **argv) exit(0); } + -- 1.7.0.4 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="osmoload_sh.txt" #!/bin/bash socket="$1" port="$2" method="$3" main_fw="$4" fw_dir="${main_fw%/*}" new_fw="${fw_dir}/rssi.highram.bin" osmoload="$OSMOCOM_ROOT/osmocom-bb/src/host/osmocon/osmoload" tag="[${0##*/}]" echo "Environment:" env if ! [ -x "$osmoload" ] ; then echo "$tag *** $osmoload not found/not executable." >&2 exit 1 fi if ! [ -f "$new_fw" ] ; then echo "$tag *** $new_fw not found." >&2 exit 1 fi echo "$tag Socket is $socket, port is $port." >&2 echo "$tag Loader method was $method." >&2 echo "$tag New firmware will be $new_fw." >&2 MAX_PINGS=5 N=0 while [ "$N" -lt "$MAX_PINGS" ] ; do N="$(( $N + 1 ))" $osmoload -l $socket ping if [ "$?" == 0 ] ; then break fi done if [ "$N" -ge $MAX_PINGS ] ; then echo "$tag *** could not ping phone!" >&2 exit 1 fi $osmoload -l $socket memload 0x820000 $new_fw if [ "$?" != 0 ] ; then echo "$tag *** could not upload firmware!" >&2 exit 1 fi $osmoload -l $socket jump 0x820000 if [ "$?" != 0 ] ; then echo "$tag *** could not run firmware!" >&2 exit 1 fi --X1bOJ3K7DJ5YkBrT--

13 years, 4 months

[PATCH 1/2] osmocon: array of download-method names

by Christian Vogel

An array of method names for the parser methods (c123xor, mtk, ...) has been introduced, so that we can easily convert back and forth. --- src/host/osmocon/osmocon.c | 39 ++++++++++++++++++++++++--------------- 1 files changed, 24 insertions(+), 15 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index fc29506..b3eaedb 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -126,6 +126,16 @@ enum dnload_mode { MODE_INVALID, }; +const char * const dnload_mode_str[]={ + [MODE_C123]="c123", + [MODE_C123xor]="c123xor", + [MODE_C140]="c140", + [MODE_C140xor]="c140xor", + [MODE_C155]="c155", + [MODE_ROMLOAD]="romload", + [MODE_MTK]="mtk", +}; + struct dnload { enum dnload_state state; enum romload_state romload_state; @@ -1170,24 +1180,21 @@ static int serial_read(struct osmo_fd *fd, unsigned int flags) static int parse_mode(const char *arg) { - if (!strcasecmp(arg, "c123")) - return MODE_C123; - else if (!strcasecmp(arg, "c123xor")) - return MODE_C123xor; - else if (!strcasecmp(arg, "c140")) - return MODE_C140; - else if (!strcasecmp(arg, "c140xor")) - return MODE_C140xor; - else if (!strcasecmp(arg, "c155")) - return MODE_C155; - else if (!strcasecmp(arg, "romload")) - return MODE_ROMLOAD; - else if (!strcasecmp(arg, "mtk")) - return MODE_MTK; + int i; + for(i=0;i<MODE_INVALID;i++) + if(!strcasecmp(arg,dnload_mode_str[i])) + return i; return MODE_INVALID; } +const char * +dnload_mode_to_str(enum dnload_mode mode){ + if(mode < 0 || mode >= MODE_INVALID) + return "invalid"; + return dnload_mode_str[mode]; +} + #define HELP_TEXT \ "[ -v | -h ] [ -d [t][r] ] [ -p /dev/ttyXXXX ]\n" \ "\t\t [ -s /tmp/osmocom_l2 ]\n" \ @@ -1414,8 +1421,10 @@ int main(int argc, char **argv) break; case 'm': dnload.mode = parse_mode(optarg); - if (dnload.mode == MODE_INVALID) + if (dnload.mode == MODE_INVALID){ + fprintf(stderr,"Invalid download mode!\n"); usage(argv[0]); + } break; case 's': layer2_un_path = optarg; -- 1.7.0.4 --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-osmocon-Option-a-runs-program-script-on-upload.patch"

13 years, 4 months

Power-savvy GSM network (was: gsm322.c Bug Fix Patch)

by Alexander Chemeris

Hi Kurtis, (I'm changing subject to the actual topic of this discussion) Yes, I quickly looked through your code. Looks like a big hack right now, but I guess it's meant to be a hack at this point :) So, your idea is to manipulate Tx power of a BTS to cover only actually working handsets, if I understand correctly. It's not possible to do with a normal GSM phone, because phone does not transmit until it sees a beacon. So you want to create a "wake up BTS" channel to get around. Am I following your logic correctly? It does look like an interesting idea if could be done dirt-cheap. But how do you plan to do paging in this system? I see the only way - to use the same "wake up channel", but in other direction. So basically you have a network-specific "default" ARFCN which is used when no active BTS is in range. All communications are first tried on this ARFCN and only then on other ones. Right? On Thu, Feb 2, 2012 at 22:43, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote: > This is part of my thesis work at Cal, yes. Range is not in any way involved. > > That's roughly the use case, areas where there are too few users to > keep a BTS in constant use. Our designs allow the power usage to scale > with the number of users, rather than sit at a fixed output, as they > do now. The BTS side is simple; the osmocom side is complicated. We > have a handset that can wakeup a sleeping tower, or a "wakeup button" > device which only transmits when a button is pressed. That thing is ~5 > bucks and can probably be attached to the back of a legacy phone in > case we can't convince a large manufacturer to incorporate our changes > into the baseband. > > Anyhow, the code is online if you're interested in looking at our > progress (https://github.com/kheimerl). It's nowhere near ready, but > you're a very knowledgeable guy, and I'd be happy to hear your > opinions on any of our designs. > > On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris > <alexander.chemeris(a)gmail.com> wrote: >> Is it a part of your TIER university work? >> I wonder about use cases for this. >> >> One use case I see is when you have a BTS which is rarely used, like >> in a desert and you don't want it to work all the time. What use cases >> do you plan to use it for? >> >> On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote: >>> >>> Yeah, and we have that working. >>> >>> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris >>> <alexander.chemeris(a)gmail.com> wrote: >>> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote: >>> >> I think I looked at that... I'll give you some context. >>> >> >>> >> We've modified osmocom to "wakeup" a specific tower at a specific >>> >> ARFCN. >>> > >>> > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? >>> > >>> > -- >>> > Regards, >>> > Alexander Chemeris. >> >> >> >> >> -- >> Regards, >> Alexander Chemeris. -- Regards, Alexander Chemeris.

13 years, 4 months

Re: Operator name in cell_log log file

by Andreas Eversberg

Dario Lombardo wrote: > Why doesn't cell_log write the operator name in its log file? Is there > any issue related to it? > Attached a patch to log operator name and country. > Dario. hi dario, the reason for that is that cell_log only logs the raw data. later it can be decoded (e.g. by gsmmap tool) with all the info you like. decoding things like "operator" could lead to the following problems when they are stored in the log file: - operator names may change - list of operators may have wrong names or is incomplete - decoding functions may have bugs, so they might output wrong results - decoding several informations would inflate the log file - someone using the log file may not care about operator names in the past we had a bug in the frequency list decoder. after i fixed it, i just parsed my log file again and got the right frequencies. if you need to know what operators you have in your log, i suggest to write a tool that parses the log file and outputs a list of operator infos and other infos you like. look at "gsmmap" to see how it is done. regards, andreas

13 years, 4 months

develop a software radio front end

by Jerry Giant

Proposal to develop a software front end Hi, list. --Intro: After watching ccc camp videos, I bought myself a moto c118 and run the Osmocom-bb software on it. It's great fun to get a free software running on proprietary hardware, and so much could be learned from the source code. But what to do when the gray market stock sold out, or some one want to pick up the task of implementing the hardware in a open source fashion? OpenBTS used USRP to implement its radio, but USRP is aged, and it's documentation and price is not so friendly as I see. If further sub projects of osmocom matured, still we have to stick on the hacking hardware would not be so fun. To better the integrity and usefulness of the whole project, we can design and build a software radio front end for osmocom project. Interested? --Background: I am a Chinese electronic engineer working at small company in China, working on machine vision, now our product is building a FPGA/TI DSP based embedded device. I have some free time to learn and very interested in build a software radio front end. --Initial Thought: The goal of build a Osmocom Software Radio Kit, is to build a multipurpose radio front end which compatible to All or Most air interfaces now osmocom is interested. Interfacing an emulated Calypso DSP interface is way to reuse the code, or build another L1 dedicated for OSRK is an option. The hardware spec could be much better than USRP as vendor's products line evolved, but OSRK better to be mobile, has modular RF power amplifier interface, and battery powered. --Hardware Specification: Let get started.

13 years, 4 months

RSSI firmware

by Dario Lombardo

Hello everybody I'm trying to use the RSSI firmware on a c118 and c115. Both of them give me this error host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/compal_e88/rssi.compalram.bin got 1 bytes from modem, data looks like: 04 . got 1 bytes from modem, data looks like: 81 . got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD The maximum file size is 64kBytes (65535 bytes) read_file(target/firmware/board/compal_e88/rssi.compalram.bin) failed with -27 Do I need to do something different to load this FW or simply my phones have no enough room for it? Thanks for your help. Dario.

13 years, 4 months

gsm322.c Bug Fix Patch

by Kurtis Heimerl

Just a quick bug fix to gsm322.c. Basically, there were two commands in an "else" block without brackets, causing the "end = 1023+299" command to execute regardless of the state of index.

13 years, 4 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel February 2012