LOL. Bon, j'crois qu'on peut oublier le __mbr avec SCEDoormat. Apparemment, le bordel ne va pas jusqu'au bout si la taille totale de tous les blocs (en bit table) est supérieure à la taille réelle du contenu inscrite dans l'en-tête du KELF. Je viens de me rendre compte que ça foire en essayant d'upgrader le uLE HDD Edition de WIP6 à WIP7. Reste à déterminer quelle est la raison et quelles sont les limites exactes, par exemple savoir si ça passe avec un contenu de taille inférieure à celle indiquée...
EDIT 1 : Mon c*l. Oubliez ce que j'ai dit plus haut. J'ai balancé un autre ELF plus petit dans le container (mais toujours + gros que la taille en header), ça marche.
Ça se précise. Ou bien le lanceur n'aime pas la façon dont ma build de uLE est conçue (standard respecté : headerless et entrypoint à 0x00100000), ou bien y'a une limite de taille en MBR (mon uLE n'était PAS packé, et faisait un peu moins de 1 MB)... L'extinction est violente, comme si il ne seekait pas dans les secteurs...
EDIT 2 : BINGO ! La taille max du KELF acceptée en MBR est 0x6BD (1725 secteurs, 883200 octets).
Résumé des propriétés :
- Le ELF doit être sans header. Load address à partir de 0x00100000 et entrypoint à 0x00100000
- La taille du KELF ne peut excéder 883200 octets
- La user header du KELF doit avoir les deux flags suivants : premier byte == 0x01, quatrième byte == 0x04
Pour où écrire le KELF, aucune idée. $ony fout les siens aux secteurs 8192 (0x2000) et 8224 (0x2020). Perso, je les place au secteur 16 (0x10), ou bien à 262144 minus la taille de mon KELF en secteur (0x040000 - kelf_size).
Faudrait que je pense à mettre des warnings de tailles pour les partitions HDL et le MBR dans le prochain SCEDoormat. Aussi, le check des flags pour le MBR est incomplet; j'ai oublié l'inspection du 1er byte :facepalm: .