Désassemblage du boot2 - Page 19

540

Le 16/01/2010 à 19:47

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

541

Le 16/01/2010 à 19:48

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

En tout cas INT_ram_data_start du boot1 est justement ce A4000100 du LCD.

542

Le 16/01/2010 à 20:23

Première fournée du boot 1 :

	MakeName	(0X40,	"Nucleus_Application_Initialize");
	MakeName	(0X2A8,	"log_rs232");
	MakeName	(0X700,	"check_voltage");
	MakeName	(0X7F0,	"restart");
	MakeName	(0X1888,	"load_diags_software");
	MakeName	(0X18DC,	"load_boot2");
	MakeName	(0X1C9C,	"DMCE_Create_Memory_Pool");
	MakeName	(0X1EB4,	"ERC_System_Error");
	MakeName	(0X23F4,	"NU_Create_Memory_Pool");
	MakeName	(0X29C4,	"CSC_Place_On_List");
	MakeName	(0X29F4,	"CSC_Priority_Place_On_List");
	MakeName	(0X2A74,	"CSC_Remove_From_List");
	MakeName	(0X2AA8,	"read_timer");
	MakeName	(0X2AC0,	"poll_sleep");
	MakeName	(0X2B44,	"TCC_Create_HISR");
	MakeName	(0X2C1C,	"TCC_Delete_Task");
	MakeName	(0X2C74,	"TCC_Delete_HISR");
	MakeName	(0X2CCC,	"TCC_Reset_Task");
	MakeName	(0X2D4C,	"TCC_Resume_Task");
	MakeName	(0X2F0C,	"TCC_Create_Task");
	MakeName	(0X30CC,	"TCC_Resume_Service");
	MakeName	(0X314C,	"TCC_Suspend_Task");
	MakeName	(0X3348,	"TCC_Terminate_Task");
	MakeName	(0X34B8,	"TCC_Suspend_Service");
	MakeName	(0X3508,	"TCC_Task_Timeout");
	MakeName	(0X35E4,	"TCC_Task_Sleep");
	MakeName	(0X3634,	"TCC_Relinquish");
	MakeName	(0X36B0,	"TCC_Time_Slice");
	MakeName	(0X3744,	"TCC_Current_Task_Pointer");
	MakeName	(0X3774,	"TCC_Current_HISR_Pointer");
	MakeName	(0X37A4,	"TCC_Task_Shell");
	MakeName	(0X39DC,	"TCC_Dispatch_LISR");
	MakeName	(0X3A2C,	"TCC_Register_LISR");
	MakeName	(0X3B84,	"INT_System_SP");
	MakeName	(0X3B8C,	"INT_First_Avail_Mem_Ad");
	MakeName	(0X3B90,	"INC_Initialize_Ad");
	MakeName	(0X3C50,	"INT_Vectors_Loaded");
	MakeName	(0X3C5C,	"INT_Setup_Vector");
	MakeName	(0X3C74,	"int_irq_enable");
	MakeName	(0X3C88,	"int_irq_disable");
	MakeName	(0X3C9C,	"INT_Retrieve_Shell");
	MakeName	(0X3CAC,	"INT_Undef_Inst");
	MakeName	(0X3CE4,	"INT_Software");
	MakeName	(0X3DE0,	"INT_Reserved");
	MakeName	(0X3E18,	"INT_IRQ_Shell");
	MakeName	(0X3EB8,	"INT_Spurious_Interrupt");
	MakeName	(0X3F20,	"INT_C_Memory_Initialize");
	MakeName	(0X3F30,	"INT_ROM_Data_Copy");
	MakeName	(0X3F5C,	"INT_Clear_BSS");
	MakeName	(0X3F78,	"INT_System_Initialize");
	MakeName	(0X4014,	"INT_HW_Memory_Initialize");
	MakeName	(0X40F8,	"io_init_table");
	MakeName	(0X4230,	"io_init_table_end");
	MakeName	(0X4234,	"INT_Target_Initialize");
	MakeName	(0X4250,	"INT_IRQ");
	MakeName	(0X4274,	"INT_FIQ");
	MakeName	(0X4284,	"INT_Interrupts_Initialize");
	MakeName	(0X4314,	"INT_Timer_Initialize");
	MakeName	(0X4538,	"TCT_Local_Control_Interrupts");
	MakeName	(0X455C,	"TCT_Restore_Interrupts");
	MakeName	(0X4580,	"TCT_Build_Task_Stack");
	MakeName	(0X462C,	"TCT_Build_HISR_Stack");
	MakeName	(0X46A8,	"TCT_Build_Signal_Frame");
	MakeName	(0X4718,	"TCT_Check_Stack");
	MakeName	(0X4774,	"TCT_Schedule");
	MakeName	(0X4850,	"TCT_Control_To_System");
	MakeName	(0X493C,	"TCT_Set_Execute_Task");
	MakeName	(0X4948,	"TCT_Protect");
	MakeName	(0X49B0,	"TCT_Unprotect");
	MakeName	(0X4A10,	"TCT_Unprotect_Specific");
	MakeName	(0X4AA4,	"TCT_Set_Current_Protect");
	MakeName	(0X4AB8,	"TCT_Protect_Switch");
	MakeName	(0X4B00,	"TCT_Schedule_Protected");
	MakeName	(0X4B60,	"TCT_Interrupt_Context_Save");
	MakeName	(0X4C74,	"TCT_Interrupt_Context_Restore");
	MakeName	(0X4CC0,	"TCT_Activate_HISR");
	MakeName	(0X4D50,	"TCT_HISR_Shell");
	MakeName	(0X4E5C,	"TMT_Set_Clock");
	MakeName	(0X4E68,	"TMT_Retrieve_Clock");
	MakeName	(0X4E74,	"TMT_Read_Timer");
	MakeName	(0X4E80,	"TMT_Enable_Timer");
	MakeName	(0X4E98,	"TMT_Adjust_Timer");
	MakeName	(0X4EBC,	"TMT_Disable_Timer");
	MakeName	(0X4ECC,	"TMT_Retrieve_TS_Task");
	MakeName	(0X4ED8,	"TMT_Timer_Interrupt");
	MakeName	(0X4FF8,	"initialize_power_mgmt");
	MakeName	(0X7AF0,	"check_for_nand");
	MakeName	(0X8A28,	"initialize_adc_driver");
	MakeName	(0X9BEC,	"read_boot_data");
	MakeName	(0XAF68,	"install_diags_software");
	MakeName	(0XD4B8,	"INC_Initialize");
	MakeName	(0XD524,	"IOI_Initialize");
	MakeName	(0XD550,	"MBI_Initialize");
	MakeName	(0XD57C,	"PII_Initialize");
	MakeName	(0XD5A8,	"PMI_Initialize");
	MakeName	(0XD5D4,	"QUI_Initialize");
	MakeName	(0XD600,	"RLC_Release_Information");
	MakeName	(0XD91C,	"SMI_Initialize");
	MakeName	(0XD960,	"TMC_Start_Timer");
	MakeName	(0XDAAC,	"j_TMC_Start_Timer");
	MakeName	(0XDAB0,	"TMC_Stop_Timer");
	MakeName	(0XDB2C,	"TMC_Stop_Task_Timer");
	MakeName	(0XDB3C,	"TMC_Timer_Expiration");
	MakeName	(0XDCCC,	"TMC_Timer_HISR");
	MakeName	(0XDD34,	"TMI_Initialize");
	MakeName	(0XE0C4,	"DMI_Initialize");
	MakeName	(0XE0F0,	"ERI_Initialize");
	MakeName	(0XE104,	"EVI_Initialize");
	MakeName	(0XE130,	"HII_Initialize");
	MakeName	(0XE174,	"TCI_Initialize");
	MakeName	(0XEA0C,	"xmodem_file_transfer");
	MakeName	(0XEB88,	"erase_diags_image");
	MakeName	(0XEBC0,	"update_diags_image");
	MakeName	(0X1BB70,	"INT_rom_data_start");
	MakeName	(0XA4000100,	"INT_ram_data_start");
	MakeName	(0XA4000418,	"INT_IRQ_Vectors");
	MakeName	(0XA4001580,	"INT_ram_data_end");
	MakeName	(0XA4001980,	"system_sp");
	MakeName	(0XA4009B00,	"INT_First_Avail_Mem");

543

Le 16/01/2010 à 20:40

J'imagine même pas les poignées de cheveux qu'ils doivent s'arracher chez TI. Eternels respects

544

Le 16/01/2010 à 23:18

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

On peut, l'adresse est en 0xC0000010.

J'essaie de me construire un mini script temporaire pour pouvoir compiler de l'ARM avec gcc, mais je bloque cruellement...
Voilà ce que je fais aujourd'hui, j'essaie simplement d'avoir quelque chose qui marchouile :
arm-elf-gcc -c -Os -Wall -W -fpic -fno-merge-constants "$cfile" -o "$cfile_noext".elf
-fpic pour éviter les adresses absolues, -fno-merge-constants pour éviter la section ".rodata.str1.1".
objdump m'indique qu'au moins 2 sections m'intéressant sont créées, .text pour le code et .rodata pour les chaînes de caractères. J'essaie donc de les extraire et les concaténer (ou peut-on faire mieux ?) :

arm-elf-objcopy -O binary "$cfile_noext".elf text.bin -j .text
arm-elf-objcopy -O binary "$cfile_noext".elf rodata.bin -j .rodata
cat text.bin rodata.bin > "$cfile_noext".bin

Mais testé sur l'émulateur, le code se rate pour retrouver les adresses des chaînes. Apparemment il pense bizarremment que la section .rodata commence au niveau de du pool de constantes à la fin de la section .text, donc un peu trop en avance

546

Le 17/01/2010 à 00:01

C'est parce qu'il y a un relogement en ELF normalement, il ne suffit pas de copier bêtement le tout. Les adresses virtuelles ne correspondent pas aux offsets dans le fichier objet.

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

547

Le 17/01/2010 à 00:24

Argh. Et si je veux porter un chargeur ELF en C, ça va se mordre la queue

548

Le 17/01/2010 à 00:40

Non tu ne fait pas le chargeur elf en elf tout simplement...

Proud to be CAKE©®™

GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

549

Le 17/01/2010 à 04:06

Il faut linker avant de convertir en binaire, donc utiliser ld ou ne pas mettre -c

J'essaye :

arm-elf-gcc -nostdlib -fpic -Os test.c -o test.elf
arm-elf-objcopy -O binary test.elf test.bin

Mais j'ai un gros offset entre .text/.rodata et .data.
Et il persiste à créer une table d'offsets absolus dès qu'il y a quelque chose dans .data.
Pourtant il accède à cette table en relatif PC.

Sinon, pour le loader on peut supprimer -fpic, et imposer une adresse de base :
arm-elf-gcc -nostdlib -Ttext=0x00100000 -Os test.c -o test.elf
et fait en assembleur un bout de code (indépendant de la position lui) qui mappe l'adresse physique à laquelle le code a été chargé en 0x00100000.

550

Le 17/01/2010 à 10:52

Effectivement, ld réalise correctement le layout

hwti (./549) :
Et il persiste à créer une table d'offsets absolus dès qu'il y a quelque chose dans .data.

Si on parle bien de la même chose, en utilisant un linker script (ldscript) de ce type là :

SECTIONS
{
  . = 0x0;
  .text : { *(.text) }
  .data : { *(.data) }
  .bss : { *(.bss) }
}

et la commande :
gcc -T ldscript ...
-> le padding disparaît.

hwti (./549) :
Sinon, pour le loader on peut supprimer -fpic, et imposer une adresse de base

Même avec un chargeur ELF on-calc, si -fpic n'est pas utilisé, il faut effectivement travailler avec la MMU, car si j'ai bien compris ELF ne permet pas le relogement des adresses absolues ?

551

Le 17/01/2010 à 11:43

Plus de padding mais toujours la Global Offset Table.

Je pensais à la MMU pour le chargeur ELF lui-même, et les programmes avec -fpic (le chargeur ELF s'occupant du relogement de la table d'offset). Ce serait mieux de pouvoir se passer de -fpic, mais si on veut permettre le multitaches il faudrait greffer la gestion de la MMU sur Nucleus (lors des changements de contextes).

552

Le 17/01/2010 à 14:54

il va vous falloir écrire un loader elf qui fait les relogements je pense.

1D86FN9
Nspire wiki
CONDUCTEUR Va-et-vient Des QUATRE MANCHE AVEC DES DIODES
La naissance de Boo en vrai

553

Le 17/01/2010 à 20:37

Un autre petit bout de boot 1 :

MakeName	(0XC74,	"load_boot2_progress_cb"); // à voir
MakeName	(0X9A9C,	"read_manuf_dat");
MakeName	(0XAA80,	"cert_get_expected_devunit_field_400");
MakeName	(0XB158,	"__rt_udiv_2");
MakeName	(0XCD70,	"__rt_udiv");
MakeName	(0XCE3C,	"memcmp");
MakeName	(0XCE7C,	"memcpy");
MakeName	(0XCEA0,	"memset");
MakeName	(0XCEC4,	"strlen");
MakeName	(0XCF6C,	"isdigit");
MakeName	(0XCF80,	"isspace");
MakeName	(0XE344,	"read_boot2"); // à voir
MakeName	(0XEF00,	"_load_boot2"); // à voir
MakeName	(0XFB18,	"cert_decrypt"); // à voir
MakeName	(0XFB20,	"free");
MakeName	(0XFB24,	"malloc");
MakeName	(0XFB2C,	"fopen");
MakeName	(0XFB34,	"fread");
MakeName	(0X10628,	"cert_get_field_size");
MakeName	(0X106E4,	"cert_get_size_size");
MakeName	(0X10758,	"cert_to_field_size");
MakeName	(0X1077C,	"cert_read_field_id");
MakeName	(0X107C8,	"cert_next_field");
MakeName	(0X10844,	"cert_find_field");
MakeName	(0X109E4,	"image_getImageInfo");
MakeName	(0X10EC0,	"image_get_program_id");
MakeName	(0X10F78,	"cert_get_public_key_size");
MakeName	(0X11054,	"cert_check_signature");

554

Le 17/01/2010 à 20:38

Si quelqu'un tombe sur des morceaux de code de l'OS permettant de lire le boot 2 en NAND je suis intéressé, apparemment celui-ci est nettoyé de la RAM une fois l'OS chargé.

555

Le 17/01/2010 à 21:30

On sait lire la NAND ? Si oui, on dump tout, c'est peu probable qu'ils aient stocké dans un autre format que le boot2.img

556

Le 17/01/2010 à 21:54

Oui, c'est quasi-sûr que le boot1 écrit tel quel le boot2.img lors d'un flash en RS232.
Je viens de voir que Goplat avait documenté toutes les fonctions d'accès à la NAND dans le boot2, ça va être simple.

557

Le 17/01/2010 à 22:51

Encore un peu de boot1 :

MakeName	(0X25EC,	"DMC_Allocate_Memory");
MakeName	(0X7514,	"lcd_power_off");
MakeName	(0X7640,	"GPIO_is_initialized");
MakeName	(0X7668,	"GPIO_init");
MakeName	(0X7758,	"GPIO_cleanup");
MakeName	(0X77EC,	"GPIO_set_handler");
MakeName	(0X7884,	"GPIO_lisrproc");
MakeName	(0X795C,	"get_nand_id");
MakeName	(0X7974,	"flash_set_debug_print_hook");
MakeName	(0X7994,	"flash_debug_print");
MakeName	(0X7A2C,	"flash_ECC_word_to_bytes");
MakeName	(0X7A58,	"flash_reset");
MakeName	(0X7A84,	"flash_query_chip_type");
MakeName	(0X7DA4,	"flash_query_status");
MakeName	(0X7DC0,	"flash_read");
MakeName	(0X7E58,	"flash_read_whole_page");
MakeName	(0X7E94,	"flash_read_extra");
MakeName	(0X7ED0,	"flash_write");
MakeName	(0X7FA8,	"flash_write_with_ECC");
MakeName	(0X81A0,	"flash_get_page_data_size");
MakeName	(0X81D8,	"flash_get_num_blocks");
MakeName	(0X8218,	"flash_get_block_data_size");
MakeName	(0X829C,	"flash_round_down_to_mult_of_page_size");
MakeName	(0X82B4,	"flash_is_block_bad");
MakeName	(0X88A4,	"flash_ECC_decode");
MakeName	(0X90EC,	"get_clock_speed_Hz");
MakeName	(0XD60C,	"SMC_Create_Semaphore");
MakeName	(0XD6C0,	"SMC_Delete_Semaphore");
MakeName	(0XD79C,	"SMC_Obtain_Semaphore");
MakeName	(0XD874,	"SMC_Release_Semaphore");
MakeName	(0XE2F0,	"flash_erase_range");
MakeName	(0XEB68,	"preload_erase_boot2");
MakeName	(0XEB88,	"preload_erase_diags");
MakeName	(0XEBA8,	"preload_update_boot2");
MakeName	(0XEBC0,	"preload_update_diags");
MakeName	(0X19724,	"flash_chip_type_table");

558

Le 18/01/2010 à 00:54

ExtendeD (./550) :
si j'ai bien compris ELF ne permet pas le relogement des adresses absolues ?

Si, mais c'est en général considéré à éviter: http://people.redhat.com/drepper/textrelocs.html. Il est probable que des patches à la chaîne d'outils soient nécessaires si vous voulez utiliser les text relocations en ARM.

559

Le 18/01/2010 à 08:48

pourquoi les text relocations sont spéciales? Je pensais qu'on pouvait avoir des relocs text et data de manière totalement équivalente!

et on a obligatoirement dès qu'on a des libs dynamiques non?

edit: bon en fait j'ai compris le coup des pages readonly et toussa. menfin sur la nspire je pense qu'osef.

1D86FN9
Nspire wiki
CONDUCTEUR Va-et-vient Des QUATRE MANCHE AVEC DES DIODES
La naissance de Boo en vrai

560

Le 18/01/2010 à 10:44

J'arrive un peu après la guerre mais ...

WOW !!!

Je me permet d'utiliser une expression que j'ai vu passer plus haut :
Je suis grave "trouducuté" par ce que vous arrivez à faire les gars.

Enfin du bon pour la nSpire ;D

Un grand bravo à vous pour ces découvertes majeures.

Continuez comme ça !

TilEm2

561

Le 18/01/2010 à 11:37

Contra (./560) :
Je suis grave "trouducuté" par ce que vous arrivez à faire les gars.

Faut que je pense à me faire payer des royalcheeses moi, c'est pas la première fois que je vois ça

562

Le 18/01/2010 à 12:27

c'est pas une expression open source?

1D86FN9
Nspire wiki
CONDUCTEUR Va-et-vient Des QUATRE MANCHE AVEC DES DIODES
La naissance de Boo en vrai

563

Le 18/01/2010 à 22:36

./558 Kevin, si j'ai bien compris d'après ton article et quelques tests :

- gcc <rien de particulier> : génère du code avec adresses absolues (bizarrement sans text relocation si -pie pas présent)
- gcc -pie : génère du code à adresses absolues, avec text relocations présentent dans la section .dynamic. Bizarrement il y a aussi une GOT...
- gcc -fpic : génère une GOT, accédée en relatif. Le loader s'occupe simplement du relogement des adresses de cette GOT. Chaque GOT relogée est dédiée à un process.
- gcc -fpie -pie : Peut potentiellement générer du code plus optimisé car non partagé en lib, d'après lfs

squalyl (./559) :
dit: bon en fait j'ai compris le coup des pages readonly et toussa. menfin sur la nspire je pense qu'osef.

Pas forcément. La MMU permet de monter un loader avancé multi-processes avec bibliothèques réellement partagées, c'est dommage de s'en priver.

Donc partons pour -fpic et sa GOT sans MMU (ou éventuellement de la MMU uniquement pour le loader si besoin comme indiquait hwti), et plus tard avec MMU dans son édition "deluxe" avec partage des libs en mémoire ?

564

Le 19/01/2010 à 00:47

ExtendeD (./563) :
Donc partons pour -fpic et sa GOT sans MMU (ou éventuellement de la MMU uniquement pour le loader si besoin comme indiquait hwti), et plus tard avec MMU dans son édition "deluxe" avec partage des libs en mémoire ?

Dans la version "deluxe" il faudrait redescendre les programmes en usermode. Le multiprocess risque d'être difficile si tous les programmes jouent avec la MMU (peu probable) ou le contrôleur LCD et les interruptions (ça par contre

565

Le 19/01/2010 à 00:57

ça va rapidement devenir une usine a gaz avec devices et tout le tintouin

1D86FN9
Nspire wiki
CONDUCTEUR Va-et-vient Des QUATRE MANCHE AVEC DES DIODES
La naissance de Boo en vrai

566

Le 21/01/2010 à 20:09

Encore bravo à tous ce que vous avez fait

Ciw? ciw... Ciw!
Vous savez quoi? J'ai un fan: il s'appelle "CPU fan".
Ma maison
Mes Amis: (1),(2),(3)

567

Le 23/01/2010 à 22:59

ExtendeD (./453) :
Bon, je me casse les dents sur cet émulateur qui n'émule pas encore parfaitement les i/o, je perds beaucoup de temps à recompiler, réinstaller, retester à l'aveugle, surtout sans kernel.
Sans JTAG je crois que je vais implémenter un GDB stub via RS232 (puis à terme USB) pour du remote debug.

Pour donner une idée de l'avancement sur ce sujet :

Capture%20plein%20%C3%A9cran%2023012010%20224947.jpg

J'ai commencé par câbler GDB à nspire_emu via un GDB stub en TCP d'une part pour commencer doucement, d'autre part pour permettre à terme le debug de programmes en C (dont ce futur GDB stub pour Nspire, depuis GDB sous emu

)

Là il manque encore le support des breakpoints et watchpoints, et peut-être d'autres choses requises pour le debug de programmes à symboles.

568

Le 23/01/2010 à 23:37

\o/

(et bon courage !)

569

Le 24/01/2010 à 01:19

Par contre ça va être la course au merge, Goplat release sacrément fréquemment.

570

Le 24/01/2010 à 05:07

Et intégrer GDB/Insight directement à l'émulateur comme ça a été fait pour TiEmu/Emu-TIGCC, ça ne te tenterait pas?