Firmware do conversor digital Zinwell ZBT-620A "tijolão" com função PVR

[rictad]

O mais estranho é que antes de desligar o STB, o painel envia a informação da tecla power ao aparelho. Este ainda tenta realizar algumas operações, como interromper a exibição da imagem, mas é subitamente desligado. Deveria levar 1 ou 2 segundos para dar tempo do desligamento ser feito corretamente. Inclusive desmontando o dispositivo USB para sincronizar os dados de gravação.

Para mim isso é erro de projeto. Só faz sentido o microcontrolador tomar uma atitude ao receber o código POWER se o aparelho estiver em standby. Com o aparelho ligado quem deveria processar esse comando é a CPU, que depois de fazer o "housekeeping" mandaria um sinal para o microcontrolador desligar o aparelho.

Acho que o firmware "não sabe" que nesse aparelho o microcontrolador faz isso, por isso ainda tenta fazer o shutdown corretamente.

Infelizmente, se é mesmo o microcontrolador que desliga o aparelho não há muito que possa ser feito.

Com certeza é erro.

Só uma curiosidade. Quando se inicia o painel frontal do ZBT-620A, a string apresentada é "8051 fp init". Parece que o microcontrolador é o 8051, o mesmo usado nos Mediatek DVD players (mas versão 8032).

[rafael_netto]

Tendo montado o pendrive (em /mnt/usb) você poderá executar a interface do Rictad no próprio pendrive para testar (/mnt/usb/zmw_base_zinwell), e enfim copiar pra dentro do conversor com o comando cp  /mnt/usb/zmw_base_zinwell /mnt/hd

Não, assim não funciona. A partição flash0.app está montada em /mnt/hd, mas é somente leitura porque não dá para gravar diretamente nela como se fosse um dispositivo de disco. É possível fazer gravações na flash via Linux, mas isso vai ser um pouco complicado.

Ah tá, não sabia disso!
Seja como for o colega já conseguiu um controle do 633 para consertar a atualização. Mas fica a dica para quem tenha tido um problema semelhante e que por acaso tenha mais facilidade de mexer direto no aparelho do que de conseguir um controle.

São duas versões porque uma inicializa o painel do ZBT-633 e outra o do ZBT-620A. O único problema é que instalar as versões a e c trocadas deixa o painel do STB sem funcionar (mas o controle continuará respondendo, sendo possível instalar a versão correta depois).

Agora entendi. Eu pensava que o "front panel" era apenas o display (que só o tijolão tem), mas tinha esquecido dos botões.

Eu fiz os testes agora com o firmware do seu Semp e descobri para que serve o bloco rootfs nesses aparelhos. Ao contrário do nome, não é o sistema de arquivos (este está em flash0.avail). Ele é uma extensão da eeprom e, portanto, guarda configurações do aparelho. Mais especificamente, a programação de canais é guardada nesse bloco. Ao gravar o backup da flash do seu Semp no meu ZBT-620A (mais especificamente os blocos CODE, KERNEL, AVAIL e ROOTFS, já que não quis sobrepor o bloco com o CFE), o aparelho reiniciou e foi direto para o canal 4.1 Globo, que provavelmente está em sua programação aí e você não apagou antes de copiar a flash.

Fico feliz e tranquilo em saber que o meu backup está perfeito. 

De fato o canal 4.1 (29 UHF) é o que está sintonizado, imagino que você consiga navegar pelos canais do Rio e que ao entrar na tela de sintonia manual estará selecionado o 29.

Isso é interessante, pois mostra que o firmware do Semp é o mais compatível até agora com todos os rootfs que eu testei.

É curioso mesmo, já que entre todas as atualizações do Semp (pelo menos desde a 14c, não sei quanto às mais antigas) o root é incompatível, isto é, ao iniciar ele faz o rescan.

Pelo que entendi o executável do Semp não trava com nenhum rootfs e faz o rescan em todos, enquanto que os da Zinwell têm comportamento diferente de acordo com a versão, alguns travam, alguns fazem rescan, e outros não fazem nada (por ex. entre a 1.5.5 e a 1.7.2).

Agora, tem uma situação que aconteceu comigo que parece que você não verificou: mesmo ao rodar um executável do próprio Semp no pendrive, mas com versão diferente do rootfs, ele trava, não faz o rescan. No caso eu testei rodar o 1.0.14c tendo o 1.1.0 instalado no aparelho.

E quanto ao sistema de arquivos e o kernel? Não precisam ser modificados também de acordo com a versão?

[rictad]

Fico feliz e tranquilo em saber que o meu backup está perfeito. 

De fato o canal 4.1 (29 UHF) é o que está sintonizado, imagino que você consiga navegar pelos canais do Rio e que ao entrar na tela de sintonia manual estará selecionado o 29.

Só não consigo navegar porque não tenho o controle e o FP não inicializa. 

É curioso mesmo, já que entre todas as atualizações do Semp (pelo menos desde a 14c, não sei quanto às mais antigas) o root é incompatível, isto é, ao iniciar ele faz o rescan.

Pelo que entendi o executável do Semp não trava com nenhum rootfs e faz o rescan em todos, enquanto que os da Zinwell têm comportamento diferente de acordo com a versão, alguns travam, alguns fazem rescan, e outros não fazem nada (por ex. entre a 1.5.5 e a 1.7.2).

Isso. Ficou meio confuso o que eu escrevi mas é mais ou menos isso que quis dizer.

Agora, tem uma situação que aconteceu comigo que parece que você não verificou: mesmo ao rodar um executável do próprio Semp no pendrive, mas com versão diferente do rootfs, ele trava, não faz o rescan. No caso eu testei rodar o 1.0.14c tendo o 1.1.0 instalado no aparelho.

Isso deve ocorrer por se tratar de uma versão Semp mais antiga contra uma mais nova, que deve criar uma estrutura em flash0.rootfs bem diferente.

E quanto ao sistema de arquivos e o kernel? Não precisam ser modificados também de acordo com a versão?

Dificilmente precisam. Pelo que notei, o Kernel sempre é o mesmo. No máximo, uma nova compilação, mas da mesma versão e com as mesmas configurações. Já o sistema de arquivos muda muito pouca coisa. Às vezes ficam umas sobras de cópias de scripts que foram utilizados no desenvolvimento, mas que não fazem diferença. No caso do seu backup, ambos não fizeram diferença para executar o binário da versão Zinwell 1.14.4.

[rafael_netto]

E quanto ao sistema de arquivos e o kernel? Não precisam ser modificados também de acordo com a versão?

Dificilmente precisam. Pelo que notei, o Kernel sempre é o mesmo. No máximo, uma nova compilação, mas da mesma versão e com as mesmas configurações. Já o sistema de arquivos muda muito pouca coisa. Às vezes ficam umas sobras de cópias de scripts que foram utilizados no desenvolvimento, mas que não fazem diferença. No caso do seu backup, ambos não fizeram diferença para executar o binário da versão Zinwell 1.14.4.

Parece que não é bem assim. Senão seria possível instalar o 1.7.2 por cima dos 1.13.x/1.14.x.
Eu entendo que a incompatibilidade entre eles não é questão de rootfs, senão atualizar os quatro blocos não faria o conversor voltar a funcionar (o 1.7.2_back não funcionaria).

[rictad]

Parece que não é bem assim. Senão seria possível instalar o 1.7.2 por cima dos 1.13.x/1.14.x.
Eu entendo que a incompatibilidade entre eles não é questão de rootfs, senão atualizar os quatro blocos não faria o conversor voltar a funcionar (o 1.7.2_back não funcionaria).

Tem razão. Acabamos nos esquecendo de um detalhe importante, que faz a diferença entre as versões mais antigas e as mais novas. Eu falei um pouco disso lá atrás e já havia me esquecido. É a versão do squashfs.

As versões mais antigas do Zinwell (1.5.5 e 1.7.2) usam um squashfs estranho, lembra? Já as versões mais recentes, usam o squashfs 3.1 + lzma. Portanto, o Kernel da versão mais nova, apesar de ser o mesmo (versão 2.6.12-4.2-brcmstb), foi compilado com suporte ao squashfs + lzma. Além disso, o sistema de arquivos passou a vir no novo formato, apesar de ter o mesmo conteúdo. Se voltarmos para a versão 1.7.2 apenas com o bloco code, o Kernel recompilado não conseguirá montá-lo. Se, em seguida, gravarmos o Kernel da versão 1.7.2 (com o squashfs antigo e sem lzma), o bloco code será montado, mas o bloco do sistema de arquivos (avail) é que não será montado, pois está no novo squashfs. Então precisa dos 3 blocos, por uma questão de compatibilidade ao squashfs usado. O bloco load não é necessário, pois o CFE continua fazendo o trabalho dele. Até por segurança, nem deveria ser atualizado. Já o bloco rootfs das versões novas acaba sendo aceito pela versão 1.7.2 e reformatado.

Mas no caso do teste pelo Semp, esses blocos não são necessários, pois o binário estará no pen drive e não em uma imagem squashfs. Para ele rodar, basta o bloco rootfs correto.

[rafael_netto]

Fiz o teste de substituir o flash0.rootfs e rodar o zmw_base_zinwell a partir do pendrive e obtive um resultado, digamos "estranho".

Na primeira tentativa funcionou. A interface iniciou, consegui operá-la normalmente com o controle do Semp, vi o canal 10 de Brasília e troquei o vídeo para NTSC. Porém eu não havia gravado o log e não registrei o que acontecia durante o boot, em especial para ver as mensagens de detecção de tuner. Só reparei que, durante o uso normal do programa, no terminal aparecia uma mensagem insistente relativa a USB.

Rodei o Putty novamente, desta vez com log, sem reiniciar o conversor (apenas havia interrompido a interface com Ctrl-\ e rodado novamente). Desta vez a interface não iniciou e ficou cuspindo muitas mensagens relacionadas a comunicação i2c (que é usada para o tuner), se não me engano dizendo que os comandos não tinham sido aceitos ou que as respostas não eram entendidas. Eu bobamente não guardei o log disso.

Com medo de que tivesse danificado algo no STB reiniciei normalmente e fiquei aliviado ao ver a interface padrão do Semp iniciar no modo de fábrica, como era esperado.

Então mais uma vez copiei o flash0.rootfs e tentei rodar no pendrive. Daí por diante não funcionou mais. O programa é interrompido logo no início com estas mensagens:

Código: [Selecionar]

broadcom create task 10 b_event
broadcom create task 30 b_idle
boot time till here (boot bsp start) 3133
Before zw_init_i2c_hw
Before zw_init_common_interface
BCHP_EBI_CS_BASE_0 0x1e00000c
BCHP_EBI_CS_CONFIG_0 0x02000411
BCHP_EBI_CS_BASE_1 0x1c00000c
BCHP_EBI_CS_CONFIG_1 0x07000410
BCHP_EBI_CS_BASE_2 0x00000000
BCHP_EBI_CS_CONFIG_2 0x07000000
BCHP_EBI_CS_BASE_3 0x00000000
BCHP_EBI_CS_CONFIG_3 0x07000000
boot time till here (boot bsp end) 3156
boot time till here (bsettop init) 3173
O prompt do Busybox então retorna.

Felizmente, ao reiniciar com a interface padrão do Semp tudo volta pro lugar.

Uma coisa que eu reparei (já tinha reparado antes) é que quando se interrompe a execução da interface que foi chamada a partir da linha de comando (isto é, não inicou na hora do boot) o prompt fica extremamente lento, os caracteres demoram muito a aparecer. E quando se roda o programa, sempre dá algum erro. Eu já tinha tentado isso anteriormente, ao tentar rodar o zmw_base_zinwell original depois de tê-lo interrompido.

Agora parece que o que aconteceu foi que na primeira vez, tudo funcionou, mas na segunda, algo foi corrompido que impediu as execuções posteriores.

Cheguei a pensar que algo fosse escrito no filesystem, mas lembrei que ele é protegido contra gravação. A única explicação é que algum lugar, fora do rootfs, foi corrompido, e seja o que for, não afeta o software padrão do Semp (felizmente). Poderia ser nos blocos nvram ou skip, que ainda não mexemos?

[rictad]

Na primeira tentativa funcionou. A interface iniciou, consegui operá-la normalmente com o controle do Semp, vi o canal 10 de Brasília e troquei o vídeo para NTSC. Porém eu não havia gravado o log e não registrei o que acontecia durante o boot, em especial para ver as mensagens de detecção de tuner. Só reparei que, durante o uso normal do programa, no terminal aparecia uma mensagem insistente relativa a USB.

Normal a mensagem. Isso ocorre porque você iniciou o programa pelo USB, que já está montado. Como as novas versões do Zinwell tentam montar automaticamente o pen drive, o mount falha (pois o dispositivo está ocupado), mostrando a mensagem mount 00000. Ele continua tentando e a mensagem fica sendo mostrada insistentemente.

Como você alterou o video, então o controle do Semp funcionou. 

Rodei o Putty novamente, desta vez com log, sem reiniciar o conversor (apenas havia interrompido a interface com Ctrl-\ e rodado novamente). Desta vez a interface não iniciou e ficou cuspindo muitas mensagens relacionadas a comunicação i2c (que é usada para o tuner), se não me engano dizendo que os comandos não tinham sido aceitos ou que as respostas não eram entendidas. Eu bobamente não guardei o log disso.

Com medo de que tivesse danificado algo no STB reiniciei normalmente e fiquei aliviado ao ver a interface padrão do Semp iniciar no modo de fábrica, como era esperado.

Isso é seguro. Você pode repetir várias vezes que nunca vai acontecer nada com o Semp. Mas precisa reiniciar  STB para tudo voltar ao normal.

Então mais uma vez copiei o flash0.rootfs e tentei rodar no pendrive. Daí por diante não funcionou mais. O programa é interrompido logo no início com estas mensagens:

Código: [Selecionar]

broadcom create task 10 b_event
broadcom create task 30 b_idle
boot time till here (boot bsp start) 3133
Before zw_init_i2c_hw
Before zw_init_common_interface
BCHP_EBI_CS_BASE_0 0x1e00000c
BCHP_EBI_CS_CONFIG_0 0x02000411
BCHP_EBI_CS_BASE_1 0x1c00000c
BCHP_EBI_CS_CONFIG_1 0x07000410
BCHP_EBI_CS_BASE_2 0x00000000
BCHP_EBI_CS_CONFIG_2 0x07000000
BCHP_EBI_CS_BASE_3 0x00000000
BCHP_EBI_CS_CONFIG_3 0x07000000
boot time till here (boot bsp end) 3156
boot time till here (bsettop init) 3173
O prompt do Busybox então retorna.

(...)
Cheguei a pensar que algo fosse escrito no filesystem, mas lembrei que ele é protegido contra gravação. A única explicação é que algum lugar, fora do rootfs, foi corrompido, e seja o que for, não afeta o software padrão do Semp (felizmente). Poderia ser nos blocos nvram ou skip, que ainda não mexemos?

Isso é estranho. Talvez após copiar novamente o rootfs, o binário do Semp chegou a fazer algumas alterações antes de ser interrompido com CTRL-\. Aconteceu comigo algumas vezes. É muito rápido. Não acho que pode ser outro bloco, porque fiz os mesmos testes aqui com seu firmware inteiro.

Uma coisa que eu reparei (já tinha reparado antes) é que quando se interrompe a execução da interface que foi chamada a partir da linha de comando (isto é, não inicou na hora do boot) o prompt fica extremamente lento, os caracteres demoram muito a aparecer. E quando se roda o programa, sempre dá algum erro. Eu já tinha tentado isso anteriormente, ao tentar rodar o zmw_base_zinwell original depois de tê-lo interrompido.

Não sei se vai funcionar com essa versão do Busybox (nunca testei), mas na nova versão que compilei é só usar o comando (no terminal lento):

setsid cttyhack sh

ou

setsid cttyhack ash

Se funcionar, você poderá, inclusive, chamar o zmw_base_zinwell com "&" no final

./zmw_base_zinwell &

para enviá-lo para segundo plano, mantendo o terminal disponível, rápido e com controle enquanto o programa roda.
Se não funcionar, tente digitar somente o comando "ash" para ver se ele consegue iniciar outro shell com controle.
Isso está relacionado com job control.

[rictad]

Nova versão 1.7.2_back2.

Montei uma nova versão 1.7.2 de volta para quem atualizou com os firmwares 1.13.x e 1.14.x. Continua com 4 blocos, mas é menor que a anterior, pois aquela usava o dump inteiro dos blocos que copiei da flash. Agora eu os reduzi para o seu tamanho útil. A exceção é o bloco LOAD, que deixei inteiro (não quis mexer, por questão de segurança). Além disso, fiz uma variação especial para o ZBT-633/620C slim, para aqueles que, por algum motivo, precisarem voltar a versão. Fiz vários testes e as duas funcionam perfeitamente. Essas versões não são intercambiáveis entre os aparelhos, por causa do controle remoto (elas são originais). E devem ser instaladas contra as versões 1.13.x ou 1.14.x, tanto as oficiais como as modificadas que estão aqui neste tópico. Após serem instaladas, você ainda poderá reatualizar para as versões 1.13.x ou 1.14.x.

ATENÇÃO:

A versão ZBT-620A_1.7.2_back2 só pode ser instalada no Zinwell ZBT-620A "tijolão" e só deve ser instalada se tiver algum motivo para voltar para a versão antiga oficial. Se você instalá-la no slim, vai precisar achar o controle do "tijolão" para operá-lo e atualizá-lo corretamente ou enviá-lo para a assistência técnica.

A versão ZBT-633_1.7.2_back2 só pode ser instalada no Zinwell ZBT-633/620C slim e só deve ser instalada se tiver algum motivo para voltar para a versão antiga oficial. Se você instalá-la no "tijolão", vai precisar achar o controle do slim para operá-lo e atualizá-lo corretamente ou enviá-lo para a assistência técnica.

Serão gravados 4 blocos na flash. Portanto, você deve esperar a barra de atualização encher 4 vezes. Após isso, o STB será reiniciado 2 vezes, a primeira é para ressetar as configurações.

[rictad]

Eu fiz um teste agora a pouco com o novo firmware 1.15.4 do Zinwell ZBT-601 no tijolão. Claro, tive que abrir o firmware no zimview e alterar o customer number de 6 para 262 para que o tijolão aceitasse o firmware. Com o zimview também podemos ver que, dos 4 blocos, o único diferente (checksum) é o bloco code. Como esperado, após a atualização só pude operar o aparelho com o controle do ZBT-633 (que deve ser igual ao do ZBT-601). O engraçado é que a saída vídeo componente funcionou normalmente (o ZBT-601 não tem vídeo componente). Ambas as saídas de áudio stereo (o 601 só tem uma) também funcionaram. Não pude testar as saídas SPDIF (óptica e coaxial), pois não tenho equipamento compatível, mas acho que estão funcionando, apesar de o 601 não as possuir. Meu palpite é que se alguém instalar esse firmware no ZBT-633, tudo vai funcionar normalmente, com exceção do painel frontal. Ao final, para voltar à versão 1.14.4a beta do tijolão, tive que alterar o customer number do arquivo de 262 para 6, para que o firmware temporário do 601 permitisse a atualização

Olhando o arquivo zmw_base_zinwell no IDA, é visível a diferença nas rotinas de inicialização do painel frontal (o ZBT-601 não possui display). Assim como o ZBT-620A, ele também chama a rotina que nomeei "pré-executa 8051 fp init", mas que agora vou renomear para "pre-executa fp init". Essa rotina chama a principal, que eu denominei "executa frontpanel init", já que é essa a string relacionada durante a inicialização.

A ideia é usar apenas a última versão do ZBT-601 para integrar todas as modificações feitas até agora (e talvez as futuras) e disponibilizar 3 versões intercambiáveis entre os 3 aparelhos. Mas para isso vou ter que descobrir se o SPDIF realmente continua funcionando nos ZBT-620/633 após a atualização com o firmware do 601.

[zeurt]

A ideia é usar apenas a última versão do ZBT-601 para integrar todas as modificações feitas até agora (e talvez as futuras) e disponibilizar 3 versões intercambiáveis entre os 3 aparelhos. Mas para isso vou ter que descobrir se o SPDIF realmente continua funcionando nos ZBT-620/633 após a atualização com o firmware do 601.

Legal saber dessa compatibilidade. Faz algum tempo que eu estou pra te perguntar sobre isso... Na verdade eu estou precisando comprar um conversor pra minha mãe, e então pensei no ZBT-601, que está com um preço ótimo. Só faltava a confirmação que você deu agora sobre a compatibilidade com o ZBT-633, pois assim, além de comprar um conversor com ótimo custo-benefício, ainda poderei brincar um pouco com o desenvolvimento do firmware (tentar ajudar nem que seja um pouquinho  ).

Outra coisa: eu abri recentemente um binário zmw_base_zinwell que você enviou, no IDA 5.5.0, e fiquei POSITIVAMENTE impressionado com a quantidade de "comentários" espalhados por todo o código. Esses "comentários" que na verdade são as mensagens enviadas para o console são realmente muito bem-vindos. Com eles, a gente não fica desesperadamente perdido no meio de tudo (é bem diferente dos firmwares Mediatek, em que não existia nada disso).
Como você ressaltou algumas vezes já neste tópico, os comentários servem pra nos mostrar que estamos no lugar certo... É claro que precisa decifrar as instruções da redondeza do comentário que interessa para se chegar a rotina definitiva que executa determinada função. De qualquer modo, me pareceu que ajuda bastante, já que cada comentário serve como uma pista, um ponto de partida, ou uma idéia para uma nova modificação...
Um exemplo: próximo de onde você colocou os NOPs pra acabar com o limite de 32G existe a string "# "Disk total size must be over 32G!!".

Código: [Selecionar]

.text:004787E4                          # ---------------------------------------------------------------------------
.text:004787E4
.text:004787E4                         loc_4787E4:                              # CODE XREF: sub_4786EC+40j
.text:004787E4 9C 8C 99 8F                             la      $t9, sub_4B2A98
.text:004787E8 09 F8 20 03                             jalr    $t9 ; sub_4B2A98
.text:004787EC 00 00 00 00                             nop
.text:004787F0 00 00 00 00                             nop
.text:004787F4 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:004787F8 D4 A0 99 8F                             la      $t9, sub_459DF0
.text:004787FC 09 F8 20 03                             jalr    $t9 ; sub_459DF0
.text:00478800 00 00 00 00                             nop
.text:00478804 06 00 40 14                             bnez    $v0, loc_478820
.text:00478808 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0047880C F0 82 99 8F                             la      $t9, sub_45B064
.text:00478810 09 F8 20 03                             jalr    $t9 ; sub_45B064
.text:00478814 00 00 00 00                             nop
.text:00478818 1D 00 40 10                             beqz    $v0, loc_478890
.text:0047881C 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478820
.text:00478820                         loc_478820:                              # CODE XREF: sub_4786EC+118j
.text:00478820                                                                  # sub_4786EC+1B0j
.text:00478820 24 80 84 8F                             la      $a0, dword_680000
.text:00478824 30 8A 99 8F                             la      $t9, sub_666260
.text:00478828 09 F8 20 03                             jalr    $t9 ; sub_666260
.text:0047882C B8 59 84 24                             addiu   $a0, (aWeHavePopWindo - 0x680000)  # "We have POP window, so we can't let use"...
.text:00478830 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478834 D8 FF 00 10                             b       loc_478798
.text:00478838 01 00 03 24                             li      $v1, 1
.text:0047883C                          # ---------------------------------------------------------------------------
.text:0047883C 34 9C 99 8F                             la      $t9, sub_45EBE0
.text:00478840 09 F8 20 03                             jalr    $t9 ; sub_45EBE0
.text:00478844 96 01 04 24                             li      $a0, 0x196
.text:00478848 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0047884C 45 01 04 24                             li      $a0, 0x145
.text:00478850 34 9C 99 8F                             la      $t9, sub_45EBE0
.text:00478854 09 F8 20 03                             jalr    $t9 ; sub_45EBE0
.text:00478858 21 80 40 00                             move    $s0, $v0
.text:0047885C 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478860 21 20 00 02                             move    $a0, $s0
.text:00478864 21 28 40 00                             move    $a1, $v0
.text:00478868 AC CA 99 8F                             la      $t9, sub_459140
.text:0047886C 09 F8 20 03                             jalr    $t9 ; sub_459140
.text:00478870 C1 00 06 24                             li      $a2, 0xC1
.text:00478874 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478878 24 80 84 8F                             la      $a0, dword_680000
.text:0047887C A0 88 99 8F                             la      $t9, sub_6660D0
.text:00478880 09 F8 20 03                             jalr    $t9 ; sub_6660D0
.text:00478884 F8 59 84 24                             addiu   $a0, (aDiskTotalSizeM - 0x680000)  # "Disk total size must be over 32G!!"
.text:00478888 B9 FF 00 10                             b       loc_478770
.text:0047888C 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)

Última coisa: encontrei um belíssimo tutorial sobre MIPS Assembly, criado por um professor da Central Connecticut State University chamado Bradley Kjell. Aqui está o link: http://programmedlessons.org/AssemblyTutorial/
Na verdade é um curso programado para ser ministrado em 1 semestre na citada universidade. Pelo que pude perceber, a intenção foi criar um curso introdutório sobre Assembly, sendo que o processador escolhido foi o MIPS. Curiosidade: vejam o que os alunos desse professor tem a dizer sobre ele.  Link: http://www.ratemyprofessors.com/ShowRatings.jsp?tid=385487
Ele recomenda que se use o simulador de MIPS chamado SPIM, para que se possa acompanhar os programas exemplos ao longo do tutorial. Testei o SPIM e é super simples de entender, e muito legal. Link do SPIM: http://pages.cs.wisc.edu/~larus/spim.html
Eu tambei testei recentemente o MIPS Assembler MARS da Missouri State University, que eu havia recomendado alguns posts atrás: http://courses.missouristate.edu/KenVollmar/MARS/
Achei muito interessante esse Assembler, que também é um simulador, e muito completo por sinal. Inclusive os programas do tutorial que recomendei acima podem ser executados no simulador do MARS (assim como no próprio SPIM, que é mais simples, e recomendado pelo autor).
Só pra finalizar, achei o Assembler MARS muito bom:
a-) Tem o Syntax Highlighting, identificando instruções, labels, comentários, etc., cada um com uma cor.
b-) Tem aquela bem-vinda função de auto-preenchimento, ou seja, você começa a digitar um instrução, e o programa já oferece as várias opções para aquela(s) letra(s) incial(ais), inclusive dando uma rápida descrição de cada uma dessas instruções possíveis.
c-) Para salvar o binário (após o código-fonte ter sido montado), é só ir em Dump Memory, e escolher Binário: me parece que salva em Little Endian; é engraçado pois no próprio programa os 4 bytes das instruções aparecem da esquerda para direita, mas quando se faz o Dump Memory, o binário é salvo em Little Endian, da direita para esquerda (cada 4 bytes).
d-) É gratuito!  Parece que o MIPS oferece mais e melhores opções gratuitas que o ARM em termos de aprendizado e ferramentas...