540

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 sad ), 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

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

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

J'imagine même pas les poignées de cheveux qu'ils doivent s'arracher chez TI. Eternels respects grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

544

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.

545

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 sad

546

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

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

548

Non tu ne fait pas le chargeur elf en elf tout simplement...
avatarProud 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

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

Effectivement, ld réalise correctement le layout smile
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

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

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

553

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

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

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

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

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

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

559

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.

560

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

WOW !!! boing pam chew fou eek helico langue king dingue trifus trigni

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

Enfin du bon pour la nSpire ;D

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

Continuez comme ça ! king


561

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 embarrassed
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

562

c'est pas une expression open source? sad

563

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

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 ?


oui

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

565

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

566

Encore bravo à tous ce que vous avez fait top .
avatarCiw? ciw... Ciw!
Vous savez quoi? J'ai un fan: il s'appelle "CPU fan".
Ma maison
Mes Amis: (1),(2),(3)

567

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

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

568

\o/
top
cool
(et bon courage !)

569

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

570

Et intégrer GDB/Insight directement à l'émulateur comme ça a été fait pour TiEmu/Emu-TIGCC, ça ne te tenterait pas? smile
avatarMes 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é