FreeCalypso > hg > freecalypso-reveng
comparison fluid-mnf/README @ 365:f888ae294b1b
fluid-mnf/README: should be complete now
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Sun, 15 Mar 2020 08:59:12 +0000 |
| parents | 37d647dfb920 |
| children |
comparison
equal
deleted
inserted
replaced
| 364:37d647dfb920 | 365:f888ae294b1b |
|---|---|
| 263 115200 baud. | 263 115200 baud. |
| 264 | 264 |
| 265 * The D-Sample board has an extra 14.745600 MHz crystal oscillator and a special | 265 * The D-Sample board has an extra 14.745600 MHz crystal oscillator and a special |
| 266 circuit (controlled by bits in a register mapped into Calypso nCS3 address | 266 circuit (controlled by bits in a register mapped into Calypso nCS3 address |
| 267 space) that can switch the Calypso clock input from the regular 13 MHz coming | 267 space) that can switch the Calypso clock input from the regular 13 MHz coming |
| 268 from the RF section to this special 14.745600 clock. Of course no GSM | 268 from the RF section to this special 14.745600 MHz clock. Of course no GSM |
| 269 functions can work in this state, but feeding this special clock to Calypso | 269 functions can work in this state, but feeding this special clock to Calypso |
| 270 allows its UARTs to produce "standard" baud rates of 230400, 460800 and 921600 | 270 allows its UARTs to produce "standard" baud rates of 230400, 460800 and 921600 |
| 271 bps! This feature is apparently called XXO for eXternal Xtal Oscillator, and | 271 bps! This feature is apparently called XXO for eXternal Xtal Oscillator, and |
| 272 is supported by FLUID, including our fluid-mnf port: just select the desired | 272 is supported by FLUID, including our fluid-mnf port: just select the desired |
| 273 baud rate with the -b option, and if the target is D-Sample, it will just | 273 baud rate with the -b option, and if the target is D-Sample, it will just |
| 368 flashed; in the case of fc-loadtool the new flash e-program-m0 command was used. | 368 flashed; in the case of fc-loadtool the new flash e-program-m0 command was used. |
| 369 The version of fc-loadtool used for this test is the one that is about to be | 369 The version of fc-loadtool used for this test is the one that is about to be |
| 370 released with fc-host-tools-r13; previous versions would be even slower. In | 370 released with fc-host-tools-r13; previous versions would be even slower. In |
| 371 the case of fluid-mnf the -C option was used to disable delta downloads, making | 371 the case of fluid-mnf the -C option was used to disable delta downloads, making |
| 372 the test operation independent of previous flash state. | 372 the test operation independent of previous flash state. |
| 373 | |
| 374 Where to go from here | |
| 375 ===================== | |
| 376 | |
| 377 So now we have two competing tools for operating on the flash memory of Calypso | |
| 378 GSM devices: fc-loadtool and fluid-mnf. Which one should you use? In most | |
| 379 practical use cases only fc-loadtool will work: | |
| 380 | |
| 381 * FLUID only works on D-Sample, Caramel and Openmoko targets. If you are | |
| 382 working with an FCDEV3B, any Mot C1xx phone, Pirelli DP-L10 or a GTM900 module | |
| 383 with the newer Samsung K5L3316CAM flash chip, then fc-loadtool is the only | |
| 384 choice. | |
| 385 | |
| 386 * Both fc-loadtool and fluid-mnf can read flash dumps, saving them in either | |
| 387 binary or S-record format. However, FLUID only accepts *.m0 S-record files | |
| 388 (16-bit moko-style by default, but 8-bit and 32-bit variants can be used too) | |
| 389 as the data source for flash programming. Binary format is much more | |
| 390 convenient for flash backups, but restoring such backups with FLUID would be | |
| 391 a complicated matter, requiring an external converter that extracts the | |
| 392 desired subrange out of a binary flash dump file and makes an m0 image out of | |
| 393 it. | |
| 394 | |
| 395 * fc-loadtool and its loadagent back end are only one part of a larger loadtools | |
| 396 and target-utils suite that supports many other operations besides flash | |
| 397 manipulation. | |
| 398 | |
| 399 On the other hand, if your target is one of the few which are supported by FLUID | |
| 400 and your desired operation is to flash a firmware image built in m0 format, | |
| 401 then you can use fluid-mnf and enjoy faster speed - or enjoy the dancing LED | |
| 402 patterns if the target is a TI D-Sample board. | |
| 403 | |
| 404 We got into the present situation we find ourselves in because of the culture | |
| 405 of suppression that was built around our dear Calypso by the Closed Moko | |
| 406 Company: back when we started FreeCalypso in 2013, the source for FLUID was | |
| 407 wrongfully withheld from Humanity, thus producing a from-scratch replacement | |
| 408 like our own fc-loadtool was the only viable option. And because the project | |
| 409 was essentially a battle for the liberation of Calypso, performance was not a | |
| 410 major concern at that time, which is how we ended up with a tool that is not | |
| 411 optimized for speed like FLUID is. | |
| 412 | |
| 413 If I (Mother Mychaela) had been a Calypso modem engineer for a truly Open kind | |
| 414 of Moko instead of those NDA-worshipping Germans back in 2006-2008, with access | |
| 415 to all documentation, firmware sources and FLUID from day 0, and working in a | |
| 416 fully open culture with everything freely published like in current FreeCalypso, | |
| 417 I would have initially produced something very similar to the present fluid-mnf | |
| 418 port, just to get the existing and known working tool running under Linux | |
| 419 instead of Windows. If the project had stayed with Samsung K5A32xx or Spansion | |
| 420 S71PL-J flash chips, such a Linux port of FLUID would have been sufficient. If | |
| 421 new requirements came along to support S71PL-N flash, second flash bank | |
| 422 operations, significantly different Calypso targets like Mot C1xx, or anything | |
| 423 else that does not fit well into FLUID architecture, then my solution would | |
| 424 have been to produce a new tool that is free of unmaintainable FLUID gunk | |
| 425 (support for hw that no longer exists and thus can't be tested, old FLUID | |
| 426 bootloader protocol), but keeps those parts of FLUID architecture that make it | |
| 427 so fast. But as they say, history does not know subjunctive mood. | |
| 428 | |
| 429 So what can we do in the present? We have targets and operations which would | |
| 430 be very difficult to shoehorn into the architecture of FLUID, but which are | |
| 431 well-supported by fc-loadtool - how can we make them as fast as FLUID? One | |
| 432 promising approach would be to extend our loadagent yet again, adding a flash | |
| 433 programming protocol similar to FLUID, with parallelized flash operations and | |
| 434 serial stream Rx and with LZ77 decompression, and change fc-loadtool to use | |
| 435 this new protocol for flash programming while keeping all other functionality | |
| 436 as it already works. But given the sorry state of FreeCalypso funding, this | |
| 437 idea may never get implemented. :-( |