Linux supports overriding your computer ACPI tables by adding updated tables to the initrd. Checkout your local documentation at the linux tree at Documentation/admin-guide/acpi/initrd_table_override.rst.

I just uploaded to Debian a small initramfs-tools hook to add tables found at /var/lib/acpi-override/ to the initrd. For now, it's all that it does. The users have to modify the tables themselves and drop them at the referred directory.

It should be on the NEW queue and out to unstable after some time, and it's maintained at salsa.

My usecase for this is a small change to the DMAR table of my Libreboot-enabled X200, so I can experiment with IOMMU on it.

As future work, I may consider a tool to help at least update the OEM revision of the tables, to make it less error-prone to users to update them.

I hope this is useful to other people.

I got a Thinkpad X200 running Libreboot. It uses an Intel CPU that has a TSC (Time Stamp Counter), which allows software to count the passage of time by the number of cycles. It's a 64-bit counter that used to count the number of CPU cycles. With CPUs changing clocks to save power, new CPUs (more than a decade old as shown by my X200) support a constant TSC that runs under a different clock whose tick duration is constant. This is supported by the X200 processor I have, and Linux will show it as constant_tsc on /proc/cpuinfo.

However, Linux won't use the TSC as its clock source if it's marked unstable, and it is by idle drivers in certain circumstances. The idle driver changes CPU power states and that may stop the TSC from ticking, unless the processor has an Invariant TSC, what Linux calls nonstop_tsc (at /proc/cpuinfo). That is not the case of my processor, so the idle drivers will mark the TSC as unstable unless they are not loaded or won't change states.

In order to do the latter, the ACPI driver (the one that ends up being used because the intel_idle does not support my processor), one needs to add processor.max_cstate=0 to the command line. That will likely save less power, which will cause the X200 to consume battery power faster. But for some of the experiments I have been running with KVM and the TSC, that is a trade-off I need to pay.

Há algumas semanas, várias pessoas passaram a se comunicar no canal de IRC #libreplanet-br através do protocolo Matrix. Coincidentemente, uma série de ataques de spam começaram a ocorrer na rede Freenode poucos dias depois.

A solução para impedir o spam foi exigir nicks registrados para o canal. No entanto, parece que nenhum usuário da rede Matrix conectado ao nosso canal estava registrado, impedindo-os que se reconectassem caso fossem desconectados. Infelizmente, o bot da ponte IRC/Matrix acabou também expulsando os usuários.

Para resolver este problema, é necessário se registrar na rede IRC Freenode. Através da ponte IRC/Matrix em matrix.org, os seguintes passos são recomendados.

Caso queira utilizar um nick diferente na rede IRC, inicie uma conversa com @appservice-irc:matrix.org e envie a mensagem "!nick meu_nick_no_IRC". No meu caso, utilizei "!nick cascardo[m]", mas o [m] pode ser removido. Eu mantive porque continuo entrando no IRC diretamente.

Inicie uma conversa com @freenode_NickServ:matrix.org, e utilize o comando "register senha email". Assim, seu nick estará registrado na rede IRC Freenode com a respectiva senha e email.

Inicie uma conversa com @appservice-irc:matrix.org e utilize o comando "!storepass senha". Desta forma, a ponte IRC/Matrix em matrix.org armazenará a sua senha e a enviará ao NickServ sempre que reconectar ao IRC. Caso não queria armazenar sua senha em matrix.org, você terá que se identificar com o Nickserv sempre que uma reconexão ao IRC acontecer.

Para se autenticar com o Nickserv manualmente, envie o comando "identify senha" para @freenode_NickServ:matrix.org.

Por fim, ainda tive erros ao tentar entrar no canal #libreplanet-br. Tive que "esquecer a sala" no Riot (cliente Matrix), e entrar novamente em #freenode_#libreplanet-br:matrix.org.

Nos últimos dias, aconteceu a Mini Debconf BR 2018 em Curitiba. Estive lá para hackear e ajudar na instalação de Debian em smartphones.

Depois de se preparar, o passo seguinte para tal instalação é desbloquear o bootloader do telefone, ou garantir formas de fazer com que o bootloader carregue o sistema Debian ou outro GNU.

Durante a Mini Debconf, encontramos a dificuldade em vencer esta etapa com o aparelho de um dos voluntários.

Se você é ou for capaz de utilizar uma versão do Android ou sistema de recuperação alternativos às versões do fabricante, é bem provável que seja capaz de iniciar o Debian ou outro GNU. Ou, digamos que a primeira barreira, que é a que descrevo aqui, foi vencida.

Alguns dos projetos alternativos que poderiam ser testados seriam: Replicant, LineageOS (ou mesmo uma versão antida de CyanogenMod), TWRP, ClockworkMod, entre muitos outros. Com exceção do Replicant, estes projetos distribuem partes que não são software livre. Por isso, evitei colocar seus links. Também não é possível descartar que distribuições de tais projetos, sejam elas oficiais ou não, contenham malware, que possam lhe causar algum prejuízo.

No entanto, tais projetos costumam oferecer documentação de como destravar o bootloader do seu aparelho, e como instalá-los. Ao invés de duplicar tal documentação, é mais fácil aproveitar o espírito de colaboração hacker e nos referirmos a elas.

No entanto, ainda gostaria de um software livre que consolidasse boa parte do conhecimento distribuído entre tantos lugares diferentes. Mas fica para o futuro.

Existem duas formas principais de instalação de um sistema operacional alternativo no aparelho.

Uma delas é o "root" do aparelho. Significa obter privilégios de super-usuário no aparelho, permitindo sobrescrever a partição que contém uma das imagens utilizadas pelo bootloader. Tal operação costuma explorar falhas de segurança no sistema operacional Android, algumas delas em seu kernel. Infelizmente, a forma mais comum de fazê-lo é utilizando uma aplicação Android proprietária que não teve nenhuma curadoria. Por outro lado, felizmente é possível utilizá-las habilitando o modo desenvolvedor do aparelho ou a permissão de instalar aplicações "inseguras". Daí, uma das vontades em desenvolver um software livre capaz de fazê-lo através de uma linha de comando no Debian ou seu GNU preferido.

A outra forma é utilizando um mecanismo oferecido pelo fabricante para "download" ou "flash" de um outro sistema operacional. Esta forma exige que o telefone esteja destravado. Alguns modelos já permitem tal operação de fábrica. Outros exigem a obtenção de um código do fabricante, depois de aceitar algum termo, como a perda da garantia. Ainda existe a necessidade de uma ferramenta a ser executa em um computador que esteja conectado ao telefone via USB. Para muitos modelos, existem ferramentas livres, como fastboot e heimdall. Para alguns modelos, o suporte no heimdall não é suficiente, exigindo ainda algum trabalho de engenharia reversa ou correções na ferramenta. De novo, seria interessante um software livre que detecte o modelo do aparelho e utilize a ferramenta apropriada tanto para destravá-lo quanto para a gravação da imagem. Existem alguns por aí, e seria interessante consolidá-los com o maior número de modelos suportado possível.

Fica como exercício, então, para mais uma etapa para o objetivo de instalar Debian ou outro GNU em um telefone: instalar uma imagem alternativa em seu telefone. Tal etapa também é importante para obter o primeiro kernel binário a ser utilizado para testar o Debian.

Você pode ver os demais posts aqui.

It's been some time since I last wrote. Life and work have been busy. At the same time, the world has been busy, and as I would love to write a larger post, I will try to be short here. I would love to touch on the Librem 5 and postmarketOS. In fact, I had, in a podcast in Portuguese, Papo Livre. Maybe, I'll touch a little on the latter.

Some of the inspiration for this post include:

• Bradley Kuhn's Copyleft for the next decade
• His previous talk Future of Copyleft
• Alexandre Oliva's The Singularity, the Matrix and the Terminator
• Requiem for the American Dream (sorry about this one not being easily available without DRM)
• My own talk about Copyleft at FISL17, in portuguese
• John Sullivan's Increasingly Permissive or Increasingly Dismissive?

All of those led me to understand how software freedom is under attack, in particular how copyleft in under attack. And, as I talked during FISL, though many might say that "Open Source has won", end users software freedom has not. Lots of companies have co-opted "free software" but give no software freedom to their users. They seem friends with free software, and they are. Because they want software to be free. But freedom should not be a value for software itself, it needs to be a value for people, not only companies or people who are labeled software developers, but all people.

That's why I want to stop talking about free software, and talk more about software freedom. Because I believe the latter is more clear about what we are talking about. I don't mind that we use whatever label, as long as we stablish its meaning during conversations, and set the tone to distinguish them. The thing is: free software does not software freedom make. Not by itself. As Bradley Kuhn puts it: it's not magic pixie dust.

Those who have known me for years might remember me as a person who studied free software licenses and how I valued copyleft, the GPL specifically, and how I concerned myself with topics like license compatibility and other licensing matters.

Others might remember me as a person who valued a lot about upstreaming code. Not carrying changes to software openly developed that you had not made an effort to put upstream.

I can't say I was wrong on both accounts. I still believe in those things. I still believe in the importance of copyleft and the GPL. I still value sharing your code in the commons by going upstream. But I was certaily wrong in valuing them too much. Or not giving as much or even more value to distribution efforts of getting software freedom to the users.

And it took me a while in seeing how many people also saw the GPL as a tool to get code upstream. You see that a lot in Linus' discourse about the GPL. And that is on the minds of a lot of people, who I have seen argue that copyleft is not necessary for companies to contribute code back. But that's the problem. The point is not about getting code upstream. But about assuring people have the freedom to run a modified version of the software they received on their computers. It turns out that many examples of companies who had contributed code upstream, have not delivered that freedom to their end-users, who had received a modified version of that same software, which is not free.

Bradley Kuhn also alerts us that many companies have been replacing copyleft software with non-copyleft software. And I completely agree with him that we should be writing more copyleft software that we hold copyright for, so we can enforce it. But looking at what has been happening recently in the Linux community about enforcement, even thought I still believe in enforcement as an strategy, I think we need much more than that.

And one of those strategies is delivering more free software that users may be able to install on their own computers. It's building those replacements for software that people have been using for any reason. Be it the OS they get when they buy a device, or the application they use for communication. It's not like the community is not doing it, it's just that we need to acknowledge that this is a necessary strategy to guarantee software freedom. That distribution of software that users may easily install on their computers is as much or even more valuable than developing software closer to the hacker/developer community. That doing downstream changes to free software in the effort of getting them to users is worth it. That maintaining that software stable and secure for users is a very important task.

I may be biased when talking about that, as I have been shifting from doing upstream work to downstream work and both on the recent years. But maybe that's what I needed to realize that upstreaming does not necessarily guarantees that users will get software freedom.

I believe we need to talk more about that. I have seen many people dear to me disregard that difference between the freedom of the user and the freedom of software. There is much more to talk about that, go into detail about some of those points, and I think we need to debate more. I am subscribed to the libreplanet-discuss mailing list. Come join us in discussing about software freedom there, if you want to comment on anything I brought up here.

As I promised I would, I would like to mention about postmarketOS, which is an option users have now to get some software freedom on some mobile devices. It's an effort I wanted to build myself, and I applaud the community that has developed around it and has been moving forward so quickly. And it's a good example of a balance between upstream and dowstream code that gets to deliver a better level of software freedom to users than the vendor ever would.

I wanted to write about much of the topics I brought up today, but postponed that for some time. I was motivated by recent events in the community, and I am really disappointed at some the free software players and some of the events that happened in the last few years. That got me into thinking in how we need to manifest ourselves about those issues, so people know how we feel. So here it is: I am disappointed at how the Linux Foundation handled the situation about Software Freedom Conversancy taking a case against VMWare; I am disappointed about how Software Freedom Law Center handled a trademark issue against the Software Freedom Conservancy; and I really appreciate all the work the Software Freedom Conservancy has been doing. I have supported them for the last two years, and I urge you to become a supporter too.

I had been using my Samsung Galaxy S Relay 4G for almost three years when I decided to get a new phone. I would use this new phone for daily tasks and take the chance to get a new model for hacking in the future. My apexqtmo would still be my companion and would now be more available for real hacking.

And so it also happened that its power button got stuck. It was not the first time, but now it would happen every so often, and would require me to disassemble it. So I managed to remove the plastic button and leave it with a hole so I could press the button with a screwdriver or a paperclip. That was the excuse I needed to get it to running Debian only.

Though it's now always plugged on my laptop, I got the chance to hack on it on my scarce free time. As I managed to get a kernel I built myself running on it, I started fixing things like enabling devtmpfs. I didn't insist much on running systemd, though, and kept with System V. The Xorg issues were either on the server or the client, depending on which client I ran.

I decided to give a chance to running the Android userspace on a chroot, but gave up after some work to get some firmware loaded.

I managed to get the ALSA controls right after saving them inside a chroot on my CyanogenMod system. Then, restoring them on Debian allowed to play songs. Unfortunately, it seems I broke the audio jack when disassembling it. Otherwise, it would have been a great portable audio player. I even wrote a small program that would allow me to control mpd by swiping on the touchscreen.

Then, as Debian release approached, I decided to investigate the framebuffer issue closely. I ended finding out that it was really a bug in the driver, and after fixing it, the X server and client crashes were gone. It was beautiful to get some desktop environment running with the right colors, get a calculator started and really using the phone as a mobile device.

There are two lessons or findings here for me. The first one is that the current environments are really lacking. Even something like GPE can't work. The buttons are tiny, scrollbars are still the only way for scrolling, some of the time. No automatic virtual keyboards. So, there needs to be some investing in the existing environments, and maybe even the development of new environments for these kinds of devices. This was something I expected somehow, but it's still disappointing to know that we had so much of those developed in the past and now gone. I really miss Maemo. Running something like Qtopia would mean grabing a very old unmaintained software not available in Debian. There is still matchbox, but it's as subpar as the others I tested.

The second lesson is that building a userspace to run on old kernels will still hit the problem of broken drivers. In my particular case, unless I wrote code for using Ion instead of the framebuffer, I would have had that problem. Or it would require me to add code to xorg-xserver that is not appropriate. Or fix the kernel drivers of available kernel sourcecodes. But this does not scale much more than doing the right thing and adding upstream support for these devices.

So, I decided it was time I started working on upstream support for my device. I have it in progress and may send some upstream patches soon. I have USB and MMC/SDcard working fine. DRM is still a challenge, but thanks to Rob Clark, it's something I expect to get working soon, and after that, I would certainly celebrate. Maybe even consider starting the work on other devices a little sooner.

Trying to review my post on GNU on smartphones, here is where I would put some of the status of my device and some extra notes.

On Halium

I am really glad people started this project. This was one of the things I criticized: that though Ubuntu Phone and FirefoxOS built on Android userspace, they were not easily portable to many devices out there.

But as I am looking for a more pure GNU experience, let's call it that, Halium does not help much in that direction. But I'd like to see it flourish and allow people to use more OSes on more devices.

Unfortunately, it suffers from similar problems as the strategy I was trying to go with. If you have a device with a very old kernel, you won't be able to run some of the latest userspace, even with Android userspace help. So, lots of devices would be left unsupported, unless we start working on some upstream support.

On RYF Hardware

My device is one of the worst out there. It's a modem that has a peripherical CPU. Much has already been said about Qualcomm chips being some of the least freedom-friendly. Ironically, it's some with the best upstream support, as far as I found out while doing this upstreaming work. Guess we'll have to wait for opencores, openrisc and risc-v to catch up here.

Diversity

Though I have been experimenting with Debian, the upstream work would sure benefit lots of other OSes out there, mainly GNU+Linux based ones, but also other non-GNU Linux based ones. Not so much for other kernels.

On other options

After the demise of Ubuntu Phone, I am glad to see UBports catching up. I hope the project is sustainable and produce more releases for more devices.

Rooting

This needs documentation. Most of the procedures rely on booting a recovery system, which means we are already past the root requirement. We simply boot our own system, then. However, for some debugging strategies, getting root on the OEM system is useful. So, try to get root on your system, but beware of malware out there.

Booting

Most of these devices will have their bootloaders in there. They may be unlocked, allowing unsigned kernels to be booted. Replacing these bootloaders is still going to be a challenge for another future phase. Though adding a second bootloader there, one that is freedom respecting, and that allows more control on that booting step to the user is something possible once you have some good upstream support. One could either use kexec for that, or try to use the same device tree for U-Boot, and use the knowledge of the device drivers for Linux on writing drivers for U-Boot, GRUB or Libreboot.

Installation

If you have root on your OEM system, this is something that could be worked on. Otherwise, there is magic-device-tool, whose approach is one that could be used.

Kernels

While I am working on adding Linux upstream support for my device, it would be wonderful to see more kernels supporting those gadgets. Hopefully, some of the device driver writing and reverse engineering could help with that, though I am not too much optimistic. But there is hope.

Basic kernel drivers

Adding the basic support, like USB and MMC, after clocks, gpios, regulators and what not, is the first step to a long road. But it would allow using the device as a board computer, under better control of the user. Hopefully, lots of eletronic garbage out there would have some use as control gadgets. Instead of buying a new board, just grab your old phone and put it to some nice use.

Sensors, input devices, LEDs

There are usually easy too. Some sensors may depend on your modem or some userspace code that is not that easily reverse engineered. But others would just require some device tree work, or some small input driver.

Graphics

Here, things may get complicated. Even basic video output is something I have some trouble with. Thanks to some other people's work, I have hope at least for my device. And using the vendor's linux source code, some framebuffer should be possible, even some DRM driver. But OpenGL or other 3D acceleration support requires much more work than that, and, at this moment, it's not something I am counting on. I am thankful for the work lots of people have been doing on this area, nonetheless.

Wireless

Be it Wifi or Bluetooth, things get ugly here. The vendor driver might be available. Rewriting it would take a long time. Even then, it would most likely require some non-free firmware loading. Using USB OTG here might be an option.

Modem/GSM

The work of the Replicant folks on that is what gives me some hope that it might be possible to get this working. Something I would leave to after I have a good interface experience in my hands.

GPS

Problem is similar to the Modem/GSM one, as some code lives in userspace, sometimes talking to the modem is a requirement to get GPS access, etc.

Shells

This is where I would like to see new projects, even if they work on current software to get them more friendly to these form factors. I consider doing some work there, though that's not really my area of expertise.

Next steps

For me, my next steps are getting what I have working upstream, keep working on DRM support, packaging GPE, then experimenting with some compositor code. In the middle of that, trying to get some other devices started.

But documenting some of my work is something I realized I need to do more often, and this post is some try on that.

No próximo sábado, dia 18 de Março de 2017, vou participar de uma oficina de Debian em gadgets, incluindo smartphones. Com esse post e outros por vir, gostaria de ajudar a preparar outras oficinas do tipo, e documentar algumas das atividades propostas e realizadas durante a oficina.

Você pode ver os demais posts aqui.

Para se preparar para a oficina, um aviso é muito importante: você pode perder seu aparelho e seus dados. Faça um backup dos seus dados antes de vir para a oficina. E caso opte por tentar alguns dos procedimentos descritos, esteja ciente dos riscos do seu aparelho não ligar mais, ou de você perder seus dados no processo.

Além disso, se possível, traga consigo um cabo USB de dados, um cartão SD compatível com seu aparelho, e um notebook com os seguintes pacotes instalados: abootimg, adb, fastboot, heimdall-flash. Traga o máximo que puder. Se for capaz de obter root em seu aparelho, melhor ainda.

Outros preparativos também são bem-vindos para algumas versões mais avançadas da oficina, o que vou tentar abordar durante a Mini Debconf Brasil 2017. Lembre-se de fazer a sua inscrição gratuita no site do evento. Ela é necessária para a entrada na UTFPR, local do evento.

Declarando IRPF com software livre

Escrevi há um bom tempo sobre o IRPF GUI, uma interface de usuário para editar arquivos XML para utilização do IRPF Livre, software mantido e distribuído por Alexandre Oliva.

Comecei a escrever o código utilizando Python. Mas como não sou proficiente na linguagem e outras mudanças exigiriam alterar o código em Java do IRPF Livre, o processo de desenvolvimento travou.

Então me veio a idéia de utilizar comandos que serviriam como um formato de entrada em simples texto para dar maior usabilidade comparada à edição de XML. Aproveitei a idéia e comecei a escrever em C. No entanto, ao invés de gerar como saída o XML que serviria de entrada ao IRPF Livre, decidi gerar o arquivo em formato DEC de uma vez. Este formato é o formato final utilizado para envio à Receita Federal.

Com a minha experiência anterior com o rnetclient, ajuda do código do IRPF Livre, um arquivo que descreve os campos de cada linha do arquivo DEC e um pouco mais de engenharia reversa, tive sucesso em emitir minhas declarações nos últimos dois anos.

Mas o programa ainda não é tão amigável quanto eu gostaria. Os comandos não são documentados, os erros nem sempre são muito claros, e alguns usuários ainda prefeririam uma interface de formulários.

Para mudar isso, adicionei ao código, recentemente, uma interface de linha de comandos e um comando de ajuda, além do código necessário para emitir melhores mensagens de erro. Agora, as mensagens de erro precisam ser escritas, assim como os textos de ajuda.

Outra idéia que tive foi a de criar um modo tutorial, já que a interface de linha de comando foi adicionada. De alguma maneira, tal modo tutorial poderia indicar pontos de melhoria no programa para permitir novas interfaces no futuro.

Assim como no caso do rnetclient, discussões sobre o desenvolvimento do declara são bem-vindas na lista software-impostos. Também estamos no canal #libreceita da Freenode.

I am typing this on an editor running on Debian on my Samsung Galaxy S Relay 4G, aka apexqtmo. Sorry if I got you the wrong image. I am not using its touchscreen or keyboard for input or its screen for output. And the editor is not graphical. I am using a console editor over an SSH session.

I will try to summarize the steps needed to get there, what else I got, the challenges that I had to overcome, and some of the challenges ahead.

My first challenge was to get some output so that I could debug any problems. If I had a terminal, even better. So, this device has a keyboard, which makes things easier for input. I once had it running with a small initrd with GNU bash and got output on the framebuffer, though a little garbled. I realize there are some problems with the framebuffer driver after I have done some tests, which would explain that. For some reason, that didn't work again for me for some time.

So, in the effort to get some debug output, I have spent a lot of time trying to get a Linux binary that would manage to output to a framebuffer console, but without no luck. Then, I realized that besides ADB, I could just configure the USB gadget to act like a serial ACM device, and have a serial console. After that, I have made a lot of progress.

So, I had a small init which would do the configuration, then mount an SD card partition as the root filesystem and have bash for me. Some of the first challenges here were the fact that this old kernel didn't support metadata checksum on ext4, so I had to tune or recreate the filesystem.

After a success with bash, I went for init. As I had a debootstrapped Debian Jessie, that would be systemd, which failed for no known reason yet, but that was expected. Though this was a 3.4 Linux, there are many missing features in the binary which would explain it. So, I went for System V, and after setting it up to have a getty at ttyGS0, I had a login console.

So, another problem is that udev initscript requires devtmpfs, which this Linux binary didn't have enabled. I decided to ignore that and skip udev. I had created some static nodes at /dev/, which were good enough for me.

Then, for the network, I noticed this kernel didn't have wireless as well, so I booted with a different one, but it looks like it requires some extra initialization, maybe some userspace loading firmware, so I skipped that as well. Now, as for a network connection, I then thought I could use the same USB strategy and have it as a multiple interface gadget, with both serial ACM and network functions. That worked wonders.

Now, I could SSH into the smartphone and start running apt, and install packages. You know what's the next step? Get that framebuffer working and have X.org running. More work getting back to a kernel where framebuffer worked. Lots of headaches for that. Though there was a framebuffer driver, it wouldn't work for the kernel that is used for CyanogenMod. It seems it requires OpenGL to work. Or some fiddling with sysfs that I couldn't mimick in order for the display to turn on. So, back to a different kernel, where things seemed to work somehow.

Now, as udev was not running, X.org would give me something at the framebuffer, but no input would work. After trying to configure it manually, change some settings here and there, I found out that only the init scripts checked for the presence of devtmpfs. So, I removed some part of that, and udev was on. But that was after an upgrade to sid, so that might have been necessary, though I can't tell for sure.

For some reason, some X clients didn't like when I used nodm as a display manager, so I went for xinit. And the X server crashed when I used certain clients. I have a hunch this is caused by a framebuffer driver bug in the kernel, which would be a very sad fact if true. So, I got xterm and matchbox-keyboard running. The touchscreen and keyboard worked fine, so now I had something to show off. Though I was excited already when I had "Hello, World!" at my USB serial console.

So, now we realize what a problem we have! These binary kernels, even the ones built by a community like CyanogenMod, require a userspace in order to initialize drivers, including OpenGL and wireless. They don't have basic features turned on, like devtmpfs. It's a daunting task to run a different userspace, that might require these features or not have any code to do those required initializations.

It's still doable to some point, but maybe not sustainable for long. We would either have to work on an alternative userspace, one that does not require or can work without some kernel features, and that can do some of the initialization or workaround some of the bugs we find in the drivers, like the framebuffer one.

The best alternative is to get those devices supported upstream. And, for that, the first step is to get some source code that builds and runs on those things. I didn't manage to get there yet. After some failures with what is supposed to be used for CyanogenMod, I tried getting source code directly from Samsung. As I couldn't find my device in their opensource site, I asked them for the source code. Four days later, they sent me a message that the source was now available in their site. That was a nice surprise. I didn't expect them to answer, and that was quick enough for me to try it before I was about to present this topic at Latinoware. It turns out I couldn't boot that yet either, and it is a 3.0 Linux, so old enough not to be supported by the latest Debian.

Next I am going to write how to try the same thing for your own Samsung gadget at your own risk, no warranties.