From usamamuneeb at gmail.com Sat Apr 1 10:39:11 2017 From: usamamuneeb at gmail.com (Usama Muneeb) Date: Sat, 1 Apr 2017 15:39:11 +0500 Subject: Connecting OsmocomBB to OpenBTS In-Reply-To: References: Message-ID: Dear Vadim Yanitskiy, Thank you very much for this. I have been wondering how to switch to manual network selection mode. The virtual SIM card is a great idea! Regards, Usama Muneeb -------------- next part -------------- An HTML attachment was scrubbed... URL: From mychaela.falconia at gmail.com Sun Apr 9 09:22:03 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 9 Apr 2017 01:22:03 -0800 Subject: FreeCalypso GSM MS development board built and mostly works Message-ID: Hello fellow GSM baseband hackers, Harald invited me to share this news with this list, so here it goes: the FreeCalypso project's GSM MS development board with the TI Calypso+Iota+Rita chipset, called FCDEV3B, has been built, and it mostly works, although there are still some issues being debugged. Pictures of this board can be seen here: https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7580.jpeg https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7581.jpeg Now the following part is bad news for me, but probably good news for you guys: right now OsmocomBB works on this board to the point of being able to connect to the live commercial GSM network in my part of the world, send and receive SMS and make a call, but my own preferred firmware is not currently able to the connect to the network (fails in the FB/SB acquisition step) because of the lack of VCXO calibration. To run OsmocomBB on my board, the same version of layer1.highram.bin that is currently built in board/gta0x works unchanged on the FCDEV3B, as my board design is derived from Openmoko GTA02. Both Calypso UARTs are equally accessible on header pins, so use whichever you prefer - tweak board/gta0x/init.c if you prefer to use the IrDA UART - for example, if you wish to use the external serial port when running the same layer1.highram.bin on Openmoko hardware. The on-board SIM socket wired to the Calypso+Iota chipset works - I used this native SIM socket (not an external SIM adapter) for the real SIM used to connect to Operator 310260's live commercial GSM network, and SMS sending and receiving worked without a hitch. After several tries I was also able to dial and connect a voice call - it took several tries, but voice calls from OsmocomBB have always been unreliable for me, even on pre-existing Calypso targets where they work flawlessly with the official firmware. However, the voice path has not been tested yet, as the hardware is not complete enough for it yet. I designed the FCDEV3B with the intent of being able to make test calls from the lab bench without needing anything except the board itself, and for this purpose there is a loudspeaker driver circuit and a microphone input circuit on the board, based on TI's Leonardo schematics. However, the actual loudspeaker and microphone themselves aren't on the board, instead there are headers meant for connecting them. At some point I will need to acquire some loudspeaker and microphone parts, wire them up to the headers and test these on-board audio circuits, but right now there are higher priorities. The following parts do not work properly yet: * There is a flash + external RAM chip on the board, the same part as used in the Pirelli DP-L10, with the gigantic capacity of 16 MiB of flash and 8 MiB of RAM. The external RAM works (I can run the large FreeCalypso firmware entirely from RAM without flashing), and the flash works in that I can erase, program and verify images in both banks of the flash - it is organized as two chip select banks of 8 MiB each. However, some strange problems happen when booting FreeCalypso fw that has been flashed - I will need to hook up JTAG (and exercise that hardware path) in order to debug it further. I am guessing that this problem affects only FreeCalypso and not OsmocomBB, as it is my understanding that you guys have no interest in producing firmware that runs fully on the baseband processor, instead of an attached PC host, and for the purpose of running your teensy-tiny L1 you don't need any flash or external RAM at all. (Sure, one can build a flashable version of this little L1, but what is the point of doing so if you still need to run osmocon in order to talk to it?) * TI's TCS211 firmware for the Calypso (the basis for FreeCalypso) expects per-unit RF calibration to be performed on the production line, and the VCXO calibration appears to be the most critical step: if I delete the VCXO calibration files on an Openmoko-made GTA02, the modem stops working (fails to acquire FB/SB in the network search just like on my FCDEV3B), whereas all other RF calibration files can be deleted and it still works. Hence I reason that the lack of this VCXO calibration is the cause of my current inability to connect to the network from my board using my preferred firmware. Now here is the part I don't understand: how are you able to get away with not requiring RF calibration in OsmocomBB? As I understand it, the requirement that each individual GSM MS unit must be RF-calibrated in production was not specific to TI Calypso, but is a general industry-wide requirement, or at least was in that time period. Per-unit calibration adds to the production test time, time is money, and the calibration equipment (R&S CMU200 is the industry gold standard) is not cheap either - so there is a non-trivial cost to this calibration requirement. So I figure that there must have been some good reason for TI and other mainstream GSM MS chipset manufacturers to require per-unit RF calibration - if they could have dispensed away with this calibration requirement like you did in OsmocomBB, they surely would have done it. So where is the catch? There must be some good reason why TI's TCS211 fw requires VCXO calibration, and when the fw is redesigned to not require such calibration as you seem to have done in OsmocomBB, something else (something important probably) must be sacrificed. So what is the good reason for requiring accurate VCXO calibration, and what is sacrificed when one cheats on this requirement like you seem to be doing? Viva La Revolucion, Mychaela aka Spacefalcon the Outlaw From laforge at gnumonks.org Sun Apr 9 10:07:13 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 Apr 2017 12:07:13 +0200 Subject: FreeCalypso GSM MS development board built and mostly works In-Reply-To: References: Message-ID: <20170409100713.tczmsjgzkzprgqjn@nataraja> Hi Mychaela, On Sun, Apr 09, 2017 at 01:22:03AM -0800, Mychaela Falconia wrote: > Harald invited me to share this news with this list, so here it goes: thanks for the update! > Now the following part is bad news for me, but probably good news for > you guys: right now OsmocomBB works on this board to the point of > being able to connect to the live commercial GSM network in my part of > the world, send and receive SMS and make a call, but my own preferred > firmware is not currently able to the connect to the network (fails in > the FB/SB acquisition step) because of the lack of VCXO calibration. this is good news, indeed. I'm quite sure you will get your preferred firmware working, too. > * TI's TCS211 firmware for the Calypso (the basis for FreeCalypso) > expects per-unit RF calibration to be performed on the production > line, and the VCXO calibration appears to be the most critical step: > if I delete the VCXO calibration files on an Openmoko-made GTA02, > the modem stops working (fails to acquire FB/SB in the network search > just like on my FCDEV3B), whereas all other RF calibration files can > be deleted and it still works. Hence I reason that the lack of this > VCXO calibration is the cause of my current inability to connect to > the network from my board using my preferred firmware. > Now here is the part I don't understand: how are you able to get away > with not requiring RF calibration in OsmocomBB? RF calibration generally is required for [spectrum, regulatory] conformity. For example, the transmit power OsmoocmBB currently uses on phones is more or less "random" in a sense that we have simply used one value that worked with one given unit of a C123, and assume that all other C123 are not too far off from that value. In reality, this can easily mean quite large discrepancy between intended transmit power and actual measured transmit power. For the proof-of-concept / lab type use that was the primary target for OsmcoomBB this was sufficient. See the dbm2apc_gsm900[] table for the power calibration values which most definitely are wrong on all but one phone. Also, for the VCTCXO: We don't use any calibration here at all. I am not even sure what exactly is calibrated in the Motorola or Openmoko firmware. you can see our AFC code in layer1/afc.c is simply using some constants for the slope and normalization in order to pull the frequency towards its intended target, based on the measured frequency error. The absolute accuracy of the VCTCXO doesn't matter, all that matters is the relative difference between the local clock and the recovered clock from the FCCH, and we use that to compensate. > So where is the catch? There must be some good reason why TI's TCS211 > fw requires VCXO calibration, and when the fw is redesigned to not > require such calibration as you seem to have done in OsmocomBB, > something else (something important probably) must be sacrificed. No idea, maybe it's simply some temperature curve? I suppose reading your "preferred firmware" source code should reveal more details what this data is actually used for. Doesn't it simply work if you copy the calibration data from a working phone (like GTA02) to your FCDEV3B ? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Sun Apr 9 15:49:45 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 9 Apr 2017 07:49:45 -0800 Subject: FreeCalypso GSM MS development board built and mostly works In-Reply-To: <20170409100713.tczmsjgzkzprgqjn@nataraja> References: <20170409100713.tczmsjgzkzprgqjn@nataraja> Message-ID: Hi Harald, > RF calibration generally is required for [spectrum, regulatory] > conformity. For example, the transmit power OsmoocmBB currently uses on > phones is more or less "random" in a sense that we have simply used one > value that worked with one given unit of a C123, and assume that all > other C123 are not too far off from that value. In reality, this can > easily mean quite large discrepancy between intended transmit power and > actual measured transmit power. Yes, this is the one part of the calibration process which I actually do understand. It's the other two parts I'm struggling with: the VCXO calibration and that for the Rx path. > For the proof-of-concept / lab type use that was the primary target for > OsmcoomBB this was sufficient. See the dbm2apc_gsm900[] table for the > power calibration values which most definitely are wrong on all but one > phone. Once I recreate the CMU200-based calibration procedure and write some programs to automate it so I can ship FreeCalypso devices with per-unit calibration like the historical commercial Calypso device manufacturers did (FCDEV3B is a development board as embedded in its name, but it is my hope that some commercial end-use-oriented FreeCalypso devices will follow), you should be able to make use of these Tx power calibration values (APC DAC values for each Tx power level) in OsmocomBB as well if you like. The flash file system format I've adopted for FreeCalypso (the one by Mads Meisner-Jensen at TI) is quite easy to parse, and if you are accessing it in a read-only manner, you don't need the full FFS code from TI's firmware or any other code from TI - a simple written-from- scratch TIFFS parser will suffice, and you can find not one but two examples of such parsers in my freecalypso-tools Hg repository: * The one under ffstools/tiffs-rd is a Unix/Linux host utility that parses a TIFFS flash image "in vitro". * The one under target-utils/libtiffs runs on an actual Calypso target; its only current usage in FreeCalypso is that it is linked into the pirexplore standalone Pirelli hardware exploration utility. Pirelli's official fw uses the same FFS format, and my pirexplore utility with libtiffs linked into it can retrieve UI artwork bitmap images from Pirelli's FFS and display them on the phone's LCD. It is worth noting that I reverse-engineered TI's FFS format at a read-only level (enough to write a reader/parser for this FFS, but not enough to create or perform write operations on these FFS images) and wrote the above readers/parsers a couple of months *before* I obtained the TCS211 firmware semi-src with the full read/write implementation. The TIFFS reader/parser version under target-utils/libtiffs will probably be the one best suited for your purposes if you wished to integrate TIFFS reading into OsmocomBB for retrieving factory RF calibration values, and it will work with all future FreeCalypso hardware products as well as Openmoko devices - but not Mot C1xx, as Compal moved their calibration values out of FFS into their own proprietary data structures which I don't know how to grok. > Also, for the VCTCXO: We don't use any calibration here at all. I am not > even sure what exactly is calibrated in the Motorola or Openmoko > firmware. This TI document for their later LoCosto chipset (not Calypso) gives some clues: https://www.freecalypso.org/LoCosto-docs/Production%20test%20and%20calibration/i_sample_rf_test_and_calibration_13_03_04_01991%20-%20v026.pdf The relevant part is section A.1.11 on PDF pages 33 through 38. The values written into the /gsm/rf/afcparams table are: * 3 AFC DAC values corresponding to the nominal center frequency and to some maximum and minimum frequency offsets; * 4 constants based on some Psi values - this is the part I'm having the most difficulty understanding. Both the DAC values and the Psi voodoo constants do vary from one produced unit to the next. In this tarball: ftp://ftp.freecalypso.org/pub/GSM/GTA02/rfcal-examples.tar.gz you can find real-life examples of the per-unit calibration values read out of six (!) different Openmoko GTA02 units, converted from TI's binary format into readable ASCII. Look in rfasc-*/global/afcparams inside to see how the AFC calibration values differ from unit to unit, and how they differ from the compiled-in values which the fw uses in the absence of calibration files. The LoCosto PDF linked above does give the formulas for computing all of the numbers going into the afcparams table from the frequency offset measurements made with the CMU200, but: * I have no way of telling if these formulas are correct or not, as some parts look suspicious. For example, the instructions say the ARFCN for the Tx test should be set to 40, but the formula for computing Psi_sta (eq. 4.18 near the bottom of page 37) includes an Fgsm value given as 900.000000 MHz near the top of page 36. I thought the uplink frequency for ARFCN 40 should be 898 MHz, not 900 - or am I horribly mistaken somewhere? * I have no way of telling what may have changed between Calypso and LoCosto, and the available document is only for LoCosto. I was really hoping to get a hold of the production line automated calibration program so I could see what it actually commands on the DUT and on the CMU200 (what ARFCN does it tell the DUT fw to transmit on? what frequency does it tell the CMU200 to look for?) and try to reverse-engineer its subsequent math, but if obtaining those historical Windows binaries is not possible, I will try performing the manual calibration procedure in the LoCosto document (after I climb the CMU200 learning curve a little more), try putting the numbers through those equations, and try tweaking them until I get something close to what Openmoko's factory has calibrated on the GTA02 units I have. > you can see our AFC code in layer1/afc.c is simply using some > constants for the slope and normalization in order to pull the frequency > towards its intended target, based on the measured frequency error. One difference I can see between your AFC code and TI's original is that you first convert the angle value from the DSP into a frequency error in Hz, whereas TI's code appears to work with the angles directly, using those Psi constants I'm having so much difficulty understanding. However, these implementation differences are rather orthogonal to the key matter at hand here. The distinction that matters is that your code uses hard-coded constants for the AFC DAC initial value and for the AFC slope (by how much should the DAC value be adjusted given a particular frequency offset or angle value from the DSP), whereas TI's version expects these constants to be calibrated on a per-unit basis. I am guessing there has to be *some* downside to having these constants hard-coded once and for all instead of having them calibrated per unit... > No idea, maybe it's simply some temperature curve? I don't see anything temperature-related in the AFC code in TI's fw or in the equations given in the LoCosto document. And as you also probably know, the VCXO in TI's Leonardo reference design (copied first by Openmoko, then by me) is a "plain" VCXO, not a VCTCXO. The only Calypso device I know of that uses a VCTCXO is the Pirelli DP-L10, and I don't know why they went for this presumably more expensive option. > I suppose reading > your "preferred firmware" source code should reveal more details what > this data is actually used for. As you can surely imagine, I have certainly studied that l1ctl_afc() function and tried to understand what it does, but the complexity is a bit beyond me. But I think I am getting a bit closer now, so once I learn how to operate the CMU200 I bought on ebay, I will try performing the calibration procedure: command the Calypso device to transmit continuously via L1 Test Mode commands (my FreeCalypso Test Mode Shell accepts these commands in exactly the same syntax as given in TI's PDF docs!), measure the frequency offsets at different DAC values as the LoCosto document instructs, and put the resulting values through the Psi formulas in the document to produce an afcparams table for feeding to the firmware via the Test Mode Shell's rftw command. > Doesn't it simply work if you copy the calibration data from a working > phone (like GTA02) to your FCDEV3B ? Copy the afcparams calibration values from which GTA02? They are different on each individual unit as you can see in the rfcal-examples tarball linked above - it's the whole point of per-unit calibration. OK, I was going to try copying the afcparams file from one arbitrarily picked GTA02 to FCDEV3B S/N 001 just to see what happens, but something quite unexpected happened. It was middle of the night here when I went to try this experiment, the night was unusually cold for April in Southern California, and the temperature difference made it work! When I pressed the PWON button on the FCDEV3B, the FreeCalypso fw image in the flash immediately booted without the usual glitches, and when I tried the AT+CFUN=1, AT+COPS=0 command sequence, it immediately connected to the network even though I had *not* uploaded the afcparams file from the GTA02, i.e., it was using the fw's compiled-in numbers. Later the flash booting problem came back, so I will still debug it once I get the "dupont" jumper wires (female to female) for connecting JTAG, and I don't know if the FB/SB acquisition will start failing again once the room warms up - but I need to try performing the proper calibration procedure in any case, as these numbers are meant to be calibrated per unit rather than hard-coded. M~ From alexander.chemeris at gmail.com Mon Apr 10 19:27:35 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 10 Apr 2017 12:27:35 -0700 Subject: FreeCalypso GSM MS development board built and mostly works In-Reply-To: References: <20170409100713.tczmsjgzkzprgqjn@nataraja> Message-ID: Hi Mychaela, On Apr 9, 2017 08:50, "Mychaela Falconia" wrote: > For the proof-of-concept / lab type use that was the primary target for > OsmcoomBB this was sufficient. See the dbm2apc_gsm900[] table for the > power calibration values which most definitely are wrong on all but one > phone. Once I recreate the CMU200-based calibration procedure and write some programs to automate it so I can ship FreeCalypso devices with per-unit calibration like the historical commercial Calypso device manufacturers did Not sure if this helps, but we're planning to open-source our Python framework we use to run various post-manufacturing tests/calibrations for our base stations. It's designed as a very generic framework, but we also implemented CMD57 flavor of SCPI commands for a completely automated procedure. I expect CMU200 to have write different SCPI command set, but it might be a good start. Let me know if that's something you might be interested in. That said, the first step is always to get things working in a manual mode, and automate them later. Keep the good work! Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbsoo7 at live.com Tue Apr 11 09:39:46 2017 From: bbsoo7 at live.com (RootZero) Date: Tue, 11 Apr 2017 02:39:46 -0700 (MST) Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: <543B79B8.2020501@vervier.info> References: <543B79B8.2020501@vervier.info> Message-ID: <1491903586643-4026772.post@n3.nabble.com> Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.html Sent from the baseband-devel mailing list archive at Nabble.com. From craig_comstock at yahoo.com Tue Apr 11 11:35:42 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Tue, 11 Apr 2017 06:35:42 -0500 Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: <1491903586643-4026772.post@n3.nabble.com> References: <543B79B8.2020501@vervier.info> <1491903586643-4026772.post@n3.nabble.com> Message-ID: <0A682638-74C3-40EB-BD36-09ED07644FDA@yahoo.com> My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero wrote: >Markus and all, > >I am very interesting in this project/hack. > >can you share more information with US? > >I searched lots web pages and do not find the source of mdlogger.cpp >file. > >I do have the source code of "modem.img" if you want please let me >know. > > > > > >thanks >RootZero > > > >-- >View this message in context: >http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.html >Sent from the baseband-devel mailing list archive at Nabble.com. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Thu Apr 13 03:21:39 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 13 Apr 2017 03:21:39 +0000 (UTC) Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) References: <1071717351.976635.1492053699369.ref@mail.yahoo.com> Message-ID: <1071717351.976635.1492053699369@mail.yahoo.com> I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" , "baseband-devel at lists.osmocom.org" Date: Wednesday, April 12, 2017, 9:39 PM Craig, do you have?the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ From: Craig Comstock Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel at lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) ? My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel - Fun with the MTK 6573 Baseband (Patching / Replacing)baseband-devel.722152.n3.nabble.comFun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com.Nabble ? Free Forum ? Embeddable Web Appsnabble.comEmbed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From bbsoo7 at live.com Thu Apr 13 06:49:43 2017 From: bbsoo7 at live.com (bruce lee) Date: Thu, 13 Apr 2017 06:49:43 +0000 Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: <1071717351.976635.1492053699369@mail.yahoo.com> References: <1071717351.976635.1492053699369.ref@mail.yahoo.com>, <1071717351.976635.1492053699369@mail.yahoo.com> Message-ID: maybe it is easiest for developing on some boards which has UART port to look it boot up message. some mt6572 based boards one can find on China market. they event can share code with us if we buy it. it is android based. so should/can we make a osmocom-bb based BP for this android board? or other smartphone? thanks RZ ________________________________ From: Craig Comstock Sent: Thursday, April 13, 2017 3:21 AM To: baseband-devel at lists.osmocom.org; bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip [https://avatars2.githubusercontent.com/u/2554776?v=3&s=400] craigcomstock/osmocom-bb github.com Contribute to osmocom-bb development by creating an account on GitHub. I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" , "baseband-devel at lists.osmocom.org" Date: Wednesday, April 12, 2017, 9:39 PM Craig, do you have the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ From: Craig Comstock Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel at lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel - Fun with the MTK 6573 Baseband (Patching / Replacing)baseband-devel.722152.n3.nabble.comFun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com.Nabble ? Free Forum ? Embeddable Web Appsnabble.comEmbed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Thu Apr 13 12:48:17 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 13 Apr 2017 12:48:17 +0000 (UTC) Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) References: <1749362888.1167903.1492087697216.ref@mail.yahoo.com> Message-ID: <1749362888.1167903.1492087697216@mail.yahoo.com> I don't know much about the architecture of these MT based Android phones yet. We would need some source for the actual baseband part of the code in order to port osmocom-bb. I was able to quickly search for mt6572 kernel sources but that's not what we need. I also found custom ROMs like CyanogenMod. That might get us a bit further. Also there are "scatter" files that newer MT based devices use as a sort of map for fastboot flashing images onto a device (I think, not much experience here). So that might give a clue as well. This one has U-Boot! That might be helpful. https://github.com/GoldRenard/AllegroROM_4.2.2_mt6572/blob/master/HWPackage/A516_S118/scatter/MT6572_Android_scatter.txt So if you can purchase a 6572 based board and get enough source that might be what is needed to make progress. If you find a link to something share it I suppose. I'm mostly focused on porting osmocom-bb to 626x at this point and figuring out how to get layer1+modem built as nuttx-bb... but... as I mentioned I work slow so if others push forward with a newer chip that would be cool. If we could end up with something like AOSP + osmocom-bb image for RILD I suppose that might be fun. I am more interested in NOT using Android for what it's worth. -Craig -------------------------------------------- On Thu, 4/13/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "baseband-devel at lists.osmocom.org" , "Craig Comstock" Date: Thursday, April 13, 2017, 1:49 AM maybe ?it is easiest ?for developing on?some boards which has UART port to look it boot up message. some mt6572 based boards one can find on China market. they event can share code with us if we buy it. it is android based.? so should/can we make a osmocom-bb based BP for this android board? or other smartphone? thanks RZ From: Craig Comstock Sent: Thursday, April 13, 2017 3:21 AM To: baseband-devel at lists.osmocom.org; bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) ? I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip craigcomstock/osmocom-bb github.com Contribute to osmocom-bb development by creating an account on GitHub. I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee wrote: ?Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) ?To: "Craig Comstock" , "baseband-devel at lists.osmocom.org" ?Date: Wednesday, April 12, 2017, 9:39 PM ? ? ? ?Craig, ? ? ? ? ? ? ?do you have?the files mentioned at ? ? ? ?https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch ? ? ? ? ? ?and for your project, seem very interesting, and I would ?like to participate in. ? ? ? ?thanks ?RZ ? ? ? ? ? ? ? ? ? ? ? ? ?From: Craig Comstock ? ? ?Sent: Tuesday, April 11, 2017 11:35 AM ? ?To: baseband-devel at lists.osmocom.org; RootZero ? ?Subject: Re: Fun with the MTK 6573 Baseband (Patching ?/ Replacing) ?? ? ?My target was Mt6735 in a Zte Obsidian. I chose it for ?4g lte. I could root one and see if similar techniques work. ?My hope was to leverage leaked source for mt626x and hope to ?work my way up the chip models. I am currently working on ?porting osmocom-bb ? and nuttx-bb to fernvale/rephone/mt626x. ? ? ? ?On April 11, 2017 ?4:39:46 AM CDT, RootZero wrote: ? ?Markus and all, ? ?I am very interesting in this ?project/hack. ? ?can you share ?more information with US? ? ?I ?searched lots web pages and do not find the source of ?mdlogger.cpp file. ? ?I do ?have the source code of "modem.img" if you want ?please let me know. ? ? ? ? ? ?thanks ?RootZero ? ? ? ?-- ?View this message in ?context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel ? - Fun with the MTK 6573 Baseband (Patching / ?Replacing)baseband-devel.722152.n3.nabble.comFun ? with the MTK 6573 Baseband (Patching / Replacing). ?-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm ?Markus, a security researcher from Germany. I recently did ?some work on MTK ?6573... ? ?Sent from the baseband-devel ?mailing list archive at Nabble.com.Nabble ? ? Free Forum ? Embeddable Web Appsnabble.comEmbed ? into any Website. All Nabble apps are naturally embeddable, ?which means that they can be easily displayed inside any web ?page. ? ? ? ? ? ? ?-- ? ?Sent from my Android device with K-9 Mail. Please excuse my ?brevity. ? ? ? From bbsoo7 at live.com Thu Apr 13 02:39:15 2017 From: bbsoo7 at live.com (bruce lee) Date: Thu, 13 Apr 2017 02:39:15 +0000 Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: <0A682638-74C3-40EB-BD36-09ED07644FDA@yahoo.com> References: <543B79B8.2020501@vervier.info> <1491903586643-4026772.post@n3.nabble.com>, <0A682638-74C3-40EB-BD36-09ED07644FDA@yahoo.com> Message-ID: Craig, do you have the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ ________________________________ From: Craig Comstock Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel at lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.html baseband-devel - Fun with the MTK 6573 Baseband (Patching / Replacing) baseband-devel.722152.n3.nabble.com Fun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com. Nabble ? Free Forum ? Embeddable Web Apps nabble.com Embed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Wed Apr 19 02:57:16 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 19 Apr 2017 02:57:16 +0000 (UTC) Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) References: <105630929.3418738.1492570636730.ref@mail.yahoo.com> Message-ID: <105630929.3418738.1492570636730@mail.yahoo.com> RootZero/bruce lee sent me this github with baseband sources very similar to what I already have for MT626x: https://github.com/zxp86021/MediaTek-HelioX10-Baseband Looking there it seems we have layer 1 GSM/2G support for many more RF chips. The trick is to figure out what AP/SOC they are used in. For example the MediaTek-HelioX10 is a MT6795 which seems to use the MT6169 transciever chip (based on some other files in the sources). My ZTE Obsidian seems to use this same TRX chip (based on a MT6735 datasheet) http://www.datasheet4u.com/pdf/MT6735-pdf/925384 Comparing L1D_RF_PowerOn functions it seems the MT6252 might be the closest to the MT626x which are completely missing from this newer set of sources that are maybe a year or so newer than the MT626x sources I have. m12196.c:/*BRIGHT2*/ void? L1D_RF_PowerOn( void ) m12196.c:/*BRIGHT4*/ void? L1D_RF_PowerOn( void ) m12196.c:/*BRIGHT5P*/ void? L1D_RF_PowerOn( void ) m12196.c:/*AERO*/ void? L1D_RF_PowerOn( void ) m12196.c:/*AERO1+*/ void? L1D_RF_PowerOn( void ) m12196.c:/*RFMD*/ void? L1D_RF_PowerOn( void ) m12196.c:/*SKY74117*/ void? L1D_RF_PowerOn( void ) m12196.c:/*SKY74400*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6119*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6119C*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6129A*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6129B*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6129C*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6129D*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6139B*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6139C*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6139E*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6140A*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6140B*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6140C*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6140D*/ void? L1D_RF_PowerOn( void ) m12196.c:/*CMOSEDGE*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1T*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6252RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6256RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6255RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6251RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*SKY74045*/ void? L1D_RF_PowerOn( void ) m12196.c:/*AERO2*/ void? L1D_RF_PowerOn( void ) m12196.c:/*SKY74137*/ void? L1D_RF_PowerOn( void ) m12196.c:/*GRF6201*/ void? L1D_RF_PowerOn( void ) m12196.c:/*IRFS3001*/ void? L1D_RF_PowerOn( void ) m12196.c:/*AD6548*/? void? L1D_RF_PowerOn( void ) m12196.c:/*AD6546*/? void? L1D_RF_PowerOn( void ) m12196.c:/*MT6162*/? void? L1D_RF_PowerOn( void ) m12196.c:/*MT6163*/? void? L1D_RF_PowerOn( void ) m12196.c:/*MT6280RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6169*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6169*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6166*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6165*/ void? L1D_RF_PowerOn( void ) one set of MT626x sources is called 11CW1418SP4 and supports the following baseband chips. Probably MT626x has an integrated baseband? m12196.c:/*MT6129D*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6139E*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6140D*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6252RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6261RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6260RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6250RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6256RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6255RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*MT6251RF*/ void? L1D_RF_PowerOn( void ) m12196.c:/*AD6548*/? void? L1D_RF_PowerOn( void ) m12196.c:/*AD6546*/? void? L1D_RF_PowerOn( void ) m12196.c:/*MT6162*/? void? L1D_RF_PowerOn( void ) So I guess I need to look elsewhere in the sources to puzzle out my MT6735 ZTE Obsidian which would give me I think the cheapest/oldest chip that supports 4G/LTE: GSM, UMTS, GPRS, HSPA+, HSUPA, TD-SCDMA, EVDO, LTE Cat 4 (from https://en.wikipedia.org/wiki/MediaTek) -Craig p.s. here are some sources I used to research both github and "from the internet": http://git.huayusoft.com/tomsu/AP7350_MDK-kernel.git https://github.com/akibsayyed/CELLTEL82_WET_KK_GPRS_HSPA_MOLY.WR8.W1315.MD.WG.MP.V35.git https://github.com/akibsayyed/HSPA_MOLY.WR8.W1449.MD.WG.MP.V16.git https://github.com/zxp86021/MT6795.kernel.git mt626x stuff: 11CW1352MP_CENON61D_3232_11C_V2_GPRS_MMI 11CW1418SP4_CORETEK02A_WIFI_BT_V13_GPRS_MMI MTK60D-11B1308-V2 -------------------------------------------- On Thu, 4/13/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" Date: Thursday, April 13, 2017, 11:40 AM check this out. it is modem firmwear source code and this guy's github https://github.com/luckasfb/Development_Documents alots of good stuff.but do not have what am looking for. bruce. From: Craig Comstock Sent: Thursday, April 13, 2017 2:10:15 PM To: bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) ? Looking at some kernel sources I see a few things that look familiar to me from mt626x source. Grepping for RIL (radio interface layer) https://github.com/eagleeyetom/android_kernel_mtk_mt6572.git ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE????????? 0x1600000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE????????? 0x0A00000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE????????? 0x1600000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define RIL_SIZE?? 0x100000 //for connsys memory ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define MEM_PRELOADER_START???????????? (DRAM_PHY_ADDR) //placed mem in RIL 256KB ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define RESERVE_MEM_SIZE??????????????? (RIL_SIZE) they mentioned infrasys and connsys near the RIL bits... craig at z500:~/android_kernel_mtk_mt6572/mediatek$ find | xargs grep -s infrasys ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* infrasys AO */ ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* infrasys */ ./platform/mt6572/kernel/core/core.c:??? /* infrasys AO first half */ ./platform/mt6572/kernel/core/core.c:??? /* infrasys AO second half */ ./platform/mt6572/kernel/core/core.c:??? /* infrasys */ ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* infrasys AO */ ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* infrasys */ craig at z500:~/android_kernel_mtk_mt6572/mediatek$ vi platform/mt6572/kernel/core/core.c So... mt_reg_base.h looks a little familiar to mt626x stuff. There is also this: https://android.googlesource.com/kernel/mediatek/ and this: https://github.com/profglavcho/mt6735-kernel-3.10.61 -------------------------------------------- On Thu, 4/13/17, bruce lee wrote: ?Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) ?To: "baseband-devel at lists.osmocom.org" , "Craig Comstock" ?Date: Thursday, April 13, 2017, 1:49 AM ? ? ? ?maybe ?it is easiest ?for developing on?some boards ?which has UART port to look it boot up message. ? ? ? ?some mt6572 based boards one can find on China market. ?they event can share code with us if we buy it. ? ? ? ?it is android based.? ? ? ? ? ? ? ?so should/can we make a osmocom-bb based BP for this ?android board? or other smartphone? ? ? ? ? ? ? ? ? ? ? ? ? ?thanks ?RZ ? ? ? ? ? ? ?From: Craig Comstock ? ? ?Sent: Thursday, April 13, 2017 3:21 AM ? ?To: baseband-devel at lists.osmocom.org; bruce lee ? ?Subject: Re: Fun with the MTK 6573 Baseband (Patching ?/ Replacing) ?? ? ? ? ?I ?don't have the files mentioned in that patch. They look ?very much like some part of an Android source code tree. So ?far I am working mostly not with Android at all... only ?osmocom-bb, nuttx, fernly and fernvale-nuttx. ? ? ? ?My work on the newer MT chip in the ZTE Obsidian is a ways ?down the road. One thing that was VERY encouraging is that I ?have tested the beginnings of interaction with it's ?bootloader (as in the fernly project) ? ?and it seems at least the initial MSG and ACK from the ?bootloader works the same as for fernly types of MT chips ?(6260/6261). So that might be a good starting point in terms ?of experimenting/fuzzing/??? ? ? ? ?Maybe you could find a custom rom source tree and find those ?files that are being patched. ? ? ? ?In terms of participating in my project, I have a github ?repo and am primarily using the fernvale board I purchased ?from sysmocom as well as some mt6260/6261 based watches and ?the Seeed Studio RePhone. ? ? ? ?So I'd say go get one or more of those things and start ?hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb ?(combo of osmocom-bb and nuttx). ? ? ? ?I don't work too hard on the project. This branch is my ?latest not-working work in progress: ? ? ? ?https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip ? ? ? ? ? ? ? ?craigcomstock/osmocom-bb ? ?github.com ? ?Contribute to osmocom-bb development by creating an account ?on GitHub. ? ? ? ? ? ? ? ? ?I have since changed my strategy and so this branch will ?likely rot. :( But it might give some indication of what ?I'm up to. ? ? ? ?-Craig ? ? ? ? ? ? ? ?-------------------------------------------- ? ?On Wed, 4/12/17, bruce lee wrote: ? ? ? ??Subject: Re: Fun with the MTK 6573 Baseband (Patching / ?Replacing) ? ??To: "Craig Comstock" ?, ?"baseband-devel at lists.osmocom.org" ? ? ??Date: Wednesday, April 12, 2017, 9:39 PM ? ?? ? ?? ? ?? ? ??Craig, ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ??do you have?the files mentioned at ? ?? ? ?? ? ?? ? ??https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch ? ?? ? ?? ? ?? ? ?? ? ?? ? ??and for your project, seem very interesting, and I ?would ? ??like to participate in. ? ?? ? ?? ? ?? ? ??thanks ? ??RZ ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ??From: Craig Comstock ? ?? ? ?? ? ??Sent: Tuesday, April 11, 2017 11:35 AM ? ?? ? ??To: baseband-devel at lists.osmocom.org; RootZero ? ?? ? ??Subject: Re: Fun with the MTK 6573 Baseband (Patching ? ??/ Replacing) ? ??? ? ?? ? ??My target was Mt6735 in a Zte Obsidian. I chose it for ? ??4g lte. I could root one and see if similar techniques ?work. ? ??My hope was to leverage leaked source for mt626x and hope ?to ? ??work my way up the chip models. I am currently working ?on ? ??porting osmocom-bb ? ?? and nuttx-bb to fernvale/rephone/mt626x. ? ?? ? ?? ? ?? ? ??On April 11, 2017 ? ??4:39:46 AM CDT, RootZero wrote: ? ?? ? ??Markus and all, ? ?? ? ??I am very interesting in this ? ??project/hack. ? ?? ? ??can you share ? ??more information with US? ? ?? ? ??I ? ??searched lots web pages and do not find the source of ? ??mdlogger.cpp file. ? ?? ? ??I do ? ??have the source code of "modem.img" if you ?want ? ??please let me know. ? ?? ? ?? ? ?? ? ?? ? ?? ? ??thanks ? ??RootZero ? ?? ? ?? ? ?? ? ??-- ? ??View this message in ? ??context: ?http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel ? ?? - Fun with the MTK 6573 Baseband (Patching / ? ??Replacing)baseband-devel.722152.n3.nabble.comFun ? ?? with the MTK 6573 Baseband (Patching / Replacing). ? ??-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, ?I'm ? ??Markus, a security researcher from Germany. I recently ?did ? ??some work on MTK ? ??6573... ? ?? ? ??Sent from the baseband-devel ? ??mailing list archive at Nabble.com.Nabble ? ?? ? Free Forum ? Embeddable Web Appsnabble.comEmbed ? ?? into any Website. All Nabble apps are naturally ?embeddable, ? ??which means that they can be easily displayed inside any ?web ? ??page. ? ?? ? ?? ? ?? ? ?? ? ?? ? ?? ? ??-- ? ?? ? ??Sent from my Android device with K-9 Mail. Please excuse ?my ? ??brevity. ? ?? ? ?? ? ?? ? ? ? ? ? ? From craig_comstock at yahoo.com Wed Apr 19 11:09:23 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 19 Apr 2017 06:09:23 -0500 Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: References: <105630929.3418738.1492570636730.ref@mail.yahoo.com>, <105630929.3418738.1492570636730@mail.yahoo.com> Message-ID: <10AC1847-33CD-49D9-A6DD-CCF1C9664D54@yahoo.com> Yes. I am using the work in fernly and fernvale-nuttx to try and make a nuttx-bb (nuttx unix os + layer1 app + mobile app) for mediatek chips... especially mt6260 and 6261. In the process I hope to possibly bring the same setup to the calypso phones. The goal being a usable 2g phone based on something like the Seeed Studio RePhone or a cheap watch phone which have mt6260 or more often MT6261. Craig On April 18, 2017 11:25:41 PM CDT, bruce lee wrote: >there is a > >https://github.com/xobs/fernly > >seems they did what you are trying to do now. they also has a qemu to >emulator that chip or so. > >I made a little progress for patching mt6573 modem.img. > >these output is from this commands. >radiff2 old.img new.img. > >0x00110d08 f0b50fb43ef052fa01280fbc03d13ef05cfcf0bdf4e7 => >68616e67654e6f74696669636174696f6e000000f0b5 0x00110d08 >0x0014f1b6 >32683846f0252d02a8352d0293352d028c352d6808210902223109029831a94201d00020f0bd01200120f0bd8d466d462d1d2d1934 >=> >06460024407b95b02746012825460fd002281ed144f001fb024611a101a868f022fd01af384671f0d4fb85b2012410e00f48314600 >0x0014f1b6 >0x0014f1ec 2d19ad => 827d68 0x0014f1ec >0x0014f1f0 ad4605d0a0e1ffbd2d196400241d6519ad460000b0e329f7adfdffbd => >33f1a6fa0106090e01d0012904d1307b4df068f9040005d1307b2b46 0x0014f1f0 >0x0014f218 be7dacf0 => 2b45414c 0x0014f218 >0x0014f54e >f0242402a834240293342402903405460e68206805e043fff0bdff0055e3fad100202946324600250446083025609cf0 >=> >06460025407bffb0c8b0012843d100272c2205233146c6a832f173fec0abc4b2187e002837d1022c03d0042c01d0052c >0x0014f54e >0x0014f57f e96660 => d12c22 0x0014f57f >0x0014f584 2360f0bdf0b5f02000460002a830 => 3146c6a832f162fec0abc7b2187e >0x0014f584 >0x0014f593 02933000029030f0bd => 2826d1052c11d11748 0x0014f593 >0x0014f5a0 >f0b5fff7f1ff07680220396800468842fbd1391d081d00460046f0bd01b4fff7f9fd012801bc01d003d00fbcc1f7a6fbf0bdf0b515461e46fff7b8fffff7e0ff0446002d08d0002e06d00a68011d0446284615469cf0e2e800f002f8f0bd >=> >164b00683146827dc6a832f1e9fec0ab187e002816d101a943a832f1abf843a871f0e2f9c0032146020c0092307b3a4601ab4cf06bf80128054609d006480321006881800022307b29461346ccf0e4f97fb048b0f0bd0000c87dacf00a02 >0x0014f5a0 >0x0014f5ff 46f0 => 00f8 0x0014f5ff >0x0014f602 2046002801d0008829463246002a00d01160f0bdf0bdf080bde8 => >002506460c480468707b01280cd1a27d3146684633f193f8ff28 0x0014f602 >0x001504fc 00bf00bf => 5bf0eaff 0x001504fc >0x001e8730 1a9866 => 0720fd 0x001e8730 >0x001e8734 3ffd => c2eb 0x001e8734 >0x001e87be 10a908600a2000021a9a1060 => 334a33a13ca0273203f0f6ee >0x001e87be > >questions here is how can we change these hex strings to a ARM >assembler code? > > >thanks > BL. > > >[https://avatars1.githubusercontent.com/u/238325?v=3&s=400] > >GitHub - xobs/fernly: Fernvale research >OS >github.com >README.md Fernly - Fernvale Reversing OS. Fernly is a simple operating >system designed for use in the reverse engineering of the Fernvale CPU. > > > > > >________________________________ >From: Craig Comstock >Sent: Wednesday, April 19, 2017 2:57 AM >To: baseband-devel at lists.osmocom.org >Cc: bruce lee >Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) > >RootZero/bruce lee sent me this github with baseband sources very >similar to what I already have for MT626x: > >https://github.com/zxp86021/MediaTek-HelioX10-Baseband >[https://avatars3.githubusercontent.com/u/3607700?v=3&s=400] > >GitHub - zxp86021/MediaTek-HelioX10-Baseband: MediaTek >... >github.com >MediaTek-HelioX10-Baseband - MediaTek MT6795 (Helio X10) baseband >source code > > > > >Looking there it seems we have layer 1 GSM/2G support for many more RF >chips. The trick is to figure out what AP/SOC they are used in. For >example the MediaTek-HelioX10 is a MT6795 which seems to use >the MT6169 transciever chip (based on some other files in the sources). >My ZTE Obsidian seems to use this same TRX chip (based on a MT6735 >datasheet) > >http://www.datasheet4u.com/pdf/MT6735-pdf/925384 >LTE Smartphone Application Processor Technical >Brief >www.datasheet4u.com >MediaTek MT6735 datasheet, MT6735 PDF, MT6735 download, MT6735 >datasheet pdf, LTE Smartphone Application Processor Technical Brief > > > > >Comparing L1D_RF_PowerOn functions it seems the MT6252 might be the >closest to the MT626x which are completely missing from >this newer set of sources that are maybe a year or so newer than the >MT626x sources I have. > >m12196.c:/*BRIGHT2*/ void L1D_RF_PowerOn( void ) >m12196.c:/*BRIGHT4*/ void L1D_RF_PowerOn( void ) >m12196.c:/*BRIGHT5P*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AERO*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AERO1+*/ void L1D_RF_PowerOn( void ) >m12196.c:/*RFMD*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74117*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74400*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6119*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6119C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129A*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129B*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139B*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140A*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140B*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*CMOSEDGE*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MTKSOC1T*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74045*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AERO2*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74137*/ void L1D_RF_PowerOn( void ) >m12196.c:/*GRF6201*/ void L1D_RF_PowerOn( void ) >m12196.c:/*IRFS3001*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6163*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6280RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6166*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6165*/ void L1D_RF_PowerOn( void ) > >one set of MT626x sources is called 11CW1418SP4 and supports the >following baseband chips. Probably MT626x has an integrated baseband? > >m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6261RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6260RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6250RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) > > >So I guess I need to look elsewhere in the sources to puzzle out my >MT6735 ZTE Obsidian which would give me I think the cheapest/oldest >chip that supports 4G/LTE: > >GSM, UMTS, GPRS, HSPA+, HSUPA, TD-SCDMA, EVDO, LTE Cat 4 (from >https://en.wikipedia.org/wiki/MediaTek) >[https://upload.wikimedia.org/wikipedia/en/thumb/2/2d/MediaTek_logo_as_shown_on_company_website.svg/220px-MediaTek_logo_as_shown_on_company_website.svg.png] > >MediaTek - Wikipedia >en.wikipedia.org >MediaTek Inc. (Chinese: ??????????; pinyin: Li?nf? K?j? G?f?n Y?uxi?n >G?ngs?) is a Taiwanese fabless semiconductor company that provides ... > > > > >-Craig > >p.s. here are some sources I used to research both github and "from the >internet": > >http://git.huayusoft.com/tomsu/AP7350_MDK-kernel.git >Tom Su / AP7350_MDK-kernel | >GitLab >git.huayusoft.com >GitLab Community Edition ... AP7350_MDK-kernel. AP7350_MDK >Android??????/??? kernel ?? bootloader ??? > > > >https://github.com/akibsayyed/CELLTEL82_WET_KK_GPRS_HSPA_MOLY.WR8.W1315.MD.WG.MP.V35.git >https://github.com/akibsayyed/HSPA_MOLY.WR8.W1449.MD.WG.MP.V16.git >https://github.com/zxp86021/MT6795.kernel.git > >mt626x stuff: >11CW1352MP_CENON61D_3232_11C_V2_GPRS_MMI >11CW1418SP4_CORETEK02A_WIFI_BT_V13_GPRS_MMI >MTK60D-11B1308-V2 > >-------------------------------------------- >On Thu, 4/13/17, bruce lee wrote: > > Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) > To: "Craig Comstock" > Date: Thursday, April 13, 2017, 11:40 AM > > > > > > > check this out. it is modem firmwear source code > > > > and this guy's github > > > > https://github.com/luckasfb/Development_Documents > > > > alots of good stuff.but do not have what am looking for. > > > > bruce. > > From: Craig Comstock > > > Sent: Thursday, April 13, 2017 2:10:15 PM > > To: bruce lee > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > / Replacing) > > > > > Looking at some kernel > sources I see a few things that look familiar to me from > mt626x source. Grepping for RIL (radio interface layer) > > > > https://github.com/eagleeyetom/android_kernel_mtk_mt6572.git > > > > > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: > #define RIL_SIZE 0x1600000 > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: > #define RIL_SIZE 0x0A00000 > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: > #define RIL_SIZE 0x1600000 > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define > RIL_SIZE 0x100000 //for connsys memory > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define > MEM_PRELOADER_START (DRAM_PHY_ADDR) > //placed mem in RIL 256KB > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define > RESERVE_MEM_SIZE (RIL_SIZE) > > > > they mentioned infrasys and connsys near the RIL bits... > > > > craig at z500:~/android_kernel_mtk_mt6572/mediatek$ find | > xargs grep -s infrasys > > ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* > infrasys AO */ > > ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* > infrasys */ > > ./platform/mt6572/kernel/core/core.c: /* infrasys AO > first half */ > > ./platform/mt6572/kernel/core/core.c: /* infrasys AO > second half */ > > ./platform/mt6572/kernel/core/core.c: /* infrasys > */ > > ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* > infrasys AO */ > > ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* > infrasys */ > > craig at z500:~/android_kernel_mtk_mt6572/mediatek$ vi > platform/mt6572/kernel/core/core.c > > > > > So... mt_reg_base.h looks a little familiar to mt626x > stuff. > > > > There is also this: > > > > https://android.googlesource.com/kernel/mediatek/ > > > > and this: > > > > https://github.com/profglavcho/mt6735-kernel-3.10.61 > > > > > > > > > > > > > > > > > > -------------------------------------------- > > On Thu, 4/13/17, bruce lee wrote: > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching / > Replacing) > > To: "baseband-devel at lists.osmocom.org" > , "Craig > Comstock" > > Date: Thursday, April 13, 2017, 1:49 AM > > > > > > > > maybe it is easiest for developing on some boards > > which has UART port to look it boot up message. > > > > > > > > some mt6572 based boards one can find on China market. > > they event can share code with us if we buy it. > > > > > > > > it is android based. > > > > > > > > > > > > > > so should/can we make a osmocom-bb based BP for this > > android board? or other smartphone? > > > > > > > > > > > > > > > > > > > > > > > > > > thanks > > RZ > > > > > > > > > > > > > > From: Craig Comstock > > > > > > Sent: Thursday, April 13, 2017 3:21 AM > > > > To: baseband-devel at lists.osmocom.org; bruce lee > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > > / Replacing) > > > > > > > > > > I > > don't have the files mentioned in that patch. They > look > > very much like some part of an Android source code tree. > So > > far I am working mostly not with Android at all... only > > osmocom-bb, nuttx, fernly and fernvale-nuttx. > > > > > > > > My work on the newer MT chip in the ZTE Obsidian is a > ways > > down the road. One thing that was VERY encouraging is that > I > > have tested the beginnings of interaction with it's > > bootloader (as in the fernly project) > > > > and it seems at least the initial MSG and ACK from the > > bootloader works the same as for fernly types of MT > chips > > (6260/6261). So that might be a good starting point in > terms > > of experimenting/fuzzing/??? > > > > > > > > Maybe you could find a custom rom source tree and find > those > > files that are being patched. > > > > > > > > In terms of participating in my project, I have a > github > > repo and am primarily using the fernvale board I > purchased > > from sysmocom as well as some mt6260/6261 based watches > and > > the Seeed Studio RePhone. > > > > > > > > So I'd say go get one or more of those things and > start > > hacking on fernly, fernvale-nuttx, osmocom-bb and > nuttx-bb > > (combo of osmocom-bb and nuttx). > > > > > > > > I don't work too hard on the project. This branch is > my > > latest not-working work in progress: > > > > > > > >https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip > > > > > > > > > > > > > > > > craigcomstock/osmocom-bb > > > > github.com > > > > Contribute to osmocom-bb development by creating an > account > > on GitHub. > > > > > > > > > > > > > > > > > > I have since changed my strategy and so this branch > will > > likely rot. :( But it might give some indication of > what > > I'm up to. > > > > > > > > -Craig > > > > > > > > > > > > > > > > -------------------------------------------- > > > > On Wed, 4/12/17, bruce lee > wrote: > > > > > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > / > > Replacing) > > > > To: "Craig Comstock" > > , > > "baseband-devel at lists.osmocom.org" > > > > > > Date: Wednesday, April 12, 2017, 9:39 PM > > > > > > > > > > > > > > > > Craig, > > > > > > > > > > > > > > > > > > > > > > > > > > > > do you have the files mentioned at > > > > > > > > > > > > > > > > https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch > > > > > > > > > > > > > > > > > > > > > > > > and for your project, seem very interesting, and I > > would > > > > like to participate in. > > > > > > > > > > > > > > > > thanks > > > > RZ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Craig Comstock > > > > > > > > > > > > Sent: Tuesday, April 11, 2017 11:35 AM > > > > > > > > To: baseband-devel at lists.osmocom.org; RootZero > > > > > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > > > > / Replacing) > > > > > > > > > > > > My target was Mt6735 in a Zte Obsidian. I chose it > for > > > > 4g lte. I could root one and see if similar > techniques > > work. > > > > My hope was to leverage leaked source for mt626x and > hope > > to > > > > work my way up the chip models. I am currently > working > > on > > > > porting osmocom-bb > > > > and nuttx-bb to fernvale/rephone/mt626x. > > > > > > > > > > > > > > > > On April 11, 2017 > > > > 4:39:46 AM CDT, RootZero > wrote: > > > > > > > > Markus and all, > > > > > > > > I am very interesting in this > > > > project/hack. > > > > > > > > can you share > > > > more information with US? > > > > > > > > I > > > > searched lots web pages and do not find the source of > > > > mdlogger.cpp file. > > > > > > > > I do > > > > have the source code of "modem.img" if you > > want > > > > please let me know. > > > > > > > > > > > > > > > > > > > > > > > > thanks > > > > RootZero > > > > > > > > > > > > > > > > -- > > > > View this message in > > > > context: > >http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel > > > > - Fun with the MTK 6573 Baseband (Patching / > > > > Replacing)baseband-devel.722152.n3.nabble.comFun > > > > with the MTK 6573 Baseband (Patching / Replacing). > > > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > > I'm > > > > Markus, a security researcher from Germany. I > recently > > did > > > > some work on MTK > > > > 6573... > > > > > > > > Sent from the baseband-devel > > > > mailing list archive at Nabble.com.Nabble > > > > ? Free Forum ? Embeddable Web > Appsnabble.comEmbed > > > > into any Website. All Nabble apps are naturally > > embeddable, > > > > which means that they can be easily displayed inside > any > > web > > > > page. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Sent from my Android device with K-9 Mail. Please > excuse > > my > > > > brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Wed Apr 19 12:11:42 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 19 Apr 2017 07:11:42 -0500 Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: References: <105630929.3418738.1492570636730.ref@mail.yahoo.com>, <105630929.3418738.1492570636730@mail.yahoo.com> Message-ID: <5D588E06-F64D-48BB-8442-E856C61B78DD@yahoo.com> Also, my main interest here is to mention which chips might have a chance of osmocom-bb/nuttx-bb support. On April 18, 2017 11:25:41 PM CDT, bruce lee wrote: >there is a > >https://github.com/xobs/fernly > >seems they did what you are trying to do now. they also has a qemu to >emulator that chip or so. > >I made a little progress for patching mt6573 modem.img. > >these output is from this commands. >radiff2 old.img new.img. > >0x00110d08 f0b50fb43ef052fa01280fbc03d13ef05cfcf0bdf4e7 => >68616e67654e6f74696669636174696f6e000000f0b5 0x00110d08 >0x0014f1b6 >32683846f0252d02a8352d0293352d028c352d6808210902223109029831a94201d00020f0bd01200120f0bd8d466d462d1d2d1934 >=> >06460024407b95b02746012825460fd002281ed144f001fb024611a101a868f022fd01af384671f0d4fb85b2012410e00f48314600 >0x0014f1b6 >0x0014f1ec 2d19ad => 827d68 0x0014f1ec >0x0014f1f0 ad4605d0a0e1ffbd2d196400241d6519ad460000b0e329f7adfdffbd => >33f1a6fa0106090e01d0012904d1307b4df068f9040005d1307b2b46 0x0014f1f0 >0x0014f218 be7dacf0 => 2b45414c 0x0014f218 >0x0014f54e >f0242402a834240293342402903405460e68206805e043fff0bdff0055e3fad100202946324600250446083025609cf0 >=> >06460025407bffb0c8b0012843d100272c2205233146c6a832f173fec0abc4b2187e002837d1022c03d0042c01d0052c >0x0014f54e >0x0014f57f e96660 => d12c22 0x0014f57f >0x0014f584 2360f0bdf0b5f02000460002a830 => 3146c6a832f162fec0abc7b2187e >0x0014f584 >0x0014f593 02933000029030f0bd => 2826d1052c11d11748 0x0014f593 >0x0014f5a0 >f0b5fff7f1ff07680220396800468842fbd1391d081d00460046f0bd01b4fff7f9fd012801bc01d003d00fbcc1f7a6fbf0bdf0b515461e46fff7b8fffff7e0ff0446002d08d0002e06d00a68011d0446284615469cf0e2e800f002f8f0bd >=> >164b00683146827dc6a832f1e9fec0ab187e002816d101a943a832f1abf843a871f0e2f9c0032146020c0092307b3a4601ab4cf06bf80128054609d006480321006881800022307b29461346ccf0e4f97fb048b0f0bd0000c87dacf00a02 >0x0014f5a0 >0x0014f5ff 46f0 => 00f8 0x0014f5ff >0x0014f602 2046002801d0008829463246002a00d01160f0bdf0bdf080bde8 => >002506460c480468707b01280cd1a27d3146684633f193f8ff28 0x0014f602 >0x001504fc 00bf00bf => 5bf0eaff 0x001504fc >0x001e8730 1a9866 => 0720fd 0x001e8730 >0x001e8734 3ffd => c2eb 0x001e8734 >0x001e87be 10a908600a2000021a9a1060 => 334a33a13ca0273203f0f6ee >0x001e87be > >questions here is how can we change these hex strings to a ARM >assembler code? > > >thanks > BL. > > >[https://avatars1.githubusercontent.com/u/238325?v=3&s=400] > >GitHub - xobs/fernly: Fernvale research >OS >github.com >README.md Fernly - Fernvale Reversing OS. Fernly is a simple operating >system designed for use in the reverse engineering of the Fernvale CPU. > > > > > >________________________________ >From: Craig Comstock >Sent: Wednesday, April 19, 2017 2:57 AM >To: baseband-devel at lists.osmocom.org >Cc: bruce lee >Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) > >RootZero/bruce lee sent me this github with baseband sources very >similar to what I already have for MT626x: > >https://github.com/zxp86021/MediaTek-HelioX10-Baseband >[https://avatars3.githubusercontent.com/u/3607700?v=3&s=400] > >GitHub - zxp86021/MediaTek-HelioX10-Baseband: MediaTek >... >github.com >MediaTek-HelioX10-Baseband - MediaTek MT6795 (Helio X10) baseband >source code > > > > >Looking there it seems we have layer 1 GSM/2G support for many more RF >chips. The trick is to figure out what AP/SOC they are used in. For >example the MediaTek-HelioX10 is a MT6795 which seems to use >the MT6169 transciever chip (based on some other files in the sources). >My ZTE Obsidian seems to use this same TRX chip (based on a MT6735 >datasheet) > >http://www.datasheet4u.com/pdf/MT6735-pdf/925384 >LTE Smartphone Application Processor Technical >Brief >www.datasheet4u.com >MediaTek MT6735 datasheet, MT6735 PDF, MT6735 download, MT6735 >datasheet pdf, LTE Smartphone Application Processor Technical Brief > > > > >Comparing L1D_RF_PowerOn functions it seems the MT6252 might be the >closest to the MT626x which are completely missing from >this newer set of sources that are maybe a year or so newer than the >MT626x sources I have. > >m12196.c:/*BRIGHT2*/ void L1D_RF_PowerOn( void ) >m12196.c:/*BRIGHT4*/ void L1D_RF_PowerOn( void ) >m12196.c:/*BRIGHT5P*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AERO*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AERO1+*/ void L1D_RF_PowerOn( void ) >m12196.c:/*RFMD*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74117*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74400*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6119*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6119C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129A*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129B*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139B*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140A*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140B*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140C*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*CMOSEDGE*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MTKSOC1T*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74045*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AERO2*/ void L1D_RF_PowerOn( void ) >m12196.c:/*SKY74137*/ void L1D_RF_PowerOn( void ) >m12196.c:/*GRF6201*/ void L1D_RF_PowerOn( void ) >m12196.c:/*IRFS3001*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6163*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6280RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6166*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6165*/ void L1D_RF_PowerOn( void ) > >one set of MT626x sources is called 11CW1418SP4 and supports the >following baseband chips. Probably MT626x has an integrated baseband? > >m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6261RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6260RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6250RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) >m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) >m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) > > >So I guess I need to look elsewhere in the sources to puzzle out my >MT6735 ZTE Obsidian which would give me I think the cheapest/oldest >chip that supports 4G/LTE: > >GSM, UMTS, GPRS, HSPA+, HSUPA, TD-SCDMA, EVDO, LTE Cat 4 (from >https://en.wikipedia.org/wiki/MediaTek) >[https://upload.wikimedia.org/wikipedia/en/thumb/2/2d/MediaTek_logo_as_shown_on_company_website.svg/220px-MediaTek_logo_as_shown_on_company_website.svg.png] > >MediaTek - Wikipedia >en.wikipedia.org >MediaTek Inc. (Chinese: ??????????; pinyin: Li?nf? K?j? G?f?n Y?uxi?n >G?ngs?) is a Taiwanese fabless semiconductor company that provides ... > > > > >-Craig > >p.s. here are some sources I used to research both github and "from the >internet": > >http://git.huayusoft.com/tomsu/AP7350_MDK-kernel.git >Tom Su / AP7350_MDK-kernel | >GitLab >git.huayusoft.com >GitLab Community Edition ... AP7350_MDK-kernel. AP7350_MDK >Android??????/??? kernel ?? bootloader ??? > > > >https://github.com/akibsayyed/CELLTEL82_WET_KK_GPRS_HSPA_MOLY.WR8.W1315.MD.WG.MP.V35.git >https://github.com/akibsayyed/HSPA_MOLY.WR8.W1449.MD.WG.MP.V16.git >https://github.com/zxp86021/MT6795.kernel.git > >mt626x stuff: >11CW1352MP_CENON61D_3232_11C_V2_GPRS_MMI >11CW1418SP4_CORETEK02A_WIFI_BT_V13_GPRS_MMI >MTK60D-11B1308-V2 > >-------------------------------------------- >On Thu, 4/13/17, bruce lee wrote: > > Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) > To: "Craig Comstock" > Date: Thursday, April 13, 2017, 11:40 AM > > > > > > > check this out. it is modem firmwear source code > > > > and this guy's github > > > > https://github.com/luckasfb/Development_Documents > > > > alots of good stuff.but do not have what am looking for. > > > > bruce. > > From: Craig Comstock > > > Sent: Thursday, April 13, 2017 2:10:15 PM > > To: bruce lee > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > / Replacing) > > > > > Looking at some kernel > sources I see a few things that look familiar to me from > mt626x source. Grepping for RIL (radio interface layer) > > > > https://github.com/eagleeyetom/android_kernel_mtk_mt6572.git > > > > > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: > #define RIL_SIZE 0x1600000 > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: > #define RIL_SIZE 0x0A00000 > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: > #define RIL_SIZE 0x1600000 > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define > RIL_SIZE 0x100000 //for connsys memory > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define > MEM_PRELOADER_START (DRAM_PHY_ADDR) > //placed mem in RIL 256KB > > ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define > RESERVE_MEM_SIZE (RIL_SIZE) > > > > they mentioned infrasys and connsys near the RIL bits... > > > > craig at z500:~/android_kernel_mtk_mt6572/mediatek$ find | > xargs grep -s infrasys > > ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* > infrasys AO */ > > ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* > infrasys */ > > ./platform/mt6572/kernel/core/core.c: /* infrasys AO > first half */ > > ./platform/mt6572/kernel/core/core.c: /* infrasys AO > second half */ > > ./platform/mt6572/kernel/core/core.c: /* infrasys > */ > > ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* > infrasys AO */ > > ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* > infrasys */ > > craig at z500:~/android_kernel_mtk_mt6572/mediatek$ vi > platform/mt6572/kernel/core/core.c > > > > > So... mt_reg_base.h looks a little familiar to mt626x > stuff. > > > > There is also this: > > > > https://android.googlesource.com/kernel/mediatek/ > > > > and this: > > > > https://github.com/profglavcho/mt6735-kernel-3.10.61 > > > > > > > > > > > > > > > > > > -------------------------------------------- > > On Thu, 4/13/17, bruce lee wrote: > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching / > Replacing) > > To: "baseband-devel at lists.osmocom.org" > , "Craig > Comstock" > > Date: Thursday, April 13, 2017, 1:49 AM > > > > > > > > maybe it is easiest for developing on some boards > > which has UART port to look it boot up message. > > > > > > > > some mt6572 based boards one can find on China market. > > they event can share code with us if we buy it. > > > > > > > > it is android based. > > > > > > > > > > > > > > so should/can we make a osmocom-bb based BP for this > > android board? or other smartphone? > > > > > > > > > > > > > > > > > > > > > > > > > > thanks > > RZ > > > > > > > > > > > > > > From: Craig Comstock > > > > > > Sent: Thursday, April 13, 2017 3:21 AM > > > > To: baseband-devel at lists.osmocom.org; bruce lee > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > > / Replacing) > > > > > > > > > > I > > don't have the files mentioned in that patch. They > look > > very much like some part of an Android source code tree. > So > > far I am working mostly not with Android at all... only > > osmocom-bb, nuttx, fernly and fernvale-nuttx. > > > > > > > > My work on the newer MT chip in the ZTE Obsidian is a > ways > > down the road. One thing that was VERY encouraging is that > I > > have tested the beginnings of interaction with it's > > bootloader (as in the fernly project) > > > > and it seems at least the initial MSG and ACK from the > > bootloader works the same as for fernly types of MT > chips > > (6260/6261). So that might be a good starting point in > terms > > of experimenting/fuzzing/??? > > > > > > > > Maybe you could find a custom rom source tree and find > those > > files that are being patched. > > > > > > > > In terms of participating in my project, I have a > github > > repo and am primarily using the fernvale board I > purchased > > from sysmocom as well as some mt6260/6261 based watches > and > > the Seeed Studio RePhone. > > > > > > > > So I'd say go get one or more of those things and > start > > hacking on fernly, fernvale-nuttx, osmocom-bb and > nuttx-bb > > (combo of osmocom-bb and nuttx). > > > > > > > > I don't work too hard on the project. This branch is > my > > latest not-working work in progress: > > > > > > > >https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip > > > > > > > > > > > > > > > > craigcomstock/osmocom-bb > > > > github.com > > > > Contribute to osmocom-bb development by creating an > account > > on GitHub. > > > > > > > > > > > > > > > > > > I have since changed my strategy and so this branch > will > > likely rot. :( But it might give some indication of > what > > I'm up to. > > > > > > > > -Craig > > > > > > > > > > > > > > > > -------------------------------------------- > > > > On Wed, 4/12/17, bruce lee > wrote: > > > > > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > / > > Replacing) > > > > To: "Craig Comstock" > > , > > "baseband-devel at lists.osmocom.org" > > > > > > Date: Wednesday, April 12, 2017, 9:39 PM > > > > > > > > > > > > > > > > Craig, > > > > > > > > > > > > > > > > > > > > > > > > > > > > do you have the files mentioned at > > > > > > > > > > > > > > > > https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch > > > > > > > > > > > > > > > > > > > > > > > > and for your project, seem very interesting, and I > > would > > > > like to participate in. > > > > > > > > > > > > > > > > thanks > > > > RZ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Craig Comstock > > > > > > > > > > > > Sent: Tuesday, April 11, 2017 11:35 AM > > > > > > > > To: baseband-devel at lists.osmocom.org; RootZero > > > > > > > > Subject: Re: Fun with the MTK 6573 Baseband (Patching > > > > / Replacing) > > > > > > > > > > > > My target was Mt6735 in a Zte Obsidian. I chose it > for > > > > 4g lte. I could root one and see if similar > techniques > > work. > > > > My hope was to leverage leaked source for mt626x and > hope > > to > > > > work my way up the chip models. I am currently > working > > on > > > > porting osmocom-bb > > > > and nuttx-bb to fernvale/rephone/mt626x. > > > > > > > > > > > > > > > > On April 11, 2017 > > > > 4:39:46 AM CDT, RootZero > wrote: > > > > > > > > Markus and all, > > > > > > > > I am very interesting in this > > > > project/hack. > > > > > > > > can you share > > > > more information with US? > > > > > > > > I > > > > searched lots web pages and do not find the source of > > > > mdlogger.cpp file. > > > > > > > > I do > > > > have the source code of "modem.img" if you > > want > > > > please let me know. > > > > > > > > > > > > > > > > > > > > > > > > thanks > > > > RootZero > > > > > > > > > > > > > > > > -- > > > > View this message in > > > > context: > >http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel > > > > - Fun with the MTK 6573 Baseband (Patching / > > > > Replacing)baseband-devel.722152.n3.nabble.comFun > > > > with the MTK 6573 Baseband (Patching / Replacing). > > > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > > I'm > > > > Markus, a security researcher from Germany. I > recently > > did > > > > some work on MTK > > > > 6573... > > > > > > > > Sent from the baseband-devel > > > > mailing list archive at Nabble.com.Nabble > > > > ? Free Forum ? Embeddable Web > Appsnabble.comEmbed > > > > into any Website. All Nabble apps are naturally > > embeddable, > > > > which means that they can be easily displayed inside > any > > web > > > > page. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Sent from my Android device with K-9 Mail. Please > excuse > > my > > > > brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Wed Apr 19 13:31:52 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 19 Apr 2017 15:31:52 +0200 Subject: gerrit for osmocom-bb Message-ID: Hi. I've just noticed that OsmocomBB is not on the list of projects at https://gerrit.osmocom.org/#/admin/projects/ Is this because nobody bothered adding it there yet or it's because maintainers do not find it suitable? If it's the latter than I'd love to see it added to streamline contributions and patch review process. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Wed Apr 19 18:17:45 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Apr 2017 20:17:45 +0200 Subject: gerrit for osmocom-bb In-Reply-To: References: Message-ID: <20170419181745.36ufm62b2rp54qkt@nataraja> Hi Max, On Wed, Apr 19, 2017 at 03:31:52PM +0200, Max wrote: > I've just noticed that OsmocomBB is not on the list of projects at > https://gerrit.osmocom.org/#/admin/projects/ > Is this because nobody bothered adding it there yet or it's because maintainers do > not find it suitable? If it's the latter than I'd love to see it added to streamline > contributions and patch review process. I guess it's simply that nobody bothered to do so, as activity on OsmocomBB has been extremely low. I don't mind gerrit for OsmocomBB, not sure how the others think. One issue that I fear is that I see very little activity outside of the sysmocom team in gerrit in terms of review. I had the feeling this was better while posting patches still on the mailing lists. I'm not sure there is a causality. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Apr 19 19:01:30 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 19 Apr 2017 21:01:30 +0200 Subject: gerrit for osmocom-bb In-Reply-To: <20170419181745.36ufm62b2rp54qkt@nataraja> References: <20170419181745.36ufm62b2rp54qkt@nataraja> Message-ID: Hi, > One issue that I fear is that I see very little activity outside of the > sysmocom team in gerrit in terms of review. I had the feeling this was > better while posting patches still on the mailing lists. I'm not sure > there is a causality. I'm not sure if it's just me or if I'm using it wrong but I'm always annoyed when I have to login to gerrit ... 1) I shouldn't be logged out at all ... it's not a high security stuff that session should be kept open for a long time, like > 1 week without issues ... 2) I have to retype the openid login url. I mean there is a login with Yahoo and login with Launchpad Id dedicated link, isn't there a way to add, "login with your osmocom redmine account" link ? 3) Then I'm redirected to redmine, where I have to login as well, because again for some reason I've been logged out. Same comment as above, unless I explicitely log out, that session should last for ever pretty much ... 4) When I then login to redmine, I get redirected to the OpenID end point but at this point the "open id state" or whatever has been lost and so I need to go back to gerrit and re-do the whole login process so it can do it in one go without being interrupted by the redmine login process and finally log me into gerrit ... I can assure you I gave up on the whole process more than one time .... Cheers, Sylvain From alexander.chemeris at gmail.com Wed Apr 19 21:13:10 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 20 Apr 2017 00:13:10 +0300 Subject: gerrit for osmocom-bb In-Reply-To: References: <20170419181745.36ufm62b2rp54qkt@nataraja> Message-ID: On Wed, Apr 19, 2017 at 10:01 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > >> One issue that I fear is that I see very little activity outside of the >> sysmocom team in gerrit in terms of review. I had the feeling this was >> better while posting patches still on the mailing lists. I'm not sure >> there is a causality. > > I'm not sure if it's just me or if I'm using it wrong but I'm always > annoyed when I have to login to gerrit ... > > 1) I shouldn't be logged out at all ... it's not a high security stuff > that session should be kept open for a long time, like > 1 week > without issues ... > 2) I have to retype the openid login url. I mean there is a login with > Yahoo and login with Launchpad Id dedicated link, isn't there a way to > add, "login with your osmocom redmine account" link ? > 3) Then I'm redirected to redmine, where I have to login as well, > because again for some reason I've been logged out. Same comment as > above, unless I explicitely log out, that session should last for ever > pretty much ... > 4) When I then login to redmine, I get redirected to the OpenID end > point but at this point the "open id state" or whatever has been lost > and so I need to go back to gerrit and re-do the whole login process > so it can do it in one go without being interrupted by the redmine > login process and finally log me into gerrit ... > > I can assure you I gave up on the whole process more than one time .... I agree with this sentiment. I haven't gave up on the process those few times I did a review, but I still find it very annoying that I need to re-login every time, especially given the process is not so straightforward. It would be nice if my login lasted forever. Another reason is that by default you're subscribed only to patches you're explicitly mentioned in. So unless you make a conscious decision to enable notifications about all patches, you won't even notice there is something to review. And then you have to figure out how to enable this. So it may help if you was offered to select project you're interested in during user registration and you're subscribed to all patches from those projects. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From laforge at gnumonks.org Thu Apr 20 05:22:14 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 20 Apr 2017 07:22:14 +0200 Subject: gerrit for osmocom-bb In-Reply-To: References: <20170419181745.36ufm62b2rp54qkt@nataraja> Message-ID: <20170420052214.idwhtgurxydckvbu@nataraja> Hi Sylvain, On Wed, Apr 19, 2017 at 09:01:30PM +0200, Sylvain Munaut wrote: > I'm not sure if it's just me or if I'm using it wrong but I'm always > annoyed when I have to login to gerrit ... thanks for raising this issue. It is probably as simple as to extend the cookie expiration or something like that. That would at least already resolve '1)' + '4)' from your list. I've created https://osmocom.org/issues/2015 and https://osmocom.org/issues/2016 to track this. We'll have to see who can look into it, guess Holger and Neels are most familiar with the setup. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu Apr 20 08:18:57 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 20 Apr 2017 10:18:57 +0200 Subject: gerrit for osmocom-bb In-Reply-To: References: <20170419181745.36ufm62b2rp54qkt@nataraja> Message-ID: <20170420081857.GA1278@ass40.sysmocom.de> On Wed, Apr 19, 2017 at 09:01:30PM +0200, Sylvain Munaut wrote: > Hi, > > > One issue that I fear is that I see very little activity outside of the > > sysmocom team in gerrit in terms of review. I had the feeling this was > > better while posting patches still on the mailing lists. I'm not sure > > there is a causality. > > I'm not sure if it's just me or if I'm using it wrong but I'm always > annoyed when I have to login to gerrit ... I've gotten somewhat used to it but it's a bit of an eyebrow raiser every time. The OpenID seems like it should be really useful, why else would it have been invented, but practically for me it blows up the usual click-on-login with the password remembered from my keystore to a three-step process. I wish gerrit simply had a password. (It does, but that seems to be unusuable for website logins, only for build bots?) > 1) I shouldn't be logged out at all ... it's not a high security stuff > that session should be kept open for a long time, like > 1 week > without issues ... > 2) I have to retype the openid login url. I mean there is a login with > Yahoo and login with Launchpad Id dedicated link, isn't there a way to > add, "login with your osmocom redmine account" link ? My browser remembers the URL but I still need to type 'h' to trigger the https... URL. > 3) Then I'm redirected to redmine, where I have to login as well, > because again for some reason I've been logged out. Same comment as > above, unless I explicitely log out, that session should last for ever > pretty much ... > 4) When I then login to redmine, I get redirected to the OpenID end > point but at this point the "open id state" or whatever has been lost > and so I need to go back to gerrit and re-do the whole login process > so it can do it in one go without being interrupted by the redmine > login process and finally log me into gerrit ... A way to shorten the process is to login on osmocom.org first, and only then move on to gerrit -- annoying, I agree. I assume the redmine login dialog loses gerrit's state. > I can assure you I gave up on the whole process more than one time .... Gave up? :) I pestered about it when we moved to gerrit, but it does work. Admitted, sometimes the '500 Bad Gateway' needs a browser restart... In summary, I agree the login is unusually cumbersome. +1 for a "login via osmocom.org" link, not sure where to plug that though. +1 for longer sessions, also not quite sure how configurable that is... I think both redmine and gerrit remain logged in as long as the browser keeps the login cookie? I'm usually logged out only when I restart the browser. In the redmine admin, I see an "Autologin: disabled" item that can be set to 1, 7, 30 or 365 days. I'd switch that to 30 days if everyone agrees. Gerrit configuration is generally a bit unusual, so far I couldn't find a way to configure login sessions. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Apr 20 08:26:21 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 20 Apr 2017 10:26:21 +0200 Subject: gerrit for osmocom-bb In-Reply-To: <20170420081857.GA1278@ass40.sysmocom.de> References: <20170419181745.36ufm62b2rp54qkt@nataraja> <20170420081857.GA1278@ass40.sysmocom.de> Message-ID: <20170420082621.GB1278@ass40.sysmocom.de> On Thu, Apr 20, 2017 at 10:18:57AM +0200, Neels Hofmeyr wrote: > In the redmine admin, I see an "Autologin: disabled" item that can be set > to 1, 7, 30 or 365 days. I'd switch that to 30 days if everyone agrees. Actually, I set it to 30 days now. Please tell me if you disagree and I'll set it back to "disabled". ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From axilirator at gmail.com Thu Apr 20 09:22:59 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 20 Apr 2017 16:22:59 +0700 Subject: gerrit for osmocom-bb Message-ID: Hi, > I'm not sure if it's just me or if I'm using it wrong but > I'm always annoyed when I have to login to gerrit ... +1 here, Gerrit login is (for now) a bit unfriendly. Even so, there are also some advantages to have OsmocomBB in Gerrit: - Jenkins builder: maintainers / reviewers don't need to manually check whether a new commit fails build or not. - I don't need to copy-paste the source code to leave a contextual comment or ask a question. - Doing 'git push gerrit ...' is simpler and faster for me, than 'git format-patch ...', 'git send-email ...'. So, I would be definitely happy to see OsmocomBB in Gerrit. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbsoo7 at live.com Wed Apr 19 04:25:41 2017 From: bbsoo7 at live.com (bruce lee) Date: Wed, 19 Apr 2017 04:25:41 +0000 Subject: Fun with the MTK 6573 Baseband (Patching / Replacing) In-Reply-To: <105630929.3418738.1492570636730@mail.yahoo.com> References: <105630929.3418738.1492570636730.ref@mail.yahoo.com>, <105630929.3418738.1492570636730@mail.yahoo.com> Message-ID: there is a https://github.com/xobs/fernly seems they did what you are trying to do now. they also has a qemu to emulator that chip or so. I made a little progress for patching mt6573 modem.img. these output is from this commands. radiff2 old.img new.img. 0x00110d08 f0b50fb43ef052fa01280fbc03d13ef05cfcf0bdf4e7 => 68616e67654e6f74696669636174696f6e000000f0b5 0x00110d08 0x0014f1b6 32683846f0252d02a8352d0293352d028c352d6808210902223109029831a94201d00020f0bd01200120f0bd8d466d462d1d2d1934 => 06460024407b95b02746012825460fd002281ed144f001fb024611a101a868f022fd01af384671f0d4fb85b2012410e00f48314600 0x0014f1b6 0x0014f1ec 2d19ad => 827d68 0x0014f1ec 0x0014f1f0 ad4605d0a0e1ffbd2d196400241d6519ad460000b0e329f7adfdffbd => 33f1a6fa0106090e01d0012904d1307b4df068f9040005d1307b2b46 0x0014f1f0 0x0014f218 be7dacf0 => 2b45414c 0x0014f218 0x0014f54e f0242402a834240293342402903405460e68206805e043fff0bdff0055e3fad100202946324600250446083025609cf0 => 06460025407bffb0c8b0012843d100272c2205233146c6a832f173fec0abc4b2187e002837d1022c03d0042c01d0052c 0x0014f54e 0x0014f57f e96660 => d12c22 0x0014f57f 0x0014f584 2360f0bdf0b5f02000460002a830 => 3146c6a832f162fec0abc7b2187e 0x0014f584 0x0014f593 02933000029030f0bd => 2826d1052c11d11748 0x0014f593 0x0014f5a0 f0b5fff7f1ff07680220396800468842fbd1391d081d00460046f0bd01b4fff7f9fd012801bc01d003d00fbcc1f7a6fbf0bdf0b515461e46fff7b8fffff7e0ff0446002d08d0002e06d00a68011d0446284615469cf0e2e800f002f8f0bd => 164b00683146827dc6a832f1e9fec0ab187e002816d101a943a832f1abf843a871f0e2f9c0032146020c0092307b3a4601ab4cf06bf80128054609d006480321006881800022307b29461346ccf0e4f97fb048b0f0bd0000c87dacf00a02 0x0014f5a0 0x0014f5ff 46f0 => 00f8 0x0014f5ff 0x0014f602 2046002801d0008829463246002a00d01160f0bdf0bdf080bde8 => 002506460c480468707b01280cd1a27d3146684633f193f8ff28 0x0014f602 0x001504fc 00bf00bf => 5bf0eaff 0x001504fc 0x001e8730 1a9866 => 0720fd 0x001e8730 0x001e8734 3ffd => c2eb 0x001e8734 0x001e87be 10a908600a2000021a9a1060 => 334a33a13ca0273203f0f6ee 0x001e87be questions here is how can we change these hex strings to a ARM assembler code? thanks BL. [https://avatars1.githubusercontent.com/u/238325?v=3&s=400] GitHub - xobs/fernly: Fernvale research OS github.com README.md Fernly - Fernvale Reversing OS. Fernly is a simple operating system designed for use in the reverse engineering of the Fernvale CPU. ________________________________ From: Craig Comstock Sent: Wednesday, April 19, 2017 2:57 AM To: baseband-devel at lists.osmocom.org Cc: bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) RootZero/bruce lee sent me this github with baseband sources very similar to what I already have for MT626x: https://github.com/zxp86021/MediaTek-HelioX10-Baseband [https://avatars3.githubusercontent.com/u/3607700?v=3&s=400] GitHub - zxp86021/MediaTek-HelioX10-Baseband: MediaTek ... github.com MediaTek-HelioX10-Baseband - MediaTek MT6795 (Helio X10) baseband source code Looking there it seems we have layer 1 GSM/2G support for many more RF chips. The trick is to figure out what AP/SOC they are used in. For example the MediaTek-HelioX10 is a MT6795 which seems to use the MT6169 transciever chip (based on some other files in the sources). My ZTE Obsidian seems to use this same TRX chip (based on a MT6735 datasheet) http://www.datasheet4u.com/pdf/MT6735-pdf/925384 LTE Smartphone Application Processor Technical Brief www.datasheet4u.com MediaTek MT6735 datasheet, MT6735 PDF, MT6735 download, MT6735 datasheet pdf, LTE Smartphone Application Processor Technical Brief Comparing L1D_RF_PowerOn functions it seems the MT6252 might be the closest to the MT626x which are completely missing from this newer set of sources that are maybe a year or so newer than the MT626x sources I have. m12196.c:/*BRIGHT2*/ void L1D_RF_PowerOn( void ) m12196.c:/*BRIGHT4*/ void L1D_RF_PowerOn( void ) m12196.c:/*BRIGHT5P*/ void L1D_RF_PowerOn( void ) m12196.c:/*AERO*/ void L1D_RF_PowerOn( void ) m12196.c:/*AERO1+*/ void L1D_RF_PowerOn( void ) m12196.c:/*RFMD*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74117*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74400*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6119*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6119C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129A*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129B*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139B*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140A*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140B*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) m12196.c:/*CMOSEDGE*/ void L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1T*/ void L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74045*/ void L1D_RF_PowerOn( void ) m12196.c:/*AERO2*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74137*/ void L1D_RF_PowerOn( void ) m12196.c:/*GRF6201*/ void L1D_RF_PowerOn( void ) m12196.c:/*IRFS3001*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6163*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6280RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6166*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6165*/ void L1D_RF_PowerOn( void ) one set of MT626x sources is called 11CW1418SP4 and supports the following baseband chips. Probably MT626x has an integrated baseband? m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6261RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6260RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6250RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) So I guess I need to look elsewhere in the sources to puzzle out my MT6735 ZTE Obsidian which would give me I think the cheapest/oldest chip that supports 4G/LTE: GSM, UMTS, GPRS, HSPA+, HSUPA, TD-SCDMA, EVDO, LTE Cat 4 (from https://en.wikipedia.org/wiki/MediaTek) [https://upload.wikimedia.org/wikipedia/en/thumb/2/2d/MediaTek_logo_as_shown_on_company_website.svg/220px-MediaTek_logo_as_shown_on_company_website.svg.png] MediaTek - Wikipedia en.wikipedia.org MediaTek Inc. (Chinese: ??????????; pinyin: Li?nf? K?j? G?f?n Y?uxi?n G?ngs?) is a Taiwanese fabless semiconductor company that provides ... -Craig p.s. here are some sources I used to research both github and "from the internet": http://git.huayusoft.com/tomsu/AP7350_MDK-kernel.git Tom Su / AP7350_MDK-kernel | GitLab git.huayusoft.com GitLab Community Edition ... AP7350_MDK-kernel. AP7350_MDK Android??????/??? kernel ?? bootloader ??? https://github.com/akibsayyed/CELLTEL82_WET_KK_GPRS_HSPA_MOLY.WR8.W1315.MD.WG.MP.V35.git https://github.com/akibsayyed/HSPA_MOLY.WR8.W1449.MD.WG.MP.V16.git https://github.com/zxp86021/MT6795.kernel.git mt626x stuff: 11CW1352MP_CENON61D_3232_11C_V2_GPRS_MMI 11CW1418SP4_CORETEK02A_WIFI_BT_V13_GPRS_MMI MTK60D-11B1308-V2 -------------------------------------------- On Thu, 4/13/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" Date: Thursday, April 13, 2017, 11:40 AM check this out. it is modem firmwear source code and this guy's github https://github.com/luckasfb/Development_Documents alots of good stuff.but do not have what am looking for. bruce. From: Craig Comstock Sent: Thursday, April 13, 2017 2:10:15 PM To: bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) Looking at some kernel sources I see a few things that look familiar to me from mt626x source. Grepping for RIL (radio interface layer) https://github.com/eagleeyetom/android_kernel_mtk_mt6572.git ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE 0x1600000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE 0x0A00000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE 0x1600000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define RIL_SIZE 0x100000 //for connsys memory ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define MEM_PRELOADER_START (DRAM_PHY_ADDR) //placed mem in RIL 256KB ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define RESERVE_MEM_SIZE (RIL_SIZE) they mentioned infrasys and connsys near the RIL bits... craig at z500:~/android_kernel_mtk_mt6572/mediatek$ find | xargs grep -s infrasys ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* infrasys AO */ ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* infrasys */ ./platform/mt6572/kernel/core/core.c: /* infrasys AO first half */ ./platform/mt6572/kernel/core/core.c: /* infrasys AO second half */ ./platform/mt6572/kernel/core/core.c: /* infrasys */ ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* infrasys AO */ ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* infrasys */ craig at z500:~/android_kernel_mtk_mt6572/mediatek$ vi platform/mt6572/kernel/core/core.c So... mt_reg_base.h looks a little familiar to mt626x stuff. There is also this: https://android.googlesource.com/kernel/mediatek/ and this: https://github.com/profglavcho/mt6735-kernel-3.10.61 -------------------------------------------- On Thu, 4/13/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "baseband-devel at lists.osmocom.org" , "Craig Comstock" Date: Thursday, April 13, 2017, 1:49 AM maybe it is easiest for developing on some boards which has UART port to look it boot up message. some mt6572 based boards one can find on China market. they event can share code with us if we buy it. it is android based. so should/can we make a osmocom-bb based BP for this android board? or other smartphone? thanks RZ From: Craig Comstock Sent: Thursday, April 13, 2017 3:21 AM To: baseband-devel at lists.osmocom.org; bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip craigcomstock/osmocom-bb github.com Contribute to osmocom-bb development by creating an account on GitHub. I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" , "baseband-devel at lists.osmocom.org" Date: Wednesday, April 12, 2017, 9:39 PM Craig, do you have the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ From: Craig Comstock Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel at lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-Patching-Replacing-tp4026683p4026772.htmlbaseband-devel - Fun with the MTK 6573 Baseband (Patching / Replacing)baseband-devel.722152.n3.nabble.comFun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com.Nabble ? Free Forum ? Embeddable Web Appsnabble.comEmbed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thayyil at yandex.com Sat Apr 22 13:45:43 2017 From: thayyil at yandex.com (thayyil09 yil) Date: Sat, 22 Apr 2017 19:15:43 +0530 Subject: osmocombb on qualcom android phones Message-ID: <5483541492868743@web20m.yandex.ru> An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Sat Apr 22 15:05:50 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Sat, 22 Apr 2017 10:05:50 -0500 Subject: osmocombb on qualcom android phones In-Reply-To: <5483541492868743@web20m.yandex.ru> References: <5483541492868743@web20m.yandex.ru> Message-ID: <7BA67EBF-638A-49EE-92BC-AA9A236D5B7A@yahoo.com> Sounds cool to me. Where is the source for qcom baseband? didn't see an obviius link on yourpage. I was thinking a rild impl which used osmocombb and other newer bits for 3g and beyond might be interesting. I'm more interested in something simpler like nuttx or bare android linux without the ui/java. ;) Craig On April 22, 2017 8:45:43 AM CDT, thayyil09 yil wrote: > > > >what about developing osmocombb on qcom msm. >anyway i put some info together on http://osmodroidbb.wordpress.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Apr 24 12:28:09 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 24 Apr 2017 14:28:09 +0200 Subject: osmocom-bb moved to gerrit Message-ID: <20170424122809.GA1050@my.box> The osmocom-bb git repository has now moved to gerrit. For patch submission to osmocom-bb, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Apr 25 12:00:40 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 25 Apr 2017 14:00:40 +0200 Subject: osmocom-bb moved to gerrit In-Reply-To: <20170424122809.GA1050@my.box> References: <20170424122809.GA1050@my.box> Message-ID: <1ea8faa3-b3ae-e00b-83b3-0fbbb26bc52a@sysmocom.de> Cool, thanks! There are no tests in osmocom-bb yet, but I wonder if it would be possible to add simple jenkins job which checks that arm cross-compilation for osmocom-bb succeeds as a patch check? On 24.04.2017 14:28, Neels Hofmeyr wrote: > The osmocom-bb git repository has now moved to gerrit. > For patch submission to osmocom-bb, see > https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit > > ~N > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From axilirator at gmail.com Wed Apr 26 00:24:28 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 26 Apr 2017 07:24:28 +0700 Subject: osmocom-bb moved to gerrit Message-ID: Hi, > The osmocom-bb git repository has now moved to gerrit. Great news! > There are no tests in osmocom-bb yet, but I wonder if it would be possible to add > simple jenkins job which checks that arm cross-compilation for osmocom-bb > succeeds as a patch check? I can take this task and try to write a Jenkins script. Also, we need to have cross-compiler installed on the build machines. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Wed Apr 26 11:00:05 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 26 Apr 2017 13:00:05 +0200 Subject: osmocom-bb moved to gerrit In-Reply-To: References: Message-ID: <69791a8c-f189-7d7d-ed13-11ce54d48d29@sysmocom.de> Please coordinate with Klaus (in CC, sorry for double-posting - not sure if you're subscribed to this list as well) who's working on revamping our jenkins install. On 26.04.2017 02:24, Vadim Yanitskiy wrote: > Hi, > > > The osmocom-bb git repository has now moved to gerrit. > > Great news! > > > There are no tests in osmocom-bb yet, but I wonder if it would be possible to add > > simple jenkins job which checks that arm cross-compilation for osmocom-bb > > succeeds as a patch check? > > I can take this task and try to write a Jenkins script. > Also, we need to have cross-compiler installed on the build machines. > > With best regards, > Vadim Yanitskiy. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Wed Apr 26 14:28:57 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 26 Apr 2017 16:28:57 +0200 Subject: osmocom-bb moved to gerrit In-Reply-To: References: Message-ID: <20170426142857.GB518@my.box> On Wed, Apr 26, 2017 at 07:24:28AM +0700, Vadim Yanitskiy wrote: > I can take this task and try to write a Jenkins script. Excellent. Best put it in contrib/jenkins.sh like in the other repositories. > Also, we need to have cross-compiler installed on the build machines. I can install any packages, just let me know which. (I assume we'd at first just build on a debian 8 slave) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Thu Apr 27 10:10:09 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 27 Apr 2017 12:10:09 +0200 Subject: osmocom-bb moved to gerrit In-Reply-To: <20170426142857.GB518@my.box> References: <20170426142857.GB518@my.box> Message-ID: <9e982d6e-0f5f-a6d1-e9f1-a395d59a51aa@sysmocom.de> It worked for me with *gcc-arm-none-eabi* package on Ubuntu - in this case the build should use "|make -e CROSS_TOOL_PREFIX=arm-none-eabi-|" command. See https://projects.osmocom.org/projects/baseband/wiki/Software_Getting_Started for details. On 26.04.2017 16:28, Neels Hofmeyr wrote: > >> Also, we need to have cross-compiler installed on the build machines. > I can install any packages, just let me know which. > (I assume we'd at first just build on a debian 8 slave) > > ~N > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Thu Apr 27 10:36:20 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 27 Apr 2017 12:36:20 +0200 Subject: osmocom-bb moved to gerrit In-Reply-To: <9e982d6e-0f5f-a6d1-e9f1-a395d59a51aa@sysmocom.de> References: <20170426142857.GB518@my.box> <9e982d6e-0f5f-a6d1-e9f1-a395d59a51aa@sysmocom.de> Message-ID: Note: there's somewhat related ticket https://projects.osmocom.org/issues/1918 which proposes to add --enable-embedded build of libosmocore to jenkins. We got to fix it first of course. Once this is available we can add 2 build for osmocomBB as a test - one using libosmocore version which is shipped with it and another using libosmocore master with --enable-embedded option. Hopefully some time in future we could drop the libosmocore source copy from osmocomBB repo completely. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From dr.blobb at gmail.com Wed Apr 26 12:04:39 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Wed, 26 Apr 2017 12:04:39 -0000 Subject: osmocom-bb moved to gerrit In-Reply-To: <69791a8c-f189-7d7d-ed13-11ce54d48d29@sysmocom.de> References: <69791a8c-f189-7d7d-ed13-11ce54d48d29@sysmocom.de> Message-ID: >> There are no tests in osmocom-bb yet, but I wonder if it would be possible to add >> simple jenkins job which checks that arm cross-compilation for osmocom-bb >> succeeds as a patch check? Sure, as I see the necessary steps to do so are: 1 - create a Jenkins gerrit-verification job that points to 2 2 - add a verification script to the osmocom-bb repo in: osmocom-bb/contrib/gerrit-jenkins.sh 3 - Create a Dockerfile that is capable to do the arm cross-compilation >> Also, we need to have cross-compiler installed on the build machines. Note: imho the smoothest solution for the current build slave setup to fulfill mentioned arm cross-compilation would be a Docker container, because it doesn't affect the current build environment at all. I have sufficient permission and time to do 1, in case it's okay for Holger and Nels? >> I can take this task and try to write a Jenkins script. And are happily collaborating on 2 and 3. Just let me know, how I can support. :) Cheers, Andr? P.S.: For clarification my real name is Andr?, my "nick" is "blobb" and "Klaus" is just a fake name for Google, which I already changed to the real one to not confuse this mailing list (anymore).