Hekate: Request - Payload booting

[NO-ob]

Would it be possible to have a feature in the future which allows to boot payload from sd for things like memloader

[CTCaer]

I'll see what I can do.

[mariogamer2]

Ninja'd :p
I'd aay there are multiple ways of doing this, more or less space consumming:
-A menu which list files on sd card
-same but on a specific folder (like luma 3ds does)
-integrate it in the main ini (probably not optimal tho)
-memloader's way (an ini for each payload, which isn't optimal too, in my opinion
-ini containing all the payload (not optimal too, better done by 1 or 2)

2 is probably the best choice possible. (Maybe the folder should simply be hekate) (should the config ini also be in it?)

[oCanna]

|-- loader
|   |-- hekate-ipl.bin
|   |-- loader.ini
|   |-- whatever.bin
|-- hekate_ipl.ini
|-- whatever.ini

Option 2 makes the most sense. Put all the binaries and the loader's config file in one directory.
The loader itself is just a stripped version of hekate that can read from the sd card, parses it's config and displays a boot menu when auto boot wasn't set or the user pressed vol-.

Config files like the hekate_ipl.ini should stay in the root directory.

[CTCaer]

This can work with current hekate if the loaded payload is max 100KiB.
Current hekate will require around 156KiB. So it would be possible to copy a payload to 0x40027000 and run it.

But I also believe that it would be best to have a stripped version that just loads the correct payload.

[CTCaer]

https://github.com/CTCaer/hekate/issues/32

[LiamMCW]

Would it be possible to have memloader built in to hekate? Once I use memloader to mount my sd card, I can't go back into hekate without force reseting and rerunning the payload.

[mariogamer2]

I don't think the loader even needs an ini. It could simply load a payload given as an argu. by Hekate (at least that's how I see it)

(Just thought that it might add on space, but a file lister shouldn't take that much, no?)

[CTCaer]

That's the plan for its file browser.
A menu that is dynamically created based on the contents of a folder.
Just select and launch. Nothing else (e.g move/delete/rename/traverse files and folders).

[CTCaer]

Update1:

• Payload file browsing is dropped in favor of .ini payload sections. This way autoboot can work with this (important for Linux)
• If there's enough space left, I'll consider adding a file browser for these.

[mariogamer2]

Then it should support both bpmp and ccplex (if possible) (will it take too much space?)

[CTCaer]

Nope. I can have a 2nd config, armv8 or ccplexx or sth, that will trigger this.
But have in mind that my intention is not to replace memloader and parse its .ini format.

I want to support each payload, linux, etc boot method if possible, so user should launch their payload from hekate.

[oCanna]

So are your plans to make a seperate loader based on hekate that loads any payload that can run on the BPMP/IRAM (like hekate, biskeydump, memloader etc.)?

But how do you want to boot linux then? Wouldn't it be necessary to have a customized coreboot that can be loaded step by step or better said stage by stage like in shofel2 but from sd card and not over a USB pipe CBFS server. Or does the loader itself initialize the SDRAM, then copy coreboot into it an jump straight into it's romstage?

[CTCaer]

Not separate. Inside hekate.

For Linux, I wanted to avoid something like memloader functions but it seems unavoidable. We'll see though. I have a couple of things in mind.

The current working code I have copies the binary to dram and calls it and let it do its stuff.

[oCanna]

The current working code I have copies the binary to dram and calls it and let it do its stuff.

Sounds to me like a good solution.

But how about loading other BPMP payloads? Doesn't hekate itself take almost all of the available space?
Wouldn't be a simple and small ini based sd card chainloader the best solution that can either load hekate or any other payload directly from the sd card?

[mariogamer2]

That's in IRAM I think (Hekate).

(Ah so that's why there's no limit)

[CTCaer]

Hekate gets overwritten if the relocation code of a payload moves it to iram (all current ones do it).

It's a one way launch.

I made it that way so there's support for 256KB (224KB with USB support) iram payloads, instead of 123KB that current injection tools support.

For Linux I will either have hekate do the chainloading or I'll write a payload that does that and will replace cbfs. I'll see tomorrow.

[fennectech]

Can you boot another payload launcher with a file manager that would be stored on the And you could store a copy of hekate on the sdcard that could be loaded into ram by the launcher. We could use a stage 1 bootloader that is run by F-G that launches our bootloader.

[CTCaer]

@fennectech
You understand that here is not a chatroom right?
Don't spam. Edit, when they are so close in time.

Additionally I don't think you understand how injection, relocation and chainloading works.
Please research first.

Edit:
Basically, I don't want to say again and again and again that hekate is the intended launcher and not a 2nd payload.

[fennectech]

Okay . Sorry

[CTCaer]

Linux chainloading was finally cracked.

I was going blindly without an UART adapter (mine was fried).
So, thanks @perillamint who send me an UART log of what was going on under the hood with booting, I was able to put the last missing piece.

Unfortunately I'll go for vacations, so this will probably be released next week.
(Because I have to check around 50 x 32 hw bit registers that are correctly configured and have to make sure that all functions inside are working.)

[mariogamer2]

So is it done throught an external payload? (and why 50*32? for what? :p)

[CTCaer]

Because hekate/Nintendo hardware configuration hangs Linux when it does its own configuration.
So I had to find out which hw registers were creating the hangs and de-init them.
This process is quite time consuming because I have to cross check the technical reference manual and the code for everything.

And all that because t.x1 is buggy as hell.

Anyway it boots and seems that everything works. But you never know.

[mariogamer2]

What is the size of the payload with payload booting and Linux?

[CTCaer]

Max.
Hekate is hitting max size since v3.0 (and before internally).

I saw the other discussion but it's a pain to answer with a phone.

I have countless ways to resolve this. But first thing first is the optimization way.

[mariogamer2]

Will this include module which can be launched by hekate, do the thing hekate requested, and return?

[CTCaer]

That's the plan. For the first release, I'll have some current functions as a module and also a test interface for a test module.

[mariogamer2]

Is the release the same as lakka one? Or a little sooner?

[CTCaer]

lakka is ready for a release. I already made the PRs.
hekate is cooking up hard. Depends how much content I want to add now that we have modules.
Maybe weekend.

[mariogamer2]

Another detail: will those module be loaded into dram?
thanks for answering all those questions btw :)

[CTCaer]

IRAM or DRAM. Depends on the case, limits and what dev chooses.
E.g. IRAM can fit ~80KB more. And that's before going to launch HOS.
For example, a PKG2 patcher, will not fit, because that space will be taken from secmon.
So this specific one is forced to run on DRAM.

[CTCaer]

At last:
https://github.com/CTCaer/hekate/commit/7803bbcd832bc97ea8fdc75c2e52076239f2f9dd

Supports ALL current CFW payloads, Linux chainloading, and tools (like memloader).