Feeds:
Posts
Comments

Posts Tagged ‘linux’

image

L’immagine qui sopra è tratta dal datasheet che potete trovare sul sito della board; la riporto qui perché trovo sia interessante il fatto che, rispetto a tanta concorrenza (da Arduino Yun a pcDuino), qui l’interfaccia hardware Arduino-compatibile è fornita direttamente dal chip, e non da un microcontrollore a parte.

Da un lato, temo che così si perda la parte real-time che il microcontrollore permette di raggiungere, dall’altro però accedere all’interfaccia hardware (e magari anche all’API software di Arduino) dovrebbe essere possibile senza librerie intermedie (tipo la Bridge per lo Yun). Mi interessa semplicemente per pensare di costruirne un wrapper in altri linguaggi (chessò, Erlang per dire…).

Spero di riuscire ad aprire presto l’immagine Linux che viene fornita con la board, così da capire che librerie ci sono e cosa ci si può linkare (l’architettura è .586).

Read Full Post »

Screen on Kindle

Since I’m doing some performance/battery duration tests on my rooted Kindle 4NT, I decided I needed the always useful screen application, so that I could execute tests while connected over SSH, then detach the console and let it run for a while, only to re-attach back later to the same console and see what happened, monitor some logs and so on, all the while without interrupting anything. There are other ways to execute stuff in background, but this remains the most practical of all.

Now, I found out that the ncurses library is already installed on the OS, even if it doesn’t seem to be in the sources archive distributed by Amazon; the version 5.4 is sitting right there in /usr/lib; since it is the only external requirement for screen, I copied the library back to my system and directly into the sysroot created by crosstool, so that the linker could find it easily. Then I downloaded the screen sources.

And there the problems started to arise.

First, the fact that you can specify the target/host/build systems in ./configure is not clear at all, or even documented in the help of the script, so you need to improvise and find out by yourself. The configuration does not work by specifying CC/CFLAGS/LDFLAGS, or at least I could not make it work, the only correct way is to use the –host option.

The second problem was, of course, the neverending source of surprises that is the triptych of commands produced by the autoconf stuff: it sucks beyond belief, and in particular in this case it does not work at all for cross-compilation: there are some tests that cannot be executed, the script tells you that, and then simply stops. So you need to apply a well known patch (for example, I have used this one), which allows the script to output the makefiles regardless of those tests. Then, of course, is not over: the failed tests do not produce the correct options in config.h, so my advice is to execute (separately) a configuration for your own computer, then use the config.h generated for the computer for the Kindle sources too: it will compile fine, and the final binary works without problems on the Kindle.

Read Full Post »

In the last couple of weeks, I decided it was time to port my Erlang framework, ELIoT, that I develop as part of my Ph.D. thesis, to several other devices than the ones on which I already ported it (the Raspberry Pi and the Carambola). So last week I ported it to Android, and while I still have to refine it so that it can be executed on non-rooted devices (i.e., you don’t need to be root to do it), I decided to give the Kindle a try. This first post describes my findings in exploring the device itself, in a later post I will talk about ELIoT itself.

I have a Kindle 4th generation non-touch, and this “non-touch” adjective is quite important, since it changes the operating system version (and probably the toolchains/hacks). The first step is to jailbreak it (beware of the consequences! this may at best break your warranty, at worse brick the device!), using the main guides it is quite easy and (seems) with little risks, from the point of view of losing all your settings and books; at the end of the procedure, you can access it through WiFi and SSH.

Given the fact that my main objective was to cross-compile stuff, I started trying to figure out how to obtain the toolchain, and the answer is, as usual, crosstool-ng. Given the fact that the Kindle runs Linux, the non-proprietary part of the OS (i.e., everything except their ebook applications) is open source and they allow us to download the source code; in this way, we know that the 4th gen runs the 2.6.31 kernel and 2.12 libc, so I started to specify those in the ct-ng configuration; for binutils I decided for the latest stable release available, and in my first try I compiled gcc 4.7 Linaro edition.

Some guides on the Web seemed to say that the floating point type was softfp, but since there was so little clue about the toolchains for this particular Kindle, I decided to give the hardfp a try. It didn’t work out, as expected, but it led to an interesting side note: if you want to know what kind of fp a distribution is, you can execute

readelf -A

on an existing binary (I tried on the wpa_supplicant binary): if it contains the line

Tag_ABI_VFP_args: VFP registers

then it means it is hardfp; otherwise it is softfp (I checked against a binary for the Raspberry Pi, which I know is the former).

So, I recompiled the toolchain with softfp and tried the usual hello world: it worked! But the joy was limited: on a more complex application some assembly errors emerged, and at this point I thought the reasons could be

  1. I was using the 2.6.31.14 vanilla as kernel, but I didn’t know the subsubsubversion of the Kindle kernel and it may have been different
  2. maybe 4.7 was a too much advanced version of gcc to use.

So I changed the ct-ng configuration again and used the existing kernel sources downloaded from Amazon for my specific Kindle version, and changed the gcc version to 4.5.4, since /proc/version says:

Linux version 2.6.31-rt11-lab126 (jenkins-official@lucid-build02) (gcc version 4.5.3 20110406 (prerelease) (Linaro GCC 4.5-2011.04-0) ) #5 Sat Jan 12 20:39:09 PST 2013

this worked and I was able to compile and execute Erlang on the Kindle! Unfortunately, no screenshots here: access was from SSH, so all I can show you is:

[root@kindle erlangarm]# ./bin/erl -name erlang@192.168.1.3 -setcookie abc
Eshell V5.9.3.1 (abort with ^G)
(erlang@192.168.1.3)1> net_adm:ping(‘erlang@192.168.1.178’).
pong

copied directly from the terminal.

The final version of the ct-ng configuration is here, if anyone wants it; you have to adjust paths for the output directory and the kernel sources path (that you have to download from Amazon).

Read Full Post »

Due premesse sono necessarie a questa review: la prima è che sono lievemente biased dal fatto che l’hardware che ho nel Mac è il più potente tra i miei computer, quindi per alcune cose probabilmente quoto questo computer più di quanto valga veramente (rispetto ad un PC equivalente); la seconda è che l’esperienza d’uso non è e non può essere generica, ma deve per forza essere legata a quanto faccio nel mio dottorato (dettagli a seguire).

Ormai da alcuni mesi sono utilizzatore full-time (cioè almeno 5 giorni a settimana) di un MacBook Pro 15″ i7 cazzi e mazzi, che è capitato più o meno per caso nel mio ufficio e che sto quindi usando principalmente per lavoro. Ora, essendo io hard-core Linux, si potrebbe supporre che ci abbia installato subito una distribuzione a caso e non abbia fatto altro che riconfigurare il tutto con l’amato pinguino. Ebbene, la risposta è: no (e so che a qualcuno piange il cuore per questo…). Sinceramente, era diverso tempo che volevo testare Mac OS X, e quale migliore occasione di usarlo sul serio in un contesto lavorativo, per verificarne pregi e difetti rispetto a Linux ed a Windows… quello che segue è un resoconto di quest’esperienza (non in ordine temporale, non ho preso appunti in merito).

L’hardware

Devo per forza spendere due righe per dire che questo Mac è il mio computer più potente, come anticipato: ha un i7 4 core (8 con la virtualizzazione/hyper threading/whatever) ed una Nvidia come scheda video; l’hard disk è normale (non SSD, purtroppo) con 750 GB di spazio, in sostanza veramente un saaaacco di spazio (non sto cancellando praticamente nulla da 4 mesi…). Lo schermo va a 1680×1050, una discreta esagerazione dato che la prima manovra che ho fatto è stata aumentare la dimensione dei caratteri; per questo, nota a margine, trovo piuttosto inutile che i nuovi Mac abbiano risoluzioni assurde: se siete fotografi probabilmente vi piaceranno tanto, per qualunque altro uso non servono assolutamente a niente.

L’hardware, in sostanza, mi piace come potenza: poter lanciare make -j 8 ha il suo fascino, così come giocare a Urban Terror a 1680×1050 (inutile, ovviamente, su un motore grafico che ha 14 anni); il primo The Witcher gira ovviamente meglio qui che sul mio Dell, ma questo era prevedibile.

Agigungo, infine, che il touchpad di questo computer è semplicemente perfetto: mi scoccia un po’ il modo di fare click destro, che ogni tanto non mi riesce al primo colpo, ma per il resto è assolutamente ottimo e dopo un po’ che si utilizzano le gesture, vi verrà da farle anche sul vostro PC; lo scrolling “al contrario” di Mac OS X Lion è, per quanto mi riguarda, decisamente più intuitivo di quello standard (nota che criticavo da fuori, ma fino a che non lo provi non lo puoi giudicare), tant’è che dopo una giornata di utilizzo ho convertito a questa modalità tutti i miei PC. Forse questo scrolling è lievemente strano in un mouse esterno con la rotellina, ma se mi sono abituato così bene e così facilmente, pur dopo tanti anni di utilizzo dell’altra modalità, mi vien da dire che forse gli ingegneri di Apple avevano ragione (almeno in questo caso).

La batteria mi delude: non credo vada oltre le due ore e mezzo circa, che è quanto mi dura sul Dell con Linux, e sinceramente speravo in molto di più; in compenso, il Mac ha la ripresa dalla sospensione più rapida che la storia ricordi, e questo non è affatto male (vero, Linux?).

Il software

La summa, che anticipo subito, è che se Windows è praticamente inutilizzabile da informatico (a meno che non sviluppiate solo ed esclusivamente per Windows stesso, leggi: .NET), e Linux è invece perfetto da informatico, visto che avete il pieno controllo del mezzo, Mac OS X è esattamente la via di mezzo: è uno unix, quindi le cose che contano funzionano (i.e., killall), se volete fare operazioni “domestiche” non dovete fare salti mortali carpiati (ad esempio, guardare rai.tv, usare il microfono integrato senza impazzire con pulseaudio), se invece dovete lavorare a livello “più basso”, diventa un inferno.

Ma andiamo con ordine: le operazioni “domestiche”, quindi dal semplice browsing (ovviamente dopo aver installato un browser serio(TM)) all’ascolto di musica, alla visualizzazione di documenti et similia, funzionano direi in modo seamless, con le applicazioni correttamente integrate tra loro e con tutto l’insieme discretamente curato; i programmi che contano qualcosa in questo scenario funzionano out-of-the-box (vedi Skype, con webcam, microfono etc). Ciò che spesso mi lascia interdetto sono alcune piccole rifiniture, che trovo piuttosto silly:

  • non c’è taglia ma solo copia, se volete muovere le cose dovete trascinarle di cartella in cartella, con ogni tanto Finder che decide di aprire una nuova finestra senza motivo
  • Finder non ha i tab (!!!), come si possa oggi come oggi pensare ad un programma senza tab, francamente non lo capisco (perfino Filezilla ha i tab, e non dico altro…)
  • iTunes decide di ordinare le cartelle come vuole lui e non come voglio io, ad esempio creando 12 cartelle diverse per lo stesso album, se ci sono collaborazioni tra l’artista principale ed altri secondari (come in Thriller); forse c’è un’opzione per impedirglielo, ma vabbè… preferisco un approccio alla Amarok sinceramente
  • lo scroll non funziona in vim/less nella shell, o meglio lo scroll “scrolla” la finestra della shell e non il documento che avete aperto ad esempio in vim; non esistono il tasto pagsu, paggiù, inizio e fine riga, che rendono un incubo il navigare nella shell stessa (salvo usare combinazioni strambe, tipo ctrl+f per simulare paggiù)
  • il f***uto tasto Cmd: non ha alcun senso usare quello invece di Ctrl, come fanno tutti gli altri, ed oltretutto è in una posizione diversa, dove in genere nelle tastiere normali c’è Alt; morale: ogni volta che usate un PC, tenterete una scorciatoia con Cmd + qualcosa, che inevitabilmente diverrà Alt + qualcosa, e farà tutt’altro
  • se installate X (essenziale per cose come Matlab, Inkscape, Gimp), le scorciatoie tornano normali. Questo vuol dire che in una finestra dovete usare Ctrl, in un’altra Cmd, a seconda dell’applicazione del momento
  • sento parecchio la mancanza del solo tastiera di Linux: in Linux, infatti, riesco a fare tutto da tastiera; qui ogni tanto bisogna andare al mouse piuttosto che al touchpad, il che è chiaramente scomodo; ammetto di non conoscere tutte le scorciatoie da tastiera, ma temo avrebbero il solito Cmd di mezzo (sì lo so, questo punto sa più di scusa, eh purtroppo…)
  • esiste questo fantomatico inglese internazionale, che decide di accoppiare gli apostrofi con le vocali che seguono e transformarvele in accenti (se avete una tastiera non italiana), questo più o meno in tutte le applicazioni, e l’unico modo di disattivarlo (grazie Domenico!) pare sia passare ad inglese uk (o usa), dato che questa sostituzione automatica di fatto rende inusabile il computer (forse viene eseguita anche nella shell, ma dovrei controllare per esserne certo, e nel caso sarebbe veramente un’assurdità d’altri tempi, come se qualcuno dovesse scrivere accenti nella shell)
  • Office ha una versione a parte, quindi la mia licenza originale di Office Student edition è carta straccia.

Le cose serie

Quando poi si deve lavorare, iniziano le bestemmie: io per il mio lavoro ho bisogno di cross-compilare parecchio, per installare varie e variegate micro-distribuzioni di sistemi operativi su dispositivi “piccoli” (OpenWRT, piuttosto che TinyOS); nel fare questo, Mac OS X sembra quasi andare contro la sua natura di unix e complica immensamente le cose.

Tanto per cominciare, la struttura delle directory lascia il tempo che trova, e fa sì che trovare ad esempio la directory di installazione di Java non sia affatto banale (e vi serve per compilare librerie con JNI); come se non bastasse, il fatto che il sistema operativo sia a 64 bit non è così chiaro come sembra (emblematico che uname -p ritorni i386…), e spesso alcune cose vengono riconosciute con il numero sbagliato di bit quando le compilate… ah, 32 bit in Mac si chiamano universal, non 32 bit.

Progetti come MacPorts o altri (che non ho mai usato) permettono di compilarvi il solito software di cui avete bisogno, mettendolo in una cartella a parte nel sistema ed automatizzando un po’ parte del lavoro; quando però vi scaricate OpenWRT ed iniziate la compilazione della toolchain, emergono tutta una serie di complicazioni più o meno insulse: alcuni Makefile non trovano le librerie di base, perchè per qualche oscuro motivo non includono /usr/include, o in altri casi non includono la directory giusta di MacPorts, o si basano su uname per capire in che sistema si trovano, e come detto alcune opzioni falliscono… per non parlare di quando alcuni software si compilano a 32 bit ma non a 64 (o viceversa), e lì è necessario reinstallare alcune dipendenze nella versione giusta.

Ogni tanto scoprite che il gcc installato da MacPorts non compila certe cose, e dovete usare quello installato da XCode, o viceversa, e naturalmente il messaggio di errore che ottenete in compilazione è più o meno random e di certo non vi spiega cosa ci sia che non va realmente.

TinyOS, per fare un ultimo esempio, non va proprio: la versione ultima di nesc è esplicitamente riconosciuta come non compatibile con il Mac, quindi bisogna andare di macchina virtuale.

Tirando le somme

Al momento non mi vengono in mente altri esempi da fare, perciò tirerò le somme: al momento sono ancora con Mac OS X in questo computer (anche se un paio di volte sono stato molto vicino a mettere Linux (ovviamente ripartizionare è un incubo, e per farlo avete bisogno di un disco con Windows, e non dico altro…)), e dopo essermi abituato a quasi tutte le sue idiosincrasie, penso lo lascerò (ma potrebbe succedere qualcosa ad agosto… non ho ancora deciso del tutto…); se ad oggi dovessi comprarmi un computer mio (quindi non pagato da terzi), comprerei un PC e metterei Linux, per me non credo prenderei un Mac: mi mancano la libertà totale di installare cose dove dico io e come dico io, mentre apprezzo la possibilità di usare facilmente altre cose senza dover cercare configurazioni esoteriche, ma il primo aspetto batte il secondo nel guidare un’eventuale scelta.

Per quanto riguarda il futuro, sono livemente preoccupato dal fatto che Apple cerchi di avvicinare sempre di più Mac OS X ad iOS: temo che se la gabbia dorata del Mac cominci ad assomigliare a quella di iOS, bisognerà abbandonare la nave, e con una certa rapidità…

Read Full Post »

News flash: le USB parrebbero funzionare correttamente con l’ultimo update del firmware di Carambola.

Come avevo anticipato due giorni fa, ho scaricato l’update del firmware di Carambola ed ho ricompilato il tutto ieri (operazione non brevissima, dato che sono cambiate sia le versioni di gcc che di uclibc in uso, e questo ha implicato una ricompilazione a due passi di praticamente tutta la toolchain), ed ho fatto immediatamente un test con una chiavetta USB: viene riconosciuta tranquillamente, montata correttamente ed ho anche provato a creare qualche file o eseguire codice Erlang senza alcun problema o errore (e senza usare alcun hub).

Ora, è necessario qualche altro test intensivo, ma se tanto mi dà tanto, forse ci siamo…

P.S.: giusto per essere fair, l’unica altra spiegazione che posso dare è che la chiavetta testata ieri era diversa da quella che avevo provato in precedenza, e “di marca” (mentre l’altra era regalata ad una conferenza); non so se questo possa influire in maniera così decisa, ulteriori test vaglieranno tutte le ipotesi sul tavolo.

Read Full Post »

Avevo promesso un breve update su Carambola, e quindi eccolo qui.

Dico “breve” per il semplice motivo che non ho fatto molti esperimenti fino ad ora: la maggior parte del tempo l’ho infatti spesa per cercare di far funzionare la versione 15B di Erlang sul sistema OpenWRT installato sulla scheda, operazione che posso assicurarvi non è stata completamente banale causa limiti di spazio sulla flash (8 MB sono veramente pochi!) e necessità di patchare la nuova release (sorvolando sui problemi di cross-compilazione con il nuovo Mac che sto usando per lavoro), e per provare i pin GPIO presenti sempre sulla scheda stessa.

Il giudizio complessivo che posso dare ora come ora è il seguente: voto 6.5 in crescendo. Questo perchè:

  • lato connettività, direi che non ci sono particolari problemi: non ho provato le porte wired, se non per fare aggiornamento del sistema, ma con la connessione WiFi ho creato addirittura reti ad-hoc senza nessun problema (se non capire bene che parametri inserire nei file di configurazione). Certo, i chip scaldano abbastanza… sarebbe interessante capire se spegnendo la wireless scalda di meno, dato che magari in un contesto in cui si tiene la scheda collegata ad un router per far girare qualcosa tipo torrent o un mini-serverino (VPN et al.), potrebbe essere una possibilità concreta (in fondo sono gli usi tipici che si fanno con router riprogrammabili con OpenWRT, e ricordo che la Carambola ha di fatto un set hardware di quel tipo)
  • lato connettività hardware (GPIO, SPI, I2C etc), scarseggiamo discretamente: far funzionare i GPIO è in realtà piuttosto semplice (la modalità più facile è leggendo e scrivendo il device /dev/gpio), ma abilitarli non è facile e/o chiarissimo, dato che il chip RT3050 ha i pin che possono funzionare secondo diverse modalità; esistono alcune guide sulla Wiki o sul forum, ed un tool che è necessario scaricare per scrivere alcuni valori nei registri del microprocessore, ma la cosa resta non banale. Con SPI e I2C sembrano esserci un po’ di ritardi lato software, non è chiarissimo se le cose funzionano o meno: in particolare, con SPI pare che le velocità siano discretamente lente. Le cose non vanno meglio con le USB, dove pare che l’hub integrato nella devboard non riesca a reggere benissimo ad alcuni picchi di potenza; pare in realtà che il problema si risolva usando uno hub esterno, il che se risolvesse il problema sarebbe decisamente interessante, vedi punto successivo; non ho ancora testato questa ultima soluzione, ma mi ripropongo di farlo al più presto
  • lo spazio su disco è veramente poco (almeno, per i miei usi): chiaramente, la memoria flash interna viene usata solo per installare i programmi, ma ce ne stanno veramente pochi; per questo, sarebbe molto importante far funzionare la presa USB, anche come repository per applicazioni tipo server Web/FTP/p2p, magari collegando addirittura hard disk esterni (meglio se anche alimentati esternamente, penso)
  • recentemente gli sviluppatori hanno rilasciato una 2.0 del software: l’ho scoperto oggi, ho ricompilato mezzo mondo ed ora ho un’immagine pronta da testare, vedremo se ci sono stati dei benefici…

Ora, ho scritto “in crescendo” perchè alcuni dei problemi riportati qui sopra si stanno risolvendo (anche se mooolto lentamente) soprattutto sui forum, dove se non altro gli sviluppatori hw/sw intervengono spesso e volentieri per aiutare gli utenti, ed il forum stesso inizia ad essere un po’ più frequentato rispetto a qualche mese fa; resta comunque un device utile all’interno di un progetto che seguo nell’ambito del mio dottorato, quindi continuerò ad usarlo e non appena ho qualche statistica ed opinione più ampia non esiterò a pubblicarla (ad un certo punto spero infatti di raggiungere una release stabile del software di cui ho bisogno, così da potermi concentrare nell’uso della scheda invece che nell’uso della sua toolchain di compilazione!).

Peraltro, sto giusto pensando di acquistarne una seconda “ad uso privato”, con tanto di scatola, da usare a casa come piccolo database per salvare dati da sensori…

Read Full Post »

If, someday, your Intel-equipped computer should stop having OpenGL working in the X session, it may be due to the (completely useless) installation of NVidia/ATI drivers… so, open a shell and type in as follows:

sudo apt-get purge nvidia*
sudo apt-get purge fglrx*
sudo apt-get install –reinstall xserver-xorg-video-intel libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core
sudo dpkg-reconfigure xserver-xorg
sudo update-alternatives –remove gl_conf /usr/lib/nvidia-current/ld.so.conf

Read Full Post »

Older Posts »