will you Bulid a slim version?

[jcrorxp]

Thank you for you contribution,but I think the payload.bin size is more and more large. And It will hard to deposit into a MCU like trinket M0. So can we make a branch with a Slim hekate CTCaer. just with base tools, like TX payload.bin?

[CTCaer]

The size of the payload can't go more than 123.5KiB, anyway.

Otherwise it breaks completely.

There is a small version in the works though.

[mariogamer2]

I thought the max size was like 2ko? Why is it breacking before?

[CTCaer]

2k above limit. If max was 2kB we wouldn't had all these with such an ease.

If you pass the 123 limit, the payload breaks because either it doesn't fit in IRAM at all or it covers the relocation code.

The injectors, inject them at an address where only 128KiB are available. And then intermezzo moves them in an address where 192kB are available.

And I don't want to force an update to all injection tools.

[fennectech]

A hekate payload cant fill a trinket. I dont get the point of a small cutdown version tho.

[AnnsAnns]

The idea is to have a minimal version that has a really small size and fits onto everything @fennectech . It may sound stupid to some but there are devices that could potentially have problems fitting the whole hekate payload onto their very limited storage (especially with the upcoming Signature Patches taking the payload to nearly max size).

I'd guess something like a payload that just chainloads the full hekate from SD could potentially be useful for small dongles/mod-chips since the payload size would be extremely small and it wouldn't require the payload to be updated often (probably ever).

[fennectech]

i suggested that before but ctcaer shut that down rather quickly

[mariogamer2]

You suggested it as for the general case, not for dongles and stuff.

Also, hekate will probably hit the max size soon. At that point some feature can be implemented in external payload ( including maybe dev stuff? unused?)

[AnnsAnns]

Yeah, there is no possible way to add new features once sigpatches are included due to the enormous size (well, there is still some room) so moving to a system with multiple payloads will be the only way to include other tools - Maybe something like a pure bootloader (without any tools to choose from except maybe nand dumping) and a tool-payload? I don't think that we reached the point where new stuff doesn't have to be added anymore and even if, this size limit will always stay a problem that we will have to deal with.

We can still take some precautions like removing "unnecessary" options like dumping certain parts such as user and sys, removing CTCaer's logo, removing the standard bootlogo, etc. but I don't think that this is the ideal solution.

People are willing to go the extra step and add stuff to there SD if that means that we would have more features and even if, most people use SDFiles packs that could just add them.

Having one single payload may be cool but is it really worth the cost?

---

Also about your issue @fennectech - While I normally try to keep that stuff out of GitHub, issues ARE NOT chats so you should try to only comment with valid and or important stuff - I see you everywhere commenting like this is some sort of social media app. Try to refrain from commenting stuff that isn't important or truly helping the issue. I don't even get how CTCaer remains so calm about you posting to every issue.

And as @mariogamer2 said, you wanted something different - a payload that just loads hekate is something different from your idea - This one is about storage in dongles and modchips - not everyone is using a trinket m0

[mariogamer2]

I don't even think there is enough space to merge kip patching, with payload booting.

[AnnsAnns]

Correct, rajkosto did manage to get it under the limit ( see here ) but we only have 27 Bytes left - So making this repo modular is currently the only way to get other features in (and the other stuff I previously mentioned)

[rajkosto]

getting rid of the menu logo frees up around 10K that should be plenty for some additional features if required.

also, arent most modchips/dongles going to have at least 256KB flash ? 64KB-128KB for the actual trinket firmware is more than enough.

[fennectech]

Could the logo be loaded from disk? That might let us have our cake and eat it too.

[GGLinnk]

My suggestion, use two different payloads :

1. The first one for launching CFW only.
2. And the second for dumping / restoring / print infos / etc.

Also, the size can be shortened by simplifying or removing texts for dump / restore menus, less warning in payload, more wiki F.A.Q. on github (or other website).

[CTCaer]

I believe that this discussion reached its end.
Mostly because it's a hit or miss suggestion thread and here is not the place for that. It's not a forum.
If you have an implementation though, be my guest and make a pull request.

Don't forget that what you are proposing, they already either worked internally or in the thoughts list since the development of v3.0. It is constantly hitting max size since then and simultaneously optimized. And I have several solutions since then. I don't upstream them because I don't want things to be a "let them and forget them".
This specific limit forced rajkosto to GREATLY optimize and future-proof (if someone wants to add many kips) his PR.

Anyway, imo the payload size limit is not something that concerns any non-contributor.
Even if someone has a modchip (there's a limit so..).
As I said, if you have a real suggestion on this matter backed with code, be my guest.
Just remember that many things are worked or already done internally for this (set it and forget it loader, plug-ins, etc).

[CTCaer]

The answer is no.
If everything goes well, next version (v5.0) will also be a loader.
So you'll be able to load hekate in hekate.

[CTCaer]

New version will be somewhat modular. This addresses this.