Hi,
I found out why class C (+1.8V) capable UICC are still used as class B (+3.3V).
This is because the board provides +3.0V on VCC_PHONE, forcing the phone
to use class B. this voltage is coming from VCC_SIM.
Normally VCC_SIM should only get the power from VCC_PHONE (in sniffing mode),
through the power switch FPF2005, or from the LDO AP3332 (in card reader).
Currently both are enabled (bug). This should be prevented in software as there
is no hardware mechanism to prevent that (fail).
Some power from the LDO is going backwards though the power switch, providing
+3.0V on VCC_PHONE (another hardware fail).
Also, SIMtrace will not be able to decode +1.8V traffic because Vih
(voltage input high level) is at +2.3V.
One solution would be to power VDDIO at 1.8V, but this is a bad solution
as the USB will not work anymore.
For the v2 board I intend to have the following:
- 1 translator/level shifter for SIM<->CPU, with selectable 1.8/3.3
- 1 translator/level shifter for PHONE<->CPU, with selectable auto/1.8/3.3
- VCC_SIM can be set to VCC_PHONE,1.8V,3.3V
- power forward with diode behaviour
any correction, comments or recommendation are welcome,
kevin
From: Holger Hans Peter Freyther <zecke(a)selfish.org>
This still needs to receive some more testing (untested on Windows
right now) and also consideration how/if we want to upgrade this in
the field. If we consider reflashing the DFU part safe enough. I would
argue that there is still SAMBA to fix things up if someone breaks the
bootloader.
Holger Hans Peter Freyther (1):
usb: Do not send ZLP when we have filled the window
firmware/src/dfu/dfu.c | 46 ++++++++++++++++----------------
firmware/src/dfu/dfu.h | 2 +-
firmware/src/os/pcd_enumerate.c | 54 +++++++++++++++++++++------------------
3 files changed, 53 insertions(+), 49 deletions(-)
--
1.7.7.2
<DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER>
Hi all,
this idea has been around for quite some time, and for 2012 I really
want to turn it into reality:
I'd like to have a Osmocom developer workshop
The idea here is to get all the active contributors of the project
together for a couple of days (maybe 2-4 days), in order to exchange
ideas, get to know each other better and last but not least work
together on ironing out some of the more difficult issues.
* City:
Regarding the location: I think for me it is only possible to organize
it if it is to be held in Berlin. I'mn happy if somebody else wants to
host it at some other location, but then that person would also have to
take care of local organization. Berlin also has good train and flight
connections, which is definitely a plus.
* Venue:
If it is in Berlin, we might consider talking with c-base or
Raumfahrtagentur as possible venues.
* Date:
Regarding a proposed date, I'm completely open for suggestions. Of
course there shouldn't be any overlap with other major FOSS or Sescurity
related conferences, and it should also not coincide with major public
holidays, as that only makes travel + accomodation more expensive.
* Funding:
As we don't have that many commercial users of Osmocom projects, getting
funding for e.g. travel / accomodation is probably going to be
difficult. We can ask the "usual suspects" among those commercial users
we know,, but I guess it will only be possible in exceptional cases to
provide that kind of funding.
Any ideas / comments / feedback is much appreciated. If somebody has
a particular suggestion.
<DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER>
Cheers,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
I'm thinking of starting a project that would allow us to
* perform SIM and USIM card pre-personalization
* read/dump and explore [U]SIM contents interactively
* perform SIM card simulation
The idea is to start with some generic data structure that can represent
the filesystem tree (DFs, EFs) and their "external" properties, i.e.
file type, size, permissions, FID, SFID, etc.
This data structure could also have the actual file content associated
with each EF.
The second step would be some code that can take that data structure and
program a freely-programmable card (like sysmoSIM-GR1) and create the
files according to that structure.
Another module would implement card-simulation (via BT SAP, SIMtrace or
virtual PC/SC card). After all, only a few instructions have to be
imilpemented if the filesystem and its content is already in a generic
data structure that the program can access..
Next step would be to associate parser and generator routines for the
content of each individual file as it is specified in TS 11.11.
After that has been done, we could think of representing the FS tree and
the parsed contents of each file in some kind of graphical / user
friendly representation. The idea here is that the UI code would be
generic and not know any of the actual ecnoding/decoding of the EF
content.
The biggest question is what language to use for this. Some kind of
object orientation might very well resemble the idea of a 'file object'
in a tree, with many different file types, each having it's own
parser/encoder.
On the other hand, Erlang's bit field syntax would probably come very
handy in terms of encoding/decoding the various EF content. However, at
least once we start to want some kidn of UI, Erlan really sucsk. Also,
almost nobody here reads/writes Erlang [yet?].
Writing all this in C seems like a bit much of an effort, probably even
more so on the UI side. However, we already have quite a bit of C code
for parsing/generating things like LAI, etc. which are stored like 04.08
inside the sim card files.
Python might be a good idea in terms of tons of available
libraries/modules, object orientation and good UI bindings. The biggest
problem here is that my python skills are really limited so far, so my
productivity might not be as high as I expect.
The individual components could even be written in different
languages, but then we would have to have some common format for
exchanging data back and forth - which might not be worth it, given the
small scope of the project.
any ideas / comments / feedback?
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
From: Holger Hans Peter Freyther <zecke(a)selfish.org>
These address various compiler warnings, there is still one left
related the flash handling but I will need to read a bit more on
the EFC. I have flashed my device using DFU with these patches applied.
Holger Hans Peter Freyther (5):
dfu: The i variable to disable interrupts shadows the outer index
dfu: udp_ep0_recv_clean is static and is not called anywhere
dfu: Mark unsued variables as __unused for now
dfu: Use {} for possible empty if statement (in case debug is off)
dfu: Remove unused variable, mark method as not retuning
firmware/include/asm/compiler.h | 3 +++
firmware/src/dfu/dfu.c | 36 +++++++++++-------------------------
2 files changed, 14 insertions(+), 25 deletions(-)
--
1.7.7.2
