This is a minimalist blog in french/english. For comment you can use my email address : castet.matthieu <at> free.fr

===============================================================================
Titre : android tethering without hacking/rooting
Catégorie : Android
Date : 11-03-2011

See http://castet.matthieu.free.fr/blog/android_tethering.txt

===============================================================================
Titre : TI/Omap complexity
Catégorie : LowLevel
Date : 11-02-2011

At work I work on a omap processor on Linux. I feel ready bad how their
infrastructure is complex :
- they used u-boot, but have to split it because it is too big
- the kernel is expecting some init from u-boot and will crash/hang if not done
- their code is too much oriented for their dev board (some driver doing mux select, pads configuration).
- each board code is very big : lot's of stuff is duplicated
- their driver try to handle lot's of things, but in the end they are big, buggy

New version of the kernel seems to go in the right direction, but why they didn't do that first ?

We also ported our processor (P6) [1], to linux. Our usage was less complex than
TI (few power management, simpler controllers), but I am happy we did things simpler :
- a tiny bootloader that don't need to be splited
- simple clock handling (on/off) that isn't dynamic (bootloader select it)
- static mux selection in a array with macro at init time
- board config shared as much as possible
- static device selection

Why people doesn't apply KISS [2] ?
There no point of supporting of the features if it didn't work at the end.

[1] https://projects.ardrone.org/wiki/ardrone-api/Gpl
[2] http://en.wikipedia.org/wiki/KISS_principle

===============================================================================
Titre : Linux kernel ugliness
Catégorie : LowLevel
Date : 11-02-2011

Linux kernel support lot's of embeded device, but sometimes I believe the
maintainers don't do their job. It is even more true if it comes from big
company like intel.

Sometimes ago during the msm usb driver merge, I protested against a driver
duplication : msm use a tdi/arc/chipidea/mips/synopsys ehci otg. So I
tell them to use the in tree ci13xxx driver. They did a nice job and used it.

But now if I look at the kernel tree we have 4 duplicate drivers : 
- fsl_udc_core.c
- ci13xxx_udc.c
- langwell_udc.c
- mv_udc_core.c

And none of them is perfect. What a shame !

I post a mail on linux-usb, but I didn't expect too much of it. Once it is
in kernel tree, nobody will want to do the merge job.

PS : a similar thing already happened for s3c2410_udc and lh7a40x_udc
PS2 : did intel really buy a tdi core or it made a clone of it ?


===============================================================================
Titre : Bios Boot
Catégorie : LowLevel
Date : 28-12-2010

It is often unclear how traditional x86 pc boot.

The bios load the mbr [1] from the boot disk, and jump on it.
This is 440 bytes stage1 bootloader and 64 bytes ms-dos primary partition.
It should end with 0x55AA (signature) at offset 510.

The mbr will scan the primary partition (load by bios) and search for a
bootable one (there should be only one). It can also parse the extended
partitions (advanced mbr).

Once the bootable partition is found, a 512 bytes VBR is loaded from the boot
partition, and we jump on the start of it (stage2 bootloader).
It should end with 0x55AA (signature) at offset 510 for FAT.
The format depends of the filesystem. One example is fat [2] where code
is 448 bytes.

This bootloader will load from the filesystem a (much bigger stage3 bootloader).
For that it will use the custom features of the filesystem.
For example stage3 can be store as a special file (system, hidden, imutable)
that won't be touched by the OS and then a list of (offset,size) can be stored
in stage2. Then stage2 can load the file, by parsing this list.

Once this done, we have a load a big bootloader that can parse filesystem
and search for config files, kernel and initrd.

An example of such bootloader is syslinux [3]

NOTE : that some bootloader like grub does unsafe thing. They hijack some
reserved zone to store for the mbr a bigger stage2. This is referer as
62 sector gap between mbr and first partition. This was done do make
partition start on a cylinder/side boundary.

NOTE2 : all this pain is due by the fact that the BIOS only load 512 bytes.
On embeded system, the ROM (BIOS) often load 32/64K of code. This allow
to do everything in a stage1.

[1] http://en.wikipedia.org/wiki/Master_boot_record
[2] http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector
[3] http://syslinux.zytor.com/wiki/index.php/The_Syslinux_Project

===============================================================================
Titre : ASCII (hexa)decimal number to character
Catégorie : Shell
Date : 28-05-2010

I was searching on google a way to transform a character to ASCII number in
shell (and number to char). I only found solution with tr, gawk or perl.

Here is a simple one (pure posix shell)

#can be extended to support a larger range
ascii="a b c d e f g h i j k l m n o p q r s t u v w x y z"
ascii_offset=97
num_to_ascii()
{
	[ $1 -lt $ascii_offset -o $1 -gt $(($ascii_offset + ${#ascii}/2)) ] && exit 1
	pos=$(($1-$ascii_offset))

	set -- $ascii
	shift $pos
	echo $1
}

ascii_to_num()
{
	char=$1
	pos=$ascii_offset
	set -- $ascii
	while [ $# -gt 0 ]
	do
		if [ $1 = $char ]
		then
			break
		fi
		shift
		pos=$(($pos+1))
	done
	[ $# -eq 0 ] && exit 1
	echo $pos
}

===============================================================================
Titre : Cardbus
Catégorie : Hard
Date : ?-?-2009

I was wondering what was the different between old pcmcia card and new one.
The awnser is on http://www.pcmcia.org/faq.htm#cardbuscard
Old one are 16 bits (ISA style) and new one are 32 bits (pci style).

===============================================================================
Titre : Hot pixel sur un Canon A710
Catégorie : APN
Date : 15-10-2008

Il y a un peu moins de 2 ans, je me suis acheté mon premier APN : un Canon A710
pour un peu moins de 300 euros.  14 mois après son achat en faisant des tests,
je me suis aperçu que mon APN avait des hot pixel : sur certaines photo on
voyait des vilains point rouges, vert ou blanc en zoomant sur certaines zones.
Le pire c'est qu'après vérification une partie de ces hot pixel était présent
dès le début (ou j'aurais pu faire marcher la garantie constructeur d'1 an).

En début de semaine, j'ai demandé un devis au SAV Canon sur Paris (Vilma), mais
la facture s'élève a 100 euros... C'est cher pour un appareil qui en a couté
300.  En plus ils me dissent devoir changer le capteur (plus le zoom qui ne fait
qu'un avec le capteur), alors qu'une recherche sur le net fait pensé qu'ils
peuvent se contenter de remappé les pixels morts sur des pixels voisins.

Heureusement sous Linux, il existe des softs pour palier à ces problèmes.  Tout
d'abord jpegpixi [1], qui permet de réparer les photos déjà prises (et aussi les
futures). C'est un logiciel qui va éditer le fichier jpeg, pour le modifier que
les zonnes ou se trouve les pixels morts et éviter de trop altérer la photo par
une recompression complète.  Mais la conversion bayer vers rgb et la compression
jpeg sont déja passé par là et ont eu pour conséquence d'étaler le pixel mort.
En effet la conversion bayer[2] vers rgb va interpoler notre mauvais pixel sur
plusieurs pixel de l'image rgb. De même la compression jpeg va lisser notre
point de couleur sur plusieurs pixel autour.

Mais pour les APN Canon il existe un logiciel magique : chdk [3] [4]. Cet outil
va "véroller" le logiciel qui tourne sur votre appareil pour ajouter des
fonctionnalité en plus. Il permet notamment de remapper les hot pixel [5],
directement en sortie du capteur (ie avant la conversion rgb et la compression
jpeg).  C'est l'équivalent du remapage par Canon du capteur, le tout pour 0 euro
et sans devoir envoyer son appareil :)


[1] http://www.zero-based.org/software/jpegpixi/
[2] http://en.wikipedia.org/wiki/Bayer_filter
[3] http://chdk.wikia.com/wiki/CHDK
[4] https://tools.assembla.com/chdk/
[5] http://chdk.wikia.com/wiki/CHDK_firmware_usage/AllBest#Hot-Pixel_Removal_.28Build_100-16_and_later.29
===============================================================================
Titre : tente go sport cusco 3 30 euros
Catégorie : Rando
Date : 15-10-2008

Ce printemps (fin mai) je suis parti en corse pour 1 semaine et demi.  Prévoyant
de faire du camping, j'ai acheté une tente cusco 3 chez go sport.  Cette tente
était pas cher 30 euros et assez légère (moins de 4 Kg).  Elle ne fait plus
partie du catalogue go sport, mais c'est l'équivalent 3 places de Andes 2. Après
une montage il s'avère que la finition est très moyenne (du bon produit chinois)
: a l'intérieur le certain fils de nylon pendouille, et il manque une attache
pour maintenir la chambre intérieure.

A l'utilisation, elle se monte assez simplement et son large auvent est
agréable.  On regrettera par contre que le haut de la chambre intérieure soit
constitué d'une moustiquaire au lieu d'un matériaux respirant. En effet celle ci
laisse passer beaucoup d'air et parfois la pluie (voir plus bas).

Le toit imperméable est un peu juste et ne dépend pas assez bas. Il m'est arrivé
une mésaventure le dernier jour. Un chat du camping a voulu visité ma tente et a
réussit a passé entre le double toit. Il a laissé de belle trace de grille sur
la chambre en nylon.

En corse j'ai pu testé a fond l'imperméabilité. En effet j'étais à ajaccio le
30mai 2008 lors du record précipitation : plus de pluie en 24h qu'en un mois
d'habitude. Et ben la conclusion, c'est que cette tente n'est pas parfaitement
imperméable. Le toit a tendance a s'imbiber d'eau et à goutter à l'intérieur.
Et malheur comme la chambre intérieure est constitué d'une moustiquaire l'eau
passe à travers au lieu d'être absorbée.

Bref pour 30 euros il ne fallait pas s'attendre à une tente de compétition.


[1] http://www.go-sport.com/fiche-technique-Randonnée_2008-96-CAMPING-2909-GO_SPORT-ANDES_2_08-18996.html