[mOved] TI-Nspire, premières impressions - Page 5

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).

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

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.

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 ? Je suis un maître doux moi.

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

ah, 512k

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.

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"

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

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"

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).

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

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
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

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

Xim > linux est pas loin derrière le NOP

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.

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é (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

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

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.

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

Bouffer les piles inutilement, par contre...

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)

OK, j'ai rien dit alors.

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 ?

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é.

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]

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

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 ?

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

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)

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

j'en sais rien 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

./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
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! )
- "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é Quoique...avec toute la RAM qu'il y a... )
- mmu ou pas (Là, je ne me prononcerai pas ^^)

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

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é Quoique...avec toute la RAM qu'il y a... )

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 (surtout que si y a pas de MMU ils sont quasiment obligés de faire comme ça ^^)

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! )

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.

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

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!

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 ?

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".

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...

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)