dvbsnoop is a tool like the known tcpdump but for Digital Video Broadcast. It almost knows about each and every section on AIR and can dump them. It also knows about the the Multiprotocol Encapsulation (MPE) which can contain IP Datagrams.
What would be nice is to use wireshark or tcpdump on these datagrams to analyse them further or to make use of these datagrams in some applications. Now how to get the IP Datagrams from dvbsnoop into the Linux IP stack? The short answer is using tuntap to get the data into the stack. You have the options to use TUN or TAP the difference is that with TAP you write complete Ethernet frames where TUN only operates on IP datagrams. I have decided to use TUN and followed the example to create a tun device and you end up with a filedescriptor and you only need to write the IP Datagrams. Well actually I have wondered about the frame format and have used the IFF_NO_PI option. Within a couple of minutines I was able to do tcpdump -i tun1 and saw UDP packages. Now one can use dvbnet and dvbsnoop to receive IP datagrams over DVB. I prefer dvbsnoop as if this crashes my kernel still works fine in contrast to using dvbnet.
I will post patches of this little hack soon, meanwhile I search for DVB-T receivers capable of receiving the full Transportstream (PID 0x2000)
Analytics
Wednesday, August 23, 2006
Sunday, August 20, 2006
GNU emacs - the way to canossa
Before having interned at ROAD I was a heavy user of XEmacs, having used the various elisp scripts from KDE and linux CodingStyle and various other elisp scripts. My .xemacs dir was quite nice and with using gnuserv the startup speed of XEmacs was no issue as well. I'm not good at remembering keyboard shortcuts so XEmacs was pretty much the only choiche I had. Somehow I switched to VIM and were able to remember most of the shortcuts and the easy searching within files, which I was never able to do within XEmacs...
Today was the day, I was used to Gtk+ apps randomly crashing on XErrors on my forwarded X sessions, sadly GNU emacs and XEmacs crashed as well and decided to google and found the -Y option for ssh and now Gtk+/GVim, XEmacs and GNU emacs do not abort on XErrors anymore. Sadly the keymap of GVim is totally wrong and I can not even do curly braces or pipe symbols, so I installed xemacs21 on my system but the fonts still looked ugly and I decided to give GNU emacs a try. Now I have a nicely looking editor with syntax highlighting and lisp under the hood. I think I will give GNU emacs a trial and try to remember the various options and collect elisp files again.
I'm really looking forward to see the release of the GREENPHONE and I hope it comes at an affordable price. One issue that worries me is that it is shipping with a 2.4.19 kernel. I sincerly hope that they have patched all security issues in their ancient kernel, use a gcc 2.95 that actually knows about XScale and can produce good enough code and that the root filesystem is not as ancient as their kernel. I think I will lose all my hairs if they ship a phone with a vulnerable zlib, freeytpe, libjpeg, libpng and the other basesystem libraries that has been vulnerable. PLEASE Trolltech do not ship a phone with known security issues.
Today was the day, I was used to Gtk+ apps randomly crashing on XErrors on my forwarded X sessions, sadly GNU emacs and XEmacs crashed as well and decided to google and found the -Y option for ssh and now Gtk+/GVim, XEmacs and GNU emacs do not abort on XErrors anymore. Sadly the keymap of GVim is totally wrong and I can not even do curly braces or pipe symbols, so I installed xemacs21 on my system but the fonts still looked ugly and I decided to give GNU emacs a try. Now I have a nicely looking editor with syntax highlighting and lisp under the hood. I think I will give GNU emacs a trial and try to remember the various options and collect elisp files again.
I'm really looking forward to see the release of the GREENPHONE and I hope it comes at an affordable price. One issue that worries me is that it is shipping with a 2.4.19 kernel. I sincerly hope that they have patched all security issues in their ancient kernel, use a gcc 2.95 that actually knows about XScale and can produce good enough code and that the root filesystem is not as ancient as their kernel. I think I will lose all my hairs if they ship a phone with a vulnerable zlib, freeytpe, libjpeg, libpng and the other basesystem libraries that has been vulnerable. PLEASE Trolltech do not ship a phone with known security issues.
Tuesday, August 15, 2006
BitBake releases
To prepare for the big changes soon coming from Richard we have decided to do two releases of BitBake. We have released version 1.4.4 from the stable branch and we have created a new stable branch from trunk that is named 1.6 and has a release as well. As with any berlios hosted project the BitBake releases can be downloaded from the Files site found at . BitBake 1.4 and 1.6 should have the same amount of features but BitBake 1.6 should be noticable faster on initial parsing. Have fun, find bugs, report them ;)
Sunday, August 13, 2006
Fun with performance
QtEmbedded has a class called QDirectPainter. This class allows to directly manipulate the mmaped screen. E.g. this can be used to memcpy images to the framebuffer like it is done in QImage, QPixmap, bitBlt. It can also be used by MediaPlayer like OpiePlayer2 to memcpy the videoplayer widget into the screen.
Having nice kernel drivers that support layers one can run the GUI on top of the video and one can control the visibility and opacity by controlling the 'a' of the RGBA. This can be done nicely using QDirectPainter. Just mark the relevant pixels with their alpha values and be done. The most obvious piece of code would use |= to OR the alpha value to the current pixel.
There is only bad thing with this approach. This code will do a load and store on the same pixel. As my failure showed this is not done within one or two cycles but requires more time. Now imagine you do this on a complete 640x480 display. Right you can not make the complete display transparent within one time slice but suffer context switches. The lesson learned is simply assign a value do not try to OR it
Having nice kernel drivers that support layers one can run the GUI on top of the video and one can control the visibility and opacity by controlling the 'a' of the RGBA. This can be done nicely using QDirectPainter. Just mark the relevant pixels with their alpha values and be done. The most obvious piece of code would use |= to OR the alpha value to the current pixel.
There is only bad thing with this approach. This code will do a load and store on the same pixel. As my failure showed this is not done within one or two cycles but requires more time. Now imagine you do this on a complete 640x480 display. Right you can not make the complete display transparent within one time slice but suffer context switches. The lesson learned is simply assign a value do not try to OR it
Saturday, August 12, 2006
EABI on OSX/Darwin
My glibc patch at http://sourceware.org/bugzilla/show_bug.cgi?id=3004 was already turned down. As Drepper says there is nothing to argue about. Building glibc requires a binary called 'readelf' in the $PATH and in worst case this should support the target platform. To talk debianism this means you need to have binutils-multiarch installed to configure glibc correctly. Otherwise it will fail silently and misdiagnose the features of gcc. In our case this means glibc will not be able to detect that our gcc can generate .init and .finit sections which should be what __attribute__((constructor)) and __attribute__((destructor))__ creates and every gcc >= 3.4 creates properly.
On the other hand - besides one mysterious error - I have an ARM EABI gcc4.1/glibc2.4/binutils-2.17 toolchain running on my OSX. glibc-intermediate and glibc fail when compiling some bits that look like 'iconv' but a second run of make works just fine. This can be an issue of using -j2 and actually having two cores or other weird issues. I will try it once again and will try hard to identify the issue. Bunutils 2.17 needed one little patch. Somehow apple's gcc4.1 thought that char stopc in read.c might be accessed unitiniliazed. I will need to send the patch upstream which means to get another bugzilla account for another GNU project.... I think it is time for a grand unified bugs.gnu.org...
On thursday I had fun building a Qt 2.3.12 with threading statically. The new and nice configure script of Qtopia2.2 loves to create funky Makefile rules. First it compiles the software using the src-mt rule and then it decides to cd src; make clean. Which will remove everytihg named .o or .tmp and finally everything called ../lib/libqt*. This means it builds the lib, ar's it together then removes it and fails somewhere on the missing .tmp directory when continuing to rebuild... Anyway this error was mysterious and needed three people to look into. Oh well we had the resources for three engineers.... What does that show us? There are no autobuilds of Qt running for different configurations and options. Maybe we should ask Trolltech to contribute to our tinderbox to improve their internal processes. At the end we had a 6 o 7 MB large konqueror embedded running. I think we should get that size down a bit starting to utilize visibility options and such.
On a private note it looks like Al(exandra) and me will take different directions and have split-up. I think we will get along as really good friends but only the future will tell if we start to hate each other or get back together. I wish her good luck, success and pleasure with everything she ends up doing.
On the other hand - besides one mysterious error - I have an ARM EABI gcc4.1/glibc2.4/binutils-2.17 toolchain running on my OSX. glibc-intermediate and glibc fail when compiling some bits that look like 'iconv' but a second run of make works just fine. This can be an issue of using -j2 and actually having two cores or other weird issues. I will try it once again and will try hard to identify the issue. Bunutils 2.17 needed one little patch. Somehow apple's gcc4.1 thought that char stopc in read.c might be accessed unitiniliazed. I will need to send the patch upstream which means to get another bugzilla account for another GNU project.... I think it is time for a grand unified bugs.gnu.org...
On thursday I had fun building a Qt 2.3.12 with threading statically. The new and nice configure script of Qtopia2.2 loves to create funky Makefile rules. First it compiles the software using the src-mt rule and then it decides to cd src; make clean. Which will remove everytihg named .o or .tmp and finally everything called ../lib/libqt*. This means it builds the lib, ar's it together then removes it and fails somewhere on the missing .tmp directory when continuing to rebuild... Anyway this error was mysterious and needed three people to look into. Oh well we had the resources for three engineers.... What does that show us? There are no autobuilds of Qt running for different configurations and options. Maybe we should ask Trolltech to contribute to our tinderbox to improve their internal processes. At the end we had a 6 o 7 MB large konqueror embedded running. I think we should get that size down a bit starting to utilize visibility options and such.
On a private note it looks like Al(exandra) and me will take different directions and have split-up. I think we will get along as really good friends but only the future will tell if we start to hate each other or get back together. I wish her good luck, success and pleasure with everything she ends up doing.
Sunday, August 06, 2006
GNU Toolchain hacking
I currently have access to a Intel Core Duo system with Darwin/OSX preinstalled. Having the power of two cores and a non GNU system installed I figured it is time to hack on OpenEmbedded's support for non GNU hosts/build systems. The last time I tried this was on a G4 system and it failed miserable. It started to fail with quilt which was full of bashism and GNUism which forced me to fix the GNUism in patcher and to use that instead. It failed on flex-native, gcc, glibc, gcc (again), ipkg-native for many different reasons.
Thanks to the power of the two cores compiling, autoreconf and configure times are nice enough for the trial and error procedure. Also quilt has progressed into using less GNUism only requiring GNU sed and GNU getopt to be installed for almost working correctly. I have taken the quilt patch from fink to fix the remaining GNUism. Having quilt available is great as I will need to manage a lot of patches in the progress.
Fixing gcc was easy as well. It only has one conceptual misusage of autotools. Autoconf checks for the presence and usability of header files using CPP. In the case of gcc when building target libraries (e.g. target-libtsdc++ for arm-angstrom-linux) using /usr/bin/cpp to check for the presence of headers is not smart. e.g. libstdc++ found that I have a sys/filio.h header available. I have patched gcc 3.3,3.4,4.0,4.1 and 4.2 snapshots to use the just built compiler (xgcc) and use that as a preprocessor by adding the -E option. The result of this little patching is: The compilation of target libraries will never fail again because autoconf thinks certain features are available. This is good for people on BSD systems creating GNU toolchains and for uclibc people having less features enabled in their library. No more failing builds because host headers were used to determine target features.
Onto glibc. glibc is really mean as configure checks fail silently leading to later trouble. One big issue was the assumption of having binutils installed on my system. The configure check checked compiled bianries using 'readelf' to check for vertain features. I have arm-angstrong-linux-readelf installed on my system but no readelf and I won't ever have one. The fix is easy as well. Use AC_CHECK_TARGET_TOOL([READELF], [readelf] [readelf], [$PATH]) and it will search for arm-angstrom-linux-readelf and will define $READELF within the configure. Now I will use $READELF wherever readelf was used before. Wow and now we have a compiling glibc on OSX. That was fairly easy. On FreeBSD we have one more issue as we will need to recompile the kernel to allow a large enough Command-Line.
Now I needed to introduce an evil hack into our gmp-native.bb for darwin. Apple's gcc has certain issues with the assembly within the GNU mp code. Using none-apple-darwin as --host will force GNU mp to not use optimized but generic implementation of their tools.
And then we just compiled a full featured version of gcc 4.1.1 and it worked. At the end of the day we have a modern GNU toolchain on a non GNU system, sent patches upstream.
For the future we will fix the remaining GNUism within OpenEmbedded, make QtE and X11 cross compile nicely on OSX and we can create complete distributions on non GNU systems.
Thanks to the power of the two cores compiling, autoreconf and configure times are nice enough for the trial and error procedure. Also quilt has progressed into using less GNUism only requiring GNU sed and GNU getopt to be installed for almost working correctly. I have taken the quilt patch from fink to fix the remaining GNUism. Having quilt available is great as I will need to manage a lot of patches in the progress.
Fixing gcc was easy as well. It only has one conceptual misusage of autotools. Autoconf checks for the presence and usability of header files using CPP. In the case of gcc when building target libraries (e.g. target-libtsdc++ for arm-angstrom-linux) using /usr/bin/cpp to check for the presence of headers is not smart. e.g. libstdc++ found that I have a sys/filio.h header available. I have patched gcc 3.3,3.4,4.0,4.1 and 4.2 snapshots to use the just built compiler (xgcc) and use that as a preprocessor by adding the -E option. The result of this little patching is: The compilation of target libraries will never fail again because autoconf thinks certain features are available. This is good for people on BSD systems creating GNU toolchains and for uclibc people having less features enabled in their library. No more failing builds because host headers were used to determine target features.
Onto glibc. glibc is really mean as configure checks fail silently leading to later trouble. One big issue was the assumption of having binutils installed on my system. The configure check checked compiled bianries using 'readelf' to check for vertain features. I have arm-angstrong-linux-readelf installed on my system but no readelf and I won't ever have one. The fix is easy as well. Use AC_CHECK_TARGET_TOOL([READELF], [readelf] [readelf], [$PATH]) and it will search for arm-angstrom-linux-readelf and will define $READELF within the configure. Now I will use $READELF wherever readelf was used before. Wow and now we have a compiling glibc on OSX. That was fairly easy. On FreeBSD we have one more issue as we will need to recompile the kernel to allow a large enough Command-Line.
Now I needed to introduce an evil hack into our gmp-native.bb for darwin. Apple's gcc has certain issues with the assembly within the GNU mp code. Using none-apple-darwin as --host will force GNU mp to not use optimized but generic implementation of their tools.
And then we just compiled a full featured version of gcc 4.1.1 and it worked. At the end of the day we have a modern GNU toolchain on a non GNU system, sent patches upstream.
For the future we will fix the remaining GNUism within OpenEmbedded, make QtE and X11 cross compile nicely on OSX and we can create complete distributions on non GNU systems.
Subscribe to:
Posts (Atom)