Désassemblage du boot2 - Page 18

Et après on fait un shell de type ZShell ou Fargo qui exporte une table de ROM_CALLs correspondant à la version de l'OS.

Un peu d'infos sur le CPU

MRC p15, 0, r0, c0, c0, 0
0x41069264
implementer : 0x41 -> ARM
variant : 0
architecture : 6 -> ARMv5TEJ
primary part number : 0x926
rev : 4

MRC p15, 0, r0, c0, c0, 1
0x1D112152
ICache: 16KB 4-way 8 word
DCache: 8KB 4-way 8 word

MRC p15, 0, r0, c0, c0, 2
0x00000000
Pas de TCM

MRC p15, 0, r0, c1, c0, 0
0x0005107F
L4=0 les instructions changeant PC peuvent changer le bit T (ARM/THUMB)
RR=0 Random Replacement DCache/ICache
V=0 vecteurs d'exceptions en 0x00000000-0x0000001C
I=1 ICache activé
B=0 little endian
C=1 DCache activé
A=1 vérification de l'alignement des accès mémoire activée
M=1 MMU activée

MRC p15, 0, r0, c2, c0, 0
Translation Table Base Register
0x10538000

MRC p15, 0, r0, c3, c0, 0
Domain Access Control Register
0x00000003
Domaine D0 : Manager (tous les accès autorisés, pas de bits de permissions par section/page)
Autres domaines : No Access

La mémoire virtuelle est découpée en sections de 1Mo
0x00000000-0x000FFFFF (1Mo)  -> 0xA4000000-0xA40FFFFF noncacheable nonbufferable       NOR boot1 ?
0x10000000-0x11EFFFFF (31Mo) -> 0x10000000-0x11EFFFFF write-back                                 RAM (sauf le dernier Mo)
0x11F00000-0x17FFFFFF (97Mo) -> 0x11F00000-0x17FFFFFF noncacheable nonbufferable        RAM (dernier Mo) + ???
0x18000000-0x180FFFFF (1Mo) -> 0x11E00000-0x11EFFFFF write-back                                   alias de 0x11E00000 (avant dernier Mo de la RAM)
0x8FF00000-0x901FFFFF (3Mo) -> 0x8FF000000-0x901FFFFF noncacheable nonbufferable
0xA0000000-0xA00FFFFF (1Mo) -> 0xA0000000-0xA00FFFFF noncacheable nonbufferable         
0xA4000000-0xA40FFFFF (1Mo) -> 0xA4000000-0xA40FFFFF noncacheable nonbufferable         alias de 0x00000000 (NOR boot1 ?)
0xA9000000-0xA90FFFFF (1Mo) -> 0xA9000000-0xA90FFFFF noncacheable nonbufferable
0xAC000000-0xAC0FFFFF (1Mo) -> 0xAC000000-0xAC0FFFFF noncacheable nonbufferable
0xB0000000-0xB00FFFFF (1Mo) -> 0xB0000000-0xB00FFFFF noncacheable nonbufferable
0xB4000000-0xB40FFFFF (1Mo) -> 0xB4000000-0xB40FFFFF noncacheable nonbufferable
0xB8000000-0xB80FFFFF (1Mo) -> 0xB8000000-0xB80FFFFF noncacheable nonbufferable
0xBC000000-0xBC0FFFFF (1Mo) -> 0xBC000000-0xBC0FFFFF noncacheable nonbufferable
0xC0000000-0xC00FFFFF (1Mo) -> 0xC0000000-0xC00FFFFF noncacheable nonbufferable
0xC4000000-0xC40FFFFF (1Mo) -> 0xC4000000-0xC40FFFFF noncacheable nonbufferable
0xC8000000-0xC80FFFFF (1Mo) -> 0xC8000000-0xC80FFFFF noncacheable nonbufferable
0xCC000000-0xCC0FFFFF (1Mo) -> 0xCC000000-0xCC0FFFFF noncacheable nonbufferable
0xDC000000-0xDC0FFFFF (1Mo) -> 0xDC000000-0xDC0FFFFF noncacheable nonbufferable

\o/

merci bien hwti.

Oubliez pas de mettre à jour hackspire, à la page CPU

hwti (./512) :
V=0 vecteurs d'exceptions en 0x00000000-0x0000001C

Ca peut être ailleurs qu'à 0+ une table de vecteurs ?

bah apparemment selon ce flag, oui ^^
l'arm est assez customizable.

Folco (./515) :

hwti (./512) :
V=0 vecteurs d'exceptions en 0x00000000-0x0000001C

Ca peut être ailleurs qu'à 0+ une table de vecteurs ?

Pour ne citer que lui, le 6502 a ces vecteur en fin de l'espace (il adresse sur 16bit, donc ça pars de 0xFFFF en descendant), et ce n'est pas le seul a faire ça

hwti> Comment as-tu réussi à obtenir toutes ces infos sur la mémoire virtuelle?

j'aurais pu, aussi.

-lire les infos du copro MMU
-trouver l'adresse des tables de pages qui s'appelle apparemment TTBR et vaut 0x10538000
...
-profit!

OK c'est donc dans la datasheet.

ça semble en effet la mmu officielle (si on peut dire) du coeur arm.

Je vois mal s'amuser a faire une autre MMU (sachant qu'en plus la MMU est + ou - dans les specs de l'ARM)

()

./519 : je suppose qu'il a quand même regardé on-calc la config pour la Nspire.
hwti, tu as tenté de dumper le boot 1/2 ?

ExtendeD (./524) :
hwti, tu as tenté de dumper le boot 1/2 ?

Le boot2, j'ai la version 1.4, donc aucun intérêt.

Pour le boot1, je me suis trompé, en fait je ne sais pas où il est.
En 0x00000000, on a 128K (répétés 8 fois) dans lequels on voit les logs RS232 du boot1.
On dirait de la RAM interne
128K ça me semble beaucoup, et pourquoi désactiver le cache ? Pour privilégier le cache des données de la SDRAM plus lente ?

Boot1 dumpé !

La NOR est à l'adresse physique 0, non accessible une fois l'OS lancé.
En ajoutant une entrée dans la table des sections, on peut y accéder.

Mais 0xA4000100 étant le buffer de l'écran, il est donc où lui ?

Tiens, ça se passe comment pour l'écran ? Il est mappé en RAM et sniffé comme pour les HW2+ ?

C'était l'écran des HW1 qui était mappé en RAM ^^
L'écran des HW2 ne l'était justement pas

A propos du futur kernel/shell, est-ce que l'utilisation d'un format d'exécutable standard type ELF est à votre avis intéressante/envisageable comparé à ce qui était fait sur TI jusqu'à aujourd'hui ?

Pour bien décider, je pense qu'on peut faire un tableau recensant les différents formats envisageables d'un côté, leurs capacités / complexité / taille / standardisation / etc. de l'autre ?

ELF serait clairement un format très standardisé, pour lequel quantité d'outils existent. Plusieurs implémentations de loaders, certainement. Ca serait donc une des solutions qui entraîneraient le moins de codage "custom" pour avoir quelque chose qui fonctionne très bien.

TOTALEMENT absolument pour le support du format ELF
on va pas réinventer un standard quand y'en a qui existent.

ne cherchons pas à reproduire ce que nous connaissons sur 68k. c'est une plate forme totalement nouvelle , profitons en pour faire un truc moderne.

le elf ça veut dire réutiliser des gcc/binutils sans avoir a patcher quoi que ce soit ou écrire de linker ou autre.

Ca peut etre du ELF ou n'importe quel format objet un minimum utilisé

c'est a dire ELF, COFF ou PE

GC -> Ah oui

Entièrement d'accord sur le principe de pas réinventer la roue.

ExtendeD (./527) :

Mais 0xA4000100 étant le buffer de l'écran, il est donc où lui ?

Il est donc en RAM interne, certainement du DMA.
Ou alors les 128K sont la mémoire du contrôleur LCD et le boot1 s'en sert comme RAM avant d'initialiser la SDRAM.

Arf quelle merde si c'est du DMA, ça plombe la bande passante déjà pas bien élevée de la RAM :/
En plus la mémoire doit obligatoirement être "uncached", donc faudra un deuxième buffer de travail, résultat ça n'a que des désavantages.

Bah, on pourrait porter ld-tigcc, aussi. En principe, il est fait pour ne pas être spécifique au 68k, ce serait bien d'éliminer les 68k-ismes.

Tant qu'à faire, autant profiter des IDE puissants supportant les compilateurs adéquats. Et TIGCC supporterait un compilo C++ ?

Brunni (./537) :
Arf quelle merde si c'est du DMA, ça plombe la bande passante déjà pas bien élevée de la RAM :/
En plus la mémoire doit obligatoirement être "uncached", donc faudra un deuxième buffer de travail, résultat ça n'a que des désavantages.

C'est de la RAM interne, pas la SDRAM, donc la bande passante doit être plus importante (bus 32 bits, par contre certainement à 45MHz aussi ), et le buffer écran ne fait que 37Ko.
Rien ne dit qu'on ne peut pas faire comme sur les 89 HW1, changer l'adresse du buffer (et donc ne désactiver le cache que sur le buffer en cours d'affichage).