Ich eröffne jetzt einfach diesen Thread, der direkt mit diesem hier:
Beitrag "PHILIPS VP5500 VoIP Telefon bei Pollin"
in Zusammenhang steht. In diesem Thread hier geht es jedoch
ausschließlich um:
Entschlüsselung der Hardware
Treiber Entschlüsselung und Entwicklung
Kernel Entschlüsselung und Entwicklung

Bitte alles andere, Konfiguration, Anbindung an SIP Provider oder
Fritz!Box  in oben angeführten Thread belassen.

Verehrte Moderatoren, ich hoffe, ich habe Euer Einverständnis, dass
dieser Thread auch gemischt in Englisch geführt wird, da einige
verdiente Teilnehmer sonst ausgeschlossen wären.

Dear VPx500 users and developers,
this thread is directly related to the following one:
Beitrag "PHILIPS VP5500 VoIP Telefon bei Pollin"
But this discussion is only for:
Decoding the hardware of the Philips VPx500 series phones
Decoding and developing of drivers and modules
Decoding and developing of kernels

Please keep any questions about configuration and SIP connection in the
other thread.

Best regards and thanks in advance
Ulrich

Hi all,

thanks to Ulrich for finally starting a new thread. I'd propose that we
use English as the main language here (the main part of the
platform/kernel/toolchain related discussion has always been in
English). Of course, if the mikrocontroller.net rules require
communication to be in German, we'd be forced to create a mishmash ;-)

/G

Hi,
to understand the functionality of the hardware, we have to reverse
engineer the system software (and drivers?). So, my first question is:
What software is being reverse engineered right now?
There is a gdbserver on the phone, it should be possible to reverse
engineer /user_data/prod/bin/APPTvlink.exe. But maybe IDA is a better
choice?!

Are the *.qm files in /usr/local/i18n/nl just language-files? Viewed
under a hex-editor, it seems like they are just containing some strings.

Another question which comes up to my mind: Isnt it theoretically
possible to play music by using /dev/audio or something ? .au or .wav
files...

I'm not experienced in reverse engineering devices, but windows
software. Maybe i can help out anyway.

Eddy Sino schrieb:
> Hi,
> to understand the functionality of the hardware, we have to reverse
> engineer the system software (and drivers?). So, my first question is:
> What software is being reverse engineered right now?

Good question. I asked for a matrix of what we have, what we know and
what we need. But, as splitting the threads, you must simply start it
without thinking about cons and pros. But before I start the matrix, I
am busy with getting openocd connected to the phone.

> There is a gdbserver on the phone, it should be possible to reverse
> engineer /user_data/prod/bin/APPTvlink.exe. But maybe IDA is a better
> choice?!
I am not sure if the tv system is the right point of priority :)
But anyway, diving in deeper never is a wrong thing.

I never worked with gdb before, but should not be a problem if openocd
is running. I don't know if the gdb inside is configured for using the
serial port or the JTAG. We'll find out.
There is no reason to go both ways. People with good equipment should
concentrate on the hardware decoding, people with deeper linux knowledge
should concentrate on the software. If you are familliar with 'hacking'
and can work with those big battleships like IDA, keep it going.

> Another question which comes up to my mind: Isn't it theoretically
> possible to play music by using /dev/audio or something ? .au or .wav
> files...
Yes, it should be, as the system already uses wav for ringtones. I doubt
that there is any mp3 support built in, but if this thread succeeds, we
should be able to do what we want on this device.
>
> I'm not experienced in reverse engineering devices, but windows
> software. Maybe i can help out anyway.
While we first have to get a toolchain going for the device, we later
need people who can write code for the device and may be tools for Linux
and Windows computers. So there is no argument against any sort of
programmer.

This whole project lives only from contribution, time, fun and people
that like to share knowledge and are willing to learn.

Hello,

there are five files that are of interrest right now:

/user_data/prod/bin/APPSensor.exe - accessing the camera
/user_data/prod/bin/APPTvlink.exe - acessing the TV ouput
/user_data/prod/bin/aic14_conf and test_aic14 - acessing the audio
devices
/user_data/prod/HD1V00_ats.sh - various registers and controls

The last one is a shell script, so that is really easy.

The first four interact with the device nodes:

/dev/sensor - camera device
/dev/dspX - audio devices, earpiece, headset and handsfree have seperate
devices
/dev/fbX - frame buffer devices for LCD and TV-output

Things like the backlight, keyboard LED's, etc. are accessed through the
"mm" binary, that directly reads or writes of/to a given memory address
(= register of the ARM CPU).

Another important device node is /dev/buttons, this is the interface to
the buttons/keypad.

Most of the kernel drivers are available in the Freescale Linux BSP for
the i.MX21.

Next week or weekend i will start to reverse the four executables to
gather information about the used sysctl calls and read/write
operations. I'm going to use IDA-Pro for that task, since i'm already
familiar with it from another project that involved reverse engineering
of an existing firmware for an ARM chip. Using the gained information i
will write some little programs to demonstrate the access to the
devices.

Greetings,

Chris

Hardware / JTAG

Has anyone seen the JTAG Port on the VP6500? There is a contact row
looking the same like on the VP5500 beyond the LCD. But is has a
different pinning, as GND is not available on it. And it is located
right below the Wireless Chip. I fear it is for reprogramming this guy,
not the iMX...

Hat schon jemand den JTAG für den iMX auf dem VP6500 ausfindig gemacht.
Die kleine Test-Pin Reihe unter dem Display scheint eher für den Philips
Wireless Chip zu sein.

g457 schrieb:
> Das VP6500 hat neben dem WLAN-Chip unter der Abschirmung noch einen
> potenziellen TAP (siehe Foto in [1]).

Hi!

Also dann ist es wohl eher so, dass der Tap unter der Abschirmung für
den WLAN und der auf der Unterseite für den iMX ist. Hatte aber noch
nicht weiter gesucht. Hatte ein Problem mit dem Zerlegten VP6500 und
seiner Versorgung. Das NT hat wohl die Begrenzung zu niedrig gehabt und
nun bootet das Tel zwar bis zu einem gewissen Punkt, schaltet sich dann
aber aus. Kommt nicht übere die Sanduhr hinweg.

Egal, dafür soll das JTAG ja da sein :)

Vielleicht hat es ja bereits jemand herausgefunden.

Gibt es die Möglichkeit, das Telefon sofort beim Anlegen der Spannung zu
starten und nicht per "EIN"-Taste? Das würde die Zweckentfremdung des
Gerätes noch unterstützen.


Can we start the phone on power-up an not by pressing the "hang-up"-key?
I want to use the hardware not as phone.

Christian H. schrieb:
> Vielleicht hat es ja bereits jemand herausgefunden.
>
> Gibt es die Möglichkeit, das Telefon sofort beim Anlegen der Spannung zu
> starten und nicht per "EIN"-Taste? Das würde die Zweckentfremdung des
> Gerätes noch unterstützen.
>
>
> Can we start the phone on power-up an not by pressing the "hang-up"-key?
> I want to use the hardware not as phone.

It does start automatically when placed in the charging craddle. So
there seems to be some mechanism for that.

Greetings,

Chris

Hello,

i finally succeeded in compiling/installing the Freescale BSP for the
i.MX21. The original package can be found here:

http://www.freescale.com/webapp/sps/site/prod_summ...

It's the "Linux BSP for Freescale i.MX21ADS"

Now, there have been some hickups initially, but i was able to sort them
out. On your host Linux, the symlink /bin/sh must point to /bin/bash.
For some reason on the Kubuntu box it pointed to /bin/dash instead,
which caused some errors for things that used stuff like "mkdir
{a,b,c}". Dash creates {a,b,c} literally, whereas bash creates the three
directories a, b and c instead.

Next thing is that you must use gcc/g++ version 3.x. The 4.x version
fails to compile some sources.

Now, during compiling, some stuff requires to include the file
"Python.h". This file is located under /usr/include/python2.X/, where X
is the minor version number. However, the standard include path is only
/usr/include, so it fails to find it. To solve that problem, you have to
do

export C_INCLUDE_PATH=/user/include/python2.X

Again, where X is the minor version number. Check out which directory
holds the Python.h file and have it point there.

Starting the install of the BSP will tell you about some packages that
you need to install. So install them first.

For some reason the first run of ltib sometimes fails, the log shows the
error:

Hello,

i finally succeeded in compiling/installing the Freescale BSP for the
i.MX21. The original package can be found here:

http://www.freescale.com/webapp/sps/site/prod_summ...

It's the "Linux BSP for Freescale i.MX21ADS"

Now, there have been some hickups initially, but i was able to sort them
out. On your host Linux, the symlink /bin/sh must point to /bin/bash.
For some reason on the Kubuntu box it pointed to /bin/dash instead,
which caused some errors for things that used stuff like "mkdir
{a,b,c}". Dash creates {a,b,c} literally, whereas bash creates the three
directories a, b and c instead.

Next thing is that you must use gcc/g++ version 3.x. The 4.x version
fails to compile some sources.

Now, during compiling, some stuff requires to include the file
"Python.h". This file is located under /usr/include/python2.X/, where X
is the minor version number. However, the standard include path is only
/usr/include, so it fails to find it. To solve that problem, you have to
do

export C_INCLUDE_PATH=/user/include/python2.X

Again, where X is the minor version number. Check out which directory
holds the Python.h file and have it point there.

Starting the install of the BSP will tell you about some packages that
you need to install. So install them first.

For some reason the first run of ltib sometimes fails, the log shows the
error:

ERROR: /tmp/rpm-XXXX/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm
would clobber reescale/ltib

where XXXX is the username you are logged in at. In that case, simply
delete all the rpm-XXXX directories under /tmp and run ltib again. This
time it should finish without any error.

The result is a working BSP for the chip used in the phone. It has the
exact same kernel version 2.4.20-celf3 compiled for the same
architecture, armv5EJl. The gcc/g++ and clib versions also match the
ones on the phone. They also use blob as bootloader.

This will give us a complete toolchain, kernel sources and modules for
most of the stuff on the phone. Missing kernel modules in the BSP for
the propietary thing in the phone can thus be replaced by the original
modules from that phone.

So, later this week i will start with reverse engineering the test-apps
from the phone.

Greetings,

Chris

Congratulations, Chris!

I'll investigate for the JTAG in the next Day but I will be on vacation
from Thrusday till Tuesday. Hope I got it finished till then including a
description here or in the wiki.
I think JTAG will give better performance of uploading a kernel to the
phone than serial port does....

Ulrich P. schrieb:
> I think JTAG will give better performance of uploading a kernel to the
> phone than serial port does....

Well, depends on the JTAG interface used. Good ones are really fast,
average ones are still fast, but very simple/bad ones can be slower.

Does anyone here have some web/ftp space where i could upload the VMware
image for the stuff i'm working on? So far i got the BSP installed
cleanly, now i'll tweak the system a bit to give a nice development
environment. Once that is done, i'd like to upload the stuff somewhere,
so that others can use it as well.

Greetings,

Chris

Edit: Same goes for serial ports as well. A real serial port will give
you the full speed. A USB adapter will almost never give you the full
115200 baud. It's simply because of the way USB serial adapters work
(one 64 byte package max., every milisecond). If you then have to use a
protocol that has a lot of back-and-forth communication going, USB is a
bottleneck for that.

I use openocd-usb dongle from the mikrocontroler.net shop with openocd.
But I compile it agains FTD2xx drivers what gives a lot more speed that
libusb.
Depending on the target and board layout I use it with speeds from
6..10MHz.

I only have a personal server running at home, but DSL is not the best
carrier for such a thingy. Ask one of the mods how to deal with packages
like this.

Hello,

so, i have the virtual machine set up so far. The BSP is installed, some
development tools, the helloworld program compiles using the toolchain
from the BSP.

If anyone is interrested in getting this VM image, just write me a
message there: http://www.mikrocontroller.net/user/show/mamalala

I will then get back to you with my address. Simply send an empty 4.7 GB
DVD (no double sided or other fancy stuff) in a padded envelope. Write
your own address on that envelope and put enough stamps on it. Then put
that into another, simple envelope and send that to me. I will then burn
the DVD and send it back to you.

If you are outside of Germany we have to find a different solution.
Either put some Euros in there for the postage, or through PayPal or
whatever.

Greetings,

Chris

Ich denke auch, dass bittorrent für sowas das mittel der Wahl wäre

Hi All,

Sorry for my long absence, i'm kinda busy lately (have to make a living
somehow ;)). I just read up with the initial thread and saw this new
thread was made, great. It was getting kinda crowded over there ;)

@Chris
I see you already figured out the probs with LTIB, it was indeed picky
about dash/bash. I'm switching over all the time ;) It's also build by
someone using an .rpm based system.. not my cup of tea, but with some
work it works very well under .deb based systems (i'm using Karmic at my
desktop).

I can help out in supplying FTP space and/or (if wanted) a virtual
machine (OpenVZ, any *nix dist. possible). Because i don't have much
time to act as a daily system manager, i prefer to have one person
managing it and who is also responsible for giving out (shell) accounts.
Chris are you up for this? If so, please PM me!

Cheers,
Joost

Joost R. schrieb:
> Chris are you up for this? If so, please PM me!
>
> Cheers,
> Joost

Definitely. My only problem is that i have to go online using UMTS. So,
uploading such a big file is basically a no-go. It has roughly 2GB right
now, compressed. I'll send you a PM now...

Greetings,

Chris

I can help out in managing or doing the transfers.
DSL16+ is fast enough for thos things, but not if you host it.

I send you my pm and we could arrange that in any way we figure out, if
you like.

Ulrich

Hello all,

thnaks for all your offers to help out here. I have arranged with Joost
that i send him the DVD and he copied it onto his FTP server, so it will
be online soon. I'm going to burn the DVD today and mail it to him.

Greetings,

Chris

Da ich mich in letzten Tagen auch mit Freetz für meine Fritzbox
beschäftigt habe, habe ich in dem dafür erstelltem freetz-linux auch mal
unsere toolchain ausprobiert.

klappt wunderbar!
Da viele die Kombination fritzbox und VPx500 haben wäre das ideal.

freetz linux gibts hier:
http://www.ip-phone-forum.de/showpost.php?p=140023...
Das ist eine VM-Ware Appliance, mit eingerichtetem samba, ssh und allem
was man zum Bauen von freetz-images braucht.
(username freetz, password freetz)

ich werde im Wiki noch eine Anleitung hinzufügen

Man könnte aber auch darüber nachdenken direkt in diese VM die aktuelle
Freetz und arm-toolchain zu integrieren und es dann per torrent zu
verteilen.
Da würde man dem freetz-hoster auch etwas Bandbreite ersparen.

Ich werde heut abend mal probieren, wie groß es gepackt ist, wenn man
die arm-toolchain und den freetz-svn-trunk mit rein nimmt.

===

In the past few days i experimented a bit with with Freetz for my
Fritzbox. in the freetz-linux that was build for creating freetz-images
i also tried our toolchain.

works just fine!
because many of us have the fritzbox-vp5500-combination, that would be
ideal.

freetz linux is available here:
http://www.ip-phone-forum.de/showpost.php?p=140023...
This is a VM-ware appliance, with fully equipped samba, ssh and
everything you need for building freetz-images.
(username freetz, password freetz)

I'll write a few lines to the tutorial in the wiki

maybe we also schould consider about integrate the freetz-trunk and the
arm-toolchain directly Freetz-linux-VM distribute it via torrent.
this also would save bandwidth of the freetz-hoster.

in evening i will try how big the packed archive with the arm-toolchain
and the svn-trunk of freetz will be

I'm abroad (again), but thanks to my trusty dns2tcp link the good news
of Christian's BSP-built reached me anyway. Congrats!

@Vlad: Freetz in combination with the VPx500 sounds really interesting,
but I think that we shouldn't attempt to mix the two projects. Apart
from the circumstance that both toolchains require a Linux environment
they don't have much in common. Mixing code of the two projects would
also complicate the task of handling updates.

@Christian: in welcher Einöde lebst Du denn, dass Dich die Segnungen von
Breitband und Flatrate noch nicht erreicht haben?

Gert D. schrieb:
> @Vlad: Freetz in combination with the VPx500 sounds really interesting,
> but I think that we shouldn't attempt to mix the two projects. Apart
> from the circumstance that both toolchains require a Linux environment
> they don't have much in common. Mixing code of the two projects would
> also complicate the task of handling updates.

I do not want to mix the projects
I just want to dual use the vm to save space.
everybody who uses freetz also need this vm to build, even if he does
not want to deveolp for freetz.

the freetz-linux actually does not comes with freetz itself but
providing a linux-vm that is designed to be a build machine easy
accessable from windows.

everything you further need to do to use it for our purposes is to
untaring the arm-toolchain

Hallo Leute,
ich habe in den letzten 2 Tagen mal eine Weile APPTvlink.exe mit IDA
reversed und es ist einfacher als ich dachte (ist es normal, dass die
Funktionsnamen noch in der binary stehen?).
Jedenfalls habe ich mal versucht zu verstehen was das Programm genau
macht, und wie es den TV anspricht. Ich weiß absolut nicht inwiefern das
alles hilfreich ist oder ob es nicht viel einfacher geht.

Habe das kleine Programm mal angehangen. Ihr könnt euch die binary auch
einfach per wget von meinem space ziehen (wget
http://eddy14.freeunix.net/tvlink) oder den Anhang (ich weiß gerade
nicht sorecht, ob archive als Anhang erlaubt sind, deswegen:
http://eddy14.freeunix.net/tvlink.tar).
Da ihr das alles per root ausführt, solltet ihr äußerst vorsichtig sein
(aber brauche ich ja nicht zu erwähnen oder?)

Also schließt erstmal euer Gerät an den Fernseher (falls es schon wieder
dunkel wird, müsst ihr einen Button auf dem Telefon drücken damit es
wieder an geht).
Zum an und ausschalten:

./tvlink on
./tvlink off

Zwischen PAL und NTSC modus wechseln:

./tvlink ntsc
./tvlink pal

Und zuletzt, den Bildschirm clearen:

./tvlink cleartv
oder sogar das display vom telefon:
./tvlink cleardisplay

Das mit dem clear habe ich gerade eben herausgefunden. Allerdings muss
ich genau 4 Bytes übertragen. Ich hätte ja zuerst auf RGB getippt, aber
dann bleibt ja ein Byte über. Sowas wie Transparenz kann es ja nicht
sein. Oder hat es etwas mit dem r565 zu tun? Ich weiß nicht genau,
welcher dieser Bytes welche Farbe repräsentiert. Vielleicht kennt sich
da ja einer aus, und kann mir da weiterhelfen.

Dann könnten wir auch schon theoretisch Bilder auf den TV zeichnen (ist
allerdings sehr langsam, hmmm).

Also habe ich mal mit den verschiedenen /dev/dsp mal rumgespielt, indem
ich ein paar lange binaries in die reingeschoben habe.
/dev/dsp1 scheint für die Freisprecheinrichtung zuständig zu sein.
bei dsp oder dsp0 tut sich nix und bei 2,3 und 4 meint er die devices
gibt es nicht
Ich hätte erwartet, dass eins davon der normale Hörer ist


Hintergrund ist, dass ich versucht habe tinysid zum laufen zu bekommen.
Nach Anpassungen des Makefiles und Auskommentieren eines ioctl-Aufrufs
(SNDCTL_DSP_STEREO) tut sich auch was.
Allerdings nur sehr abgehackt und. Man erkennt auf jeden Fall nicht, was
es sein sollte.
Jetzt weiß ich nicht, ob einfach die CPU-Listung nicht reicht, oder obs
andere Probleme sind.
Sids wäre cool für Klingeltöne ;) nehmen nicht so viel platz weg, wie
waves und sind so schön oldscool


Edit:
also laut top ist der tinysid-prozess bei 10%, daran wirds also nicht
liegen.

Gert D. schrieb:
> @Christian: in welcher Einöde lebst Du denn, dass Dich die Segnungen von
> Breitband und Flatrate noch nicht erreicht haben?

In der Kulturhauptstadt Essen! Hehe. Angeblich ist der Verteiler auf der
Strasse voll belegt. Wenn überhaupt würde nur noch was von der TKom
gehen. Auf die habe ich aber wenig bis keine Lust. Nachdem ich mich
gerade mit meinem Ex-Provider QSC vor Gericht streiten muss habe ich
auch erstmal die Nase voll von lange laufenden Verträgen.

An sich ist UMTS garnicht mal so schlecht. 20 Euro für ne Flatrate mit
10GB Volumen bei voller Geschwindigkeit, danach bis Monatsende auf
64kBit runter. Je nach Wind- & Wetterlage komme ich bis auf 4 MBit/s
Geschwindigkeit...

Aber zum Hochladen von so Riesendateien ist das halt nix...

Grüße,

Chris

Ist das Image schon irgendwo zum runterladen?
Was brauchst noch? Nur einen VMWare-Player?

Gruß, Ulrich

Ulrich P. schrieb:
> Ist das Image schon irgendwo zum runterladen?
> Was brauchst noch? Nur einen VMWare-Player?
>
> Gruß, Ulrich

Noch nicht, ich schicke die DVD Morgen zum Joost, bin Heute nicht dazu
gekommen.

Ja, es wird nur noch der aktuelle VMWare-Player benötigt.

Grüße,

Chris

Gast! schrieb:
> Konkurrenz, kabelgebunden: 6MBit im Downstream, 460kBit im Upstream (die
> auch jeweils stabil erreicht werden), wetterunabhängig,
> tageszeitunabhängig, ohne Volumenbeschränkung, EUR 20/Monat. Leider eine
> Mindestvertragslaufzeit von 24 Monaten..

Naja, das ist nicht wirklich billig für die mickrige Datenrate
kabelgebunden. Ausserdem hilft mir das alles nichts solange im Verteiler
auf der Straße alles voll belegt ist. Wäre dem nicht so müsste ich nicht
mit UMTS online sein. Allerdings ist das auch nicht weiter schlimm. Ich
bin keiner von diese Power-Saugern. Bin Jahrelang mit 2MBit glücklich
gewesen, da aber dann symetrisch mit 5 festen IP's.

Grüße,

Chris

Um mal wieder auf den Kernel zurück zu kommen :)

Wenn man mit WinSCP auf den Dingern arbeitet, dann bekommt man immer
wieder die Meldung, dass die Groups nicht aufgelöst werden können. Da
die VPs ja in einer Menge Verzeichnisse als User:Group 301:504 statt
Namen haben, denke ich, dass da eine Datei oder ein Feature fehlt. Kann
man das mit Bordmitteln nachziehen oder ist dafür eine Runde
Kernel/Busybox fällig?

*/etc/passwd* und */etc/group* so anpassen, dass zu jeder
User-/Gruppen-ID ein Eintrag vorhanden ist.

Beispiele
/etc/passwd
user:x:301:504:Vorname Nachname:/home/user:/bin/bash

/etc/group
gruppe:x:504:

Hello,

attached are the sources & makefiles for two simple programs.

The first is "mmaptest". It uses mmap() to map the processors PRP
registers to a local struct that represents them. It then sets these
registers according to the values that are used in the
"FUNC_VIEWFIND_ON_LCD()" function in the HD1V00_ats.sh test script that
resides on the 5500 phone.

The PRP is used to convert image formats, scaling, etc. This is used for
the built-in camera. The PRP can write the output of it's work to a
given memory address. In this case, it uses the framebuffer's address.
You could change that and have it point to a buffer that you malloc'd,
and then save the incomming stream. Or whatever pleases you ;)

The second program is "sensortest". I reverse engineered the
APPSensor.exe file from the phone to get the ioctl's used therein. Then
i reimplemented them in my source to control the camera. There are seven
ioctl's i could find:

0x6C01 - init the sensor
0x6C02 - set the contrast, values range from 0 to 4 inclusive
0x6C03 - set the cameras register. no idea what that does
0x6C04 - start capture
0x6C05 - stop capture
0x6C06 - set format, want's a struct consisting of uint16's for width,
height, and two other, yet unknown parameters
0x6C07 - power on the camera

To display the camera image on the LCD screen, first run mmaptest, then
run sensortest. Voila, you see yourself (or whatever you pointed that
thing at). To turn that off, start the phone's camera application once
and exit it. I was too lazy to add that functionality ;)

Greetings,

Chris

Forgot to include the binaries of these programs. Here they are.

It works on the 5500 as well as on th 6500.

Greetings,

Chris

Onno schrieb:
> Das
> Kernelmodul alleine würde reichen!

Hello,

attached is the tun.o kernel module. You need to create the tun device
node first, something like:

mkdir /dev/tun
mknod /dev/net/tun c 10 200

Don't forget to set the proper permissions as needed.

Loading the module is done with:

insmod /path/to/tun.o

Greetings,

Chris

Da ich auf meiner QRL keine Bilder hier einstellen kann , werde ich
heute Abend mal einige Testpins vom VP6500 hier einstellen.
Hoffe ich bin dazu jetzt im richtigen Thread. Ist ganzschön
unübersichtlich gewurden hier.

Timo schrieb:
> @Chris:
> Wäre es für dich möglich, ein kleines Binary zu schreiben, dass die
> Daten der Kamera nicht in den /dev/fb0 schiebt, sondern in eine Datei?
> Danke & Gruß. Timo

Mal schauen wann ich dazu komme. Habe momentan etwas andere Prioritäten
;) Das Prinzip ist aber einfach. Mittels malloc einen buffer aus
u_int16_t anlegen der groß genug ist, dann als Argument für set_prp()
eben die Startadresse dieses Buffers übergeben. Capture starten, kurz
warten, Capture stoppen, danach den Buffer in eine Datei schreiben. Ggf.
noch ein wenig in den PRP einlesen, also im Datenblatt zur CPU, um
Ausgabeformat und -größe auf die eigenen Bedürfnisse anzupassen.

Grüße,

Chris

Timo schrieb:
> @Chris:
> Wäre es für dich möglich, ein kleines Binary zu schreiben, dass die
> Daten der Kamera nicht in den /dev/fb0 schiebt, sondern in eine Datei?
> Danke & Gruß. Timo

warum nicht parameterisierbar,
fb0, fb1 und Datei (wahlweise mit formatierung für fb0 oder fb1)

Hallo,

bitte versteht das folgende nicht falsch. Der Sinn und Zweck dieser (und
zukünftiger) kleinen Programme ist lediglich zu zeigen wie man die
Hardware im Telefon benutzen kann. Das ist Primär dafür gedacht anderen
Leuten eine Basis zu geben.

Es gibt noch viel zu erforschen in dem Telefon. So werde ich mich z.B.
als nächstes an die Audio-Devices machen, um die ans Laufen zu bekommen.
Das ist doch einiges an Arbeit, vor allem das Reverse-Engineering und
testen. Zudem muss ich auch noch Arbeiten, um meinen Lebensunterhalt
irgendwie reinzubekommen.

Daher bleibt nur ein gewisser Teil an Zeit übrig den ich da reinstecken
kann. Und ehrlich gesagt, den verbringe ich eben lieber damit, Sachen zu
erkunden und gängig zu machen, und nicht damit irgendwelche Wünsche, die
nichts zu den Grundlagen beitragen, zu erfüllen.

Das ist nicht böse gemeint, aber ich kann meine Zeit halt nur einmal
verbrauchen. Wer es eilig hat und meint, ohne solche Funktionalitaet
nicht auszukommen, der ist herzlich Eingeladen das selber zu erweitern.
Dafür ist es ja schliesslich da!

Schöne Grüße,

Chris

Hi Christian,

das sehe ich genau so. Ziel dieses Threads sollte es sein, zu aller erst
mal die vollständige Software auf dem Telefon reproduzieren zu können.
Dann sollten wir versuchen Ersatz für die proprietären Treiber zu
finden.

Danach sind die Wege offen. Die Oberfläche bietet einiges
Verbesserungspotential,auch das Telefonieren könnte man einfacher
gestalten, also Freizeichen nicht über Lautsprechen, oder wenigstens mit
einstellbarer Lautstärke u.s.w.

Auch der eigentliche SIP Client scheint proprietär zu sein, ich habe
zumindest einige Config-Einträge ergoogeln wollen und keinen einzigen
Treffer landen können.

Ich denke dann haben wir ein richtiges Open-Surce Telefon und die Wege
werden sich dan trennen. Die einen sind damit zufrieden, die Anderen
wollen an der GUI arbeiten. Wieder andere (so auch ich) möchten
vielleicht einen Kernel 2.6.x laufen haben...

Gruß, Ulrich

Ulrich P. schrieb:
> Auch der eigentliche SIP Client scheint proprietär zu sein, ich habe
> zumindest einige Config-Einträge ergoogeln wollen und keinen einzigen
> Treffer landen können.

Ja, das ist der VeriCall Edge VoiP/SIP Stack.

Grüße,

Chris

Edit: Der SIP Stack ist in der libqtopiaphone eingebaut.

Bzgl. Kernel/Hardware:

Also, so wie es aussieht ist der Großteil der Sachen sehr stark an das
ADS (Application Development System) von Freescale angelehnt.
Dementsprechend kann man dort vermutlich auch einiges an Erkenntnissen
gewinnen, wenn man einen neuen Kernel bauen möchte.

So ist z.B. das LCD ja über den LCDC des Prozessors angeschlossen. Die
Kamera scheint ebenfalls über das dafür vorgesehene Interface zu laufen.
Der Audio-Codec geht über I2C. Der TV Encoder ist ebenfalls genauso wie
auf dem ADS Board.

Was wirklich Haarig werden könnte sind die Treiber für die WLAN Sachen,
besonders beim 6500. Keine Ahnung ob man da einen 2.6er Kernel mit ans
laufen bekommt. Allerdings habe ich da auch nicht wirklich weiter
nachgesehen. Zumindest im 5500 scheint das WLAN Modul über den regulären
PCCard/PCMCIA Bus des Prozessors angebunden zu sein. Das entsprechende
Kernel-Modul für den Bus ist ja auch geladen.

Beim Audio-Codec mache ich langsam Fortschritte. Die wichtigsten
Register kann ich schon mal Lesen und Schreiben. Allerdings scheinen ein
paar Dinge nicht oder anders implementiert zu sein als wie im aic Test
Program. So kann man über das Programm ja angeblich die Codec-Register
einzeln auslesen. Das funktioniert aber nicht. Anstelle dessen habe ich
durch experimentieren einen anderen IOCTL Call gefunden, der alle
Register auf einmal in ein Array aus 10 u_int32_t lesen kann. Nur das
passende Gegenstück zum schreiben habe ich noch nicht entdecken können.
Vielleicht gibt es das ja auch garnicht.

Wie auch immer, da die Doku zu dem Codec ja vorhanden ist sollte es
theoretisch möglich sein auch gleich einen neuen Treiber dafür zu
schreiben, wenn nötig. Wie die Audio-Seite angebunden ist habe ich noch
nicht geschaut, das werde ich Morgen oder Übermorgen mal angehen. Würde
mich nicht wundern wenn auch das über die dafür vorgesehenen Teile des
Prozessors läuft.

Alles in allem bin ich sehr zuversichtlich das man, zumindest mit dem
2.4er Kernel und den Treibern auf dem Telefon, da was eigenes machen
kann. Es gibt ja einige SIP/VoiP Stacks als OpenSource, auch als
Kommadozeilen-Versionen. Soetwas ist Ideal als Basis, da klein und ohne
GUI. Die kann man sich dann selber dazubauen.

Der MP4 Encoder/Decoder (Hantro) ist ja im Freescale BSP soweit
vorhanden. Das ist ja zum Teil Hardware-Unterstützt, somit sollte auch
der Video-Link relativ Probelmlos und Performant zu realisieren sein.

Es muss ja auch nicht Qtopia bzw. QT Extended sein. Das
Framebuffer-Interface ist ja wirklich einfach. /dev/fbX öffnen, per mmap
auf einen lokalen Pointer mappen, und auf dem dann die ganzen Pixel
schreib-/lese Aktionen ausführen. Da kann man sich auch schnell was
eigenes Basteln.

Bzgl. des 5500: Es wäre natürlich schön wenn z.B. der Tino mal ausmessen
könnte ob wirklich alle PCCard/PCMCIA Signale der CPU auf dem Sockel für
den WLAN Adapter liegen. Wenn ja würde das ja auch ganz neue
Möglichkeiten zum Hacken eröffnen. So könnte man dann nämlich auch
andere Karten anstecken, z.b. für USB, Festplatten, etc. Auch der cfio
Treiber ist geladen (CompactFlash I/O).

Beim 6500 wäre auch mal Interresant zu wissen was von den ganzen Pins
des WLAN Chips auf welche Pins an der CPU gehen. Auf dem Bild
http://www.mikrocontroller.net/attachment/74205/V6... sind ja
doch einige Pads zu sehen. Was natürlich extrem viele wären, wenn der
Chip angeblich nur über SPI angeschlossen ist. Vielleicht liegt ja auch
dort mehr an, nur das es (aus Zeitmangel, Treiberproblemen, was auch
immer) letztendlich dann nicht genutzt wurde.

Schöne Grüße,

Chris

Hallo zusammen,
  ich habe mit ähnlichen Gedanlen gespielt und habe ein paar Infos
ergoogelt, welche evtl. helfen könnnen.

Christian Klippel schrieb:
> Bzgl. Kernel/Hardware:
>
> Also, so wie es aussieht ist der Großteil der Sachen sehr stark an das
> ADS (Application Development System) von Freescale angelehnt.
> Dementsprechend kann man dort vermutlich auch einiges an Erkenntnissen
> gewinnen, wenn man einen neuen Kernel bauen möchte.

Das hatte ich schon mal im anderen Thread gepostet:
"
Für die es interessiert ein neues System aufzusetzen:

Bei Freescale gibt es ein angepasstes uBoot und einen relativ aktuellen
2.6er Kernel.

http://opensource.freescale.com/git

Es gibt auch noch ein paar andere alternativen:

http://en.wikipedia.org/wiki/User:Sogliphy/i.MX21_Linux
"
>
> So ist z.B. das LCD ja über den LCDC des Prozessors angeschlossen. Die
> Kamera scheint ebenfalls über das dafür vorgesehene Interface zu laufen.
> Der Audio-Codec geht über I2C. Der TV Encoder ist ebenfalls genauso wie
> auf dem ADS Board.

Das der Audio-CODEC über I²C läuft ist nur die halbe Wahrheit. Die Daten
laufen über I²S oder SPI. Die Config über I²C.

>
> Was wirklich Haarig werden könnte sind die Treiber für die WLAN Sachen,
> besonders beim 6500. Keine Ahnung ob man da einen 2.6er Kernel mit ans
> laufen bekommt. Allerdings habe ich da auch nicht wirklich weiter
> nachgesehen. Zumindest im 5500 scheint das WLAN Modul über den regulären
> PCCard/PCMCIA Bus des Prozessors angebunden zu sein. Das entsprechende
> Kernel-Modul für den Bus ist ja auch geladen.

"
Info-Quellen zum WLan gibts hier:

http://avr32linux.org/twiki/bin/view/Main/WirelessNetworking
"

Angeblich wird der WLAN-Chip vom VP55 im 2.6er unterstützt.

Für den TV-Chip gibt es wohl einen Treiber im Montavista Linux. Leider
nicht OpenSource. Hier gibt es ein DIFF zum Code. Vielleicht kann das
helfen.

http://www.blackberry.com/support/blackberrypresen...

viele Grüße
   Maarten

Christian Klippel schrieb:
> So ist z.B. das LCD ja über den LCDC des Prozessors angeschlossen. Die
> Kamera scheint ebenfalls über das dafür vorgesehene Interface zu laufen.
> Der Audio-Codec geht über I2C. Der TV Encoder ist ebenfalls genauso wie
> auf dem ADS Board.

Nur der Vollständigkeit wegen:
Der Audio-Codec ist über I2C und I2S abgeschlossen. Dabei übernimmt I2C
die Steuerung (Umschaltung, Lautstärke...) und I2S liefert den
Audio-Datenstrom in beide Richtungen.
>
> Was wirklich Haarig werden könnte sind die Treiber für die WLAN Sachen,
> besonders beim 6500. Keine Ahnung ob man da einen 2.6er Kernel mit ans
> laufen bekommt. Allerdings habe ich da auch nicht wirklich weiter
> nachgesehen. Zumindest im 5500 scheint das WLAN Modul über den regulären
> PCCard/PCMCIA Bus des Prozessors angebunden zu sein. Das entsprechende
> Kernel-Modul für den Bus ist ja auch geladen.

Ich hatte ja ursprünglich vermutet, dass das WLAN beim 5500er mehr
Probleme bereitet. Da es aber vom Hörensagen her einen Linux Treiber für
den beim 5500er genutzten WLAN Chip gibt, hat der es vielleicht auch in
die neuen Linux Versionen geschafft. Was ich nicht verstehe ist die
Unnötige Geheimniskrämerei bei NXP über den 211er Chipsatz. Wenn man das
Datenblatt liest, ist einem schnell klar, dass das ganze geheime
LowLevel Interface, aus dem alle Hersteller so ein Geheimnis machen,
bereits auf dem Chipsatz integriert. Man muss ihm per SPI nur ein paar
Befehle schicken und daskomplete WLAN steht. Die Geheimhaltung ist also
vollends unbegründet und die Opensource-Gemeinde und auch die ganzen
AVR...ARM7 Bastler würden NXP das Ding aus den Regalen reißen, wenn...

Ich werde da also nächste Woche mal ein paar Telefonate führen müssen,
selbst wenn ich nix erreiche, ich will es verstehen.

Adererseits sollte es eher einfach sein, das Modul vom 6500er für die
Kommunikation mit dem 211er WLAN Chip mit geeigneten Mittel reverse zu
engineeren. Denn dort drinn kann nicht sehr viel stecken.

Gruß, Ulrich

Christian Klippel schrieb:
> Beim 6500 wäre auch mal Interresant zu wissen was von den ganzen Pins
> des WLAN Chips auf welche Pins an der CPU gehen. Auf dem Bild
> http://www.mikrocontroller.net/attachment/74205/V6... sind ja
> doch einige Pads zu sehen. Was natürlich extrem viele wären, wenn der
> Chip angeblich nur über SPI angeschlossen ist. Vielleicht liegt ja auch
> dort mehr an, nur das es (aus Zeitmangel, Treiberproblemen, was auch
> immer) letztendlich dann nicht genutzt wurde.

So wie ich das sehe ist nur der Außenkranz teilweise mit aktiven
Signalen belegt. Viele der Pinne sind Vcc und GND, auch ein JTAG ist
darüber geführt. Die vier Padflächen sind alle GND, wohl für eine gute
Antennen-Masse, EVM und Wärmeableitung.

Ulrich P. schrieb:
> Nur der Vollständigkeit wegen:
> Der Audio-Codec ist über I2C und I2S abgeschlossen. Dabei übernimmt I2C
> die Steuerung (Umschaltung, Lautstärke...) und I2S liefert den
> Audio-Datenstrom in beide Richtungen.

Ja, das habe ich in der Eile übersehen.

Bin mit den ioctl's des aic14.o und des aud.o fast fertig. Zumindest
soweit das man das meiste bereits benutzen kann. aud.o implementiert zum
Glück gängige OSS ioctl's, leider aber auch ein paar eigene.

Naja, zumindest die Register des aic14 konfigurieren geht schon mal,
ebenso das Abspielen von Sounds mit 8khz sowie 16khz Samplerate. Für
16khz muss man vor dem öffnen des /dev/dsp1 erstmal einen ioctl auf dem
/dev/aic14 machen (0x4004703E), damit er umschaltet. Sobald man das dsp1
schliesst, schaltet er automatisch auf 8khz zurück.

Lautstärke einstellen geht, Amp ein/aus ebenfalls, etc. Eigentlich
soweit alles was man braucht. Ich schau mal ob ich Morgen meinen
Testcode ein wenig aufgehübscht bekomme um ihn hier Hochzuladen.
Ansonsten halt Montag oder Dienstag.

Grüße,

Chris

Ulrich P. schrieb:
> Adererseits sollte es eher einfach sein, das Modul vom 6500er für die
> Kommunikation mit dem 211er WLAN Chip mit geeigneten Mittel reverse zu
> engineeren. Denn dort drinn kann nicht sehr viel stecken.

-r--r--r--    1 301      504        632836 Feb 28  2007 ga_linuxdrv.o

Satte 600 KB. Ich befürchte das dort mehr drinsteckt als einem Lieb sein
kann. Immer diese dämlichen, riesigen Binär-Blobs in den Treibern. Zum
Heulen.... Von 0x00013434 bis 0x0004AD24 ein Block, und dann weiter bis
0x0007E1BC der zweite Block gleich hinten dran, also insgesamt 437640
bytes. Beide in der Funktion "PhgHhalResetAndBootLoad" benutzt.

Und auch sonst gibt es sehr viele Funktionen in dem Treiber. Das wird
sicher ein Spaß werden.

Man könnte natürlich hergehen und über eine Firma dort die Informationen
anfragen, vermutlich nach Unterzeichnung eines NDA....

Grüße,

Chris

Tom schrieb:
> Wir wollen ja nicht den WLAN-Chip
> hacken. Der Rest des Codes wäre also der interessante Teil, nämlich die
> tatsächliche Schnittstelle. Der Name der Funktion deutet darauf hin, daß
> sie eine Art Bootloader für den WLAN-Chip ist.
>
>
> Andererseits blieben dann knapp 200k an relevantem Code, was auch kein
> Zuckerschlecken ist. :-/

Ja, schon klar. Ich bezog mich damit eher auf Ulrich's Aussage das in
dem Treiber ja nicht viel drin stecken könne. Wie das halt oft so ist
bei solch komplexen Chips. Die dürftigen Datenblätter jubeln immer wie
Leicht und Einfach doch alles damit geht, die Realität ist dann meistens
eine andere - leider.

Die Firmware und Treiber scheinen auch einige Probleme zu haben. So gibt
es z.B. die Funktionen "Leak_Malloc", "Leak_Free" und "Leak_Dump", wo
dann so Strings wie "No memory allocated / no leaks found" drinstehen.
Anstatt sauber die malloc's und free's zu benutzen implementiert man
also eigene die der Schlamperei dann hinterherräumen.

Auch Lustig sind Funktionen wie "PhgHhalCheckForHang",
"PhgHhalNotifyMacHang" und "HhalPlatformCheckForHang" etc. Klingt sehr
nach Rumgewürge um zu kaschieren das sich der Chip wohl gerne mal
verabschiedet.

Kein Wunder also das sie da ungern die Quellcodes rausgeben wollen ;-D

Aber mal Ernsthaft: Bei WLAN Sachen gibt es selten offene Quelltexte.
Diese Chips sind ja Universell einsetzbar. D.h. man kann
Frequenzbereiche und Sendeleistungen einstellen. Das hat natürlich zur
Folge das man Dinge auswählen könnte die im jeweiligen Land nicht Legal
sind. Das wollen sie wohl verhindern. Was ich allerdings als Gängelei
empfinde. Zumal man den Treibern ja auch ein anderes Land vorgaukeln
kann, woraufhin sie sich dann entsprechend anders verhalten.

Achja, insgesamt 260 exportierte Funktionen in dem Treiber. Dazu kommt
dann wohl noch die eine oder andere Funktion die nicht exportiert wird,
da als static deklariert im Code. Das zu zerlegen würde sicher ein
Riesenaufwand sein. Aber vielleicht hat ja jemand Lust dazu.

Grüße,

Chris

Onno schrieb:

...

> Danke, danke! Ich werde dann auch den openvpn-Build hier posten (bzw.
> Link), wenn es gewünscht ist.

Ist gewünscht.
Wie weit bist Du? Brauchst Du Unterstützung?

Abhörsicher telefonieren hätte etwas :-)

Falk

Christian Klippel schrieb:
> -r--r--r--    1 301      504        632836 Feb 28  2007 ga_linuxdrv.o
>
> Satte 600 KB. Ich befürchte das dort mehr drinsteckt als einem Lieb sein
> kann. Immer diese dämlichen, riesigen Binär-Blobs in den Treibern. Zum
> Heulen.... Von 0x00013434 bis 0x0004AD24 ein Block, und dann weiter bis
> 0x0007E1BC der zweite Block gleich hinten dran, also insgesamt 437640
> bytes. Beide in der Funktion "PhgHhalResetAndBootLoad" benutzt.

Auf dem 21er steckt noch ein LPC-like ARM7, der das ganze Protkoll
selbst abfrühstückt, das normalerweise der Treiber macht. Ich rate mal,
dass es aus Produktionssicht günstiger ist, solch einem Modul die
aktuelle Software aus dem eigentlichen Produkt zu übergeben, als einen
weiteren In-Production JTAG Prozess vorzuhalten. Das hat einen Vor- und
einen Nachteil für uns.
Nachteil: Die Blobs müssen vermutlich sauberst übernommen werden, wenn
man einen eigenen Treiber schreibt.
Vorteil: Die Probleme mit neuen Basisstationen, wie der FB72xx, können
vermutlich nur durch ein Bugfix in eben diesen Blobs korrigiert werden
und ich denke, dass es einfacher ist solch einen Blob irgendwoher zu
bekommen, als ein Image, das man über ein nicht dokumentiertes JTAG auf
solch ein Modul laden muss.

Christian Klippel schrieb:
> Die Firmware und Treiber scheinen auch einige Probleme zu haben. So gibt
> es z.B. die Funktionen "Leak_Malloc", "Leak_Free" und "Leak_Dump", wo
> dann so Strings wie "No memory allocated / no leaks found" drinstehen.
> Anstatt sauber die malloc's und free's zu benutzen implementiert man
> also eigene die der Schlamperei dann hinterherräumen.

Hmm.... Das kenne ich doch, ist aber nur geraten, da ich hier imUrlaub
weder IDA, noch die Objects der VP habe :)

Es gibt einige Implementationen von Schichten-Basierten Treibern, die
ein eigenartiges System verfolgen, um ein versandfertiges Paket zu
produzieren.
Sie allozieren den Speicher in der reihenfolge, wie er benötigt wird.

Also zuerst gibt es ein my_malloc( netto_daten), dann ein
my_malloc_before( netto_daten, netw_layer), dann ein my_malloc_before(
netw_layer, llc_layer)...

Es wird also ein Paket im RAM reserviert, dass anschließend von vorne
erweitert wird. Das alles nur, um hinterher mit einem einzigen memcpy
das komplette Paket an den Tranceiver senden zu können.

Persönlich halte ich das für schön lesbar und verständlich, aus sicht
eines kleinen Systems aufgrund wilder memcpy Vorgänge aber für vollends
schwachsinnig. Ich nutze für Layer-basierte Systeme ein Pointer-Array,
welches ich zuerst alloziere und das aus Pointern zu den verschiedenen
Layer-spezifischen Structen besteht.
Das Pointer-Struct wird so, wie die Datenfelder bekannt werden
mitgültigen Zeigern aufgefült. Beim Senden gibt es dann einen memcpy pro
Layer. Das klingt komplizierter, ist aber vermutlich um Faktoren pro
Layer schneller, da man weder auf ausreichend leere Puffer vor einem
Layer-Puffer achten muss, noch, wenn das nicht der Fall ist, schwere
Umkopier-Aktionen starten muss.

Christian Klippel schrieb:
> Aber mal Ernsthaft: Bei WLAN Sachen gibt es selten offene Quelltexte.
> Diese Chips sind ja Universell einsetzbar. D.h. man kann
> Frequenzbereiche und Sendeleistungen einstellen. Das hat natürlich zur
> Folge das man Dinge auswählen könnte die im jeweiligen Land nicht Legal
> sind. Das wollen sie wohl verhindern. Was ich allerdings als Gängelei
> empfinde. Zumal man den Treibern ja auch ein anderes Land vorgaukeln
> kann, woraufhin sie sich dann entsprechend anders verhalten.

Es ist aber reich rechtlich Sache des Geräteanbieters die Einhaltung der
Landesspezifischen Funk-Standards zu garantieren, nicht die des Chip- /
Modulherstellers. Der Chiphersteller kann allemal Application-Notes
beisteuern, die eine erfolgreiche Zulassung unterstützen.
>
> Achja, insgesamt 260 exportierte Funktionen in dem Treiber. Dazu kommt
> dann wohl noch die eine oder andere Funktion die nicht exportiert wird,
> da als static deklariert im Code. Das zu zerlegen würde sicher ein
> Riesenaufwand sein. Aber vielleicht hat ja jemand Lust dazu.

Stellt sich mir die Frage, welche der Funktionen tatsächlich verwendet
werden, was man doch auch herausfinden können müsste. Ich habe aber,
zugegeben, noch nie größere Systeme durch den IDA gejagt. Bislang habe
ich das nur für AVR, ARM7 und einige kleine Prozessoren aus OnBoard
Radio/Navis geraucht um z.B. eine Lenkradfernbedienung nachrüsten zu
können.

Stelemich da gerne mal zur Verfügung, wenn ich Fragen dazu vielleicht an
diesem Thread vorbei per eMail an Wissende senden darf?

Hmmm, leider ist NXP nicht mehr Philips. In meiner Zeit bei Philips habe
ich einige NDAs unterschrieben, so dass es vielleicht eine Chance
gegeben hätte an die Specs vom 211er heran zu kommen. Es würde ja allen
reichen, wenn einer einen aktuellen laufenden Treiber zur Verfügung
stellt.

Tom schrieb:
> Ein gutes Beispiel für ein erfolgreiches Reverse-Engineering in diesem
> Bereich ist der b43-Treiber für bestimmte Broadcom-Chips.

Also gerade bei Broadcom kann ich mich nicht beschweren. Die haben mir
als Privatperson gegen NDA einen Zugang ins eigene Developer-Netz
angeboten. Ich bin letztendlich nicht darauf eingegangen, weil die Chips
eben wegen SoftMAC zu viel Last auf dem ARM7 verursachen würden.
Beim 211er sieht as ganze ganz anders aus, das Teil wäre für alle, die
einen AVR oder einen ARM7 ans WLAN bringen wollen echt ideal. Fast wie
das BTM222 Modul für Bluetooth.

Bzgl. der zwei Blobs...
Das Datasheet zu dem BGW211 sagt, dass es einen ARM7 und einen RISC
basierten DFC (Data-Flow-Controller) gibt. Vieleicht ist der große Blob
für den ARM, der kleine für den DFC?

Es müsste eigentlich ein recht aktueller Treiberfür den BGW211
exitieren, jedenfalls scheint es für die QBox einen für einen Kernel
2.6.17 zu geben:
http://www.sat-universe.com/archive/index.php/t-124235.html
Kann hier jetzt aber kein Kernelarchiv herunter laden, das spare ich mir
dann für nächste Woche auf :)

Ulrich P. schrieb:
> Beim 211er sieht as ganze ganz anders aus, das Teil wäre für alle, die
> einen AVR oder einen ARM7 ans WLAN bringen wollen echt ideal. Fast wie
> das BTM222 Modul für Bluetooth.

Müsste dann aber schon einer der größeren AVR's sein, oder zumindest mit
passendem Interface zu externem Speicher. Das dann auch noch möglichst
schnell. Wenn da 400 KB Blob's zum Chip gehen müssen, dann wollen die ja
auch irgendwo gespeichert und übertragen werden.

Wie dem auch sei, ich mache mal an dem Audiokram weiter.

Grüße,

Chris

Hallo,

ich habe einen kleinen Daemon geschrieben der alle 10 Sekunden den
Wachhund kitzelt ;)

Es wird ja ein watchdog.o Kernelmodul geladen. Wenn man nun Qtopia
abschaltet wird selbiger nicht mehr aktualisiert. Das hat zur Folge das
sich das Gerät ständig neu startet. Dieser Daemon beseitigt das Problem.

Zusätzlich sollte man noch die Dateien /sbin/reboot und /sbin/shutdown
umbenennen, z.B. in *.old. Irgendein Prozess ruft die nämlich auf wenn
Qtopia nicht läuft, hab aber noch nicht geschaut welcher das ist. Evtl.
reicht es ja den ticklewdt in qpe umzubenennen (Start-Script
entsprechend anbassen!) damit der Prozess ausgetrickst werden kann.

Apropos qpe: In der Datei /usr/local/startup/daemon.sh in Zeile 146
steht ein "$CMD &". Das startet das qpe (Qtopia). Wenn man das
auskommentiert startet es dann nicht mehr. Ich brauche das derzeit so um
mit den Sound-Devices ordentlich spielen zu können. Das Playback-Device
für den Codec ist zwar auch so ansprechbar (solange qpe nicht drauf
zugreift), aber das Aufnahme-Device eben nicht. So kann man
sicherstellen das außer dem eigentlich System nichts anderes auf die
Devices zugreift.

Für die Detailverliebten: Man öffne /dev/watchdog und schicke ein ioctl
0x80045705 ohne weitere Parameter dort hin um den Hund zu kitzeln. Das
muss natürlich periodisch passieren.

Grüße,

Chris

Tom schrieb:
> Einge Gruppe "reverse-engeneered" den
> Ursprungstreiber (meines Wissens damals den Binary-Blob vom WRT54G) und
> dokumentiert die Register, Zugriffsmuster, usw. Eine zweite Gruppe
> programmiert anhand dieser Doku den offenen Treiber. So geht man
> rechtlichen Problemen (Copyright) sowie NDAs aus dem Weg.
>
> Naja, in unserem Fall fürchte ich, dass die "User-Base" einfach zu klein
> ist. :-/

Hmmm... Also zwei sind doch genug dafür? Da ist einer, der sich mit IDA
und reverse Engineering auskennt und ich sehe mich durchaus in der Lage
einen Network-Stack zu schreiben. Aber vielleicht hilft ja auch noch
einer oder zwei :)

Christian Klippel schrieb:
> Müsste dann aber schon einer der größeren AVR's sein, oder zumindest mit
> passendem Interface zu externem Speicher.

Das ist so nicht notwendig. Wenn man die Blobs in einen externen
SPI-Flash ala AT45Dxx auslagert ist das kein Problem, denn die müssen ja
nur ein einziges mal geladen werden. Ein AVR kann solch einen Speicher
mit einigen MBit ansprechen, ein AT91SAM7X schiebt bei mir hier ein
Funkmodul mit 24MHz mit Daten voll. Ist also Problemlos machbar.

Ich gehe auch davon aus, dass von den vielen zur Verfügung gestellten
Funktionen nur wenige benötigt werden, wenn die Reklame von NXP auch nur
ein wenig zutrifft.

Hello,

since a few days i'm looking into the audio stuff of the phone. I got it
partially working, however, i'm not satisfied at all. The whole setup is
a bit awkward. There are three drivers involved:

i2c-aic14.o
aic14.0
aud.o

Also, there are six device nodes used:

/dev/cod
/dev/aud0
/dev/dsp0
/dev/aud1
/dev/dsp1
/dev/mixer1

The cod device seems to be the raw audio interface to the codec chip.
aud0 is the "network" recording device, dsp0 the "network" playback
device. aud1 and dsp1 are for the "player", again aud is for recording
and dsp for playback. mixer1 is a rudimentary mixer that only has two
controls: "Vol" and "Spkr".

However, and this is where the fun starts: If qpe is running, i can
write to /dev/dsp1 and hear the sound on the speaker. aud1 is blocked
because it is opened by qpe. Sending data to dsp0 gives no output, i
guess that is used internally by the voip stack. Also, aud0 is opened.
The cod device is also in use and can not be opened.

If qpe is not running, i can write to cod and hear the sound. However,
the aud and dsp devices are non-funct. The reason is that dma buffers
are created upon request. These have to be handled somehow, and i guess
that is what also happens through qpe, or better, qss (the sound
server). Opening aud0 and aud1 cretes dma buffers for the audio devices,
which can be seen by "cat /proc/aud". However, no (dma) buffers are
created for the aic14, as can bee seen by "cat /proc/aic14". With some
weird combination of my code and the aic14_conf program, some buffers
are created. However, still no playback through the dsp devices.

I think the best way would be to re-implement the drivers, using the
dbmx sound drivers as a base (they are available as source in the
Freescale BSP for the iMX.21). The only other choice would be to dig
deep into the Qtopia binaries and attempt to find out what's going on.
My guess is that a clean reimplementation would be the faster way. This
would also allow to implement a simple audio mixing routine to allow
multiple opens on the dsp device for playback. The final transfer itself
of the audio data is done through the SSI peripherial of the iMX,
together with dma buffering.

So, if anyone is interrested, i can upload some example code using the
/dev/dsp1 device for playback. However, it is pretty pointless that way,
since that would only run if qpe is running as well, and no recording of
sound is possible anyways.

Greetings,

Chris

Ulrich P. schrieb:
> Hmmm... Also zwei sind doch genug dafür? Da ist einer, der sich mit IDA
> und reverse Engineering auskennt und ich sehe mich durchaus in der Lage
> einen Network-Stack zu schreiben. Aber vielleicht hilft ja auch noch
> einer oder zwei :)

Kommt halt drauf an wie lange man warten will. Mit nur zwei Leuten wird
das lange dauern. Zumal diese Leute ja noch Arbeiten müssen und auch
ansonsten noch ein Leben ausserhalb des Telefon-Hackens haben ;)

Grüße,

Chris

Ulrich P. schrieb:
> Christian Klippel schrieb:
>> Müsste dann aber schon einer der größeren AVR's sein, oder zumindest mit
>> passendem Interface zu externem Speicher.
>
> Das ist so nicht notwendig. Wenn man die Blobs in einen externen
> SPI-Flash ala AT45Dxx auslagert ist das kein Problem, denn die müssen ja
> nur ein einziges mal geladen werden. Ein AVR kann solch einen Speicher
> mit einigen MBit ansprechen, ein AT91SAM7X schiebt bei mir hier ein
> Funkmodul mit 24MHz mit Daten voll. Ist also Problemlos machbar.
>
> Ich gehe auch davon aus, dass von den vielen zur Verfügung gestellten
> Funktionen nur wenige benötigt werden, wenn die Reklame von NXP auch nur
> ein wenig zutrifft.

Ja, das meinte ich ja, externen Speicher dann halt.

Wieviele von den Funktionen nun letztendlich auch genutzt werden kann
ich natürlich nicht sagen. Nur das es viele sind... Viele sind aber
recht klein.

Grüße,

Chris

SD-Fritze schrieb:
> Hey *,
>
> i still wait for my VP, so I couldnt try.
>
> Does
> dd if=/dev/sensor of=/dev/fb? //? for the tv fb
> work?
>
> Greets,
>   SD-Fritze

Hello,

no. it's not that simple. The camera is connected using the CSI
interface, and the image data is pre-processed through the PRP part of
the iMX. However, it can be set-up so that the PRP writes it's output to
the same memory region that the fb device uses.

See these two messages for the code:
Beitrag "Using the camera"
Beitrag "camtest binaries"

You could change the code so that it uses a malloc'd memory region
instead of the fb, so that you can actually capture images and save them
elsewhere.

Greetings,

Chris

Habe mir die ga_linuxdrv.o mal in den IDA geladen. Sieht schon recht
wild aus...

Schaue mir mal die Tage noch weitere Treiber als Referenz an. Irgendwas
muss doch dabei sein, das bei dem Kernel Standard war.

Ok, Licht kommt ins Dunkle...

NXP hat seine RF-Sparte in eine Kooperation mit ST geschickt, die
ihrerseits das ganze wieder in Kooperation mit Ericsson machen. Das
ganze ist letztes Jahr passiert. Daher ist von dem an sich genialen Chip
nix mehr zu hören.

Bei ST tauchen nun zwei ähnliche Modelle auf:
http://www.stericsson.com/sales_marketing_resource...
http://www.stericsson.com/sales_marketing_resource...
kommt den Daten des BGW211 ziemlich nahe, es gibt auch einen großen
Bruder:
http://www.stericsson.com/sales_marketing_resource...

Ich fürchte, es wird bei NXP also kaum noch etwas zu holen geben.

Ulrich P. schrieb:
> Ich fürchte, es wird bei NXP also kaum noch etwas zu holen geben.

Was man noch versuchen könnte: Wenn man mal nach dem Chip und Linux
googelt finden sich doch einige Seiten. Es nutzen wohl auch einige
andere Geräte diesen Chip. Man sieht dann oft irgendwelche Updates für
irgendwelche Dinger mit Linux 2.6.x. Nun müsste man noch ein Gerät
finden das ebenfalls einen ARM9 benutzt und dann probieren ob man den
Treiber aus dem Update zusammen mit einem 2.6er Kern für das Telefon ans
laufen bringen kann.

Behebt zwar natürlich nicht das Quellcode-Problem, aber man könnte so
mit etwas Glück einen Treiber für 2.6er Kernel bekommen.

Wobei sich natürlich immer noch die Frage stellt, zumindest mir, warum
man überhaupt einen 2.6er auf dem Telefon haben will. Das Gerät hat ja
nun doch recht limitierte Resourcen, und wird sich Hardwaremäßig wohl,
anders als normale PC's die man ab und an mal erweitert, auch nicht
ändern.

Grüße,

Chris

Christian Klippel schrieb:
> Wobei sich natürlich immer noch die Frage stellt, zumindest mir, warum
> man überhaupt einen 2.6er auf dem Telefon haben will. Das Gerät hat ja
> nun doch recht limitierte Resourcen, und wird sich Hardwaremäßig wohl,
> anders als normale PC's die man ab und an mal erweitert, auch nicht
> ändern.

Die Diskussion kenn ich von OpenWRT. Für mein Teil bin ich bei embedded
Linux zufrieden mit dem 2.4er - die Verwendbarkeit der nur als Binary
vorliegenden Treiber ist mir wichtig.

Devfs und ungeschränkten hotplug-Fähigkeiten sind kein Problem (die
VPx500 haben derzeit je nicht mal USB). An der Leistungsaufnahme des
Geräts ist nichts auszusetzen und viel besser wird diese durch einen
"tickless kernel" wahrscheinlich auch nicht.

Schließlich wird der 2.4er auch heute noch gepflegt (die aktuelle
Version 2.4.37.7 ist von November 2009
http://marc.info/?l=linux-kernel&m=125761436627901). Es könnte sich
lohnen die eine oder andere "relevante" Korrektur in den 2.4.20
einzupflegen.

Grüße
/G

> http://marc.info/?l=linux-kernel&m=125761436627901). Es könnte sich
> lohnen die eine oder andere "relevante" Korrektur in den 2.4.20
> einzupflegen.

Ein paar Suchen mit grep über die ChangeLogs des Kernels ab 2.4.21
zeigen schon ein paar wichtige Korrekturen. Die meisten Änderungen sind
für unser Gerätchen natürlich uninteressant.

Ich nehme an, dass dem einen oder anderen bereits der folgende "Zombie"

9 root      35  10     0    0     0 Z N   0.0  0.0   0:01 jffs2_gcd_mtd2 <defunct>

aufgefallen ist. Hier ist etwas über die Ursache zu lesen:
http://mhonarc.axis.se/jffs-dev/msg01647.html. Offensichtlich passiert
das nur, wenn eine JFFS-Root-Partition verwendet wird (und das ist wohl
ziemlich ungewöhnlich).

Gruß
/G

Gert D. schrieb:
> Die Diskussion kenn ich von OpenWRT. Für mein Teil bin ich bei embedded
> Linux zufrieden mit dem 2.4er - die Verwendbarkeit der nur als Binary
> vorliegenden Treiber ist mir wichtig.

Ja, das ist auch ein Grund. Allerdings werde ich mich dransetzen und
nach und nach die meisten Treiber reimplementieren, eben damit Quellen
dafür vorhanden sind. Wenn alles so läuft wie ich mir das vorstelle
bleibt am Ende nur noch der WLAN Treiber als Binary übrig.

Das meiste sollte auch kein sonderlich großes Problem sein. Die Basis
ist ja im BSP als Quellcode vorhanden. In den jetzigen Treibern auf dem
Telefon steckt einfach zuviel Mist drin. Beispiel kpp.o, der für die
Tasten zuständig ist. Der Großteil des Treibers besteht aus Routinen zum
abfangen einer speziellen Sequenz, und daraufhin das Handling von
Produkt-Tests, ausgeben von diversen Systemdateien, etc. Das muss ja da
alles nicht rein.

>
> Devfs und ungeschränkten hotplug-Fähigkeiten sind kein Problem (die
> VPx500 haben derzeit je nicht mal USB). An der Leistungsaufnahme des
> Geräts ist nichts auszusetzen und viel besser wird diese durch einen
> "tickless kernel" wahrscheinlich auch nicht.

Vermutlich nicht. Man muss halt abwägen ob der Aufwand den
letztendlichen Mehrnutzen Wert ist. Ich vermute mal eher nicht.

Das soll aber natürlich niemanden davon abhalten einen 2.6er für das
Gerät zu bauen ;) Jeder so wie er es mag....

>
> Schließlich wird der 2.4er auch heute noch gepflegt (die aktuelle
> Version 2.4.37.7 ist von November 2009
> http://marc.info/?l=linux-kernel&m=125761436627901). Es könnte sich
> lohnen die eine oder andere "relevante" Korrektur in den 2.4.20
> einzupflegen.

Ah, Interresanter Fund!

>
> Grüße
> /G

Grüße,

Chris

Edit: Ups, mit dem Fund meinte ich natürlich die Nachricht bzgl. des
JFFS2.

Hi All,

I received the dvd from Chris and uploaded it to:
https://vpx500.nederlandlive.nl/ (http://vp6500.bd8.nl is also redirect
to this new place now). Maybe Chris can explain what the contents of
each file exactly are (haven't tryed it out myself yet). If anyone wants
to mirror go ahead, it's always good to have two versions online!

Cheers,
Joost

Hallo zusammen!

es gäbe schon einige gute Gründe auf 2.6.x zu wechseln. Als Beispiel sei
hier IPv6 angeführt, an dem langfristig sicher nichts vorbei geht.

Ansonsten kann ich nur sagen das hier verdammt gute Arbeit abgeliefert
wird. Da könnte sich mancher Hersteller eine Scheibe von abschneiden :)

Sind inzwischen eigentlich neue Erkenntnisse zum WLAN Problem zwischen
FritzBox 72xx 75xx und VP6500 zu verzeichnen? Ich hörte das es ein
Fehler in der FritzBox sein könnte.

Gruß Marcel

Christian Klippel schrieb:
> Wobei sich natürlich immer noch die Frage stellt, zumindest mir, warum
> man überhaupt einen 2.6er auf dem Telefon haben will. Das Gerät hat ja
> nun doch recht limitierte Resourcen, und wird sich Hardwaremäßig wohl,
> anders als normale PC's die man ab und an mal erweitert, auch nicht
> ändern.

Naja, der Kernel 2.6.x ist nicht dicker als der 2.4.x sondern anders und
an einigen Stellen sogar schlanker / schneller.

Abgesehen davon ist der Weg alles mit altem Kram zurecht zu prepeln aus
der Not heraus sicherlich richtig. Aber die Option mit neuen Tools mehr
zu machen ist verlockend.

Und das WLAN hat nun einmal Probleme:
- WMM wird benötigt, damit man garantiert die Sprachverbindung halten
kann, funktioniert aber nicht mit neuen Basen ala FB72xx
- Multiple SSIDs laufen nicht, d.h. das Telefon kann sich zwischen
verschiedenen Basistationen nicht umbuchen.

Also wäre ein Quellcode für den BGW211 sehr nützlich. Ob man den jetzt
für den Kernel 2.4.x repariert oder für die Aufrüstung auf 2.6.x nutzt,
ist letztendlich egal :)

Marcel F. schrieb:
> Sind inzwischen eigentlich neue Erkenntnisse zum WLAN Problem zwischen
> FritzBox 72xx 75xx und VP6500 zu verzeichnen? Ich hörte das es ein
> Fehler in der FritzBox sein könnte.

Da wiederum könnte es helfen, den debug im BGW Treiber zu aktivieren, es
sind einige Strings enthalten, die auf diese Fähigkeit hin deuten, aber
ich habe noch nicht heraus gefunden, wie man das aktiviert :)

@All:
Does anyone know how to 'usually' enable debug output in linux drivers?

The BGW211 disassembly shows some informational strings in the code
which I'd like to activate for testing.

Hello,

Joost R. schrieb:
> Hi All,
>
> I received the dvd from Chris and uploaded it to:
> https://vpx500.nederlandlive.nl/ (http://vp6500.bd8.nl is also redirect
> to this new place now). Maybe Chris can explain what the contents of
> each file exactly are (haven't tryed it out myself yet). If anyone wants
> to mirror go ahead, it's always good to have two versions online!
>
> Cheers,
> Joost

ahh, thats good news indeed!

As for the files, i placed the original BSP from Freescale as well as
the QTopia Greenphone SDK on there as well, just for convenience.

"PhoneDevelop.tgz" is the actual VM. It is about 2GB in size, and you
need about 6GB or so to unpack it. It has a Kubuntu 8.04LTS base
install, with a few extra programs added. It also has german and english
language support, the default for KDE is set to german. More details
about it below.

The file "imx21ads_20070612-ltib-rel7.2-rc2.iso" is the original Linux
BSP from Freescale. This is what is installed on top of the Linux VM.

Then there is "qtopia-greenphone-sdk-4.3.2.iso". It is the full SDK for
the Greenphone. It uses QTopia, and a full version of that. This means
that things like QTopiaPhone are also there, including sources. This
should give a nice starting point to replace the software on the phone
at some later date in the future.

About the Kubuntu VM. It uses VMWare. Simply download and install the
VMWare Player, open the VM file there and start it. The username is
vpx500, the password is the same. Once started and logged in you end up
on the desktop. The "Konsole" icon at the upper left opens a shell
window that directly drops you into the VPx500/code subdirectory in the
home directory. You will find the helloworld example there.

Tip: there is mc installed, a norton-commander like thing to navigate
easily on the shell.

As editor you can use kate, which is a nice program including
syntax-highlighting, a shell-window, etc. Press Alt+F2, enter "kate" and
hit return. You can also reach it through the normal K menu at the
bottom left.

The BSP base is placed under BSP/ltib-imx21ads-20070609 in the home
directory. If you want to change stuff there, like compiling a kernel
etc., use ./ltib <options> from within that directory. You can get the
available options by using "./ltib --help". The actual installation of
the BSP is in the /opt directory. In the "mtwk" subdirectory there is
the actual toolchain. The helloworld example is already adjusted to that
directory, so you can use that as a template.

Hint: the linux console and console-windows have an tab-completion
feature. For example, if you enter "cd ~/BSP/lt" and then hit the TAB
key, it auto-completes that into "cd
/home/vpx500/BSP/ltib-imx21ads-20070609/"

Note that ~ is the short form for your home directory.

So, that's it for now. Any questions about linux in general should
please go to the propper forums/wikis/whatever, as that would be beyond
the scope of this thread. Linux and Kubuntu is well documented
elsewhere. Note that Kubuntu is basically the same as Ubuntu, just with
KDE instead of the Gnome Desktop. So if you search for something, look
for Ubunto as well.

Greetings,

Chris

Marcel F. schrieb:
> es gäbe schon einige gute Gründe auf 2.6.x zu wechseln. Als Beispiel sei
> hier IPv6 angeführt, an dem langfristig sicher nichts vorbei geht.

Das mag sein. Nur ist die Frage zum einen: lebt das Telefon solange? Zum
anderen: Wann kommt es denn nun, dieses IPv6? Immer wird gejammert das
der Adressraum ausgeht, und nun endlich v6 kommt. Seit Jahren. Aber
wirklich was passieren tut da bisher nicht so recht.

Zudem: Selbst wenn das ganze iNet nun v6 spricht, im Heimnetz wird man
sicher weiter v4 nutzen können, der Router erledigt das dann schon...

Grüße,

Chris

Ulrich P. schrieb:
> Naja, der Kernel 2.6.x ist nicht dicker als der 2.4.x sondern anders und
> an einigen Stellen sogar schlanker / schneller.
>
> Abgesehen davon ist der Weg alles mit altem Kram zurecht zu prepeln aus
> der Not heraus sicherlich richtig. Aber die Option mit neuen Tools mehr
> zu machen ist verlockend.

Ich meinte damit jetzt nicht das der Kernel größer wäre. Sondern eher
die Tatsache das das Telefon halt kaum erweiterbar ist, und so vieles
von dem was es an neuen Sachen im 2.6er gibt eh nicht benutzt werden
wird.

> Also wäre ein Quellcode für den BGW211 sehr nützlich. Ob man den jetzt
> für den Kernel 2.4.x repariert oder für die Aufrüstung auf 2.6.x nutzt,
> ist letztendlich egal :)

Das ist allerdings richtig. Dann ist der Treiber aber nur die halbe
Miete: anschliessend geht es weiter beim wpa_supplicant, der ebenfalls
einen Philips-spezifischen Teil enthält.

Grüße,

Chris

Edit: Natürlich ist es nicht verkehrt auf mehreren Fronten gleichzeitig
zu arbeiten. Ich habe mir erstmal das Treiber-Neuschreiben für LCD,
Sound, Power-Management und "Tastatur" zur Aufgabe gemacht. Jeder der in
Richtung 2.6 arbeiten will ist natürlich herzlichst dazu eingeladen ;)
Später kann man das ganze dann ja zusammenführen (für 2.6) oder
Backports machen (auf 2.4).

Thanks for the Chris-BSP and the putting it online!

Download is progressing, but that can by machine do without me sitting
in front :)

Good night to all of you!

About the WLAN drivers and wpa_supplicant:

One could disassemble the driver, split it up in function blocks and
write c-wrappers to the resulting assembly functions. The function
arguments and return types can be derived more or less from that
assembly source. That could be used as a base to gradually convert it
into C.

As for the supplicant: One could compile the very same version from
source. Then walk through the disassembly of both versions to isolate
the philips specific driver code in there (and maybe changes to the base
code, if there are any). Then integrate the changes back into the real
source, and add the philips specific driver again as a mixture of
assembly-code and c-wrappers.

Quite some work, sure, but i think a feasible solution if everything
else fails.

Greetings,

Chris

Joost R. schrieb:
> I received the dvd from Chris and uploaded it to:
> https://vpx500.nederlandlive.nl/ (http://vp6500.bd8.nl is also redirect

@Joost: Hartelijk bedankt voor 't ter beschikking stellen van de server
ruimte!

@Christian: Danke für die ganze Arbeit mit der VM!

/G

Hi!

The BGW211 driver consists out of doezends of small functions accessing
the Device via SPI or addressing a shadow memory. By their names it
should be more or less obvious, what they do. This can be used to
reverse engineer the chips registers without using wrappers.

I am still hasseling with the setup of IDA, but it will go on. I hate
dynamic memory mapping or I/O mapping :)

Best regards,
Ulrich

Ulrich P. schrieb:
> I am still hasseling with the setup of IDA, but it will go on. I hate
> dynamic memory mapping or I/O mapping :)
>
> Best regards,
> Ulrich

Be happy that the code is for ARM, which is a rather simple instruction
set. Imagine the same stuff on X86 ... ;-D

Greetings,

Chris

I did assembler on several different devices before, but never on an
ARM. But, however, it's only another assembler :)

Here's a quick reference card of the ARM instruction set(s).

http://infocenter.arm.com/help/topic/com.arm.doc.q...

A really nice feature of it is that every instruction can be
conditional, bis simply adding things like GT, LT, etc. to it.

Greeting,

Chris

The 'debug code' found in the driver and mentioned by me before is
active, if the TIN line is low. These strings are sent to the serial
console then.

SPI2:: drvIoctl :dot11LongRetryLimitAC1 = 8
SPI2:: drvIoctl :dot11LongRetryLimitAC2 = 8
SPI2:: drvIoctl :dot11LongRetryLimitAC3 = 8
SPI2:: drvIoctl :dot11ShortRetryLimitAC0 = 8
SPI2:: drvIoctl :dot11ShortRetryLimitAC1 = 8
SPI2:: drvIoctl :dot11ShortRetryLimitAC2 = 8
SPI2:: drvIoctl :dot11ShortRetryLimitAC3 = 8
SPI2:: drvIoctl :PA Request
SPI2:: drvIoctl :No state change!
SPI2:: drvIoctl :Fast PS Request
PhgHhalDoM2SDMA:1661:-->P1
SPI2:: drvHhalEventIndicationHandler :PS Ind (1) in Drvmain

If e log the complete startup until the registreation is completed, we
might get a line the driver follows and an idea of what the functions
are doing.

Ulrich P. schrieb:
> The 'debug code' found in the driver and mentioned by me before is
> active, if the TIN line is low. These strings are sent to the serial
> console then.

You'll see the same when you type "cat /proc/kmsg". The VP6500 seems to
be a bit more talkative than the VP5500 (it won't show the debug
messages you listed, but try removing the VPx500 from the cradle,
activate and turn the camera).

Btw: the command prompt of the VP5500 seems to be a lot more responsive
than that of the VP6500. Processes on the VP6500 wait much longer for
execution, while the CPU is idle. There is a module "doze", which I
suspect is responsible for making the CPU sleep, even if processes are
waiting for execution. However, I have no clue what sends the CPU to
sleep and what makes it react immediately to GUI events, even if the
console is sluggish (if not QTopia itself ;-).

/G

Hi Gert,

I recognize these slow console behavior only on the serial port. Via
Putty/ssh there is no problem of delayed characters.

The debug messages are part of the philips driver for the BGW211 chip.
As the VP5500 has an other chip on its module, there is other or, as you
said, no debug code.

With or without the debug... if you do not have the detailed datasheet
of the chip, the info is nice but not really helpfull. Lot of shortcuts
in it. May be it helps if I work myself through the 802.11 standards...

Regards, Ulrich

Looking for a BGW211 driver i came across the LPC3180 dev-kit made by
FDI:
http://www.teamfdi.com/products/downloads/support/...

At http://www.teamfdi.com/pages/products_index.html you can download the
documentation and maybe someone is able to get hold of the password
required to download the sources...

BR
Robert

Hi Dirk!

do13 schrieb:
> * BGW200 datasheet: http://www.ic72.com/pdf_file/14pdf/bgw200eg.pdf
> Isn't enough to write a driver but helps to understand to host
> communication

Right, got that before.

> * The compulab CMX270
> http://www.compulab.co.il/x270cm/html/x270-developer.py
> also has the bgw211 wifi onboard. 2.6 drivers are binary only

Hmm, yes looks like there is one on the board, but then later they
mention the Mavell Chipset...

> * Beck Wl01 is another source.
> http://www.beck-ipc.com/de/products/sc2x/wl01.asp  As usual no code
> available only a binary lib
>
No, but some things that a disassembler really likes :) But it's x86
code. Beck doesn't use ARM afaik.

> I suspect we won't find the sourcecode.
Don't give up so early :)

Best regards, Ulrich

It looks like a friendly guy at Openwrt is working on a 2.6 Kernel:

https://dev.openwrt.org/changeset/20786/
https://dev.openwrt.org/changeset/20817/

I suspect serial, flash, keyboard and led's are working.

Dirk

Hello,

by coincidence i found this datasheet today:

http://www.ic72.com/pdf_file/14pdf/bgw200eg.pdf

Maybe that gives some hints about the BGW211 as well? At least there is
a lot more information in this datasheet.

Greetings,

Chris

Mario,

sorry to tell you, but before posting such stuff it would be great if
you could do some fact-checking. Read the Wiki-Page about the phones.
Read this and the main thread.

Virtually everything of your post is completely wrong.

Mario schrieb:
> BGW200 was the predecessor of BGW211 but they have not
> very much in common except the pinout.

Wrong. They actually have quite some things in common. They internally
use an ARM7 based controller. Both are connected through their SPI2 port
to the host CPU. Both have the same ports than can be used to upload the
firmware, one of them said SPI2. You can cleary see that if you look at
the disassembly of the driver from the phone. Yes, they probably have
(partially) different register, and a different RF frontend. However, to
get an understanding of the basic structure, the BGW200 can give quite
some hints.

Mario schrieb:
> The VP5500 should be based on TI OMAP plattform (dont ask me which one)

Again, wrong. Both phones are based on the iMX.21 ADS from Motorola, now
part of Freescale. Both used the Linux-BSP for development, which you
can still download from there. Again, this becomes clear by looking at
the files on the phones. And, partial sources for the phones have
appeared, from phillips. And guess what they use? No, it is not OMAP.

Mario schrieb:
> I believe later versions of the VP phones should use another WLAN
> (Marvell?).
> So the WLAN stuff will be not compatible i assume.

You could have spent a few minutes reading the Wiki-Article. The VP5500
uses an add-on card that has a Marvell chip on it. The 6500 uses the
BGW211. From the production date, the 5500 came first, after that the
6500. So, the BGW came later. However, the software revision number on
the 6500 is lower, which looks like a discrepancy. But then, it's quite
possible that they started a new branch for the 6500 that is completely
independant from the 5500, in terms of version-numbering.

Greetings,

Chris

Mario schrieb:
> - Das BGW200 war ein Vorgaenger Modell, allerdings nur fuer 11b WLAN.
>   Das BGW211 ist als Drop In Replacement konzipiert worden. Deshalb hat
> es
>   nach aussen im wesentlichen die gleichen Schnittstellen.
>   Der innere Aufbau ist natuerlich auch aehnlich, aber ich bezweifle,
> dass
>   die Treiber wirklich so aehnlich sind. Es liegt doch erheblich Zeit
>   zwischen den beiden Devices. Mal schauen kann aber nicht schaden ;)

Ich denke das die beiden mehr miteinander zu tun haben. So geht das
Datasheet vom BGW200 ja auch auf den BGW211 ein, nämlich in der
Pin-Beschreibung. So findet sich dort "reserved for pin-compatibility
with BGW211" bei einigen Pins.

Da beide Chips auch prinzipiell die gleiche Funktion haben, nämlich ein
Interface zu WLAN herzustellen, ist anzunehmen das auch der prinzipielle
Aufbau der Kommunikation mit dem Chip sehr ähnlich ist. Es wäre aus
sicht von Philips bzw. NXP ziemlicher Unsinn da zwei völlig verschiedene
Versionen zu machen. Das würde nämlich ein komplettes Neudesign mit
entsprechend höheren Entwicklungskosten bedeuten. Verwertet man aber
"altes" und funktionierendes erneut, und modifiziert dies lediglich,
spart das ein haufen Geld. Zudem erleichtert das für die Kunden ein
"drop-in-replacement" wenn man einen Großteil der Software
wiederverwenden kann.

Letztendlich haben beide Chips intern einen ARM7 Kern der über die
Firmware, die man dann hochlädt, den Großteil der Funktionalität
implementiert. Nach außen hin gibt es wenig zu tun. Halt ein paar
Mailboxen für Datentransfer, dazu ein paar Kommandos für DMA etc. Ich
bin mir sicher das das bei beiden recht ähnlich ist, und der großteil
sogar identisch. Das ist ja eben der Sinn des ARM7 Kerns da drin: die
Schnittstelle und das Protokol nach außen hin zu vereinfachen. Worauf es
halt ankommt ist die Firmware die in die Chips geladen wird. Denn die
implementiert letztendlich auch das Interface nach außen.

Grüße,

Chris

kruemeltee schrieb:
> SDL mit Framebufferausgabe, wenn du willst, kann ich dir heute Abend ein
> Beispiel posten.

das wäre dann ja aber am qtopia vorbei, oder?
Ich vermute das das dann Probleme gibt, wenn qtopia irgendwelche
elemente updated, da dann Teile der Applikation überschrieben werden.

Edit:
Ich stell mir das so vor, dass es wäre, als wenn man unter Windows an
allen Anwendungen vorbei direkt auf den top-Level-HDC (getDC(0)) malt

kruemeltee schrieb:
> eis wie es sei, SDL/fb ist sehr praktisch wenn man selbst was basteln
> will, ist einfach und ich könnte ein Beispiel posten, welches auf dem
> Framebuffer rennt.

man kann schon den Framebuffer manuell beschreiben, das zeigt ja das
Schnippsel, was im Artikel steht um die bin splash screens anzuzeigen.

Für ne quick&dirty Anzeige aus einem Prog reicht das eventuell auch.

rtux schrieb:
> Thanks, maybe I should rephrase my question: where do I find TFM?

Hello,

cd ~/BSP/ltib-imx21ads-20070609
./ltib --configure

In the upcomming menu, scroll down a bit and check the "Configure the
kernel" option using the space key. Tab to "Exit" and answer the
following question with "Yes". It then starts the kernel configuration
dialog. Choose the options you want, select "Exit" and again answer
"Yes" if asked to save the config. It should then start to build the
kernel, and other packages if any new ones are selected.

You can get a list of options for ltib with "./ltib --help" executed
from the ~/BSP/ltib-imx21ads-20070609 directory. However, i'm not
familiar with ltib either....

Greetings,

Chris

Hello,

sorry for my silence recently, but i'm quite busy these days and have
virtually no time to continue working on the phone.

Attached is a small dsp test program. It opens the aic and dsp1 devices,
gathers some information and then play back a 1 khz tone from the file
named sig1k.le. It does that twice, one time with 8khz and then with
16khz sampling rate.

Note that the sound system on the phone can only do these two sampling
rates, and only in mono. To use 16khz you have to issue the proper
ioctly always before playback. Once the devbice is closed it
automatically reverts back to 8khz.

The code also tries to read the mic input, but i haven't completely
figured out that one yes, so for now recording does not work.

As for the camera. The iMX itself has a section to handle the camera
input, scales it, does the color conversion, etc. It does so by using
DMA to read from the camera, and to write to the memory. So if you give
it a proper memory address, it should write the data there. Keep in mind
that linix itself translates memory addresses. The address that you get
through an alloc is probably not the correct physical address that the
cpu "sees". So it may be neccesarry to re-translate that address to the
real physical memory address.

Greetings,

Chris

Hello,

there is the /dev/mixer1 device that you could use. It is standard, so
you can use the regular OSS ioctl's for that. I attached a small sample
source that i did a while ago which lists the dsp capabilities and the
mixer stuff. Not sure if the mixer device can be opnened while qtopia is
running, didn't test that.

Greetings,

Chris

mitch schrieb:
> PS: When the phone goes to into one of it's sleep states (display goes
>
> dark), trying to play an MP3 seems to result in a system freeze...

you can try that hint here:
Beitrag "Re: PHILIPS VP5500 VoIP Telefon bei Pollin"

Hello,

alternatively you could use ioctl's on the aic14 device node. There are
provisions to set the chip's ADC and DAC gain. I think it should be
somewhere in the code i posted, but not sure.

Greetings,

Chris

Hello Chris,

yes, feel free to do with that stuff whatever you want ;)

Greetings,

Chris

Hi!

Is somebody still working on the phone (I am not talking about setting
up SIP as in the other thread). Any new insights on the Philips-Sources
(GPL...) or about WLAN and Display-Driver etc? Any chance the phone will
ever be usable without the linux (in terms of using its hardware in a
bare-metal system).

BR
Robert

Christian Klippel schrieb:
> Hallo,
[...]
> Für die Detailverliebten: Man öffne /dev/watchdog und schicke ein ioctl
> 0x80045705 ohne weitere Parameter dort hin um den Hund zu kitzeln. Das
> muss natürlich periodisch passieren.
>
> Grüße,
> Chris

Hallo,
ist es auch möglich dem Watchdog mitzuteilen, dass er das System bitte
neustarten soll?
Ginge das auch ohne C, per Shellskript?

Grüße
Stefan

Hallo , ich habe hier auch noch ein VP6500 .
Leider bekomme ich das Ding an keinem AP hier angemeldet.
Das VP5500 geht problemlos.
Kann mir von euch evtl jemand helfen ?
Würde ihm das Telefon zusenden mit einem kleinen Obolus .

LG Tino