<oriansj>as hex2 doesn't need catm to be built generally speaking <oriansj>M0 and above absolutely require catm <oriansj>(atleast until proper mescc-tools is built) <stikonas>well, catm is useful once hex2 is there (to add hex2 header) <stikonas>but obviously you can't use that for catm itself <stikonas>but you can still embed hex2 header inside catm.hex2 file and get most of the benefits <oriansj>nope and thus there will be a hair of duplication for hex2 ELF headers but oh well <oriansj>^nope^no it isn't possible to leverage the standard hex2 elf header in building of catm because you need catm to do so^ <stikonas>well, yes, but embedded hex0 header is no better than embedded hex2 header <stikonas>and you have either hex0 or hex2 header in catm <oriansj>so hex0, hex1, hex2 and catm just need manually to update their ELF bits if we figure out new standardized changes but I guess there is no avoiding that anyway <oriansj>atleast with hex2, wrong values are easier to fix <stikonas>although here I think they put code in some empty space in the header <stikonas>if most or all UEFI implementations can run those terse images, we can have way smaller binaries <oriansj>yeah, there is huge savings potential IF I can get a solid block to focus on working out the ugly details <oriansj>our ELF binaries are tiny compared to their standard tools built equal <stikonas>well, I still can't understand if Terse images are supported in UEFI applications <oriansj>well we will know for absolute certain once I make a proper M1 UEFI application <oriansj>then we will know absolutely the most minimal UEFI binary we can make <stikonas>well, it can be just "RET" in the code section <stikonas>but the header or maybe header and footer might be harder ***civodul` is now known as civodul