Openmoko

I am currently implementing GSM ARFCN range encoding and I do this by writing the algorithm and a test application. Somehow my test application ended in a segmentation fault after all tests ran. The first thing I did was to use gdb on my ... [More] application:$ gdb ./si_test(gdb) r...Program received signal SIGSEGV, Segmentation fault.0x00000043 in ?? ()(gdb) bt#0 0x00000043 in ?? ()#1 0x00000036 in ?? ()#2 0x00000040 in ?? ()#3 0x00000046 in ?? ()#4 0x00000009 in ?? ()#5 0xb7ff6821 in ?? () from /lib/ld-linux.so.2The application crashed somewhere in glibc on the way to the exit. The next thing I used was valgrind but it didn't report any invalid memory access so I had to resort to todays tool. It is called mudflap and part of GCC for a long time. Let me show you an example and then discuss how valgrind fails and how mudflap can help.int main(int argc, char **argv) { int data[23]; data[24] = 0; return 0;}The above code obviously writes out of the array bounds. But why can't valgrind detect it? Well we are writing somewhere to the stack and this stack has been properly allocated. valgrind can't know that &data[24] is not part of the memory to be used by data.mudflap comes to the rescue here. It can be enabled by using -fmudflap and linking to -lmudflap this will make GCC emit extra code to check all array/pointer accesses. This way GCC will track all allocated objects and verify the access to memory before doing it. For my code I got the following violation.mudflap violation 1 (check/write): time=1350374148.685656 ptr=0xbfd9617c size=4pc=0xb75e1c1e location=`si_test.c:97:14 (range_enc_arfcns)' /usr/lib/i386-linux-gnu/libmudflap.so.0(__mf_check+0x3e) [0xb75e1c1e] ./si_test() [0x8049ab5] ./si_test() [0x80496f6]Nearby object 1: checked region begins 29B after and ends 32B aftermudflap object 0x845eba0: name=`si_test.c:313:6 (main) ws'I am presented with the filename, line and function that caused the violation, then I also get a backtrace, the kind of violation and on top of that mudflaps informs me which objects are close to the address I allocated. So in this case I was writing to ws outside of the bounds. [Less]

The OpenBSC and Osmocom project has grown a lot in recent years. It has grown both in people using our code, participating in the development and also in terms of amount of sourcecode. As part of the growth we have more advanced testing and the ... [More] following blog posts will show what we are doing.Each post will describe the problems we were facing and how the system deployed is helping us to resolve these issues.OpenBSC/Osmocom and continous integration (Jenkins)OpenBSC/Osmocom and GNU autotest (unit testing)OpenBSC/Osmocom and End-to-End tests [Less]

This part of a series of blog posts about testing inside the OpenBSC/Osmocom project. In this post I am focusing on continuous integration with Jenkins.ProblemWhen making a new release we often ran into the problem that files were missing from the ... [More] source archive. The common error was that the compilation failed due some missing header files.The second problem came a bit later. As part of the growth of OpenBSC/Osmocom we took code from OpenBSC and moved it into a library called libosmocore to be used by other applications. In the beginning our API and ABI of this new library was not very stable. One thing that could easily happen is that we updated the API, migrated OpenBSC to use the new API but forgot to update one of the more minor projects, e.g. our TETRA decoder. SolutionThe solution is quite simple. The GNU Automake buildsystem already provides a solution to the first problem. One simply needs to call make distcheck. This will create a new tarball and then build it. Ideally all developers use make distcheck before pushing a change into our repository but in reality it takes too much to do this and one easily forgets this step.Luckily CPU time is getting more and more affordable. This means that we can have a system that will run make distcheck after each commit. To address the second part of the problem we can rebuild all users of a specific library, and do this recursively.The buzzword for this is Continuous Integration and the system of our choice is Jenkins (formerly known as Hudson). Jenkins has the concept of a Job and a Node. A Job can be building a certain project, e.g. building libosmocore. A Node is a physical system with a specific compiler. A Job can instruct Jenkins to monitor our git repositories and then schedule the job to be build.In our case we have nodes for FreeBSD/AMD64, Debian6.0/i386 and mingw/i386. All our projects are multi-configuration projects. For some of our Jobs we use it to build the software on FreeBSD, Debian and mingw for others only on Debian. Another useful feature is the matrix build. This way one job can build several different configurations, e.g. debug and release.Jenkins allows us to have dependencies between Jobs and we are using this to rebuild the users of a library after a change, e.g. build libosmo-abis after libosmocore.The build-status can be reported by EMail, irc but I generally use the RSS feed feature to find out about broken builds. This way I will be made aware of build breakages and can escalate it by talking to the developer that has caused the breakage.Jenkins of OsmocomConclusionThe installation of Jenkins makes sure that the tarballs built with make dist contains everything needed to build the software package and we have no silent build breakages in less active sub-projects. A nice side-effect is that we have less Emails from users due build breakages. Setting up Jenkins is easy and everyone building software should have Jenkins or a similar tool.OutlookWe could have more build nodes for more Linux distributions and versions. This mainly depends on volunteers donating CPU time and maintaining the Jenkins Node. Jenkins offers a variety of plugins and it appears to be easy to write new plugins. We could have plugins that monitor and plot the binary size of our libraries, check for ABI breakages, etc. [Less]

OpenPhoenux project The OpenPhoenux project by the german company “Golden Delicious Computers” (goldelico) is creating a fully free software compatible mobile handheld plattform, based upon an open hardware design. The first step was to design a ... [More] motherboard fitting the Openmoko Neo Freerunner, so owners of Openmoko phones could “upgrade” their devices to state of the art hardware. To finance the production of the first big batch of GTA04 boards, goldelico collected preorders of interested people [0]. This “Group Tour” enabled them to start production of about 200 boards, which started to ship to it’s new owners in May 2012 and the last ones are going to be shipped in the coming weeks. Now – about one year and a lot of production complications later – the first batch of GTA04A4 boards is finished [1] and the next one is being prepared [2]. It will include the new GTA04A5 board design, providing some minor bug fixes, and a now working production process. If you’re interested in one of the new GTA04A5 boards, please subscribe to the OpenPhoenux-Community mailinglist, to get notified about the next production batch and the next round of preorder collection. Visit the project’s website at: www.OpenPhoenux.org OpenPhoenux 2804 – Smartphone The OpenPhoenux 2804 is a smartphone providing a 2.8” touchscreen and a GTA04 core. It’s case can be produced by a 3D printer. Technical Specifications: 800 MHz / 1GHz ARM Cortex-A8 processor PowerVR SGX integrated graphics 2.84” (43mm x 58mm) VGA touchscreen HSDPA 3G modem 512MB RAM 512MB internal memory + micro SDHC up to 32GB WLAN, Bluetooth, GPS, FM Transceiver Accelerometer, Compass, Gyroscope, Barometric Altimeter, Camera USB 2.0 port, 2.5mm headset port, GPS antenna port, video out QtMoko, SHR, Android (Replicant), Debian, … OpenPhoenux 7004 – Tablet The OpenPhoenux 7004 is a free software centric tablet, powered by a 7.0” touchscreen and the same GTA04 core, as it’s small brother OpenPhoenux 2804. This tablet was developed while solving the GTA04 production problems and is in the prototyping phase at the moment. So it’s not yet ready to order, unfortunately. Technical Specifications: 1GHz ARM Cortex-A8 processor PowerVR SGX integrated graphics 7” (140mm × 110mm) VGA touchscreen HSDPA 3G modem 1GB RAM 512MB internal memory + micro SDHC up to 32GB WLAN, Bluetooth, GPS, FM Transceiver Accelerometer, Compass, Gyroscope, Barometric Altimeter USB 2.0 port, 3.5mm headset port, Ethernet port, GPS antenna port, video out QtMoko, SHR, Android (Replicant), Debian, … If you’re interested in high quality open hardware, “Made in Germany”, which is fully compatible with you favorite free and open source software, you should definitely track the projects mentioned above and jump in to get one of those great devices once you’re ready. I’m absolutely satisfied with my GTA04A3 early adopter board, which I’m happily using since over one year! [0] http://lists.goldelico.com/pipermail/gta04-owner/2011-November/000679.html [1] http://lists.goldelico.com/pipermail/community/2012-September/000091.html [2] http://lists.goldelico.com/pipermail/community/2012-October/000103.html [Less]

When I published my last post about ARM boards there were many questions and suggestions with interesting devices. Thank You all for it.But there were also suggestions about ARM9 or ARM11 based devices. So I decided that it is good time to write what ... [More] interest me now in ARM world.But first some inventory. I had/used/have several devices with ARM cpu:StrongARM (armv4) one:Sharp Zaurus SL-5500 (which took me to ARM world)ARM920 (armv4t) ones:Openmoko GTA01 bv3, bv4 (s3c2410)EDB9301 (EP9301 cpu)Sim-One (EP9307)ARM926 (armv5te) ones:Sharp Zaurus sl-5600 (pxa250)Sharp Zaurus c760/sl-6000 (pxa255)Sharp Zaurus sl-c3000 (pxa272)Sheevaplug (kirkwood)Atmel devboards (at91sam9263, at91sam9m10)ST-Microelectronics/ST-Ericsson NDK-15, NHK-15 (st88n15)Nokia 770 (omap1710)Linksys NSLU2 (ixp425 iirc)ARM1136 (armv6) ones:Nokia N810 (omap2430)Bug r1.0, r1.2 (i.mx31)Cortex-A8 (armv7a) ones:Beagleboard B7, B7, C3 (omap3430)Nokia N900 (omap3430)Nexus S (exynos3)Genesi Efika MX Smartbook (i.mx51)Freescale Quickstart (i.mx53)Cortex-A9 (armv7a) ones:Pandaboard EA1, A1 (omap4430)Archos G9 80 (omap4430)All of that during last 8 years. Most of my ARM live so far was around ARM926 based devices (some of them still can not be listed here) and I do not want to go there again. Kirkwood core was fastest one with 1.2GHz clock and 512MB of RAM it was really fast machine. I only missed Serial ATA in my Sheevaplug (rev 1.0) but even with hard drive on USB it was nice improvement.Then I played a bit with ARM11 processors. Ok, they were faster than most of ARM9 cpus but I already had experience with Sheevaplug. And after few months first Cortex-a8 board landed on my desk — I got Beagleboard B7 from Bug labs as test platform for their new device. This was improvement!I still remember my reaction when connected it to normal LCD monitor and saw it used at 720p resolution (1680×1050 was a bit hard for omap3). Moved to Nokia N900 few months later and found that fast cpu means nothing when paired with slow storage and not enough memory for system.So today I prefer to not look below Cortex-A9 (or comparable cores like ones from Qualcomm or Marvell). Hope to play one day with Cortex-A5 (which should replace ARM926 one day) just to see how low-end armv7a cpu behave.And wait for ARMv8 to hit market.Related content: Does Vortex86sx based devices are worth something? Bought Archos 80 G9 Turbo tablet My palmtops story OpenZaurus time is over – long live Ångström What makes a good developer board?All rights reserved © Marcin Juszkiewicz What interest me in ARM world was originally posted on Marcin Juszkiewicz website [Less]

It seems, somehow, for the last few months, I've been working on layout. I'm not quite sure how it happened, as anyone who's spoken to me or follows me on Twitter would know that I have a very healthy fear of the Gecko layout code. I still have that ... [More] fear, but I'd like to think now that it's coupled with a tiny amount of understanding; understanding that has, dare I say it, even let me have fun while working on this code! Those of you that have used browsers on mobile phones (all of you?), especially not the very latest phones, may be familiar with an annoying problem. That is, elements that have position:fixed in their style tend to jump around the place like they've had too much coffee. You commonly see this on sites that have a persistent bar at the top or bottom of the page, or floating confirmation notifications, things like this. Brad Frost wrote about this far more eloquently than I could here. This has always annoyed me, especially after learning more about how browsers work. Certainly in Gecko, we have all of the context we need for this not to happen. It also ended up that this problem had been worked on long before I even joined Mozilla last year, so that made it doubly surprising that we suffered from this problem in all releases of Firefox Mobile. When I first came across this last year, I discovered that the support was already there in the old Firefox Mobile, but disabled by default due to it causing test failures. I was working on other things then, and wasn't at all acquainted with layout code, so I let it be. Revisiting it for the new, native Firefox Mobile though, these test failures didn't exist anymore. Enabling this basic support that would let position:fixed elements move and zoom with user input correctly was not too big a deal - just flip an environment variable and write a small amount of support code. This landed in Firefox 15 and is tracked in Bug 607417. Just this is enough for a lot of mobile sites to start using position:fixed (I'm looking at you, Twitter and Facebook!). This wasn't enough for me though. Around this time, Android 3.x (Honeycomb) tablets had been around for quite a while and the Galaxy Nexus with Android 4.0 (Ice-cream Sandwich) had just come out, both with even better support for position:fixed. Not to mention the iPhone, which has excellent support. A problem with our implementation in Firefox 15, is that anything fixed to the bottom or right of the screen, or anything that doesn't anchor to the top-left in any way, may become inaccessible after zooming in. In recent versions of the Android stock browser, not only do these remain accessible, but they zoom very smoothly too. Not wanting to be one-upped by what could be considered our main competition, I started to work on more comprehensive position:fixed support. This work was tracked in Bug 758620. When zooming in our browser, we don't change how the page is laid out, but fixed position elements are still rendered relative to the viewport. What we want (at least, for now) is for fixed position elements to lay out with respect to this viewport so that they always remain visible, and to transition smoothly between these states. To achieve this, I changed layout so that fixed position elements are laid out to what we call the scroll-port. When we zoom in, we change the scroll-port, otherwise you wouldn't be able to scroll to the bottom-right of the page, but this only changes scrolling behaviour and nothing else. This change also made it so that fixed-position children of the document would be relayed out when this scrollport was changed. This fixed the inaccessibility problem, but left nasty-looking transitions when zooming in. To fix the transitions was quite a bit more comprehensive and lead me down a long path of causing and fixing various layout bugs. When a page is rendered, the DOM tree is parsed into a frame tree, which better represents the layout of the page. This frame tree is then parsed into a display-list, which represents how to draw the page. This display-list is then optimised and parsed/drawn into a layer tree, which is the final representation before we composite it. There's cleverness to make sure that layers aren't recreated unnecessarily, but that's another subject for another time. We wanted to be able to annotate the layer tree so that when compositing, we have enough information to determine how to place fixed-position layers when zooming. This involved creating a new display-list item with the information about how the element is fixed (to the top? left? right? bottom?), and also that would guarantee that the items representing this element would end up on their own layer. Once this was done, code in the compositor was added to leverage this information and draw layers in the right place. This is an area that a lot of browsers have difficulty with, so it was a fun problem to work on. Try out a couple of my test-cases if you're interested, they expose how different browsers handle this situation, and in the case of a few of them, some bugs :) We're still not perfect, but we're better than we were before - and to my feeling, we're adequate now. This work landed in Firefox 16. So is there work left to do? Well, unfortunately, yes. I've just finished off support for fixed backgrounds and backgrounds with multiple fixed/non-fixed layers, and this will arrive in Firefox 18. This is tracked in Bug 786502. I also think that the best behaviour would be for fixed position elements to layout to whichever is largest of the CSS viewport or the scroll-port, and for scrolling to be within the CSS viewport and push the edges when you reach them. I'm told this is what happens in IE10 on Windows 8, and is similar (but slightly better) to what gets done in Safari on iOS. I think it's about time for a break from this particular feature for me, though. [Less]

This post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar. java-gnome 4.1.2 (30 Aug 2012) Applications don’t stand idly by. After a bit of a break, we’re back with a second ... [More] release in the 4.1 series covering GNOME 3 and its libraries. Application for Unique The significant change in this release is the introduction of GtkApplication, the new mechanism providing for unique instances of applications. This replaces the use of libunique for this purpose, which GNOME has deprecated and asked us to remove. Thanks to Guillaume Mazoyer for having done the grunt work figuring out how the underlying GApplication mechanism worked. Our coverage begins in the Application class. Idle time The new Application coverage doesn’t work with java-gnome’s multi-thread safety because GTK itself is not going to be thread safe anymore. This is a huge step backward, but has been coming for a while, and despite our intense disappointment about it all, java-gnome will now be like every other GUI toolkit out there: not thread safe. If you’re working from another thread and need to update your GTK widgets, you must do so from within the main loop. To get there, you add an idle handler which will get a callback from the main thread at some future point. We’ve exposed that as Glib.idleAdd(); you put your call back in an instance of the Handler interface. As with signal handlers, you have to be careful to return from your callback as soon as possible; you’re blocking the main loop while that code is running. Miscellaneous improvements Other than this, we’ve accumulated a number of fixes and improvements over the past months. Improvements to radio buttons, coverage of GtkSwitch, fixes to Assistant, preliminary treatment of StyleContext, and improvements to SourceView, FileChooser, and more. Compliments to Guillaume Mazoyer, Georgios Migdos, and Alexander Boström for their contributions. java-gnome builds correctly when using Java 7. The minimum supported version of the runtime is Java 6. This release depends on GTK 3.4. AfC You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch from ‘mainline‘: $ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome though if you’re going to do that you’re best off following the instructions in the HACKING guidelines. AfC [Less]

Last week I wrote briefly about using wget and curl to test RESTful interfaces. A couple people at CERN wrote in to suggest I look at a tool they were quite happy with, called httpie. I’m impressed. It seems to strike a lovely balance between ... [More] expressiveness and simplicity. What’s especially brilliant is that it’s written for the common case of needing to customize headers and set specific parameters; you can do it straight off the command line. For what I was doing last week: $ http GET http://localhost:8000/muppet/6 Accept:application/json ... sets the Accept header in your request; sending data is unbelieveably easy. Want to post to a form? -f gets you url encoding, and meanwhile you just set parameters on the command line: $ http -f POST http://localhost:8000/ name="Kermit" title="le Frog" POST / HTTP/1.1 Accept: */* Accept-Encoding: gzip Content-Type: application/x-www-form-urlencoded; charset=utf-8 Host: localhost:8000 User-Agent: HTTPie/0.2.7 name=Kermit&title=le+Frog ... Nice. If you’re sending JSON it does things like set the Content-Type and Accept headers to what they should be by simply specifying -j (which sensibly is the default if you POST or PUT and have name=value pairs). And, -v gets you both request and response headers; if you’re testing at this level you usally want to see both. Good show. $ http -v -j GET http://localhost:8000/muppet/6 GET /muppet/6 HTTP/1.1 Accept: application/json Accept-Encoding: gzip Host: localhost:8000 User-Agent: HTTPie/0.2.7 HTTP/1.1 200 OK Cache-Control: max-age=42 Content-Encoding: gzip Content-Type: application/json Date: Thu, 09 Aug 2012 03:52:27 GMT Server: Snap/0.9.1 Transfer-Encoding: chunked Vary: Accept-Encoding { "name": "Fozzie" "title": "Bear" } $ Speaking of bears, I’m afraid to say it turned out to be quite the bear getting httpie installed on Ubuntu. I had to backport pygments, requests, python-oathlib, and pycrypto from Quintal to Precise, and meanwhile the httpie package in Quintal was only 0.1.6; upstream is at 0.2.7 and moving at a rapid clip. I finally managed to get through dependency hell; if you want to try httpie you can add my network tools PPA as ppa:afcowie/network. I had to make one change to httpie: the default compression header in python-requests is Accept-Encoding: identity, deflate, compress, gzip which is a bit silly; for one thing if the server isn’t willing to use any of the encodings then it’ll just respond a normal uncompressed entity, so you don’t need identity. More importantly, listing deflate and compress before gzip is inadvisable; some servers interpret the order encodings are specified as an order of preference, and lord knows the intersecting set of servers and clients that actually get defalate right is vanishingly small. So, Accept-Encoding: gzip Seems more than sufficient as a default; you can always change it on the command line if you have to for testing. Full documentation at github; that said, once it’s installed, http --help will tell you everything you’d like to know. AfC [Less]