Informações (gerais) relevantes para quem quer mexer no firmware

[Jefferson]

Esse tipo de firmware híbrido, sistema + aplicações, parece ser excelente para modificações. A lógica deve ser deixar o sistema bootar pela flash e a aplicação (dvdplayer, por exemplo) rodar pelo HDD. E fazer como Shantic deve ter feito: o sistema na flash teria um script para montar o HDD e só depois chamar a aplicação. Muito prático para modificações futuras, inclusive.

Shantic manteve dvdplayer na flash. Mas sua idéia é boa. Se dvdplayer funcionar no HDD isso pode facilitar *muito* o trabalho de testar patches. Se o firmware puder ser programado para procurar dvdplayer no HDD e, caso não o encontre, rodar uma cópia na flash, torna-se possível até permitir ao usuário testar as modificações sem que ele corra os riscos existentes na atualização da flash.

Como o HDD pode demorar muito a ficar pronto o "timeout" para ir buscar na flash pode ser muito longo. Uma alternativa seria programar o firmware para ir procurar um arquivo de configuração na USB a cada boot. Encontrando esse arquivo, mudar sua configuração de boot a partir dele. Entre outras coisas esse arquivo poderia dizer onde o firmware deve procurar dvdplayer nos próximos boots.

Você acha que isso é possível?

[rictad]

Shantic manteve dvdplayer na flash. Mas sua idéia é boa. Se dvdplayer funcionar no HDD isso pode facilitar *muito* o trabalho de testar patches. Se o firmware puder ser programado para procurar dvdplayer no HDD e, caso não o encontre, rodar uma cópia na flash, torna-se possível até permitir ao usuário testar as modificações sem que ele corra os riscos existentes na atualização da flash.

Como o HDD pode demorar muito a ficar pronto o "timeout" para ir buscar na flash pode ser muito longo. Uma alternativa seria programar o firmware para ir procurar um arquivo de configuração na USB a cada boot. Encontrando esse arquivo, mudar sua configuração de boot a partir dele. Entre outras coisas esse arquivo poderia dizer onde o firmware deve procurar dvdplayer nos próximos boots.

Você acha que isso é possível?

Acho que é possível sim. Pelo menos é isso que fiz no Zinwell e estou terminando (já está funcionando, faltam alguns ajustes). No caso do Zinwell, o sistema boota normalmente pela flash, mas roda um script meu em segundo plano antes de chamar o zmw_base_zinwell da flash. Porém, o meu script que está em segundo plano aguarda 18 segundos (tempo de segurança para o zmw_base_ziwnell montar o HDD ou pendrive) e, após isso, procura por outro zmw_base_zinwell em /zim_dev/zim_test na primeira partição do HDD. Se encontrar, ele mata o que está rodando e chama o do HDD. Isso seria para testes e desenvolvimento (esse script é capaz de fazer outras operações que vou explicar depois lá no tópico).

Mas é possível fazer isso também de forma fixa, para todo boot. O script seria executado em primeiro plano e ele próprio montaria o HDD. Esperaria uns 15 segundos para procurar pelo arquivo no HDD. Se não achar, ele executa o da flash. O incômodo aqui seria o tempo de boot de 15 segundos. Nem todo HDD ou pendrive precisa desse tempo todo para ser reconhecido. É só um valor de segurança. Mas valores muito baixos poderiam deixar HDDs lentos não utilizáveis para hospedarem a aplicação.

[Jefferson]

Os firmwares Realtek podem usar dois sistemas de arquivos distintos (nunca ao mesmo tempo):

squashfs
http://en.wikipedia.org/wiki/SquashFS

yaffs
http://en.wikipedia.org/wiki/YAFFS

O que eles tem em comum é que o sistema de arquivos inteiro fica dentro de um arquivo. Com o driver adequado o sistema "monta" o arquivo como se fosse uma unidade (no Linux o termo não é bem esse), mais ou menos como usar o Daemon Tools para montar um ISO

Pelo que entendi, a principal diferença entre ambos é que no squashfs não é possível gravar. Então todos os arquivos que você vê ao entrar no MP via telnet que sejam contidos no volume squashfs são "somente leitura". Isso pode ser contornado com links simbólicos, mas gera um desperdício de espaço (ter duas cópias dos mesmos arquivos).

[Jefferson]

Cada firmware é distribuído como um único arquivo, geralmente denominado "install.img". Trata-se de um arquivo TAR que pode ser facilmente "unpacked" no Windows usando o Winrar. Basta acrescentar a extensão .rar e pedir para o Winrar descomprimir (o 7-zip também serve).

Você verá vários arquivos, mas os mais interessantes são os volumes squashfs ou yaffs dentro do diretório package2. Se o firrmware for baseado em squashfs, você verá um arquivo squashfs1.img. Se for baseado em yaffs, encontrará um ou mais arquivos de nome yaffs2_x.img ('x' pode ser 1, 2,...).

Para squashfs existem binários Windows disponíveis, em diversas versões, para descomprimir/comprimir esses arquivos. A maior preocupação sendo usar a versão correta, com as opções corretas, na hora de comprimir. Já no caso do yaffs a coisa se complica. O programa para descomprimir é fácil de achar, mas o para comprimir dizem que existe, mas parece enterro de anão

De qualquer forma, mesmo tendo binários Windows, o melhor mesmo parece ser ter uma máquina Linux (ou uma máquina virtual) pronta, só para fazer isso. Se alguém conhecer alguma máquina virtual pronta, já disponível para baixar na internet, que tenha suporte a squashfs/yaffs, por favor avise, porque eu estou enrolado aqui

Squashfs para Windows
versão 3.4 (provavelmente a primeira versão com suporte a LZMA)
http://download.nicksoft.info/linux/backuplivecd/squashfs-tools.zip

Também a versão 3.4, mas os arquivos são diferentes (provavelmente por ser compilado por uma pessoa diferente)
ftp://ftp.slax.org/useful-binaries/win32/squashfs-tools/

Versões 3.0, 3.1, 3.4 e 4.0
http://fragilematter.blogspot.com/2010/02/squashfs-tools-40-windows-binaries.html


 

[rictad]

Esse YAFFS é realmente muito interessante. Com ele, é possível, inclusive, alterar a flash online.

Using YAFFS2 is straightforward. Assuming you already patched the kernel, just erase your MTD partition using:
   

Código: [Selecionar]

flash_eraseall /dev/mtd[x]
and mount it as YAFFS using:
   

Código: [Selecionar]

mount -t yaffs /dev/mtd[x] /mnt/flash
You can copy files to it right away and YAFFS2 will take care of everything. It is also possible to create a YAFFS2 image offline using "mkyaffs2image" utility, but the former option is preferrable as YAFFS2 will properly use the OOB bits it is responsible for.

O chato é que você tem que recompilar o kernel patcheado com o YAFFS, pois ainda não está incluído oficialmente (ao contrário do Squashfs, que já foi incluído há algumas versões, ao menos com gzip) e nem parece vir nas distros mais comuns.

[rictad]

É essencial para quem quer mexer com o firmware ter o cabo serial. O mesmo cabo usado na recuperação de players MT13x9 serve para os MP Realtek (mas observe a voltagem).  No caso do DIYOMATE S9 eu publiquei as instruções aqui:
http://ryan.com.br/wp/diyomate-s9-porta-serial/

Tenho o conector aqui e devo tentar aproveitar o cabo USB que já uso no Zinwell. Estou doido para fazer esse cabo para poder ver a interação com o firmware do S9, mas ainda não consegui por falta de tempo. 
Até para testar o aparelho está difícil. Desde quando o player da vaquinha chegou, eu só consegui assistir a um episódio de série nele. Por sinal, com qualidade excelente e ótima exibição de legendas.

[Jefferson]

Todos os posts relacionados com o Simple RSS Jukebox foram movidos para um tópico dedicado:
http://ryan.com.br/smf/index.php?topic=706.0

[Jefferson]

ATENÇÃO: Este é um tópico de desenvolvimento e não de suporte. Comentários sem relação direta com o que estou escrevendo serão apagados ou vetados.

[Jefferson]

Todos os posts relacionados com o IRFAKE foram movidos para um tópico dedicado:
http://ryan.com.br/smf/index.php?topic=707

[Jefferson]

Acabo de confirmar que a simples instalação de firmware através de pendrive não sobreescreve o conteúdo do diretório /usr/local/etc. Fiz uma reinstalação do firmware original e tanto o irfake quanto o jukebox sobreviveram.

Isso é bastante vantajoso, porque hacks feitos via Telnet não precisam ser refeitos caso você faça um upgrade do firmware, mas tem vários efeitos negativos:

• Se você fizer uma besteira grande (como corromper o arquivo rcS de forma que DvdPlayer não rode) reinstalar o firmware não vai consertar o problema.
  
• Qualquer comportamento esquisito ou incômodo provocado por suas modificações também perdurará.
• Instalar um firmware modificado e depois instalar o original pode também deixar o aparelho inoperante se o firmware modificado depender do irfake.
• Modificações feitas diretamente no firmware em /usr/local/etc podem não ser instaladas quando você instalar esse firmware via pendrive;

A solução para o problema está no blog de Shantic:

http://dpi.mx/s9mod/2011/05/easier-installation-test/

Basta rodar via Telnet o comando:

Código: [Selecionar]

echo “ ” | dd of=/dev/mtdblock/0 bs=2048 seek=8192
E reiniciar o S9. A princípio eu achei que não tinha funcionado, porque o aparelho simplesmente ficou parado na tela preta inicial. Mas depois de um longo tempo ele reiniciou sozinho e começou a carregar o firmware no pendrive.


Note que no segundo parágrafo Shantic explica o problema:

when you select upgrade from the menu it triggers a special command “kill -6 1″ that will put the system in upgrade mode, this will read the FW from the pendrive and install it to the nand, the problem with custom FW (or at least mine) is that a lot of the info (moServices) goes into the /usr/local/etc/ path, and this path gets completely ignored by the “upgrade” so big part of the custom firmware will not get installed :( as far as I know there is no way to “force” the installation of the new /usr/local/etc/ if this was possible then this problem would not exist

Se o firmware não tiver acesso Telnet você vai estar encrencado. Existe outro método, mas requer que você tenha o cabo serial.