Jump to content
Nokioteca Forum

Core, Rofs, Uda, Rom


Recommended Posts

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:

bootx.jpg

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 da Il.Socio
  • Mi Piace 9
Link to comment
Condividi su altri siti

  • 7 mesi dopo...
  • 1 mese dopo...
  • 1 mese dopo...
  • 3 settimane dopo...

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

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 da Il.Socio
Link to comment
Condividi su altri siti

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 da GiacomoMattina
Link to comment
Condividi su altri siti

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 da Il.Socio
Link to comment
Condividi su altri siti

Please sign in to comment

You will be able to leave a comment after signing in



Accedi Ora
 Share

×
×
  • Crea Nuovo...

Informazione Importante

Questo sito utilizza i cookie per analisi, contenuti personalizzati e pubblicità. Continuando la navigazione, accetti l'utilizzo dei cookie da parte nostra | Privacy Policy