Alexander Leidinger

Just another weblog

Aug
13

ICS on the Sam­sung Galaxy Tab 10.1

Last week I had a look if there are some news for an offi­cial update of the Galaxy Tab 10.1 to ICS. To my sur­prise there is one at least in Italy. The one I found to down­load was marked more or less for the Euro­pean mar­ket. Well… that was good enough for me and the night from Fri­day to Sat­ur­day I have spend to update the Tab by hand (unfor­tu­nately this includes a fac­tory reset, no smooth migra­tion from an old ver­sion, but at least I still have root access).

What I noticed so far:

  • OpenGL ES speed improved from 4.2 to 6.6 FPS.
  • I had some lock-ups so far, I do not know if this may be related to some restored data (app data and e.g. Bluetooth/WLAN con­fig restored with Tita­ni­um­Backup) or to bugs (Dalvik cache and cache par­ti­tion where clean, fac­tory reset was done too prior to restor­ing from the backup). I had to press the power but­ton for some sec­onds to ini­ti­ate a reboot. Most of the time it helped to wait a minute before enter­ing the PIN for the SIM. One time it did not help at all, the only way to get it work­ing was to take my WLAN Access Point (AP) offline, start the Tab, enter the PIN, and to restart the AP. At that point I had GPS and WLAN in the Tab acti­vated, in the lock-ups before I did not have GPS active. I had some­thing sim­i­lar like this with my Nexus S when it got ICS, some­how this resolved itself. Update 2012-08-14: I googled a bit, there was a bug in ICS 4.0.3 related to WLAN, but I have 4.0.4 on the Tab, so this may not be this. I also got the freeze with­out WLAN but with the mobile data con­nec­tion active. 2nd update 2012-08-14: If I dis­able account sync­ing with the mobile data con­nec­tion it does not freeze. I have not yet tried this with the WLAN con­nec­tion. Update 2012-08-16: The syn­chro­niza­tion of the cal­en­dar data caused the prob­lem. Delet­ing all data for any app with cal­en­dar in the name and re-syncing fixed the prob­lem. No freeze since I did this yesterday.
  • When I open/close a folder (much missed fea­ture in Android 3.x), the Tab speaks with me (some­thing like “Folder XXX opened” in the con­fig­ured lan­guage… that is a bit annoying).
  • I like the default back­ground image.
  • Update 2012-08-14: The bat­tery icon does stay green even when the bat­tery is nearly empty. :(

I was not able to test the Email APP yet, I am wait­ing for a warranty-replacement of the PSU of my server at home (Murphy’s law: Your PSU will break when you just started a big ren­o­va­tion of your kitchen and do not have time to take care about it, and when you get time a lot of peo­ple from the PSU-manufacturer which take care about warranty-replacements are in holiday).

I also need to check the mobile data con­nec­tiv­ity (qual­ity and speed), but I would expect that it is not worse than before. Update 2012-08-14: The down­load speed test shows sim­i­lar results than before, the upload speed test is slower, but this may be the mobile net­work here where I tested. At least I can con­firm that it works, mod­ulo the prob­lem of the freezes described above.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…
Share

Tags: , , , , , , , , ,
Jul
13

Book review: FreeBSD Device Drivers

In mid-April a woman from the mar­ket­ing depart­ment of No Starch Press con­tacted me and asked if I am inter­ested to do a pub­lic review of the FreeBSD Device Dri­vers book by Joseph Kong (no link to a book shop, go and have a look in your pre­ferred one). Just this sim­ple ques­tion, no strings attached.

I had my nose in some device dri­vers in the past, but I never wrote one, and never had a look at the big pic­ture. I was inter­ested to know how every­thing fits together, so this made me a good vic­tim for a review (novice enough to learn some­thing new and to have a look if enough is explained, and expe­ri­enced enough to under­stand what is going on in the FreeBSD ker­nel).

Some min­utes after I agreed to review it (but with a lit­tle notice that I do not know how long I need to review it), I had the PDF ver­sion of the book. That was faster than I expected (maybe I am too old-school and used to have paper ver­sions of books in my hands).

Let the review begin… but bear with me, this is the first time I do a real pub­lic review of a book (instead of a tech­ni­cal review for an author). And as this is my very own per­sonal opin­ion, I will not allow com­ments here. This page is all about my opin­ion while read­ing the book, ques­tions I have while read­ing the book shall serve as a hint about the qual­ity of the book and they should be answered in the book, not here.

In short, the book is not per­fect, but it is a good book. There is room for improve­ment, but on a very high level. If you want to write a device dri­ver for FreeBSD, this book is a must. I sug­gest to read it com­pletely, even chap­ters which do not belong to the type of dri­ver you want to write (spe­cially the case stud­ies of real dri­vers). The rea­son is that each chap­ter has some notes which may not only apply to the chap­ter in ques­tion, but to all kinds of device dri­vers. The long review fol­lows now.

The first chap­ter is titled “Build­ing and run­ning mod­ules”. The author begins with descrip­tion of the usual device dri­ver types (NIC dri­ver, pseudo-device, …) and how they can be added to the ker­nel (sta­t­i­cally linked in or as a mod­ule). The first code exam­ple is a small and easy ker­nel mod­ule, so that we do not have to reboot the sys­tem we use to develop a dri­ver (except we make a fault dur­ing dri­ver devel­op­ment which causes the machine to panic or hang). Every part of the exam­ple is well explained. This is fol­lowed by an overview about char­ac­ter devices (e.g. disks) and a sim­ple character-device dri­ver (so far a pseudo-device, as we do not have real hard­ware we access) which is not only as-well explained as the module-example, but there is also a note where the code was sim­pli­fied and what should be done instead.

After read­ing this chap­ter you should be able to write your own ker­nel mod­ule in 5 min­utes (well, after 5 min­utes it will not be able to do a lot — just a “hello world” – but at least you can already load/unload/execute some code into/from/in the kernel).

I have not tried any exam­ple myself, but I com­piled a lot of mod­ules and dri­vers I mod­i­fied in the past and remem­ber to have seen the described parts.

The sec­ond chap­ter explains how to allo­cate and free mem­ory in the ker­nel. There is the pos­si­bil­ity to allo­cate maybe-contiguous mem­ory (the nor­mal case, when your hard­ware does not do DMA or does not have the require­ment that the mem­ory region it makes DMA from/too needs to be con­tigu­ous), and really con­tigu­ous. For the size argu­ment of the free­ing of the the con­tigu­ous mem­ory there is the sen­tence “Gen­er­ally, size should be equal the amount allo­cated.”. Imme­di­ately I wanted to know what hap­pens if you spec­ify a dif­fer­ent size (as a non-native eng­lish speaker I under­stand this sen­tence in a way that I am allowed to spec­ify a dif­fer­ent size and as such are able to free only parts of the allo­cated mem­ory). Unfor­tu­nately this is not answered. I had a look into the source, the ker­nel frees mem­ory pages, so the size argu­ment (and addr argu­ment) will be rounded to include a full page. This means the­o­ret­i­cally I am able to free parts of the allo­cated mem­ory, but this is a source-maintenance night­mare (needs knowl­edge about the machine spe­cific page bound­aries and you need to make sure that you do the absolutely cor­rect size cal­cu­la­tions).  To me this looks more like as long as nobody is point­ing a gun at my head and tells me to use a dif­fer­ent size, spec­i­fy­ing the same size as made dur­ing the allo­ca­tion of this mem­ory region is the way to go.

After read­ing this chap­ter you should know how to kill the sys­tem by allo­cat­ing all the RAM in the kernel.

Again, I did not try to com­pile the exam­ples in this chap­ter, but the dif­fer­ence of the mem­ory allo­ca­tion in the ker­nel com­pared with mem­ory allo­ca­tion in the user­land is not that big.

The third chap­ter explains the device com­mu­ni­ca­tion and con­trol inter­faces (ioctl/sysctl) of a dri­ver. The ioctl part teached me some parts I always wanted to know when I touched some ioctls, but never both­ered to find out before. Unfor­tu­nately this makes me a lit­tle bit ner­vous about the way ioctls are han­dled in the FreeBSD lin­ux­u­la­tor, but this is not urgent ATM (and can prob­a­bly be han­dled by a com­mend in the right place). The sysctl part takes a lit­tle bit longer to fol­low through, but there is also more to learn about it. If you just mod­ify an exist­ing dri­ver with an exist­ing sysctl inter­face, it prob­a­bly just comes down to copy&paste with lit­tle mod­i­fi­ca­tions, but if you need to make more com­plex changes or want to add a sysctl inter­face to a dri­ver, this part of the book is a good way to under­stand what is pos­si­ble and how every­thing fits together. Per­son­ally I would have wished for a more detailed guide when to pick the ioctl inter­face and when the sysctl inter­face than what was writ­ten in the con­clu­sion of the chap­ter, but it is prob­a­bly not that easy to come up with a good list which fits most drivers.

After read­ing this chap­ter you should be able to get data in and out of the ker­nel in 10 minutes.

As before, I did not com­pile the exam­ples in this chap­ter. I already added ioctls and sysctls in var­i­ous places in the FreeBSD kernel.

Chap­ter 4 is about thread syn­chro­niza­tion – mutexes, shared/exclusive locks, reader/writer locks and con­di­tion vari­ables. For me this chap­ter is not as good as the pre­vi­ous ones. While I got a good expla­na­tion of every­thing, I missed a nice overview table which com­pares the var­i­ous meth­ods of thread syn­chro­niza­tion. Bren­dan Gregg did a nice table to give an overview of DTrace vari­able types and when to use them. Some­thing like this would have been nice in this chap­ter too. Apart from this I got all the info I need (but hey, I already wrote a NFS client for an exper­i­men­tal com­puter with more than 200000 CPUs in 1998, so I’m famil­iar with such syn­chro­niza­tion primitives).

Delayed exe­cu­tion is explained in chap­ter 5. Most of the infor­ma­tion pre­sented there was new to me. While there where not much exam­ples pre­sented (there will be some in a later chap­ter), I got a good overview about what exists. This time there was even an overview when to use which type of delayed exe­cu­tion infra­struc­ture. I would have pre­ferred to have this overview in the begin­ning of the chap­ter, but that is maybe some kind of per­sonal preference.

In chap­ter 6 a com­plete device dri­ver is dis­sected. It is the vir­tual null modem ter­mi­nal dri­ver. The chap­ter pro­vides real-world exam­ples of event-handlers, call­outs and taskqueues which where not demon­strated in chap­ter five. At the same time the chap­ter serves as a descrip­tion of the func­tions a TTY dri­ver needs to have.

Auto­mated device detec­tion with New­bus and the cor­re­spond­ing resource allo­ca­tion (I/O ports, device mem­ory and inter­rupts) are explained in chap­ter 7. It is easy… if you have a real device to play with. Unfor­tu­nately the chap­ter missed a para­graph or two about the sus­pend and resume meth­ods. If you think about it, it is not hard to come up with what they are sup­posed to do, but a lit­tle explicit descrip­tion of what they shall do, in what state the hard­ware should be put and what to assume when being called would have been nice.

Chap­ter 8 is about inter­rupts. It is easy to add an inter­rupt han­dler (or to remove one), the hard part is to gen­er­ate an inter­rupt. The exam­ple code uses the par­al­lel port, and the chap­ter also con­tains a lit­tle expla­na­tion how to gen­er­ate an inter­rupt… if you are not afraid to touch real hard­ware (the par­al­lel port) with a resistor.

In chap­ter 9 the lpt(4) dri­ver is explained, as most of the top­ics dis­cussed so far are used inside. The expla­na­tion how every­thing is used is good, but what I miss some­times is why they are used. The most promi­nent (and only) exam­ple here for me is why are call­outs used to catch stray inter­rupts? That call­outs are a good way of han­dling this is clear to me, the big ques­tion is why can there be stray inter­rupts. Can this hap­pen only for the par­al­lel port (respec­tively a lim­ited amount of devices), or does every dri­ver for real inter­rupt dri­ven hard­ware need to come with some­thing like this? I assume this is some­thing spe­cific to the device, but a lit­tle expla­na­tion regard­ing this would have been nice.

Access­ing I/O ports and I/O mem­ory for devices are explained in chap­ter 10 based upon a dri­ver for a LED device (turn on and off 2 LEDs on an ISA bus). All the func­tions to read and write data are well explained, just the part about the mem­ory bar­rier is a lit­tle bit short. It is not clear why the CPU reorder­ing of mem­ory accesses mat­ter to what looks like func­tion calls. Those func­tion calls may be macros, but this is not explained in the text. Some lit­tle exam­ples when to use the bar­ri­ers instead of an abstract descrip­tion would also have been nice at this point.

Chap­ter 11 is sim­i­lar to chap­ter 10, just that a PCI bus dri­ver is dis­cussed instead of an ISA bus dri­ver. The dif­fer­ences are not that big, but important.

In chap­ter 12 it is explained how to do DMA in a dri­ver. This part is not easy to under­stand. I would have wanted to have more exam­ples and expla­na­tions of the DMA tag and DMA map parts. I am also sur­prised to see dif­fer­ent sup­ported archi­tec­tures for the flags BUS_DMA_COHERENT and BUS_DMA_NOCACHE for dif­fer­ent func­tions. Either this means FreeBSD is not coher­ent in those parts, or it is a bug in the book, or it is sup­posed to be like this and the rea­sons are not explained in the book. As there is no explicit note about this, it prob­a­bly leads to con­fu­sion of read­ers which pay enough atten­tion here. It would also have been nice to have an expla­na­tion when to use those flags which are only imple­mented on a sub­set of the archi­tec­tures FreeBSD sup­ports. Any­way, the expla­na­tions give enough infor­ma­tion to under­stand what is going on and to be able to have a look at other device dri­vers for real-live exam­ples and to get a deeper under­stand­ing of this topic.

Disk dri­vers and block I/O (bio) requests are described in chap­ter 13. With this chap­ter I have a lit­tle prob­lem. The author used the word “unde­fined” in sev­eral places where I as a non-native speaker would have used “not set” or “set to 0″. The word “unde­fined” implies for me that there may be garbage inside, whereas from a tech­ni­cal point of view I can not imag­ine that some ran­dom value in those places would have the desired result. In my opin­ion each such place is obvi­ous, so I do not expect that an expe­ri­enced pro­gram­mer would lose time/hairs/sanity over it, but inex­pe­ri­enced pro­gram­mers which try to assem­ble the cor­re­spond­ing struc­tures on the (unini­tial­ized) heap (for what­ever rea­son), may strug­gle with this.

Chap­ter 14 is about the CAM layer. While the pre­vi­ous chap­ter showed how to write a dri­ver for a disk device, chap­ter 14 gave an overview about how to an HBA to the CAM layer. It is just an overview, it looks like CAM needs a book on its own to be fully described. The sim­ple (and most impor­tant) cases are described, with the hardware-specific parts being an exer­cise for the per­son writ­ing the device dri­ver. I have the impres­sion it gives enough details to let some­one with hard­ware (or pro­to­col), and more impor­tantly doc­u­men­ta­tion for this device, start writ­ing a driver.

It would have been nice if chap­ter 13 and 14 would have had a lit­tle schematic which describes at which level of the kernel-subsystems the cor­re­spond­ing dri­ver sits. And while I am at it, a schematic with all the dri­ver com­po­nents dis­cussed in this book at the begin­ning as an overview, or in the end as an annex, would be great too.

An overview of USB dri­vers is given in chap­ter 15 with the USB printer dri­ver as an exam­ple for the expla­na­tion of the USB dri­ver inter­faces. If USB would not be as com­plex as it is, it would be a nice chap­ter to start driver-writing exper­i­ments (due to the avail­abil­ity of var­i­ous USB devices). Well… bad luck for curi­ous peo­ple. BTW, the author gives point­ers to the offi­cial USB docs, so if you are really curi­ous, feel free to go ahead. :)

Chap­ter 16 is the first part about net­work dri­vers. It deals with ifnet (e.g. stuff needed for ifcon­fig), ifme­dia (sim­pli­fied: which kind of cable and speed is sup­ported), mbufs and MSI(-X). As in other chap­ters before, a lit­tle overview and a lit­tle pic­ture in the begin­ning would have been nice.

Finally, in chap­ter 17, the packet recep­tion and trans­mis­sion of net­work dri­vers is described. Large exam­ple code is bro­ken up into sev­eral pieces here, for more easy dis­cus­sion of related information.

One thing I miss after reach­ing the end of the book is a dis­cus­sion of sound dri­vers. And this is surely not the only type of dri­vers which is not dis­cussed, I can come up with crypto, firewire, gpio, watch­dog, smb and iic devices within a few sec­onds. While I think that it is much more easy to under­stand all those dri­vers now after read­ing the book, it would have been nice to have at least a lit­tle overview of other dri­ver types and maybe even a short descrip­tion of their dri­ver methods.

Con­clu­sion: As I wrote already in the begin­ning, the book is not per­fect, but it is good. While I have not writ­ten a device dri­ver for FreeBSD, the book pro­vided enough insight to be able to write one and to under­stand exist­ing dri­vers. I really hope there will be a sec­ond edi­tion which addresses the minor issues I had while read­ing it to make it a per­fect book.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…
Share

Tags: , , , , , , , , ,
Jul
09

Email app from Android 3.1 in Android 3.2?

As pre­vi­ously reported, I tried the update to Android 3.2 on my Tab and was not happy about the new EMail app. At the week­end I had a lit­tle bit of time, so I tried to get the Email.apk from Android 3.1 into Android 3.2.

Long story short, I failed.

Tita­ni­um­Backup PRO was restor­ing or hours (the option to migrate from a dif­fer­ent ROM ver­sion was enabled) until I killed the app, and it did not get any­where (I just emailed their sup­port if I did some­thing com­pletely stu­pid, or of this is a bug in TB). And a copy by hand into /system/apps did not work (app fails to start).

Ideas welcome.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…
Share

Tags: , , , , , ,
Dec
13

Sam­sung HMX-H200 camcorder

My wife decided that we need a cam­corder. As I am a good hus­band, I do not com­plain (she pays :-D ).

There was an offer in a super mar­ket nearby. Not as low as you can find in the inter­net, but if there is a prob­lem, it is much more easy to com­plain. For some­thing like this, I/we pre­fer this and am-are OK to spend a lit­tle bit more money for this con­ve­nience.

This cam­corder is record­ing to SDHC cards. Such cards have a speed rat­ing, and you need to take some min–speed one, to be able to record videos with a cam­corder. Unfor­tu­nately Sam­sung does not list the speed rat­ing some­where. I searched on the Sam­sung site in the spec­i­fi­ca­tions and in the FAQ. Noth­ing. After a lit­tle bit of googling I at least found a review where the record­ing time for spe­cific card-sizes where listed.

So I took the card-size in MB, divided it by the record­ing time in sec­onds, and got the data trans­fer rate per sec­ond for the spec­i­fied res­o­lu­tions. The 1080i res­o­lu­tion has the high­est trans­fer rate and as such it is the most inter­est­ing one to decide what kind of card one needs.

The high­est trans­fer rate seems to be less than 2.2 MB/s, so a class 4 SDHC card should be enough.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…
Share

Tags: , , , , , , , , ,
Dec
07

Sony Bravia and HD videos (via DLNA)

I made some more tests which video res­o­lu­tions my TV accepts via DLNA. While I was look­ing before a SD res­o­lu­tions, this time I took care about some HD res­o­lu­tions.

As the Sin­tel video in the 1024×436 res­o­lu­tion did not play, I tried to reen­code it to 1024×720 (for the enabled x264 options see below). This did not work either. After that I went to the offi­cial res­o­lu­tion of 1280×720, and this works. Ini­tially this video was encoded as High@L3.1, but with this the TV pro­duced some arti­facts on play­back. After chang­ing this to High@L4.0 (sim­ply by remux­ing instead of reen­cod­ing), the play­back was fine (warn­ing: increas­ing the H.264 level is OK, decreas­ing it if the video does not com­ply to the low­ered level, may cause prob­lems). I miss a set­ting in avide­mux for the level, it would be nice if there would be the pos­si­bil­ity to set it.

I also tested if the 1280×544 ver­sion of the Sin­tel video plays fine on the TV or not. It does not play fine, so there is prob­a­bly a hard require­ment on the com­plete res­o­lu­tion for HD video.

While doing this I noticed that tsMuxeR is trun­cat­ing the audio, instead of the 6 chan­nel audio it was before, the remuxed file has only two channels.

As I did not want to always go through all the set­tings to enter what I want, I made a lit­tle avidemux-script to setup (ECMA script + xml) every­thing for me. This was easy, I just took an exist­ing one (the Sony PSP one) as a base and changed the encod­ing options and the tar­get con­tainer (unluck­ily avide­mux 2.5.4 does not sup­port H.264 in MPEG-TS yet, so I have to use a MP4 con­tainer and remux it into the MPEG-TS stream afterwards).

The options I used for the x264-reencoding are –8x8dct –analyse all –mixed-refs –bime –weightb –subme 9 –b-rdo –ref 4 –b-adapt 2 –bframes 4 –direct auto –me umh (this includes b-pyramid, for which there are reports that it does not work).

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…
Share

Tags: , , , , , , , , ,