Il.Socio Pubblicato: 12 Aprile 2011 Segnalazione Share Pubblicato: 12 Aprile 2011 (modificato) Introduzione: Questo thread serve per fornire qualche chiarimento riguardo alle relazioni esistenti tra: - la memoria fisica del cellulare (Flash) - i vari file contenenti il fw (CORE, ROFS2, ROFS3, UDA) - il file-system del cellulare C:\ Z:\ Partiamo con il presentare questa immagine, che descrive bene il quadro della situzione: La memoria fisica del cell (Flash): Come da immagine, risulta suddivisa in sezioni: - Boot Section - Locked Section - Unlocked Section - Block Replacement Section - Partition Information Block (PIB) Le sezioni interessate dal cooking sono la Locked Section e l'Unlocked Section, che come gia' intuibile dal nome, sono rispettivamente sezioni di sola lettura e di lettura/scrittura, che alla "fine dei giochi", si mapperanno 1:1 con le unita' Z:\ e C:\ I vari file del firmware: Ora vado a descrivere brevemente i file del fw, che sono presenti nel mondo del cooking e vediamo come questi si relazionano all'immagine presentata... - CORE: Contiene la BootSection (MiniBoot + Core Loader), la Core OS Image (ovvero la ROM) e la Primary ROFS Image (ovvero la ROFS1) - ROFS2: E' la Secondary ROFS dell'immagine - ROFS3: Non e' presente nell'immagine, ma non e' altro che la Tertiary ROFS - UDA: E' la User Data Area Il file-system del cellulare: Sempre facendo riferimento all'immagine, e' possibile notare come il contenuto di ROM+ROFS1+ROFS2+ROFS3 sia visibile tramite l'unita' Z:\ del file-system composito Mentre il contenuto dell'UDA, risulta visibile tramite l'unita' C:\ del file-system. Le restanti sezioni della memoria Flash: Chi desidera ottenere ulteriori dettagli tecnici riguardo le altre sezioni della memoria Flash, puo' continuare a leggere gli spoiler qui di seguito... - Miniboot Since NAND Flash is non-XIP, any system using NAND Flash for code storage must provide a hardware mechanism for the system to boot from the NAND device. Options include: a hardware boot loader – logic associated with the NAND device, including a small RAM buffer which has the effect of making a small part at the start of the NAND device behave as XIP. a small boot ROM - a separate XIP ROM which contains code to shadow the first part of the NAND code image into RAM. Either way, a mechanism is provided which enables a small area of XIP memory at the start of the device (typically less than 1K bytes) to execute a boot-up program. This program is the Miniboot, which is normally written in assembler. Its function is to locate the Core Loader image, copy it into RAM and then execute it. - Core Loader The function of the Core Loader is to locate the Core OS image, copy it entirely into RAM, and then execute the standard Symbian OS bootstrap within it. The Core Loader itself is copied into RAM by the Miniboot. The Core OS image is part of the Locked Section, and may contain bad blocks. This means that the Core Loader has to interpret the Block Replacement Table for the Locked Section, and may be required to read certain blocks of the Core OS image from the Block Replacement section in the event of a bad block. The Core OS image may be compressed and, therefore, the Core Loader must be able to detect this, and to de-compress the image when necessary. The Core Loader normally starts straight after the Miniboot and cannot extend beyond the first block; this is necessary so that the Miniboot never needs to perform bad block detection. - Block Replacement Section This section contains a reservoir of spare blocks. These are used by the GBBM software to replace bad blocks in both locked and unlocked sections. The reservoir is shared between these two sections. Replacement blocks for the unlocked area are allocated starting from the top of the reservoir (lowest address), and replacement blocks for the locked area are allocated starting from the bottom of the reservoir (highest address). If the two areas meet, then it means that all spare blocks are in use. In this situation any further bad blocks encountered in the unlocked area would lead to the capacity of the unlocked area becoming reduced. The locked area is read-only, so there should be no new bad blocks appearing in this section. This section also contains the Block Replacement Tables (BRTs). These hold the mapping information between a bad block in the locked/unlocked sections and the block in the reservoir which replaces it. The replacement tables for the unlocked area are located at the top of the section (lowest address), and the replacement tables for the locked area are located at the bottom of the section (highest address). Each replacement table occupies an entire block and there are two tables allocated to each section. Two blocks are reserved for each replacement table. An entry in the replacement table may be up to 512 bytes long, i.e. 1 page worth, and allows the mapping of up to 127 blocks. A block replacement table may be updated as new bad blocks are detected and this may lead to there being multiple replacement table entries within each table. The current valid replacement table entry is identified using the count field within an entry. - Partition Information Block This section is only one block in length and occupies the last good block on the device, i.e. the last block, provided that this isn’t bad. It contains a table holding the location and size of each of the other sections and sub-sections on the device. Locating the last block on the device requires knowledge of the size of the Flash device(s) fitted. In addition, the location of the PIB may vary depending on whether the last block(s) on the device are bad. Altre discussioni correlate: - Alcuni Chiarimenti Tecnici Sulle Patch E Sul Modding Software Modificato 12 Aprile 2011 da Il.Socio 9 Link to comment Condividi su altri siti More sharing options...
emanueleandreatta96 Pubblicato: 16 Novembre 2011 Segnalazione Share Pubblicato: 16 Novembre 2011 grazie, guida molto utile Link to comment Condividi su altri siti More sharing options...
gigio92 Pubblicato: 26 Dicembre 2011 Segnalazione Share Pubblicato: 26 Dicembre 2011 Infatti, serve per ampliare le conoscenze sul cooking dei Symbian Link to comment Condividi su altri siti More sharing options...
capitanbaudo Pubblicato: 15 Febbraio 2012 Segnalazione Share Pubblicato: 15 Febbraio 2012 Grazie Socio, utilissima spiegazione.. complimenti! Link to comment Condividi su altri siti More sharing options...
GiacomoMattina Pubblicato: 6 Marzo 2012 Segnalazione Share Pubblicato: 6 Marzo 2012 come fare che i file o programmi si salvano in memoria "E" su symbian 3??? Link to comment Condividi su altri siti More sharing options...
Darkangel Pubblicato: 7 Marzo 2012 Segnalazione Share Pubblicato: 7 Marzo 2012 eh? quale è la tua domanda? Link to comment Condividi su altri siti More sharing options...
GiacomoMattina Pubblicato: 7 Marzo 2012 Segnalazione Share Pubblicato: 7 Marzo 2012 eh? quale è la tua domanda? Praticamente vorrei inserire dei file o programmi nella memoria di massa "Unita E", Se inserisco i File nelle ROFS2/ROFS3/ROFS1 (Si salvano nella ROM "Unita C", Se inserisco i File nella UDA ( Si salva nella memoria cellulare "Unita C" ). Che metodo devo usare per farsi che i programmi/file si salvano nell "Unita E"??? Link to comment Condividi su altri siti More sharing options...
Il.Socio Pubblicato: 7 Marzo 2012 Autore Segnalazione Share Pubblicato: 7 Marzo 2012 (modificato) Devi operare sul file del fw che contiene l'immagine della memoria esterna... Lo scarichi con NaviFirm+, lo modifichi con NokiaCooker (sperando che ti venga letto), lo flashi con Phoenix. Alcune immagini della memoria esterna sono nello stesso formato della UDA, quindi vengono lette da NokiaCooker, altre, invece, sono in un formato differente e non vengono lette da NokiaCooker. Modificato 7 Marzo 2012 da Il.Socio Link to comment Condividi su altri siti More sharing options...
GiacomoMattina Pubblicato: 7 Marzo 2012 Segnalazione Share Pubblicato: 7 Marzo 2012 (modificato) Devi operare sul file del fw che contiene l'immagine della memoria esterna... Lo scarichi con NaviFirm+, lo modifichi con NokiaCooker (sperando che ti venga letto), lo flashi con Phoenix. Alcune immagini della memoria esterna sono nello stesso formato della UDA, quindi vengono lette da NokiaCooker, altre, invece, sono in un formato differente e non vengono lette da NokiaCooker. Quale sarebbe il file immagine della memoria esterna??? O.o Modificato 7 Marzo 2012 da GiacomoMattina Link to comment Condividi su altri siti More sharing options...
Il.Socio Pubblicato: 8 Marzo 2012 Autore Segnalazione Share Pubblicato: 8 Marzo 2012 (modificato) Apri NaviFirm+ e connettiti al server "Nokia Care Suite" Il file che contiene l'immagine della memoria esterna e' quello che ha nella colonna "Type" il valore "MemoryCardContent" Modificato 8 Marzo 2012 da Il.Socio Link to comment Condividi su altri siti More sharing options...
GiacomoMattina Pubblicato: 8 Marzo 2012 Segnalazione Share Pubblicato: 8 Marzo 2012 Apri NaviFirm+ e connettiti al server "Nokia Care Suite" Il file che contiene l'immagine della memoria esterna e' quello che ha nella colonna "Type" il valore "MemoryCardContent" Lo sto scaricando almeno per provare, però è un file di 16gb O.o se restano 16gb fissi non faccio niente :S Link to comment Condividi su altri siti More sharing options...
Il.Socio Pubblicato: 9 Marzo 2012 Autore Segnalazione Share Pubblicato: 9 Marzo 2012 (modificato) A meno che tu non abbia un quantitativo esagerato di RAM nel pc, non riuscirai ad aprirlo con NokiaCooker... perche' quel file verra' caricato interamente in RAM, quindi, dovrai avere almeno 16Gb di RAM installata per poterlo elaborare. Modificato 10 Marzo 2012 da Il.Socio Link to comment Condividi su altri siti More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Accedi Ora