Paul Fertser <fercer...@gmail.com> wrote: > What exactly do you want to change in it? Disabling RRLP? Having AT > command intepreter sources wouldn't help it, also i'm not sure if the > original firmware had that "functionality" implemented in the first > place.
I have no way of knowing a priori whether I would want/need to change anything at all. For me it's a matter of having the source just for the point of it. Perhaps I just want to study it and understand how it works, perhaps I won't need to modify it at all. But being able to rebuild the image from the source is the only way to prove that the source is complete. A piece that's missing altogether is worse than having that piece in the form of an ARM ELF .o file. > Having TI's > blobs is not much different from having them all in a single firmware > files. Are you sure? Have you seen those blobs, as you call them? Without having seen them, my a priori guess would be that it's a big pile of little .o files in ARM ELF format. In order to be linkable with other modules, an ELF file has to be unstripped. Even if TI's "blobs" were/ are in the form of a few big .o files (on even just one) rather than a big pile of little ones, it still has to be unstripped ELF. That means symbol information: names of functions, names of variables, exactly where one function ends and the next begins, etc. Much better than a fully linked binary with no ELF symbolic information whatsoever. And if it's a big pile of little .o files (perhaps in a .a archive/ library) rather than one really big .o, that would be even better: one could conceivably disassemble these .o's one by one, using module and function names as a guide to where the more interesting bits are more likely to reside... Basically what I'm saying is that reasoning a priori, without having seen the ware, I would not discount the possibilities. MS _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
