Organisation mémoire - Page 1

(maintenant qu'il y a des rubriques, autant en profiter pour dédier des topics plutôt que lutter avec ceux de 20 pages)

L'écran About affiche 2 boots (boot 1 et boot 2), qui ont chacun leur version, respectivement 1.1.8916 et .1.8981. D'après Samuel Stearley, la Nspire CAS a aussi 2 boots, avec les mêmes versions que la Nspire.

Des idées de leurs rôles possibles ?

Un boot qui peut être mis à jour et un boot de secours en ROM en cas de problème pour pouvoir renvoyer un OS ?

je pensais pareil. Un bootloader avec juste les fonctions minimales pour charger le vrai bootloader.

On peu envisager un truc genre

boot1 met a jour boot2 et verifie le tout, et une fois a fait il passe la main au boot2 qui met a jour le boot1 et le valide, le tout fait de telle maniere que si le flash de boot1 foire, c'est boot2 qui reprend la main au reset pour permettre de rebooter le tout. On peu meme imaginer que les certifs soit copié de maniere redondantes entre les deux "boots"

A mon avis l'un des deux n'est pas mis à jour, car les écritures en flash sont mauvaises pour la durabilité de la mémoire elle même. Je pense que le premier boot reste là, comme ça on est sur que ce block est bon, et il peut ensuite s'occuper de la recherche des mauvais blocs, par exemple si le bloc numéro 2 est mauvais, le premier boot est capable de le voir et d'aller chercher le vrai boot sur le bloc suivant.

J'ai appris qu'en général, le premier bloc d'une mémoire flash est garanti correct (donc on y met le bootloader), mais les suivants peuvent avoir des défauts d'usine. Donc faut les gérer pour éviter d'écrire dedans.

A voir, mais si ils donne la version du boot1 et boot2 c'est qu'apriori rien n'empecherais qu'il puisse etre mis a jour. Et puis je pense pas que ça soit forcement le genre de choses qui soit mis a jour a chaque update de l'OS

tout a fait d'accord c'est toujours flashable et préférablement à éviter

./3 ./4 : Peut-être aussi qu'aucun des 2 n'est flashable, que boot 1 sait simplement charger boot 2, et boot 2 sait charger l'OS (décryptage/décompression du code de l'OS et préparation du FS).

En tout cas je crois moyennement à une extraction du boot code depuis le .tnc/.tno et à son installation, ça m'a l'air un peu trop compliqué de la part de TI.

Godzil (./6) :
A voir, mais si ils donne la version du boot1 et boot2 c'est qu'apriori rien n'empecherais qu'il puisse etre mis a jour.

Ils donnaient aussi la version du boot sur TI68k.

En lisant la datasheet du chip de mémoire NOR sur lequel nous pensons localiser le boot, je vois qu'il n'y a aucune protection spéciale, et il n'est nulle part question de secteurs protégés en écriture. tout serait flashable, ce qui pourra être pratique.

Dis, en trifouillant l'USB, en faisant planter la calcu dans le boot, etc... Y'aurait pas une interface DFU (device firmware upgrade) dans la gestion l'USB?

rah, dumper la NOR nous en apprendrait beaucoup je suis certain qu'elle boote dessus. Mais sans la dessouder vas y

squalyl (./9) :
il n'est nulle part question de secteurs protégés en écriture.

Intéressant, comme ils interdisent l'exécution de code tiers ils pourraient trouver ça inutile

squalyl (./9) :
en faisant planter la calcu dans le boot,

Tu pensais à quoi exactement ? J'ai essayé de virer une pile lors du boot, il ne se passe rien de spécial.

squalyl (./9) :
en trifouillant l'USB

A voir, des commandes cachées dans leur protocole USB pourquoi pas, mais pas de ce type là je pense.

je sais pas. J'essaye de voir comment ils pourraient avoir calé une porte dérobée permettant de flasher les bêtes à la sortie des chaines de montage. Le soft il est pas né sur les chips mémoire, donc y'a forcément un moyen de com quelconque.

Comment auraient étaient flashés les boots des 68k ? Ce n'est pas très différent.

alors ça j'en sais rien

• squalyl entering mode pas du tout probable et totalement délirant


mais bon, vu la geule du chip de flash des 68k, on peut se dire que c'est plus facile d'avoir des programmeurs de chips SSOP soudés à postériori que des BGA. Mais bon, j'en sais rien.

en plus bon, la nspire, c'est plus récent, alors que la technologue des ti68k c'est moyen récent

bon j'arrête les délires

(il y a generalement des points tests sur les carte mere avec lequels qui ils flashent le boot)

ExtendeD (./8) :

Godzil (./6) :
A voir, mais si ils donne la version du boot1 et boot2 c'est qu'apriori rien n'empecherais qu'il puisse etre mis a jour.

Ils donnaient aussi la version du boot sur TI68k.

mais pas dans le about...

squalyl (./11) :
je sais pas. J'essaye de voir comment ils pourraient avoir calé une porte dérobée permettant de flasher les bêtes à la sortie des chaines de montage. Le soft il est pas né sur les chips mémoire, donc y'a forcément un moyen de com quelconque.

D'après ce que nous a dit un le représentant d'une entreprise de sous-traitance pour la fabrication et montage de composants sur circuits imprimés, la programmation des composants se fait avant le montage sur les CIs.
Ceci avec des grands programmateur pouvant programmer plusieurs 10ene de composants en même temps.
Et ces entreprises possèdent quasi tous les adaptateurs pour tout type de boitier, et si elles ne l'ont pas, elles l'achètent (et évidement c'est répercuté sur les prix )

"et merde"

boaf, on trouvera une autre piste

(moué c'est logique ce que tu dis, ça évite de passer chaque bécane une à une, c'est long un flashage...

squalyl (./9) :
En lisant la datasheet du chip de mémoire NOR sur lequel nous pensons localiser le boot, je vois qu'il n'y a aucune protection spéciale, et il n'est nulle part question de secteurs protégés en écriture. tout serait flashable, ce qui pourra être pratique.

Ca dépend de la broche WE#, mais comme le ZEVIO est donné comme ayant une interface flash NOR, je pense qu'elle est reliée normalement, et que l'écriture est possible, à condition de pouvoir écrire aux adresses mémoires concernées (donc certainement de pouvoir exécuter du code privilégié pour modifier la config de la MMU)

squalyl (./5) :
A mon avis l'un des deux n'est pas mis à jour, car les écritures en flash sont mauvaises pour la durabilité de la mémoire elle même

Même pour la flash NAND (10000 cycles au minimum), ce n'est pas le flashage qui va user grand chose, surtout si TI suit le même rythme de sortie des ROMs que sur les ti68k.

Des suggestions après la découverte de ce que j'ai appelé le recovery mode là-bas.

Le bootage semble se faire en 2 temps. Pendant les 2 étapes une barre de chargement est affichée, à mi-temps la barre est à mi-chemin. Les étapes sont séparées par un clignottement d'une fraction de seconde, qui pourrait être une réinitialisation complète de l'écran et un redessinage. La première étape dur 4 secondes et on ne voit que la barre croître par morceaux. La seconde étape affiche "Preparing file system..." puis "Loading Operating system...", avant de booter l'OS (écran de démarrage avec fond d'écran la X11 et sablier puis l'OS même). les 2 étapes sont aussi présentes dans le recovery mode, c-à-d sans OS, mais la 2ème n'aboutit alors pas.

Une idée serait peut-être que la première étape serait le boot 1, stocké en flash NOR, qui sait simplement charger en RAM le boot 2 stocké dans la flash NAND. Le boot 2 serait la seconde étape, capable de charger l'OS. Comme les 2 boots sont présents même sans OS, ils ne seraient pas flashables. C'est intéressant de voir que la "storage capacity" est de 27.8MB avec ou sans OS. Le boot2 prendrait alors 4,2MB. Ca paraît assez énorme, mais il faut voir qu'on a un support du Computer Link Software complet en recovery mode. L'idée que Nucleus soit non flashable (et donc dans ce boot 2) est peut-être possible (</conditionnel^2>).

Je poste ma question ici car ça n'a rien a faire sur le wiki:

Find out how to reinitialize completely the TI-Nspire, i.e. how to make the OS reinstall the TI-84 Plus flash applications, and display the configuration wizard you meet when you starts your TI-Nspire for the first time

est-ce qu'on sait fait afficher ce "wizard" sur les TI-68k ? Ce n'était pas une histoire d'application flash qui s'auto détruit ?

Tes suppositions confirment ce que je pense. Le "boot2" est simplement l'image ROM du kernel. 4mo c'est tout a fait raisonnable. Le boot 1 est le véritable bootloader (uboot, redboot, ou un truc maison). Il doit être bien plus petit.

C'est classique dans un appareil linux embarqué (openmoko, nslu2, wrt54g, iphone, ipaqs et PDAs). l'OS est en flash, il utilise la RAM pour fonctionner et la mémoire de stockage n'est pas mappée en mémoire.

Y'a même des partitions. Voir le sous-système MTD (memory technology device). sur openmoko (je parle de ce que je connais) /dev/mtd0 est le bootloader, /dev/mtd1 c'est les paramètres du bootloader, /dev/mtd2 c'est l'image du kernel et /dev/mtd3 c'est le rootfs (système de fichiers en jffs2)

doit y'avoir des idées similaires.

edit: krauss

Godzil (./20) :
est-ce qu'on sait fait afficher ce "wizard" sur les TI-68k ? Ce n'était pas une histoire d'application flash qui s'auto détruit ?

Mmm, non, c'est un wizard spécifique à la TI-Nspire, il affiche simplement quelques écrans pour configurer la langue, la taille de la police, etc. Il est affiché après une mise à jour d'OS. J'ai réussi à le faire apparaître en enlevant et remettant une pile, mais impossible à reproduire. Je me demande comment l'OS détermine la "première fois".

ExtendeD (./19) :
Une idée serait peut-être que la première étape serait le boot 1, stocké en flash NOR, qui sait simplement charger en RAM le boot 2 stocké dans la flash NAND. Le boot 2 serait la seconde étape, capable de charger l'OS. Comme les 2 boots sont présents même sans OS, ils ne seraient pas flashables. C'est intéressant de voir que la "storage capacity" est de 27.8MB avec ou sans OS. Le boot2 prendrait alors 4,2MB. Ca paraît assez énorme, mais il faut voir qu'on a un support du Computer Link Software complet en recovery mode. L'idée que Nucleus soit non flashable (et donc dans ce boot 2) est peut-être possible (</conditionnel^2>).

Si le boot2 n'est pas flashable, alors ils auraient toute l'interface "computer link software" en double (boot2 + OS), car ça serait étrange d'avoir ce type de code figé (bugs éventuels)
En plus, le fait qu'ils aient des versions différentes semble indiquer une certaine indépendance entre les deux.

En plus, ce qui me semble étrange avec cette organisation, c'est la taille de la flash NOR (512Ko), qui semble énorme pour ce qu'il y aurait à faire (initialisations, lecture flash NAND et décompression)
Avec 512Ko, je pensais à un support minimal de l'USB, pour pouvoir flasher.

Et 4Mo ça me semble beaucoup pour un kernel + computer link (surtout avec une probable compression)

TOUTE la mem flash est flashable, les chips utilisés n'ont pas de write protect comme les ti68k. C'est clair,net,précis, et pas contournable. C'est le chip.

512 ko c'est pas énorme, ça fait 8 erase block de 64 ko, et si un ou deux sont utilisés pour des variables ça vient vite.

et je pense que le kernel n'est pas compressé, mais qu'il est mappé en mémoire. c'est possible et bien probable.

squalyl (./24) :
TOUTE la mem flash est flashable, les chips utilisés n'ont pas de write protect comme les ti68k. C'est clair,net,précis, et pas contournable. C'est le chip.

Je parlais du point de vue utilisateur, pour une mise à jour venant de chez TI.

squalyl (./24) :
512 ko c'est pas énorme, ça fait 8 erase block de 64 ko, et si un ou deux sont utilisés pour des variables ça vient vite.

il y a des secteurs de 4Ko

squalyl (./24) :
et je pense que le kernel n'est pas compressé, mais qu'il est mappé en mémoire. c'est possible et bien probable.

Je parlais surtout de l'hypothèse boot2 = kernel de 4Mo. Dans ce cas le kernel est dans la flash NAND, donc il n'est pas mappé en mémoire. Et en plus, même en cas de mappage en mémoire, le kernel voire le boot est souvent compressé (les routeurs (Linux, VxWorks) où le kernel est compressé, le BIOS des PC). Ca a du sens dès qu'il y a beaucoup de RAM et une puissance de CPU suffisante pour avoir une décompression assez rapide.

Dans une Flash quelconque, il y a des erase block qui font jamais moins de 68 ko

Dans une flash NAND y'a des secteurs

Dans une flash NOR, y'en a pas, on peut lire ou on veut.

squalyl (./24) :
TOUTE la mem flash est flashable, les chips utilisés n'ont pas de write protect comme les ti68k. C'est clair,net,précis, et pas contournable. C'est le chip.

La puce qui gère les adresses ("telle plage est allouée à tel composant") ne peut-elle pas refuser la communication avec la flash quand un accès en écriture est demandé ?

en mode superviseur c'est désactivable, en supposant que c'est désactivé.

Mais il faut déjà y arriver, au mode superviseur. Pour l'instant, on n'a même pas le mode utilisateur! Et ça m'étonnerait qu'il y ait un cadeau de type trap #12 pour passer direct en superviseur...

c'est sûr