Progressos da O3 Zeebo Desbloqueado mais perto ainda
+2
Diegobras
ari789
6 participantes
Página 1 de 1
Progressos da O3 Zeebo Desbloqueado mais perto ainda
Olha o que acabaram de postar no forum para quem não viu vou postar aqui
Yo!
Postando uma pequena atualização sobre os últimos progressos e o estado atual do projeto.
- Segurança
Um dos maiores problemas que encontraríamos para fazer modificações permanentes no console, seja para homebrews ou Linux, seria como desviar de todo o mecanismo de segurança que a Qualcomm implementou no MSM7201A. Teoricamente, tudo no console teria alguma forma de proteção contra modificações. O MSM7201A foi feito para validar cada etapa do boot e assim garantir total integridade do sistema.
Felizmente (ouch, Longcheer!), estes mecanismos não estão ativados. De todos que testei (que são os úteis para nós), nenhum está protegido, podendo ser livremente modificados e gravados de volta no console. Isso significa que temos total controle do Z.
Dos dados presentes na NAND, e interessantes de serem modificados, é a partição APPS (que no caso do Zeebo, contém o BREW) para homebrews; ou os bootloaders OEMSBL2 (o 1 é idêntico ao 2, mas não é utilizado no Z) e APPSBL para Linux.
- Flash via Diag
Para quem viu o vídeo sobre o patch permanente de homebrew, eu disse que pesquisaria sobre como fazê-lo sem precisar de JTAG. É possível gravar firmwares na NAND pela porta de DIAG, através do modo de download que todo dispositivo baseado nos MSM (e QSDs?) da Qualcomm tem. O que não temos, é o software para enviar a imagem para o Zeebo. As ferramentas oficiais não suportam o MSM7201A, o bootloader (pequeno código que a ferramenta envia para o aparelho antes de enviar a imagem completa) para esta série não está incluída.
O autor do RevSkills, modificou um bootloader de outro SoC para funcionar com o MSM7201A. Por isso não gastei tempo olhando sobre, já que ele estava trabalhando neste ponto. Além do que, ele já tem boa documentação acerca dos BLs e o modo "software download", se fosse para nós do OpenZeebo fazer, teríamos que começar quase que do zero.
Infelizmente, até a versão atual do RevSkills, ele ainda não funciona corretamente. Conversei com o autor e ele disse que consertaria-o nas próximas versões, mas mesmo depois de vários novos updates, o bootloader ainda não está funcional. Expliquei o porquê que queria este recurso e ainda ofereci trabalhar nesta parte em específico, assim ele me mandaria o material que já havia pesquisado e eu continuaria, sem a necessidade de créditos ou coisas do tipo. Mas, depois que ele fechou o app (era open source) e começou a vender alguns recursos no RS, perdeu o "espírito hacker" e o dinheiro falou mais alto. Assim, não sei se algum dia veremos suporte a CPU do Zeebo no RS. Caso não obtenha resposta dele em algumas semanas, vou parar o trabalho com o Linux e pesquisar sobre flashing pela porta de Diag, mesmo que tenhamos que começar do 0.
- Porta serial
Quando desmontei o Z pela primeira vez, logo imaginei que aqueles dois pads abaixo da antena poderiam ser uma porta serial. É normal quando você desmonta algo, tentar descobrir para que serve cada pad/terminal/botão na placa que não esteja rotulado.
Tentei confirmar a teoria de várias formas possíveis, mas os pads pareciam simplesmente, mortos. Investiguei novamente há algumas semanas e realmente: estão ligados a UART1! Realmente é uma porta serial. Acontece que a função configurada para eles internamente não era essa, por isso sempre pareciam mortos.
Um dos problemas para levar o Linux ao Z era a falta de uma porta serial (vide Wiki). Bem, problem solved! Detalhes http://projects.tripleoxygen.net/openzeebo/index.php?title=UART
- Linux
Quando falo Linux, entenda como Android também. Por que? A árvore do Android é a mais completa em termos de funcionalidades para o usuário final. E uma coisa importante é a aceleração gráfica: geralmente os fabricantes dos SoC (Qualcomm neste caso) não oferecem os fontes para usufruir 100% da GPU. Se usarmos o Android, podemos aproveitar os binários do HTC G1 (módulo do kernel e libs OpenGL). Apenas com o Linux, é improvável que consigamos aceleração gráfica em hardware.
Além do trabalho normal que teremos para finalizar uma distro para o console, temos atualmente um "pequeno problema": proc_comm + AMSS atuais. Em resumo, o AMSS é OS (não é só um OS, mas para simplificar, considerem assim) que roda no ARM9 e cuida das funções de radio/rede, enquanto no ARM11 roda o OS de aplicações (BREW, Android/Linux, WinCE). Todos os aparelhos baseados no MSM7201A ou compatíveis funcionam de maneira similar. Mesmo entre aqueles que rodam o BREW (Zeebo) ou o Android (G1), os AMSS são bem parecidos, pois 95% dele é fornecido pela própria Qualcomm.
Já o proc_comm, é um mecanismo IPC, ou resumindo: um meio dos núcleos conversarem. Como o ARM9 é uma espécie de hypervisor, o ARM11 geralmente não comunica diretamente com alguns periféricos, mas solicita ao ARM9 que o faça. Esta solicitação é feita através de uma área especial na RAM (chamada SMEM, ou Shared Memory. No shit sherlock!), compartilhada pelos dois núcleos, onde um insere o comando e avisa ao outro que há algo a ser feito. Este, por vez, verifica o comando na SMEM, executa-o (se for possível), retorna o resultado e avisa o núcleo solicitante que pode pegar o resultado. Na verdade é mais complexo que isso, mas fundamentalmente, é assim.
Independente do OS que o ARM11 vá rodar, estes mecanismos existem. Apesar do funcionamento exato ser quase idêntico, a implementação do proc_comm presente no kernel da árvore do Android/Linux foi feita para "conversar" com AMSSs do G1/insira_smartphone_com_msm7201a/msm7200a_e_android_aqui, não sendo compatível com o AMSS do Zeebo. Ainda não sei até que ponto são diferentes, mas o caso é que devemos estudar estas diferenças e modificar o kernel para que ele suporte especificamente o Z. Até agora, estou configurando o que preciso para o kernel através de um pequeno bootloader + modificações no OEMSBL, comentando as solicitações do kernel ao proc_comm, enquanto deixo o AMSS em loop infinito (ou o watchdog mata o ARM11, achando que ele travou).
Uma opção, já que temos total controle do hardware, é modificar o OEMSBL para dar o máximo de controle possível do SoC ao ARM11 e ignorar o AMSS completamente ( while(1) {} ). Entretanto, há coisas que o ARM11 nunca terá acesso, assim pode não ser uma idéia segura para o futuro.
Resumindo: estou trabalhando inteiramente no Linux e olharei sobre flashing via diag nas próximas semanas caso não tenha retorno do RS. Sobre progressos nos apps nativos do Z (jogos, opera, zeeboids, etc..), espero que outras pessoas olhem.
Obrigado àqueles que -ainda- estão conosco.
Fonte:http://www.openzeebo.org/t73-atualizacao-em-28072011#697
Yo!
Postando uma pequena atualização sobre os últimos progressos e o estado atual do projeto.
- Segurança
Um dos maiores problemas que encontraríamos para fazer modificações permanentes no console, seja para homebrews ou Linux, seria como desviar de todo o mecanismo de segurança que a Qualcomm implementou no MSM7201A. Teoricamente, tudo no console teria alguma forma de proteção contra modificações. O MSM7201A foi feito para validar cada etapa do boot e assim garantir total integridade do sistema.
Felizmente (ouch, Longcheer!), estes mecanismos não estão ativados. De todos que testei (que são os úteis para nós), nenhum está protegido, podendo ser livremente modificados e gravados de volta no console. Isso significa que temos total controle do Z.
Dos dados presentes na NAND, e interessantes de serem modificados, é a partição APPS (que no caso do Zeebo, contém o BREW) para homebrews; ou os bootloaders OEMSBL2 (o 1 é idêntico ao 2, mas não é utilizado no Z) e APPSBL para Linux.
- Flash via Diag
Para quem viu o vídeo sobre o patch permanente de homebrew, eu disse que pesquisaria sobre como fazê-lo sem precisar de JTAG. É possível gravar firmwares na NAND pela porta de DIAG, através do modo de download que todo dispositivo baseado nos MSM (e QSDs?) da Qualcomm tem. O que não temos, é o software para enviar a imagem para o Zeebo. As ferramentas oficiais não suportam o MSM7201A, o bootloader (pequeno código que a ferramenta envia para o aparelho antes de enviar a imagem completa) para esta série não está incluída.
O autor do RevSkills, modificou um bootloader de outro SoC para funcionar com o MSM7201A. Por isso não gastei tempo olhando sobre, já que ele estava trabalhando neste ponto. Além do que, ele já tem boa documentação acerca dos BLs e o modo "software download", se fosse para nós do OpenZeebo fazer, teríamos que começar quase que do zero.
Infelizmente, até a versão atual do RevSkills, ele ainda não funciona corretamente. Conversei com o autor e ele disse que consertaria-o nas próximas versões, mas mesmo depois de vários novos updates, o bootloader ainda não está funcional. Expliquei o porquê que queria este recurso e ainda ofereci trabalhar nesta parte em específico, assim ele me mandaria o material que já havia pesquisado e eu continuaria, sem a necessidade de créditos ou coisas do tipo. Mas, depois que ele fechou o app (era open source) e começou a vender alguns recursos no RS, perdeu o "espírito hacker" e o dinheiro falou mais alto. Assim, não sei se algum dia veremos suporte a CPU do Zeebo no RS. Caso não obtenha resposta dele em algumas semanas, vou parar o trabalho com o Linux e pesquisar sobre flashing pela porta de Diag, mesmo que tenhamos que começar do 0.
- Porta serial
Quando desmontei o Z pela primeira vez, logo imaginei que aqueles dois pads abaixo da antena poderiam ser uma porta serial. É normal quando você desmonta algo, tentar descobrir para que serve cada pad/terminal/botão na placa que não esteja rotulado.
Tentei confirmar a teoria de várias formas possíveis, mas os pads pareciam simplesmente, mortos. Investiguei novamente há algumas semanas e realmente: estão ligados a UART1! Realmente é uma porta serial. Acontece que a função configurada para eles internamente não era essa, por isso sempre pareciam mortos.
Um dos problemas para levar o Linux ao Z era a falta de uma porta serial (vide Wiki). Bem, problem solved! Detalhes http://projects.tripleoxygen.net/openzeebo/index.php?title=UART
- Linux
- Spoiler:
Uncompressing Linux......................................................................................................... done, booting the kernel.
[ 0.000000] Linux version 2.6.29-zeebo (tripleoxygen@stratosphere) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #45 PREEMPT Mon Jul 25 17:18:43 BRT 2011
[ 0.000000] CPU: ARMv6-compatible processor [4117b362] revision 2 (ARMv6TEJ), cr=00c5387f
[ 0.000000] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Zeebo
[ 0.000000] Warning: bad configuration page, trying to continue
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] msm_clock_init()
[ 0.000000] allocating 2097152 bytes at c0800000 (10800000 physical)for pmem kernel ebi1 arena
[ 0.000000] allocating 8388608 bytes at c0a00000 (10a00000 physical)for pmem
[ 0.000000] allocating 10485760 bytes at c1200000 (11200000 physical)for camera pmem
[ 0.000000] allocating 8388608 bytes at c1c00000 (11c00000 physical)for adsp pmem
[ 0.000000] allocating 8388608 bytes at c2500000 (12500000 physical)for gpu1 pmem
[ 0.000000] allocating 2097152 bytes at c2d00000 (12d00000 physical) for fb
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: rdinit=/bin/sh root=/dev/ram rw console=ttyMSM0,115200n8 mem=64M
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000000] Console: colour dummy device 80x30
[ 0.006595] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.009371] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.012235] ... MAX_LOCK_DEPTH: 48
[ 0.015278] ... MAX_LOCKDEP_KEYS: 8191
[ 0.018313] ... CLASSHASH_SIZE: 4096
[ 0.021350] ... MAX_LOCKDEP_ENTRIES: 8192
[ 0.024475] ... MAX_LOCKDEP_CHAINS: 16384
[ 0.027515] ... CHAINHASH_SIZE: 8192
[ 0.031593] memory used by lock dependency info: 2399 kB
[ 0.035673] per task-struct memory footprint: 1152 bytes
[ 0.041405] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.047046] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.049925] Memory: 64MB = 64MB total
[ 0.055466] Memory: 18428KB available (1908K code, 4423K data, 1184K init)
[ 0.057985] Calibrating delay loop... 525.92 BogoMIPS (lpj=2629632)
[ 0.319490] Mount-cache hash table entries: 512
[ 0.323136] CPU: Testing write buffer coherency: ok
[ 0.331793] khelper used greatest stack depth: 6560 bytes left
[ 0.348661] smem_find(137, 56): wrong size 48
[ 0.351170] khelper used greatest stack depth: 6464 bytes left
[ 0.351886] L val: PLL0: 12, PLL1: 40, PLL2: 55
[ 0.351943] Turbo mode not supported.
[ 0.352073] Suboptimal up stepping for CPU freq 245760 KHz.
[ 0.352353] ACPU running at 528000 KHz
[ 0.360926] CPU-Freq PLL DIV AHB-Freq ADIV AXI-Freq Dn Up
[ 0.365705] 19200 -1 1 19200 1 30720 -1 5
[ 0.370475] 122880 0 2 61440 2 61440 -1 4
[ 0.375248] 128000 1 6 64000 2 61440 -1 7
[ 0.380025] 176000 2 6 88000 2 61440 -1 6
[ 0.384798] 245760 0 1 81920 3 61440 -1 7
[ 0.389571] 256000 1 3 128000 2 128000 -1 7
[ 0.394346] 352000 2 3 88000 4 128000 3 -1
[ 0.399120] 384000 1 2 128000 3 128000 2 -1
[ 0.403895] 528000 2 2 132000 4 128000 6 -1
[ 0.451190] bio: create slab <bio-0> at 0
[ 0.966393] Partition(from smem) 0:EFS2APPS -- Offset:191 Size:0
[ 0.980739] smem_log_init: no log or log_idx allocated, smem_log disabled<3>smem_log_init: no static log or log_idx allocated, smem_log disabled<3>smem_log_init: no power log or log_idx allocated, smem_log disabled<6>SMD Control Port Driver Initialized.
[ 1.009301] ashmem: initialized
[ 1.012671] yaffs Jul 21 2011 13:11:47 Installing.
[ 1.012923] msgmni has been set to 36
[ 1.013244] io scheduler noop registered
[ 1.013334] io scheduler anticipatory registered (default)
[ 1.123594] msm_serial: detected port #0
[ 1.124189] msm_serial.0: ttyMSM0 at MMIO 0xa9a00000 (irq = 9) is a MSM
[ 1.125196] msm_serial: console setup on port #0
[ 1.125291] console [ttyMSM0] enabled
[ 1.680976] msm_serial: driver initialized
[ 1.687834] msm_serial_hs module loaded
[ 1.719166] brd: module loaded
[ 1.745381] khelper used greatest stack depth: 6152 bytes left
[ 1.747519] loop: module loaded
[ 1.747888] pmem_gpu0: 0 init
[ 1.750034] Creating debugfs file pmem_gpu0
[ 1.750511] pmem_gpu1: 0 init
[ 1.752684] Creating debugfs file pmem_gpu1
[ 1.757234] msm_nand: phys addr 0xa0a00000 dmac 0x7
[ 1.757634] allocated dma buffer at ffc00000, dma_addr 131fe000
[ 1.764769] ONFI probe : Found a nonONFI Compliant device
[ 1.771541] status: 20
[ 1.777354] nandid: 5580b1ad maker ad device b1
[ 1.784821] Found a supported NAND device
[ 1.791069] NAND Id : 0x5580b1ad
[ 1.796451] Buswidth : 16 Bits
[ 1.801749] Density : 128 MByte
[ 1.807216] Pagesize : 2048 Bytes
[ 1.812944] Erasesize: 131072 Bytes
[ 1.818501] Oobsize : 64 Bytes
[ 1.824141] CFG0 Init : 0xe85408c0
[ 1.830219] CFG1 Init : 0x0004745e
[ 1.836294] ECCBUFCFG : 0x00000203
[ 1.843761] Creating 1 MTD partitions on "msm_nand":
[ 1.852963] 0x000003220000-0x000008000000 : "0:EFS2APPS"
[ 1.948176] clock_late_init() disabled 21 unused clocks
<3>msm_pm_init: failed get SLEEP
/bin/sh: can't access tty; job control turned off
/ #
/ # ls
bin dev linuxrc sbin usr
/ # mkdir -p /proc
/ # mount -t proc proc /proc
/ # ls -l /proc
total 0
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 1
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 104
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 105
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 106
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 108
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 2
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 219
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 242
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 3
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 4
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 5
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 55
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 6
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 60
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 77
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 78
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 84
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 90
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 92
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 94
dr-xr-xr-x 5 0 0 0 Jan 1 00:01 96
-r--r--r-- 1 0 0 0 Jan 1 00:01 buddyinfo
dr-xr-xr-x 3 0 0 0 Jan 1 00:01 bus
-r--r--r-- 1 0 0 0 Jan 1 00:01 cmdline
-r--r--r-- 1 0 0 6140 Jan 1 00:01 config.gz
dr-xr-xr-x 2 0 0 0 Jan 1 00:01 cpu
-r--r--r-- 1 0 0 0 Jan 1 00:01 cpuinfo
-r--r--r-- 1 0 0 0 Jan 1 00:01 devices
-r--r--r-- 1 0 0 0 Jan 1 00:01 diskstats
dr-xr-xr-x 2 0 0 0 Jan 1 00:01 driver
-r--r--r-- 1 0 0 0 Jan 1 00:01 execdomains
-r--r--r-- 1 0 0 0 Jan 1 00:01 fb
-r--r--r-- 1 0 0 0 Jan 1 00:01 filesystems
dr-xr-xr-x 3 0 0 0 Jan 1 00:01 fs
-r--r--r-- 1 0 0 0 Jan 1 00:01 interrupts
-r--r--r-- 1 0 0 0 Jan 1 00:01 iomem
-r--r--r-- 1 0 0 0 Jan 1 00:01 ioports
dr-xr-xr-x 66 0 0 0 Jan 1 00:01 irq
-r--r--r-- 1 0 0 0 Jan 1 00:01 kallsyms
-r-------- 1 0 0 0 Jan 1 00:01 kmsg
-r-------- 1 0 0 0 Jan 1 00:01 kpagecount
-r-------- 1 0 0 0 Jan 1 00:01 kpageflags
-rw-r--r-- 1 0 0 0 Jan 1 00:01 latency_stats
-r--r--r-- 1 0 0 0 Jan 1 00:01 loadavg
-r-------- 1 0 0 0 Jan 1 00:01 lockdep
-r-------- 1 0 0 0 Jan 1 00:01 lockdep_chains
-r-------- 1 0 0 0 Jan 1 00:01 lockdep_stats
-r--r--r-- 1 0 0 0 Jan 1 00:01 locks
-r--r--r-- 1 0 0 0 Jan 1 00:01 meminfo
-r--r--r-- 1 0 0 0 Jan 1 00:01 misc
-r--r--r-- 1 0 0 0 Jan 1 00:01 modules
lrwxrwxrwx 1 0 0 11 Jan 1 00:01 mounts -> self/mounts
-r--r--r-- 1 0 0 0 Jan 1 00:01 mtd
-r--r--r-- 1 0 0 0 Jan 1 00:01 pagetypeinfo
-r--r--r-- 1 0 0 0 Jan 1 00:01 partitions
-r--r--r-- 1 0 0 0 Jan 1 00:01 sched_debug
-r--r--r-- 1 0 0 0 Jan 1 00:01 schedstat
lrwxrwxrwx 1 0 0 64 Jan 1 00:01 self -> 242
-rw-r--r-- 1 0 0 0 Jan 1 00:01 slabinfo
-r--r--r-- 1 0 0 0 Jan 1 00:01 stat
dr-xr-xr-x 1 0 0 0 Jan 1 00:01 sys
dr-xr-xr-x 2 0 0 0 Jan 1 00:01 sysvipc
-rw-r--r-- 1 0 0 0 Jan 1 00:01 timer_list
-rw-r--r-- 1 0 0 0 Jan 1 00:01 timer_stats
dr-xr-xr-x 4 0 0 0 Jan 1 00:01 tty
-r--r--r-- 1 0 0 0 Jan 1 00:01 uptime
-r--r--r-- 1 0 0 0 Jan 1 00:01 version
-r-------- 1 0 0 0 Jan 1 00:01 vmallocinfo
-r--r--r-- 1 0 0 0 Jan 1 00:01 vmstat
-r--r--r-- 1 0 0 0 Jan 1 00:01 yaffs
-r--r--r-- 1 0 0 0 Jan 1 00:01 zoneinfo
/ # cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 2 (v6l)
BogoMIPS : 525.92
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant : 0x1
CPU part : 0xb36
CPU revision : 2
Hardware : Zeebo
Revision : 0000
Serial : 0000000000000000
/ #
Quando falo Linux, entenda como Android também. Por que? A árvore do Android é a mais completa em termos de funcionalidades para o usuário final. E uma coisa importante é a aceleração gráfica: geralmente os fabricantes dos SoC (Qualcomm neste caso) não oferecem os fontes para usufruir 100% da GPU. Se usarmos o Android, podemos aproveitar os binários do HTC G1 (módulo do kernel e libs OpenGL). Apenas com o Linux, é improvável que consigamos aceleração gráfica em hardware.
Além do trabalho normal que teremos para finalizar uma distro para o console, temos atualmente um "pequeno problema": proc_comm + AMSS atuais. Em resumo, o AMSS é OS (não é só um OS, mas para simplificar, considerem assim) que roda no ARM9 e cuida das funções de radio/rede, enquanto no ARM11 roda o OS de aplicações (BREW, Android/Linux, WinCE). Todos os aparelhos baseados no MSM7201A ou compatíveis funcionam de maneira similar. Mesmo entre aqueles que rodam o BREW (Zeebo) ou o Android (G1), os AMSS são bem parecidos, pois 95% dele é fornecido pela própria Qualcomm.
Já o proc_comm, é um mecanismo IPC, ou resumindo: um meio dos núcleos conversarem. Como o ARM9 é uma espécie de hypervisor, o ARM11 geralmente não comunica diretamente com alguns periféricos, mas solicita ao ARM9 que o faça. Esta solicitação é feita através de uma área especial na RAM (chamada SMEM, ou Shared Memory. No shit sherlock!), compartilhada pelos dois núcleos, onde um insere o comando e avisa ao outro que há algo a ser feito. Este, por vez, verifica o comando na SMEM, executa-o (se for possível), retorna o resultado e avisa o núcleo solicitante que pode pegar o resultado. Na verdade é mais complexo que isso, mas fundamentalmente, é assim.
Independente do OS que o ARM11 vá rodar, estes mecanismos existem. Apesar do funcionamento exato ser quase idêntico, a implementação do proc_comm presente no kernel da árvore do Android/Linux foi feita para "conversar" com AMSSs do G1/insira_smartphone_com_msm7201a/msm7200a_e_android_aqui, não sendo compatível com o AMSS do Zeebo. Ainda não sei até que ponto são diferentes, mas o caso é que devemos estudar estas diferenças e modificar o kernel para que ele suporte especificamente o Z. Até agora, estou configurando o que preciso para o kernel através de um pequeno bootloader + modificações no OEMSBL, comentando as solicitações do kernel ao proc_comm, enquanto deixo o AMSS em loop infinito (ou o watchdog mata o ARM11, achando que ele travou).
Uma opção, já que temos total controle do hardware, é modificar o OEMSBL para dar o máximo de controle possível do SoC ao ARM11 e ignorar o AMSS completamente ( while(1) {} ). Entretanto, há coisas que o ARM11 nunca terá acesso, assim pode não ser uma idéia segura para o futuro.
Resumindo: estou trabalhando inteiramente no Linux e olharei sobre flashing via diag nas próximas semanas caso não tenha retorno do RS. Sobre progressos nos apps nativos do Z (jogos, opera, zeeboids, etc..), espero que outras pessoas olhem.
Obrigado àqueles que -ainda- estão conosco.
Fonte:http://www.openzeebo.org/t73-atualizacao-em-28072011#697
ari789- Ser Evoluido
-
Mensagens : 5964
Data de inscrição : 26/09/2010
Idade : 26
Localização : MYXterLand / Mundo 1 / Casa 16
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
É só uma pena que todo esse trabalho pode resultar em um sucesso teórico, pois o Zeebo não está mais à venda para ser desbloqueado. Aliás, quando estive em Vitória/ES, vi um monte de Zeebos à venda na Casa e Video do Shopping de lá, e o engraçado é que o preço era maior que o de tabela, 311 Dilmas!
Diegobras- Moderador Fórum Zeebo
-
Mensagens : 3951
Data de inscrição : 23/05/2009
Idade : 43
Localização : Brasília/DF
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
uaí e daí q n estará mais a venda? o q interessa é tem tem ele em mãos...
EDZ- Profissional
-
Mensagens : 1468
Data de inscrição : 19/11/2008
Idade : 34
Localização : São Paulo-SP
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
EDZ escreveu:uaí e daí q n estará mais a venda? o q interessa é tem tem ele em mãos...
E daí que o alcance do fruto do trabalho dele estará limitado aos Zeebos que já foram vendidos e que ainda estão funfando...
Diegobras- Moderador Fórum Zeebo
-
Mensagens : 3951
Data de inscrição : 23/05/2009
Idade : 43
Localização : Brasília/DF
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
A Zeebo deveria, já que deu errado o projeto e tal, fazer um Zeebo sem o 3G e com todos os jogos da ZIS, pelo menos, e alguns outros. Uns 20 jogos na memória já dá para vender e não perder os Zeebos já feitos e as possíveis peças já encomendadas, lá sei.
Koster- Profissional
-
Mensagens : 2916
Data de inscrição : 16/02/2010
Idade : 31
Localização : São Paulo - SP
Tem o Zeebo? : Não
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
Eu acho que eles vão aproveitar e lançar é o Zeebo Phone com as peças que sobraram....
COMO EU NÃO PENSEI NISSO ANTES?!?!?! hauhauahuahuahuaha
COMO EU NÃO PENSEI NISSO ANTES?!?!?! hauhauahuahuahuaha
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
Koster escreveu:A Zeebo deveria, já que deu errado o projeto e tal, fazer um Zeebo sem o 3G e com todos os jogos da ZIS, pelo menos, e alguns outros. Uns 20 jogos na memória já dá para vender e não perder os Zeebos já feitos e as possíveis peças já encomendadas, lá sei.
Hehehe, o velho método Tectoy de vender videogames
Diegobras- Moderador Fórum Zeebo
-
Mensagens : 3951
Data de inscrição : 23/05/2009
Idade : 43
Localização : Brasília/DF
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
bom , uma coisa mmais lucida era eles venderem os jogos no SD...pelo menos...
EDZ- Profissional
-
Mensagens : 1468
Data de inscrição : 19/11/2008
Idade : 34
Localização : São Paulo-SP
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
olha a quanto tempo eu criei este topico e olha quanto tempo demorou pra responder u.u
ari789- Ser Evoluido
-
Mensagens : 5964
Data de inscrição : 26/09/2010
Idade : 26
Localização : MYXterLand / Mundo 1 / Casa 16
Tem o Zeebo? : Sim
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
ari789 escreveu:olha a quanto tempo eu criei este topico e olha quanto tempo demorou pra responder u.u
u mad? lol.
Cara, tô precisando mandar meu Zeebo pra AT. ele tá com todas ( I MEAN IT) as animações da Z-Wheel corrompidas e um bocado dos jogos não pegam. :C
Espero que não seja terminal.
Re: Progressos da O3 Zeebo Desbloqueado mais perto ainda
Com a pequena diferença que o Mega Drive não era defasado na época e deuDiegobras escreveu:Koster escreveu:A Zeebo deveria, já que deu errado o projeto e tal, fazer um Zeebo sem o 3G e com todos os jogos da ZIS, pelo menos, e alguns outros. Uns 20 jogos na memória já dá para vender e não perder os Zeebos já feitos e as possíveis peças já encomendadas, lá sei.
Hehehe, o velho método Tectoy de vender videogames
Koster- Profissional
-
Mensagens : 2916
Data de inscrição : 16/02/2010
Idade : 31
Localização : São Paulo - SP
Tem o Zeebo? : Não
Tópicos semelhantes
» Zeebo 2.0 - Ainda com bugs?
» Uma olhada mais de perto nos novos Alienware: Area-51, Aurora e M15x as super maquinas da Dell.
» Vocês ainda jogam o Zeebo?
» Para quem não comprou o Zeebo ainda...
» Zeebo está morrendo? Talvez não
» Uma olhada mais de perto nos novos Alienware: Area-51, Aurora e M15x as super maquinas da Dell.
» Vocês ainda jogam o Zeebo?
» Para quem não comprou o Zeebo ainda...
» Zeebo está morrendo? Talvez não
Página 1 de 1
Permissões neste sub-fórum
Não podes responder a tópicos
|
|