mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PHILIPS VPx500 Kernel/System Development


Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gert D. (gert_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Eddy Sino (eddy14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

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

HTH

[1] Beitrag "VP6500 öffnen (und wieder schließen)"

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie groß ist das vmware image denn aktuell? Eventuell könnte ich es bei 
mir hochladen .... das problem an der geschichte ist das ich limierten 
traffic habe und danach runtergeschaltet werde .... sind zwar zwei tb 
aber wenn das ding entsprechend oft runtergeladen wird auch recht 
schnell weg ;-)

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chris,

wie wäre es mit einer Verteilung über Torrent? Dann hat wirklich jeder 
etwas davon und bei dem Interesse wird die Verteilung auch nicht so 
schnell abreißen...

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

Autor: Joost R. (Firma: Nederland Live) (joost_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich könnte die Datei auch hochladen ... ich sitze im uni netz und könnte 
mit 100 MBit´s sowohl runter wie auch hochladen


--------------

i can uploade the file too..... i am student and live in a "hall of 
residence"(says leo... Studentenwohnheim?) i can up an download with up 
to 100MBit´s

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: der_voiper (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn ihr wollt kann ich das Image auf einen Webserver legen.
Ich habe noch 40GB Speicherplatz frei.
Dann kann es jeder mit einer schnelleren Anbindung einfach 
herunterladen.

Besteht Interesse?

Autor: der_voiper (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh sorry - ich sollte vor dem Schreiben auf aktualisieren drücken.

Wie ich sehe hat sich das ganze schon erledigt. Werde einfach wenn die 
VM online ist einen Mirror machen.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gert D. (gert_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Eddy Sino (eddy14)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sobald ihr es geschafft habt das linux aus zu tauschen .... werde ich 
mich darin versuchen openvpn auf die kiste zu portieren

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

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..

Autor: Ulrich P. (uprinz)
Datum:

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

Gruß, Ulrich

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hierzupampa 'mussten' wir umsteigen, weil die Betreiber es erstens nicht 
geschafft haben, mehr als Ultralangsam-DSL zu schalten und zweitens 
mehrmals willkürlich rumgeschaltet haben (Ablauf: Callcenter ruft an 
'Wollen Sie..' - 'Nein' - Einen Monat später trudelt ein Brief ein 
'Danke für ihren Auftrag. Sie können den Auftrag weder widerufen noch 
stornieren, wir machen einfach. Und wenn sie ein paar Tage ohne 
Anschluss dastehen dann interessiert uns das auch nicht. Pech für Sie 
dass sie von einem Callcenter angerufen worden sind.'

Tja, da hilft nur wechseln. Bei der Konkurrenz sind übrigens zwei 
vollwertige Telefon(!)anschlüsse mit dabei, da kostet ein einzelner 
andernorts auch ohne DSL schon das selbe, mit Schneckentempo-DSL dann 
gut das doppelte.

Wie gesagt einziges Manko die lange (erste) Vertragslaufzeit.

So, aber ich will erstens keine Werbung machen und zweitens jetzt EOOT.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*/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:

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn man mit WinSCP auf den Dingern arbeitet, dann bekommt man immer
> wieder die Meldung, dass die Groups nicht aufgelöst werden können.

Das sollte daran liegen:
# groups
sh: groups: command not found
Freiwillige, die es unbedingt protieren wollen, bitte vortreten ;-)

> 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.

Ja, aber weder eine Datei noch ein 'Feature' :-) Was fehlt sind die 
Einträge in /etc/passwd und /etc/group (aka die User/Groups gibt es 
schlicht nicht). Im wesentlichen gibbet drei Möglichkeiten:

1. Ignorieren. Das war jetzt einfach ;-)

2. Nachtragen.
# ls -l        
drwxr-xr-x    2 301      504             0 May  1  2005 Documents
drwxr-xr-x    2 301      504             0 Feb 28  2007 Settings
drwxr-xr-x    2 301      504             0 Feb 28  2007 bin
# echo 'nogroup:x:504:' >> /etc/group 
# ls -l
drwxr-xr-x    2 301      nogroup         0 May  1  2005 Documents
drwxr-xr-x    2 301      nogroup         0 Feb 28  2007 Settings
drwxr-xr-x    2 301      nogroup         0 Feb 28  2007 bin
Für den User analog.

3. chown-en. Da muss man nur aufpassen, dass man sich keine 
Berechtigungen kaputt macht - ergo rausfinden ob irgendwelche Dämonen 
mit der angegebenen UID/GID rumlaufen.

HTH

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Forgot to include the binaries of these programs. Here they are.

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

Greetings,

Chris

Autor: Onno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin auch an OpenVPN auf der Kiste interessiert, kann mal jemand, der 
den Platz und die Zeit hatte, das BSP komplett mit Kernel und allen 
Modulen zu bauen zumindest die Kernel-Module hier posten? Ich wäre an 
tun/tap interessiert. OpenVPN hab ich schon auf das Telefon gekriegt 
(mit gcc, und lzo/ssl-Build mit sehr wenigen Anpassungen), aber dann 
fehlt ihm eben genau das TUN/TAP-Device damit ich weiterkomme. Das 
Kernelmodul alleine würde reichen!

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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:
Angehängte Dateien:
  • tun.o (164 KB, 332 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Onno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

thank you a lot for the tun module! Vielen Dank!

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Tino N. (tino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> warum nicht parameterisierbar,
>
> fb0, fb1 und Datei (wahlweise mit formatierung für fb0 oder fb1)

auch recht

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maarten Jaegers (quirk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Klippel schrieb:
> Beide in der Funktion "PhgHhalResetAndBootLoad" benutzt.

Das klingt vielleicht blöd, aber das ist vielleicht gar nicht mal so 
schlecht. Die "dicken Brocken" könnten die Firmware des eigentlichen 
WLAN-Chips sein. Falls dies der Fall sein sollte, wären sie ziemlich 
uninteressant - zumindest inhaltlich. 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. :-/

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
möchte dann auch mal meinen Teil dazu beitragen.
OpenVPN version 2.0.9

zum installieren auf dem Telefon:
cd /
wget http://host/openvpn.tar.gz
tar -xzf openvpn.tar.gz
depmod
mknod /dev/net/tun c 10 200

Gruß Marc

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
>
> 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.

Ich kann mir ein Schmunzeln leider nicht verkneifen... :-) Chipmasken 
sind bekanntlich teuer, daher versucht man möglichst viele 
(optimalerweise alle) Unzulänglichkeiten der Hardware mit der Firmware 
auszubügeln. Also nichts Überraschendes hier. ^_^

Custom Malloc-/Free muß nicht unbedingt schlechten Code bedeuten. Zu den 
2.4er-Zeiten hatte der Kernel keine wirklich guten Debugging-Funktionen. 
Abgesehen davon weiß man nicht wirklich, wo der Treiber seinen Ursprung 
hat. Oft portiert man einen Code-Blob zwischen verschiedenen OS und 
versucht mit einem Zwischenlayer möglichst viele internen Funktionen 
unverändert zu lassen.

Auch der Watchdog-Code muß nichts Schlechtes bedeuten. Das hier ist ein 
Chip mit hauptsächlicher Embedded-Ausrichtung. Vor dem Hintergrund, daß 
man "im Feld" oft keine weiteren Firmware-Updates durchführen kann, ist 
so ein Watchdog vielleicht nicht elegant, allerding dürfte er die 
eigentliche Systemverfügbarkeit letztendlich verbessern. Wir lieben ja 
alle diese sporadischen Fehler, die nur bei Vollmond und gleichzeitiger 
Donautemperatur von exakt 9,85 Grad auftreten. ;-)


> 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.

Meines Wissens ist das nicht unbedingt das Problem. Schlimmer (aus Sicht 
der Behörden) ist vielmehr die Tatsache, daß man mit den Chips auch 
völlig andere Frequenzen anfahren -->könnte<--. Gerade die Freunde 
jenseits des Atlantiks scheinen da sehr empfindlich. Die FCC (bzw. 
indirekt das Militär) achtet wohl gezielt darauf, daß man als "User" 
kaum etwas machen kann. Will man also etwas auf dem US-Markt plazieren, 
kommt man nicht herum, nach deren Regeln zu spielen. :-/ Man könnte 
natürlich die WLAN-Funktionalität komplett kapseln, allerdings scheinen 
die SoftMAC-Implementierungen billiger, weil hier das Hauptsystem einen 
Teil der Rechenleistung zur Verfügung stellen muß.

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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
OpenVPN 2.1.1 mit tun-Modul und openssl

Anleitung im Wiki ;-)

Gruß Marc

Autor: Marc (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tinc 1.0.12 mit tun-Modul und openssl

Anleitung im Wiki ;-)

Gruß Marc

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. schrieb:
> Also gerade bei Broadcom kann ich mich nicht beschweren. Die haben mir
> als Privatperson gegen NDA einen Zugang ins eigene Developer-Netz
> angeboten.

Also beschweren wollte ich mich keinesfalls. Broadcom hat sich IMHO auch 
ziemlich gut entwickelt, was OpenSource angeht. :-)

Allerdings ist der Broadcom-Treiber ein gutes Beispiel fürs sog. 
Clean-Room-Design ist. 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, daß die "User-Base" einfach zu klein 
ist. :-/

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SD-Fritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mist .... ich warne nochmal ausdrücklich vor änderungen von hand in der 
wpa_supplicant.conf :( ich schaffe es nicht das mein telefon sich noch 
bei mir einbucht....

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SD-Fritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Chris,

danke für deinen Tipp,

Gruß,
  Martin

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gert D. (gert_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gert D. (gert_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joost R. (Firma: Nederland Live) (joost_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcel F. (techno)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gert D. (gert_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gert D. (gert_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert B. (robertb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: do13 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

other Resources about the BGW211:

* 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
* 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
* Beck Wl01 is another source. 
http://www.beck-ipc.com/de/products/sc2x/wl01.asp  As usual no code 
available only a binary lib

I suspect we won't find the sourcecode.

best regards
Dirk

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk O. (do13)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Chris,

i fear not much. BGW200 was the predecessor of BGW211 but they have not
very much in common except the pinout.
The VP5500 should be based on TI OMAP plattform (dont ask me which one)
and the BGW211 was a WLAN that was discontinued some years ago.
So there is also nothing that came behind.
I believe later versions of the VP phones should use another WLAN 
(Marvell?).
So the WLAN stuff will be not compatible i assume.
There are some test points close to the BGW211. I assume at one there 
should be some serial output with 115k2 8n1. Maybe you find another UART 
output at this 6 or 7 testpoints at the other side of the PCB. Assume 
115k2 8N1 as well.

Would be nice if anyone can post traces.

Mario

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BTW 3.3V I/O voltage...

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chris,

ich bitte erstmal um Entschuldigung. War da wohl etwas voreilig.
Die Wiki Seiten sind wirklich sehr informativ. Wegen der Plattform hat 
mir
mein Gedaechtnis wohl einen Streich gespielt.
Der Hinweis zu den richtigen Versionen ist gut. Da war ich auch verwirrt 
durch das Bild im Konfigurations Thread, aber auch da steht ja VP6500 
drann.

Also was das WLAN betrifft:
- weshalb man so wenig hoert liegt daran, dass die WLAN Entwicklung bei 
NXP
  2008 bereits vor dem Joint Venture mit ST eingestellt wurde.
  Ich glaube auch nicht, dass Teile aus der Entwicklung in die Systeme 
von
  ST eingeflossen sind, auch wenn die vom Aufbau her ganz aehnlich sind.
- 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 ;)

Also nochmal sorry wegen dem ueberstuerzten Beitrag.

Gruss
Mario

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: LemonSquash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich versuche momentan, den crond für das VP5500 zu übersetzen (DANKE! 
Chris für die VM). Hapert allerdings im Moment noch etwas.

Wenn irgendjemand noch Infos hätte, wie man zusätzliche "Programme" für 
die GUI erstellen kann, könnte ich damit eine Wecker / 
Terminerrinnerungsapp bauen.

Die wird dann (im Erfolgsfall) selbstverständlich auch hier 
veröffentlicht!

Gruß,
LemonSquash

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SDL mit Framebufferausgabe, wenn du willst, kann ich dir heute Abend ein 
Beispiel posten.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: rtux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I’m not familiar at all with the ltip stuff, but has anyone any hints or 
links to documentation on how to start hacking the kernel for the phone?

I got the VM image running in VirtualBox and seem to have found the 
kernel-source in ~/BSP/ltib-imx21ads-20070609/rpm/BUILD/linux, but 
typing make there raises a bunch of errors, so I’m wondering on how to 
get started.

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Ja, da hab ich wohl einen Fehler gemacht und zu schnell gelesen. Ich 
denke mal, dass da dann sowieso gar nichts geht, wenn X rennt, geht SDL 
auf dem Framebuffer auch nicht bzw man sieht es nicht.

Seis 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.

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> but
> typing make there raises a bunch of errors, so I’m wondering on how to
> get started.
RTFM

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rtux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kruemeltee schrieb:
>> typing make there raises a bunch of errors, so I’m wondering on how to
>> get started.
> RTFM
Thanks, maybe I should rephrase my question: where do I find TFM?
The doc/ directory was not particulary helpful, and it seemed I could 
save myself a couple of hours trial/google/error if just asking here, as 
probably some of you figured out a reasonable workflow for module 
development, which again might also help others getting started.

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: LemonSquash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kruemeltee: Ich dachte zwar eher an eine art Applikation, die 
einheitlich mit qtopia rennt (sozusagen ein Add-in ;) ). 
Nichtsdestotrotz wäre ich dir für das besagte Beispiel dankbar, denn es 
kann nie schaden ;)

Gruß,
Lemon

Autor: Thinksilicon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LemonSquash schrieb:
> ich versuche momentan, den crond für das VP5500 zu übersetzen (DANKE!
> Chris für die VM). Hapert allerdings im Moment noch etwas.

Hi,
wenn du dich mit meinem Paket zufrieden gibst, brauchst du das nicht -> 
guckst du http://thinksilicon.de/57/Hacking-the-VP6500.html einfach 
entpacken und runlevel-Script entsprechend verlinken. Die entsprechenden 
Einträge von Crontab + Script sind ebenfalls in der Dateistruktur 
vorhanden ;)

Autor: LemonSquash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thinksilicon,

das sieht doch schonmal ganz gut aus ;)
Bleibt noch die Frage nach der GUI dafür - ich möchte ja wie gesagt am 
Ende eine Art Wecker / Terminerrinnerung für das VPx haben.

Danke soweit und MfG

Autor: arturh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

I'm trying to access the VP6500 camera in order to stream it to a 
network computer and display it there.

I used Chris's camtest.tgz file as a base for developing it, but I'm 
afraid my skills in this area are quite lacking.

Chris writes:

> 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.
Beitrag "Using the camera"

I did exactly that, but my malloc'ed buffer doesn't get filled with any 
camera data - it only contains zeros for the runtime of the application.
I tried to make it into shared memory by called mmap() but i guess I 
don't really understand what it does.

You can find my current attempt here (testMode = 1)
http://github.com/arturh85/vp6500cam/blob/master/main.c

Would anyone take a look at it? Any help would be appreciated!

arturh

Autor: arturh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I researched some more into the topic and found out that I can't use 
malloc because it allocates virtual uncoherent memory where I need 
coherent physical memory.

As far as I see you need to use dma_alloc_coherent() for which I have to 
be writting a kernel module.

Fact checking: Is that correct? Any viable alternatives?

http://mirror.linux.org.au/linux-mandocs/2.6.4-cse...

Autor: mitch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Klippel schrieb:
> 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.

I would be very interested, then I could try to use the phone as a kind 
of portable WLAN radio :-)

Simply compiling madplay for arm did not work as an ioctl while opening 
/dev/dsp fails - with your example code I can propably look into that.

Regards
Christian

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mitch (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
And we now have music!

Thanks for your test program.  I took the aic14* files, plugged them 
into madplay and it just works :-)

The patch and precompiled tarball are attached to this message.

To play an MP3 file, do this:
$ /usr/local/bin/madplay -o aic:/dev -R 16000 -m -b 16 <filename>

Playing audio streams/web radios:
$ wget -O- http://relay4.slayradio.org:8000/ | /usr/local/bin/madplay -o aic:/dev/dsp1 -R 16000 -m -b 16 -

Next thing on my list is to find a small mixer application and 
crosscompile it, too, because listening to MP3s on top volume is kind of 
annoying (or am I missing something and there is volume control hidden 
in the phone menus?).

Regards
Christian

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mitch (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
I got aumix running with a one line patch, but it just "did nothing".
I also wrote a small mixer app this afternoon - it works on my regular 
PC, but on the phone it also does nothing (source attached).

/dev/mixer1 is opened successfully, the ioctl for setting the volume 
throws no error but the volume is not changed at all.

I've never before written anything for sound devices under linux, so I'm 
a bit out of ideas for now.

Regards
Christian

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...

Autor: Sebastian R. (sebr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: mitch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Use "madplay -a -16" to decrease the volume.
This makes you loose some bits (e.g. 14bit sound instead of 16bit sound) 
but the phone is rather lo-fi anyways :-)
Regards
Christian

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mitch (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
The DACGAIN, it does nothing :(
(bei ADCGAIN rührt sich übrigens auch nichts)
# /usr/local/bin/vp6500mixer 0 
DAC Gain before:        2A (    0 dB)
DAC Gain after:         2A (    0 dB)
# /usr/local/bin/vp6500mixer 50
DAC Gain before:        2A (    0 dB)
DAC Gain after:         2A (    0 dB)
# /usr/local/bin/vp6500mixer 100
DAC Gain before:        2A (    0 dB)
DAC Gain after:         2A (    0 dB)

regards
Christian

Autor: mitch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
grrr, forget my last post.  moving the "bytereg[0] = vol" line to the 
correct position makes this work :-)
it definitely did not work before, though, that's why I added the 
GET_DAC_GAIN calls for debugging...

btw, Christian, can I add your header files to a git repository or a big 
tar.gz containing everything that's needed for MP3 output?  Can I 
consider your files GPL'ed?

Regards
Christian

Autor: Christian Klippel (Firma: Atelier Klippel) (mamalala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Chris,

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

Greetings,

Chris

Autor: rtux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
arturh schrieb:
> I researched some more into the topic and found out that I can't use
> malloc because it allocates virtual uncoherent memory where I need
> coherent physical memory.
>
> As far as I see you need to use dma_alloc_coherent() for which I have to
> be writting a kernel module.
>
> Fact checking: Is that correct? Any viable alternatives?

I was looking into this a while ago. Yes, you’ll need coherent memory + 
its physical address.
However the camtest approach would probably suck. So for a good solution 
you’ll need to write a kernel module, but then again the drivers for the 
video are already there (linked at the wiki-page somewhere), so there’s 
already software for talking to the hardware which will then take care 
of most things including the encoding of the video.
I didn’t look too long into it, but there were some things that weren’t 
as straightforward as I thought though ;)

Happy hacking!

Autor: arturh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rtux schrieb:
> So for a good solution
> you’ll need to write a kernel module, but then again the drivers for the
> video are already there (linked at the wiki-page somewhere), so there’s
> already software for talking to the hardware which will then take care
> of most things including the encoding of the video.
> I didn’t look too long into it, but there were some things that weren’t
> as straightforward as I thought though ;)

I'm quite a newbie to kernel/drive development and reverse engineering, 
but I'd love to hack further on this issue.

Could you give me any more information on where to find that video 
driver (i guess it's the video.o file?) and how to access it?
Do i have to use ioctl like in the camtest example?

My current attempt is successfully transfering the camera image (out of 
the framebuffer) to a python wxWidgets application which can draw the 
uncompressed video stream at about 5 fps. Getting it hardware encoded 
would certainly help :)

Regards, arturh

Autor: Robert B. (robertb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Could someone successfully write the camera snapshot into a file? I 
would like to use the phone as webcamera.

Autor: rtux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
arturh schrieb:
> I'm quite a newbie to kernel/drive development and reverse engineering,
> but I'd love to hack further on this issue.
>
> Could you give me any more information on where to find that video
> driver (i guess it's the video.o file?) and how to access it?
> Do i have to use ioctl like in the camtest example?

The video-driver is linked here: 
https://www.das-labor.org/wiki/VP5500#Camera
And contains basically all code needed to access the hardware, although 
some is not used, or used in a complex fashion in the v4l system which 
I’m not familiar with. There is also documentation available on the 
hardware in the internet and how to access it and what all the register 
information mean etc., tough I don’t have a link at hand right now.

Happy hacking :)

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi all,
In a post of Mitch I see that volume-control (for MP3 playing) is 
possible. I searched for a binary but not found yet. Anybody that can 
give me a binfile for it?

Thanks,
Jan

PS next step would be to include MP3 play (stream from a fixed server) 
and volume in the menus, seems to be possible,. Probably only need a 
german translator ;-)

Autor: mitch (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:

> In a post of Mitch I see that volume-control (for MP3 playing) is
> possible. I searched for a binary but not found yet. Anybody that can
> give me a binfile for it?

I've attached a binary to this posting.

Starting playback and changing volume via the menu is only writing some 
small scripts, should be no problem.

But you propably will run into the problem with the power-saving: After 
about 30 seconds the CPU is throtteled and MP3 playback starts to 
jitter.

If somebody knows how to prevent the powersaving, please tell :-)

Regards
Christian

Autor: delirium (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Trick um momentan an nen bild von der Kamera zu kommen ist einfach 
das vorher beschriebene sensortest laufen zu lassen und dann einfach mit
cat /dev/fb0 | nc server 5000
den framebuffer komplett an nen anderen rechner zu senden...
mit
netcat -l -p 5000 | ./scap | pnmtopng > out.png
hol ich das bild dann ab und mach nen png draus.
scap stammt von hier. http://handhelds.org/scap/code/scap.c
Dabei muss einmal die auflösung angepasst werden!

Ist alles nen bisle hässlich.. :)

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

auch, wenn es hier ziemlich ruhig geworden ist, habe ich mich nach einem 
Treiber fürs BGW211-WiFi umgeschaut.

Auch, wenn ich nicht direkt fündig geworden bin, bin ich über ein paar 
Informationen gestolpert, die hier noch nicht erwähnt wurden.

Das WiFi-Modul scheint den Code-/Platformnamen "Georgia" gehabt zu 
haben, und wurde außer in den oben erwähnten Geräten offensichtlich auch 
in diversen Multimedia-Playern von Archos verbaut. Der übliche 
Treibername scheint ga_linuxdrv.ko oder bgw211.ko/BGW211.ko zu sein. 
Zumindest ersteren findet man auch als Binärdatei, wenn man die bekannte 
Suchmaschine verwendet. Der Ursprung schient hier bei den Archos-Geräten 
zu liegen.


Ulrich P. schrieb:
> 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 :)

Daran habe ich mir echt die Zähne ausgebissen, denn scheinbar gibt es 
nur entsprechende Quellen nur für den Nachfolger, nämlich die Qbox HD. 
Unabhängig davon, dürfte das Modul höchstens zur Extraktion der 
BGW211-Firmware dienen, denn die Qbox-One scheint eine PPC-Architektur 
zu haben. Natürlich gibt es die Firmware-Blobs des Herstellers, 
allerdings habe ich keinen Weg gefunden, den Inhalt aus den QBU-Dateien 
zu extrahieren.


Christian Klippel schrieb:
> 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.

Hier bin ich fündig geworden. :-)
In den GPL-ISO-Images von Archos für die Gerätegenerationen 4 und 5 
(andere habe ich nicht überprüft) gibt es jeweils die Datei 
buildroot/package/wpa_supplicant/driver_philips.patch (vom Inhalt her in 
beiden ISO-Dateine bis auf CVS-Tags identisch).
Die ISOs findet man auf www.archos.com unter Support&Konto -> Downloads, 
dann runterscrollen und bei "Notice of GNU General Public License and 
Lesser General Public Licence" auf den Show-Button klicken.

Ich bin mir nicht sicher, aber der Patch sieht so aus, als ob man damit 
auch einen Host-Treiber bauen könnte - zumindest Teile davon. Nachprüfen 
kann ich das leider nicht, da mir einerseits einiges an Wissen, 
andererseits ein Rechner mit entsprechender Entwicklungsumgebung fehlt. 
Ich denke, Ihr (d.h. Christian und Ulrich) könnt damit mehr anfangen als 
ich... :-)

Schöne Grüße,
Tom

Autor: Stefan Kraus (stehpanka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tino N. (tino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.