120

ExtendeD (./119) :
Dans le cas où le boot serait sur la flash NOR, le code ne serait pas plutôt exécuté directement depuis la flash ?

Quand j'ai lu ca la derniere fois, je me suis fait la meme reflexion que toi ExtendeD, et j'en suis arrivé a la meme conclusion qu'hwti concernant un boot isolé sur la flash NOR.

Et ca me fait penser a une chose : ./40 & ./39
Mais ce qui me titille c'est surtout ca :
bloo (./40) :
ExtendeD (./36) :
Tu disais qu'il n'y avait pas de mécanisme de reset profond comme les autres TI. Ca se manifeste comment de bout-en-bout un plantage sur Nspire ?


Lorsqu'elle a plantée, la Nspire a rebooté, puis je suis repassé par les écrans de bienvenue (réglges système...). J'ai perdu mon document en cours, non sauvegardé (RAM), mais en revanche, je n'ai pas perdu le contenu de la mémoire flash. La Nspire fonctionne plus comme un ordinateur que comme une calc. Finalement, l'usage de la RAM est plutôt transparent pour nous.


Ce qui laisse penser que la NOR est lue/executée (comprendre le boot), puis une partie de l'OS sur la NAND est copié en RAM, non ?
A moins que dans les deux cas les flash soient copiées avant d'etre executées...Mais là, je trouve rien qui laisserai penser ca hum2

121

Dude (./120) :
A moins que dans les deux cas les flash soient copiées avant d'etre executées...

Si c'était le cas je verrais pas l'interêt de la NOR (ou en tout cas qu'elle soit si grosse).

122

pour l'OS justement.
ExtendeD (./117) :
A la fois j'espère (plus pratique pour le dev) et j'espère pas (limite les possiblités d'attaque).

Je pensais pareil sorry
ExtendeD (./119) :
DataMath indique : "Due to the missing address bus the NAND Flash-ROM chip doesn't allow random access to the individual memory positions and therefore it can't be used for program memory of a microprocessor."
Donc (peut-être que je dis n'importe quoi) le code exécuté est toujours copié en RAM, et soit il y a une MMU, soit il serait possible de patcher le code de l'OS à la volée dans le cas où le flot d'exécution serait détourné. Il indique aussi : "During power-up of the system the program content of the NOR Flash is simply copied into the SDRAM and executed from there.". Dans le cas où le boot serait sur la flash NOR, le code ne serait pas plutôt exécuté directement depuis la flash ?


Ca c'est normal, la NAND s'accède par secteurs. Si du soft y est stocké il est FORCEMENT chargé en ram.
Le bootloader et l'OS nucleus, je pense qu'ils sont sur la NOR, qui est la seule mémoire avec la ram à pouvoir se trouver dans l'espace mémoire du CPU.
La NAND sert de stockage.

La solution viendra du JTAG si on le trouve.
J'ai un câble, il faut explorer le PCB.

J'ai une expérience en OpenEmbedded maintenant, et je sais que le Linksys NSLU2 fait tourner un linux complet sur 8 Mo de NOR + 32 Mo de RAM, ça doit passer en 4 Mo de flash.
Il est envisageable de l'utiliser sur cette bécane.

Extended, il faudrait qu'on se rencontre.

123

squalyl (./122) :
Le bootloader et l'OS nucleus, je pense qu'ils sont sur la NOR, qui est la seule mémoire avec la ram à pouvoir se trouver dans l'espace mémoire du CPU.

Tout ça tiendrait vraiment sur 512k ? J'aurais plutôt vu Nucleus embarqué dans le .tno/tnc (je doute qu'il y ait un flashage sur 2 puces différentes).
Et dans tous les cas il y du code exécutable autre que Nucleus, qui sera un moment ou un autre copié en RAM.
Extended, il faudrait qu'on se rencontre.

Je l'ai depuis à peine une journée et tu veux la malmener ? eek Je suis un maître doux moi.

124

grin boah l'ouvrir pour chercher le jtag quoi grin
(nan j'déconne bidouille la soft, avant grin)
(mais j'ai pas 150 euroballes moi on vient de me débiter la caution de mon appart tsss)

ah, 512k sorry

quoique... Pour un RTOS c'est lâârgement suffisant, surtout si toutes les données sont dans la nand et qu'un MMU permet d'avoir de la mémoire virtuelle et un mmap()

copié en RAM pas forcément si l'OMAP est assez avancé pour avoir un MMU.

125

Un maître doux ? C'est marrant quand quelqu'un (LD ?) a dit "une nspire de plus" j'avais envie de dire "bientôt une de moins" grin

Et l'hypothèse d'une des deux mémoire comme tampon avant flashage de l'autre pour les mises à jour ? Pas besoin d'accès aléatoire pour ça.

Sinon avant d'installer un linux ça serait pas mal d'arriver à exécuter un nop tongue
avatarQue cache le pays des Dieux ? - Ximoon's Box - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

126

squalyl (./124) :
quoique... Pour un RTOS c'est lâârgement suffisant, surtout si toutes les données sont dans la nand et qu'un MMU permet d'avoir de la mémoire virtuelle et un mmap()

Mais ils auraient dans tous les cas interêt à avoir Nucleus embarqué dans l'OS pour le mettre à jour (dans l'hypothèse où la NOR n'est pas touchée par un flashage).
Copié en RAM pas forcément si l'OMAP est assez avancé pour avoir un MMU.

Mais "NAND Flash-ROM's requires bad block management to be performed by device driver software or hardware." comme Joerg dit, donc elle sera bien un moment en RAM avant exécution, même mmappée.
Il y a vraiment un OMAP dans l'histoire ?
Ximoon (./125) :
Un maître doux ? C'est marrant quand quelqu'un (LD ?) a dit "une nspire de plus" j'avais envie de dire "bientôt une de moins" grin

grin Seule une 89 HW1 a trépassé, c'est un taux de survie correct.
Et l'hypothèse d'une des deux mémoire comme tampon avant flashage de l'autre pour les mises à jour ? Pas besoin d'accès aléatoire pour ça.

Ca serait seulement pour le flashage ? Pourquoi ne pas utiliser la RAM directement pour ça ? (ou j'ai rien compris).

127

Quand tu fais la manip transfert usb -> mémoire tampon -> mise à jour, si tu stockes en mémoire non volatile ça te permet de gagner tu temps en cas de coupure, de garantir une meilleure sécurité des données (impossibilité de hacker facilement les données pendant le transfert, qui peut être fait en dma ou par une puce dédiée d'ailleurs), puis tu vérouilles tout et effectue le décryptage/mise à jour.

Si tu copies en RAM, déjà ça t'en monopolise un paquet, et ensuite tu es drôlement vulnérable.

Enfin c'est ma vision des choses grin
avatarQue cache le pays des Dieux ? - Ximoon's Box - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

128

Oui, on peut très bien télécharger le nouvel OS en NAND et le reflasher ensuite à sa bonne place.

Imaginez la NAND comme un disque dur, et la NOR comme un BIOS.
ExtendeD (./126) :
Mais ils auraient dans tous les cas interêt à avoir Nucleus embarqué dans l'OS pour le mettre à jour (dans l'hypothèse où la NOR n'est pas touchée par un flashage).

Ca pose aucun souci smile
Openslug ( http://www.nslu2-linux.org/ ) boote sur une partition flash de 4 Mo en jffs2 et de dépêche de monter un stick USB sur "/" pour profiter d'un espace mémoire plus grand, ext2, plus swap smile

ExtendeD (./126) :
ais "NAND Flash-ROM's requires bad block management to be performed by device driver software or hardware." comme Joerg dit, donc elle sera bien un moment en RAM avant exécution, même mmappée.

Oui, la NAND se lit par bloc de ~512 octets (rien à voir avec les "erase block" de 64-128 Ko) , la MMU a des pages de quelques ko, on peut se servir de la RAM comme d'un cache smile

Xim > linux est pas loin derrière le NOP trioui

Si on accède au JTAG on pourra flasher la mémoire NOR en se passant complètement du cryptage, ce qui permettrait d'y mettre au moins un bootloader.
U-boot sait déja faire pas mal de trucs qui pourront être utile, comme trouver les cartographies mémoire, etc
Par JTAG on peut (théoriquement) aussi écrire en RAM et puis l'exécuter.

129

ExtendeD (./117) :
KonanYao (./114) :
A ce propos,vu que la TI-Nspire contient 32 Mo de NAND Flash et que seulement 27.8 Mo sont visibles pour le soft et la mémoire de stockage,il semblerait que Nucleus RTOS soit stocké dans ces 4.2 Mo manquants.

L'OS en fait ~3Mo. Le boot en ferait plus de 1Mo ?? (où il y a encore une fois de la mémoire gâchée ?)

Ce serait aussi envisageable que l'OS soit compressé smile (surtout sachant que les trucs en clair sont déjà zippés ^^)
Et puis si c'est compressé y a bcp de chances pour que ça soit décompressé sans être réencrypté avant d'être stocké en flash, ça nous arrangerait bien cheeky

(par contre ça fait peut-être un peu faible comme taux de compression, 70% ?)

130

perso, je pense que ça sert à rien de le compresser. Les performances s'en ressentiront.
Si on bidouille avec de la mémoire virtuelle c'est largement plus facile. Seul le noyal doit être chargé en permanence. Les autres trucs sont swappables.

131

les "performances" ? c'est vraiment gravissime de perdre 2 sec quand on transfère un nouvel OS trioui (surtout si le transfert va N% plus vite)

132

Bouffer les piles inutilement, par contre... cheeky
avatarQue cache le pays des Dieux ? - Ximoon's Box - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

133

euh je parle d'un OS *décompressé* dans la flash, c'est juste le .tnc qui serait compressé ^^ (donc aucun impact sur les piles)

134

135

squalyl (./128) :
Si on accède au JTAG on pourra flasher la mémoire NOR en se passant complètement du cryptage, ce qui permettrait d'y mettre au moins un bootloader.

Ca serait bizarre que ce soit aussi simple. C'était techniquement faisable un truc pareil sur 68k ?

136

non, car il n'y avait pas d'accès JTAG, ou alors si il y en avait un , il se situe au niveau de l'ASIC et n'a jamais été identifié.

137

Donc là y'aurait beaucoup de chances que les JTAG n'existent toujours pas ? Tu irais comment pour les trouver, ça se voit pas à l'oeil ? [ou pourquoi le E de ISEP n'a plus de sens]

138

je sais pas encore. Sur le PCB, c'est pas évident, mais y'a plein de testpoints. on sait jamais.

si c'est ça http://www.unsads.com/~squalyl/nspire/specs/ZEVIO1020_PB.pdf qu'elle a dans le ventre, le jtag est prévu.

EDIT: c'est quoi ce connecteur noir avec des ressorts dorés en haut?
http://www.unsads.com/~squalyl/nspire/pics/nspire003.jpg

139

Pour résumer les suppositions précédentes :

- Seule la NAND est flashée lors d'une mise-à-jour d'OS
- La NOR contient un bootloader qui charge Nucleus depuis la NAND
- D'une façon ou d'une autre tout code hors boot est copié en RAM avant exécution
- mmu ou pas

Ca se tient ?

140

en gros. Moi je voyais le kernel dans la nor aussi.

141

Mais :
ExtendeD (./126) :
Mais ils auraient dans tous les cas interêt à avoir Nucleus embarqué dans l'OS pour le mettre à jour (dans l'hypothèse où la NOR n'est pas touchée par un flashage)

142

bah qui nous empêche d'updater les 2 flashs?

j'en sais rien sorry ptet carrément y'a un système de fichiers complet dans la nand.

m'énerve m'énerve m'énerve

• squalyl veut dumper ces flashs
• squalyl veut trouver le jtag

• squalyl sad

143

./141 Ca se tiens : il y a qu'a voir sur les 68k, quand on flashe l'OS on touche pas au boot a ce que je sache smile
Mais un point me chiffonne quand meme : voir le 3° point ci-dessous.

- "Seule la NAND est flashée lors d'une mise-à-jour d'OS" (La mise a jour des 2 flash est tres peu probable, donc a priori oui, sinon ce serait stupide : bonjour les retours SAV! tongue )
- "La NOR contient un bootloader qui charge Nucleus depuis la NAND" (donc execution depuis la flash; quasi-certain)
- "D'une façon ou d'une autre tout code hors boot est copié en RAM avant exécution" (<- Ca me laisse penser que si c'est le cas, alors il devrait y avoir une partie du noyau dans la NOR aussi, chargée de loader en RAM les bons bouts de code de l'OS car ca m'etonnerai que l'OS en entier soit copié sorry Quoique...avec toute la RAM qu'il y a... confus )
- mmu ou pas (Là, je ne me prononcerai pas ^^)

144

J'ai un peu fouillé, et s'il s'agit bien d'un LSI Zevio 1020, on peut peut-etre se referer a ca :
http://www.arm.com/products/CPUs/ARM926EJ-S.html
mais surtout ca :
http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf
squalyl, ya des trucs pour toi sur le JTAG dedans smile

145

Dude (./143) :
- "D'une façon ou d'une autre tout code hors boot est copié en RAM avant exécution" (<- Ca me laisse penser que si c'est le cas, alors il devrait y avoir une partie du noyau dans la NOR aussi, chargée de loader en RAM les bons bouts de code de l'OS car ca m'etonnerai que l'OS en entier soit copié sorry Quoique...avec toute la RAM qu'il y a... confus )

A mon avis avec 32 Mo de RAM et < 4 Mo de code c'est sûrement bcp plus simple pour eux de tout copier smile (surtout que si y a pas de MMU ils sont quasiment obligés de faire comme ça ^^)

146

Si c'est ça j'espère vraiment vraiment vraiment que y'a pas de mmu, ça simplifiera pas mal.
Dude (./143) :
(La mise a jour des 2 flash est tres peu probable, donc a priori oui, sinon ce serait stupide : bonjour les retours SAV! tongue.gif )

Sur 68k le bloc de flash où se situe le boot (sur la même puce) est verrouillé en écriture très tôt après le reset par le boot code, donc c'est possible de flasher une puce sur lequel se trouve le boot sans prendre vraiment de risques.

147

C'est vrai...qu'il y a 32 Mo de RAM ^^' M'y habituerai pas de sitôt! hehe

bloo ou ExtendeD > Y a-t-il un ecran où on peut voir l'occupation de la mémoire ? Si oui, est-ce comme sur les 68k où l'on pouvait voir la place que prennait le systeme ?

Et c'est vrai qu'a y reflechir, TI a pas trop dû s'embeter avec ca : ils copient tout et hop! tongue

Pour ce qui est de la MMU, j'ai l'impression qu'il y en a une (si j'ai bien compris le datasheet de l'ARM officiel)
Mais il y a une question que je me pose : LSI a-t-il pu enlever des trucs comme la MMU en creant son Zevio ?

148

ARM impose une mmu ??
ExtendeD (./126) :
Il y a vraiment un OMAP dans l'histoire ?

Sur ticalc.org, à propos des premiers protos vs la version d'aujourd'hui : "Based on a Texas Instruments OMAP instead the LSI Logic ASIC".

149

Ca m'en a tout l'air...
Sur http://www.arm.com/products/CPUs/ARM926EJ-S.html on voit une MMU par cache, mais bon...Dans les features il y a clairement indiqué une MMU

Sur http://fr.wikipedia.org/wiki/Processeur_ARM ils parlent de la Famille ARM9E, dont :
"ARM926EJ-S: DSP, double cache, MMU, 2 ports AHB"

Et sur la meme page, un poil plus haut, je cite :
"MMU : Gestionnaire de mémoire permettant d'avoir une sécurité accrue (uniquement presente sur l'ARM710 et les ARM9).la MMU permet l'adressage virtuelle de la memoire, elle est nécessaire pour faire fonctionner certains systèmes d'exploitation comme windowsCE ou la plupart des linux."

Je sais pas trop quoi en penser, on dirai qu'elle y est integrée d'office, a moins (encore une fois) que LSI ai pu retoucher les spef techniques de l'ARM, mais ca me semblerai bizzard...

150

Elle est intégrée et fait partie de l'architecture. MAIS de toute façon c'est comme sur les autres CPU, un MMU ça se désactive par un bit de registre quand on est en mode superviseur.

Dude, quelles sont tes sources pour affirmer que la nspire contient bien un zevio 1020 ? (pas pour te contredire mais pour être au courant quoi)