baseband-devel

baseband-devel@lists.osmocom.org

1 participants
2024 discussions

The 'uplink' branch / Status update
by Harald Welte 02 Mar '10

02 Mar '10

Hi! After quite a bit of hacking on libosmocore as well as the various parts of Osmocom-BB, I've now committed the latest state to the 'uplink' branch of osmocom-bb.git. I have decided to introduce RSL/RLL as the interface between Layer2(LAPDm) and Layer3(04.08), as it is a clean protocol that we already understand from the OpenBSC side. You can see in src/host/layer2/src/osmocom_rslms.c how we receive e.g. the 04.08 PAGING REQUEST and 04.08 IMMEDIATE ASSIGNMENT on the PCH/AGCH inside RSL UNIT DATA INDICATION messages. Please note the layer2/src/lapdm.c implementation is extremely incomplete, particularly when it comes to ABM (asynchronous balanced mode) and I-frames. It's full of FIXME's that I'll be working on as soon as possible. However, the infrastructure now seems to be coming together and we basically have everything in place for bi-directional transmission of data for SAPI0 and SAPI3 for both DCCH and ACCH (limited to SDCCH/4 on combined CCCH on C0T0) 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)

1 0

Getting Started..
by Thomas Kindler 01 Mar '10

01 Mar '10

Hi! I'm just getting started with GSM and Osmocom and received my C123 from eBay last week. I got everything to compile under Ubuntu 9.10, using the arm-elf toolchain from http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_X Will that be usable at all? As I'm still waiting for my official cable to arrive, I built one myself using an old CP2102 USB-Serial development board.. unfortunately, osmocon fails to upload programs: $ ./osmocon -p /dev/ttyUSB0 -m c123../../target/firmware/hello_world.bin got 2 bytes from modem, data looks like: 04 81 got 5 bytes from modem, data looks like: 1b f6 02 00 41 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 read_file(../../target/firmware/hello_world.bin): file_size=16676, hdr_len=4, dnload_len=16683 got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 52 got 1 bytes from modem, data looks like: 01 got 1 bytes from modem, data looks like: 53 got 1 bytes from modem, data looks like: 66 got 1 bytes from modem, data looks like: 74 got 1 bytes from modem, data looks like: 6d got 1 bytes from modem, data looks like: 74 got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 6c Received FTMTOOL from phone, ramolader has aborted got 1 bytes from modem, data looks like: 65 got 1 bytes from modem, data looks like: 72 got 1 bytes from modem, data looks like: 72 got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 72 What do I do wrong? best regards, -- Thomas Kindler <mail+gsm(a)t-kindler.de>

1 0

Hi all
by Erik Ekman 01 Mar '10

01 Mar '10

I have ordered a C139+cable and I am waiting for it to arrive. I guess the helloworld and other binaries will run on it but the peripherals that differ from the C123 will not work. Is that correct? At work we used ARM7TDMI, now an ARM9, and we looked at FreeRTOS before going for a custom non-RTOS event-based os. We use the gnu toolchain and OpenOCD. So far, I have only used GSM/GPRS from the AT-command level, but it looks interesting to see more. While waiting for the hardware I did some trivial patches for osmocon that are attached. Hope that form (as well as the content :) is acceptable. /Erik

2 1

more c118 testing
by chekov 01 Mar '10

01 Mar '10

hi, i'd like to do some more c118 testing. the only tool i further got to work was l1test.bin[1]. the others were downloaded correctly but ended up /blue/ :) is it worth the time to make some tests with older object-code-versions? otherwise i will investigate what happens to compal_dump.bin[1], because this one answers with some "Dropping sample" lines. attachments: [1] l1test.bin.txt [2] compal_dump.bin.txt l1test.bin $ ../osmocom-bb/src/host/osmocon/osmocon -m c123 -p /dev/ttyUSB0 ../osmocom-bb/src/target/firmware/l1test.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 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 read_file(../osmocom-bb/src/target/firmware/l1test.bin): file_size=31836, hdr_len=4, dnload_len=31843 got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 41 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 43 Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/31843) handle_write(): 4096 bytes (8192/31843) handle_write(): 4096 bytes (12288/31843) handle_write(): 4096 bytes (16384/31843) handle_write(): 4096 bytes (20480/31843) handle_write(): 4096 bytes (24576/31843) handle_write(): 4096 bytes (28672/31843) handle_write(): 3171 bytes (31843/31843) handle_write(): finished got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 41 got 1 bytes from modem, data looks like: 03 got 1 bytes from modem, data looks like: 42 Received DOWNLOAD ACK from phone, your code is running now! Hello World from apps/l1test/main.c program code ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: <snip> ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ====================================================================== Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Download Status: 0x0001 DSP API Version: 0x822e 0x08bf Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 Performing power measurement over GSM900 LOST!ARFCN Top 10 Rx Level ARFCN 26: -57 dBm ARFCN 64: -58 dBm ARFCN 104: -59 dBm ARFCN 80: -64 dBm ARFCN 71: -75 dBm ARFCN 77: -76 dBm ARFCN 123: -77 dBm ARFCN 111: -78 dBm ARFCN 121: -78 dBm ARFCN 114: -88 dBm Starting FCCH Recognition FB0 (379:5): TOA= 5040, Power= -59dBm, Angle= 1044Hz =>FB @ FNR 378 fn_offset=378 qbits=68 FB1 (390:2): TOA= 1251, Power= -60dBm, Angle= 259Hz =>FB @ FNR 388 fn_offset=388 qbits=4912 FB1 (400:2): TOA= 1251, Power= -61dBm, Angle= 68Hz =>FB @ FNR 398 fn_offset=398 qbits=4912 FB1 (410:2): TOA= 1251, Power= -63dBm, Angle= 35Hz =>FB @ FNR 408 fn_offset=408 qbits=4912 FB1 (420:2): TOA= 1243, Power= -65dBm, Angle= -13Hz =>FB @ FNR 418 fn_offset=418 qbits=4880 FB1 (430:2): TOA= 1251, Power= -66dBm, Angle= 5Hz =>FB @ FNR 428 fn_offset=428 qbits=4912 FB1 (441:3): TOA= 2503, Power= -67dBm, Angle= 17Hz =>FB @ FNR 439 fn_offset=439 qbits=4920 FB1 (451:2): TOA= 1299, Power= -69dBm, Angle= 2Hz =>FB @ FNR 450 fn_offset=450 qbits=104 FB1 (471:11): TOA=12567, Power= -69dBm, Angle= 21Hz =>FB @ FNR 470 fn_offset=470 qbits=176 FB1 (492:12): TOA=13675, Power= -68dBm, Angle= -31Hz =>FB @ FNR 490 fn_offset=490 qbits=4608 FB1 (502:2): TOA= 1251, Power= -68dBm, Angle= 14Hz =>FB @ FNR 500 fn_offset=500 qbits=4912 FB1 (512:2): TOA= 1299, Power= -68dBm, Angle= 6Hz =>FB @ FNR 511 fn_offset=511 qbits=104 FB1 (532:11): TOA=12555, Power= -66dBm, Angle= 7Hz =>FB @ FNR 531 fn_offset=531 qbits=128 FB1 (543:2): TOA= 1275, Power= -67dBm, Angle= 26Hz =>FB @ FNR 542 fn_offset=542 qbits=8 FB1 (563:11): TOA=12503, Power= -67dBm, Angle= -13Hz =>FB @ FNR 561 fn_offset=561 qbits=4920 FB1 (573:2): TOA= 1243, Power= -67dBm, Angle= 15Hz =>FB @ FNR 571 fn_offset=571 qbits=4880 FB1 (583:2): TOA= 1251, Power= -67dBm, Angle= 9Hz =>FB @ FNR 581 fn_offset=581 qbits=4912 FB1 (594:3): TOA= 2503, Power= -67dBm, Angle= 3Hz =>FB @ FNR 592 fn_offset=592 qbits=4920 FB1 (604:2): TOA= 1251, Power= -67dBm, Angle= 22Hz =>FB @ FNR 602 fn_offset=602 qbits=4912 FB1 (614:2): TOA= 1251, Power= -67dBm, Angle= 10Hz =>FB @ FNR 612 fn_offset=612 qbits=4912 FB1 (624:2): TOA= 1243, Power= -67dBm, Angle= -1Hz =>FB @ FNR 622 fn_offset=622 qbits=4880 FB1 (634:2): TOA= 1251, Power= -66dBm, Angle= -14Hz =>FB @ FNR 632 fn_offset=632 qbits=4912 FB1 (645:3): TOA= 2499, Power= -66dBm, Angle= 0Hz =>FB @ FNR 643 fn_offset=643 qbits=4904 FB1 (655:2): TOA= 1295, Power= -66dBm, Angle= 17Hz =>FB @ FNR 654 fn_offset=654 qbits=88 FB1 (675:11): TOA=12515, Power= -66dBm, Angle= -23Hz =>FB @ FNR 673 fn_offset=673 qbits=4968 FB1 (685:2): TOA= 1251, Power= -66dBm, Angle= 14Hz =>FB @ FNR 683 fn_offset=683 qbits=4912 FB1 (696:3): TOA= 2503, Power= -66dBm, Angle= 0Hz =>FB @ FNR 694 fn_offset=694 qbits=4920 FB1 (706:2): TOA= 1251, Power= -67dBm, Angle= 13Hz =>FB @ FNR 704 fn_offset=704 qbits=4912 FB1 (716:2): TOA= 1295, Power= -68dBm, Angle= 17Hz =>FB @ FNR 715 fn_offset=715 qbits=88 FB1 (736:11): TOA=12443, Power= -68dBm, Angle= -23Hz =>FB @ FNR 734 fn_offset=734 qbits=4680 FB1 (747:3): TOA= 2527, Power= -68dBm, Angle= 22Hz =>FB @ FNR 746 fn_offset=746 qbits=16 FB1 (767:11): TOA=12503, Power= -69dBm, Angle= -15Hz =>FB @ FNR 765 fn_offset=765 qbits=4920 FB1 (777:2): TOA= 1203, Power= -69dBm, Angle= 19Hz =>FB @ FNR 775 fn_offset=775 qbits=4720 FB1 (787:2): TOA= 1311, Power= -70dBm, Angle= 5Hz =>FB @ FNR 786 fn_offset=786 qbits=152 FB1 (798:2): TOA= 1251, Power= -70dBm, Angle= 17Hz =>FB @ FNR 796 fn_offset=796 qbits=4912 FB1 (808:2): TOA= 1199, Power= -71dBm, Angle= 17Hz =>FB @ FNR 806 fn_offset=806 qbits=4704 FB1 (818:2): TOA= 1251, Power= -71dBm, Angle= -18Hz =>FB @ FNR 816 fn_offset=816 qbits=4912 FB1 (828:2): TOA= 1299, Power= -72dBm, Angle= 2Hz =>FB @ FNR 827 fn_offset=827 qbits=104 FB1 (849:12): TOA=13675, Power= -69dBm, Angle= -13Hz =>FB @ FNR 847 fn_offset=847 qbits=4608 FB1 (859:2): TOA= 1299, Power= -69dBm, Angle= 14Hz =>FB @ FNR 858 fn_offset=858 qbits=104 FB1 (879:11): TOA=12503, Power= -69dBm, Angle= -36Hz =>FB @ FNR 877 fn_offset=877 qbits=4920 FB1 (889:2): TOA= 1243, Power= -68dBm, Angle= 35Hz =>FB @ FNR 887 fn_offset=887 qbits=4880 FB1 (900:3): TOA= 2555, Power= -68dBm, Angle= 24Hz =>FB @ FNR 899 fn_offset=899 qbits=128 FB1 (920:11): TOA=12451, Power= -69dBm, Angle= -28Hz =>FB @ FNR 918 fn_offset=918 qbits=4712 FB1 (930:2): TOA= 1251, Power= -69dBm, Angle= 7Hz =>FB @ FNR 928 fn_offset=928 qbits=4912 FB1 (940:2): TOA= 1195, Power= -69dBm, Angle= 11Hz =>FB @ FNR 938 fn_offset=938 qbits=4688 FB1 (951:3): TOA= 2523, Power= -69dBm, Angle= 6Hz =>FB @ FNR 950 fn_offset=950 qbits=0 FB1 (971:11): TOA=12547, Power= -71dBm, Angle= 3Hz =>FB @ FNR 970 fn_offset=970 qbits=96 FB1 (991:11): TOA=12567, Power= -75dBm, Angle= 18Hz =>FB @ FNR 990 fn_offset=990 qbits=176 FB1 (1032:4): TOA= 3803, Power= -75dBm, Angle= -10Hz =>FB @ FNR 1031 fn_offset=1031 qbits=120 Synchronize_TDMA LOST!SB2 (2711:1684): TOA= 17, Power= -60dBm, Angle= 1738Hz => SB 0x00089797: BSIC=37 fn=2438464(1838/ 2/ 1) qbits=4976 SB2 (2444039:7257): TOA= 22, Power= -58dBm, Angle=-2015Hz => SB 0x012f13ff: BSIC=63 fn=2087603(1574/11/71)=> DSP reports SB in bit that is 1239921045 bits in the future?!? SB1 (2090933:10585): TOA= 9, Power= -59dBm, Angle= 1849Hz => SB 0x00a58606: BSIC=1 fn=1715151(1293/ 9/21)=> DSP reports SB in bit that is 1681302282 bits in the future?!? SB2 (1718584:14016): TOA= 16, Power= -54dBm, Angle= 1703Hz => SB 0x00089797: BSIC=37 fn=2438464(1838/ 2/ 1)=> DSP reports SB in bit that is 2146739789 bits in the future?!? SB1 (2446030:21580): TOA= 2, Power= -58dBm, Angle= 1683Hz => SB 0x00c30b0c: BSIC=3 fn=31528(23/16/61)=> DSP reports SB in bit that is 1237431025 bits in the future?!? SB2 (44003:34053): TOA= 22, Power= -57dBm, Angle= -5Hz => SB 0x0148ca37: BSIC=13 fn=2573420(1940/18/11) qbits=4996 Synchronize_TDMA LOST!SB2 (2573793:34424): TOA= 37, Power= -56dBm, Angle= -836Hz => SB 0x00a3a0ab: BSIC=42 fn=2462494(1857/ 8/61)=> DSP reports SB in bit that is 1077728560 bits in the future?!? SB1 (2471920:43848): TOA= 35, Power= -58dBm, Angle= -552Hz => SB 0x00090ea8: BSIC=42 fn=38118(28/ 2/21)=> DSP reports SB in bit that is 1205068558 bits in the future?!? works, powerbutton works lcd shows l1test.bin $ ../osmocom-bb/src/host/osmocon/osmocon -m c118 -p /dev/ttyUSB0 ../osmocom-bb/src/target/firmware/compal_dump.bin got 2 bytes from modem, data looks like: 04 81 got 5 bytes from modem, data looks like: 1b f6 02 00 41 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 read_file(../osmocom-bb/src/target/firmware/compal_dump.bin): file_size=10264, hdr_len=0, dnload_len=10267 got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 41 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 43 Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/10267) handle_write(): 4096 bytes (8192/10267) handle_write(): 2075 bytes (10267/10267) handle_write(): finished got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 41 got 1 bytes from modem, data looks like: 03 got 1 bytes from modem, data looks like: 42 Received DOWNLOAD ACK from phone, your code is running now! Dropping sample 'm' Dropping sample 'p' Dropping sample 'a' Dropping sample 'l' Dropping sample ' ' Dropping sample 'd' Dropping sample 'e' Dropping sample 'v' Dropping sample 'i' Dropping sample 'c' Dropping sample 'e' Dropping sample ' ' Dropping sample 'd' Dropping sample 'a' Dropping sample 't' Dropping sample 'a' Dropping sample ' ' Dropping sample 'd' Dropping sample 'u' Dropping sample 'm' Dropping sample 'p' Dropping sample 'e' Dropping sample 'r' Dropping sample ' ' hangs, blue

2 1

Re: hello_world.bin on C118
by Dieter Spaar 01 Mar '10

01 Mar '10

Hello Chekov, On Mon, 01 Mar 2010 02:04:13 +0100, "chekov" <chekov(a)riseup.net> wrote: > but now i'm stuck, because i get no feedback from the phone, except that > the display lights up blue. I think the problem is related to this: > Received PROMPT2 from phone, starting download > handle_write(): 4096 bytes (4096/16503) > handle_write(): 4096 bytes (8192/16503) > handle_write(): 4096 bytes (12288/16503) > handle_write(): 4096 bytes (16384/16503) > handle_write(): 119 bytes (16503/16503) > handle_write(): finished > handle_write(): 4096 bytes (4096/16503) <<<<----- this should not happen > got 1 bytes from modem, data looks like: 1b This probably means that the downloader does not receive a reply in time and continues to download the code. You can try to fix it with this modification: --- ./src/host/osmocon/osmocon.c Tue Feb 23 18:38:39 2010 +++ /src/host/osmocon/osmocon.c Mon Mar 01 07:59:22 2010 @@ -275,6 +275,7 @@ usleep(1); } else if (dnload.write_ptr >= dnload.data + dnload.data_len) { printf("finished\n"); + dnload.serial_fd.when = BSC_FD_READ; dnload.write_ptr = dnload.data; return 1; } As a consequence of still sending data to the phone, the firmware could crash because there was a bug which is already fixed in the latest GIT version. You can check if you already have the latest version: --- ./src/target/firmware/comm/msgb.c Tue Feb 23 18:38:39 2010 +++ /src/target/firmware/comm/msgb.c Sun Feb 28 11:22:57 2010 @@ -35,7 +35,11 @@ #ifdef NO_TALLOC /* This is a poor mans static allocator for msgb objects */ -#define MSGB_DATA_SIZE 256 +#define MSGB_DATA_SIZE 256+4 #define MSGB_NUM 16 struct supermsg { uint8_t allocated; Maybe the above helps to solve the problem. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

layer2/3 interface
by Harald Welte 01 Mar '10

01 Mar '10

Hi! I'm currently working on getting the integration between l1, l2 and l3 running. As it seems to me, using at least the RLL part of RSL as an interface between l2 and l3 seems to make a lot of sense. After all, it contains all information we need, such as timeslot/subslot/sapi/... and supports all the various {data,unit_data,establish}{{request,indication} messages. So my idea is to generate a RSL RLL message in L2 and send ot to L3 and vice versa. I'll commit it to the 'uplink' branch as soon as I have something useful. -- - 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)

1 0

hello_world.bin on C118
by chekov 01 Mar '10

01 Mar '10

hi, i'm trying to follow this projects developement with my revived Motorola C118. The wiki helped me making the phone downloading the hello_world.bin file. but now i'm stuck, because i get no feedback from the phone, except that the display lights up blue. here is what osmocon prints when i make the phone downloading the hello_world.bin: $ ./host/osmocon/osmocon -m c118 -p /dev/ttyUSB0 target/firmware/hello_world.bin got 2 bytes from modem, data looks like: 04 81 got 5 bytes from modem, data looks like: 1b f6 02 00 41 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 read_file(target/firmware/hello_world.bin): file_size=16500, hdr_len=0, dnload_len=16503 got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 41 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 43 Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/16503) handle_write(): 4096 bytes (8192/16503) handle_write(): 4096 bytes (12288/16503) handle_write(): 4096 bytes (16384/16503) handle_write(): 119 bytes (16503/16503) handle_write(): finished handle_write(): 4096 bytes (4096/16503) got 1 bytes from modem, data looks like: 1b got 1 bytes from modem, data looks like: f6 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 41 got 1 bytes from modem, data looks like: 03 got 1 bytes from modem, data looks like: 42 Received DOWNLOAD ACK from phone, your code is running now! this also works with -m c118xor maybe you can create something like a user mailinglist if this kind of questions produces to much volume.

1 0

Re: batter charging interface / iota madc block
by Dieter Spaar 28 Feb '10

28 Feb '10

Hello Joachim, On Sun, 28 Feb 2010 03:55:12 +0100, "Joachim Steiger" <roh(a)hyte.de> wrote: > > ps: according the the schem the vibra should be controlled by the auxdac > of iota. i poked it and some enable bit few minutes, but couldnt get it > doing anything. Have you turned the Auxiliary DAC on ? It has its own power control bit and bit 5 (ADACS) in TOGBR1 hat to be set to turn the Auxiliary DAC on. I just did a quick test with a C123, and the following seems to work: twl3025_reg_write(TOGBR1, 1 << 5); // turn ADAC on twl3025_reg_write(AUXDAC, 1000); delay_ms(1500); twl3025_reg_write(AUXDAC, 0); twl3025_reg_write(TOGBR1, 1 << 4); // turn ADAC off Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

batter charging interface / iota madc block
by Joachim Steiger 28 Feb '10

28 Feb '10

sorry for not writing anything earlier, but i'm currently moving so i'm a bit short of time. i have been working on the bci and madc block already, so if you are not already done, i'd like to do that. its a bit tricky since one needs to do quite a lot to charge the battery correctly, but in the end we could even charge nimh and i guess small lead batterys also if we want to (with different code). i have done the irq handlers, the charger plug in detection and the async madc stuff is already working. it just needs some cleanup before commit. about the bci stuff: i'm now done reading and understanding the iota datasheets and appnotes (the latter one having invaluable information not in the datasheets). 'just' need to get it written down in code and debug it. ;) summary: if you can live with charging your batteries for another week or 2, just try figuring out the ringer and or vibra for example ps: according the the schem the vibra should be controlled by the auxdac of iota. i poked it and some enable bit few minutes, but couldnt get it doing anything. so there is still a mystery or 2 left. kind regards -- roh

1 0

Bootloader
by Ingo Albrecht 27 Feb '10

27 Feb '10

Hi everyone Without further introduction and in a similar manner to laforge's last mail I would like to note that I am working on a bootloader that will allow for larger binaries in RAM and flexible flashing. To avoid troublesome interaction between the Calypso bootrom (which we use for interrupt redirection) and CFI support, I have decided to go for an interrupt-less approach. So don't be surprised to see me committing a polling mode to fundamental drivers (keypad, uart) sometime soon. Luckily, the required changes are trivial. I'll push my branch sometime soon, just dropping a line to keep everyone informed. Feel free to drop a line in case you are interested in other flash-based tasks like hammering out linkage details and implementing some kind of filesystem. Greetings prom

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel