Organisation mémoire - Page 2

Va savoir...

Faudrait deja se renseigner sur Nucleus pour voir comment il est organisé...

Ca m'étonnerait pas vraiment qu'ils aient mal isolés les modules "système", et que n'importe quel code y est accès, puisque de toute façon il n'y a pas de chargement de code externe possible.

Il ne devrais pas y avoir un sorte d'application flash sur la NSpire ?

C'est pas prévu pour l'instant. C'est un modèle "avec toutes les applications intégrées" comme ils disent au marketing de TI.

hwti (./23) :
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)

Mais sur TI-68k c'est pareil (même si le support du link est plus minimal). Dans tous les cas c'est quasi-sûr que le support complet du link est dans le boot (quelqu'il soit), vu que j'avais interrompu l'installation de l'OS.
[edit] : non c'est stupide, ce code là aurait pu être mis à jour avec l'OS comme tu devais penser.

Sur les TI89TI, l'USB est-il géré par le boot ?

Oui.

En tout cas sur Nspire le code de gestion du link est le même (ou est identiquement dupliqué) entre l'OS et le boot. Y'a un buffer overflow très simple et gros comme une maison qui se manifeste sur les 2. L'OS a un mécanisme de reboot automatique en cas de plantage, que n'a pas le boot. Apparemment l'écran doit pas être mappé en mémoire aussi simplement que sur 68k, les plantages ne le perturbent jamais.

Un autre truc marrant en cas de plantage et que le flag "Bus Powered" des descripteurs USB est visiblement bien réel, on peut virer le clavier et les piles en dessous en laissant le câble branché sans que ça s'éteigne (c'est moins visible en tant normal car l'enlèvement du clavier provoque automatiquement l'éteignage de la calc).

Bon, à la recherche d'un petit shell code maintenant (je garantie rien du tout).

bus powered ça évite les embrouilles avec les piles plates

un shell code pour nucleus? Courage!

<hs> : Tiens, TI cherche des codeurs indiens http://www.lionbridge.com/careers/empdisplay.asp?intJobID=621

ExtendeD (./39) :
Y'a un buffer overflow très simple et gros comme une maison qui se manifeste sur les 2. L'OS a un mécanisme de reboot automatique en cas de plantage, que n'a pas le boot. Apparemment l'écran doit pas être mappé en mémoire aussi simplement que sur 68k, les plantages ne le perturbent jamais.

Bonne nouvelle, même si le fait que l'écran ne soit pas affecté me conforte dans l'idée qu'ils utilisent la MMU.

Application development experience on handheld devices like TI-73/TI-84 and TI-Nspire using Nucleus RTOS and embedded C

A part les ceux qui ont travaillé sur la Nspire, je ne vois pas qui pourrait qui pourrait avoir développé dessus.

embedded C using TIGCC Compiler

Depuis quand TI reconnait TIGCC ? Etrange, car vu que la Nspire est fermée, c'est probablement pour travailler pour TI, qui reconnaitraient donc que leur SDK est pourri.

Mais tigcc n'est même pas supporté officiellement par TI
Sinon,

Application development experience on handheld devices like [...] TI-Nspire using Nucleus RTOS and embedded C

Je croyais qu'on pouvait pas faire d'application sur TI-Nspire.

Hallucinant!

hwti (./43) :
Bonne nouvelle, même si le fait que l'écran ne soit pas affecté me conforte dans l'idée qu'ils utilisent la MMU.

Je viens de trouver un plantage qui affiche systématiquement les mêmes déchets de pixels à l'écran, mais ça ne veut rien.
Pour la MMU, étant donné que c'est un module optionnel de Nucleus, je penche toujours pour du non-MMU.

PpHd : peut-être que LionBridge ne sait pas vraiment de quoi il parle.

./45: Il faut quand même se rappeler que la RAM fait 32 Mo et que le code y est stocké. Même si l'écran est mappé dans l'espace mémoire, il ne doit pas être si facile de faire un plantage qui affiche quelque chose.

ExtendeD (./45) :
PpHd : peut-être que LionBridge ne sait pas vraiment de quoi il parle.

Probablement, mais ca reste superbe. Qui répond avec un faux CV ?

Mine de rien s'ils sont ou ont été en contact avec TI ça serait un moyen d'avoir des infos (enfin quelles infos...)

On sait jamais. Peut être tout le code source.

Nucleus sans MMU couterait moins cher ?
Dans ce cas, ils auraient tout misé sur le cryptage de leurs updates d'OS. Sans MMU, on n'aurait même pas la "protection" des HW2 et plus.

mais tu sais ce que c'est un MMU

y'en a pas dans les HW2 hein ^^

c'est pas vraiment une bonne nouvelle d'en avoir un dans la nspire, ça veut dire que le CPU peut nous faire prendre des vessies pour des lanternes avec la mémoire.

Bien sur, je sais ce que c'est.

Je disais que si ils n'utilisent pas la MMU, on n'a même pas de protection d'exécution et d'écriture en flash comme celle qu'on a sur les HW2 et plus implantée dans l'ASIC.
Une MMU protégerait bien mieux que ce qu'on avait sur les ti68k.

• ExtendeD compte les pixels au microscope et confirme que le pattern à l'écran du dernier plantage fait 32 bits de large

C'est marrant, au microscope certains niveaux de gris se rapprochent plus du rouge que du vert.

Hé hé, un plantage avec une pattern de 32 bits de large... ça semble avancer

Apparemment l'ARM travaillerait en little-endian (j'avais lu qu'avec ARM on pouvait choisir le mode utilisé). L'alignement des instructions sur des multiples de 4 se confirme aussi.

je confirme qu'on peut choisir l'endianess arm

ExtendeD (./52) :
• ExtendeD compte les pixels au microscope et confirme que le pattern à l'écran du dernier plantage fait 32 bits de large

32 bits au sens de 8 pixels en niveaux de gris ou 32 pixels d'un plan noir&blanc ?

ie, le buffer écran est entrelacé ou en plans séparés?

Pardon, 32 pixels.

en noir et blanc alors?

• squalyl veut une photo (dsl )

Qu'est-ce qu'il faut pas faire... http://picasaweb.google.com/olivier.armand/TINspire