Hacking Hekate Ipl

[Peabutt]

Hm i never knew linux shows it like that. I do know in windows 1 mb = 1024 bytes. So 31.268.536.320 bytes = 29,121 gb

Yeah I did a little research and came up with this.

In Windows …

Windows assumes that there are 1024 Bytes in a Kilobyte unit, and 1024 Kilobytes in a Megabyte unit etc.

In Ubuntu (GNU/Linux) …

Ubuntu assumes, a 1000 bytes constitute a Kilobyte (KB) unit, 1000 Kilobytes for a Megabyte (MB) and so on.

Windows uses a binary prefix, which technically means they should be listing file sizes in KiB, MiB, GiB.

Ubuntu uses a decimal prefix so they are using the "proper" size listings with KB, MB, GB.

You learn something new everyday.

 

[bailli]

Wrong. Almost all Linux distributions I know display binary prefixes (KiB, MiB, GiB) as default. From there you can usually switch what is displayed to either the "wrong Windows format" without "i" but still counting 1024 bytes = 1 KB or to actually use 1000 bytes = 1 KB

 

[Peabutt]

Well Ubuntu itself is not doing that, at least not on my system. I'm not 100% sure about the other distros. None of this really matters anyways, just didn't want others to be thrown off by that if they ran into what I ran into.

 

[guily6669]

I guess windows does it for a reason since I prefer seeing GB than GiB... not that anyone cares either .

 

[Jack Daniels]

I guess windows does it for a reason since I prefer seeing GB than GiB... not that anyone cares either .

it comes from the origin of kb, back in the old days digital every memmory was build in 2 to the power of # so the closest to 1000 bits logicly was standardised to 1024, they called this 1kilo for it was easier to calculate with.
today we can come close to the real kile cause we're using far bigger memmories even in ram w're not talking in bits bytes or kilobytes anymore, but these we're not long ago real high standards to be used.
my first pc (IBM 386 with turbo 16 MHz proccessor) had only 40 mb hdd, and 4 mb ram, but back then those 4 mb's were more than today's 4 mb, and the 40 mb whas also more then todays 40 mb. even ms doesn't count in logical kilo's, and based on that in logical mb's.

 

[Loke]

Yeah I did a little research and came up with this.

In Windows …

Windows assumes that there are 1024 Bytes in a Kilobyte unit, and 1024 Kilobytes in a Megabyte unit etc.

In Ubuntu (GNU/Linux) …

Ubuntu assumes, a 1000 bytes constitute a Kilobyte (KB) unit, 1000 Kilobytes for a Megabyte (MB) and so on.

Windows uses a binary prefix, which technically means they should be listing file sizes in KiB, MiB, GiB.

Ubuntu uses a decimal prefix so they are using the "proper" size listings with KB, MB, GB.

You learn something new everyday.

It's not about how a kb converts to a byte, but how a byte is constructed in bits. I think a byte is build with 8 bits. It's build with 2 to the power of n. This is also the case with RAM. Following this, 1024 is actually right, not 1000.

 

[Jack Daniels]

It's not about how a kb converts to a byte, but how a byte is constructed in bits. I think a byte is build with 8 bits. It's build with 2 to the power of n. This is also the case with RAM. Following this, 1024 is actually right, not 1000.

both have somithing for it: kilo means 1000, so there is 1000 bits it actual fits math laws.
but then again each bit is like a switch, with 1 switch you have 2 options, with 2 switches you've got 4 options, with 3 switches there are 8 options... 8 switches makes 512 options... 10 switches makes 1024 options, so one kb makes 10 bits...
so unles you disable 24 of the options there's no digital 1000 bits but this would be stupid.
but since we came to tb as normal standard drive space calculating in bit level is annoying so today most factories came back to the math law calculation.

 

[Peabutt]

It's not about how a kb converts to a byte, but how a byte is constructed in bits. I think a byte is build with 8 bits. It's build with 2 to the power of n. This is also the case with RAM. Following this, 1024 is actually right, not 1000.

Right, I wasn't arguing with that. I was just stating the differences in the OS and why the readouts are different, hence why I was saying assumes and why I put "proper" in qoutes.

 

[guily6669]

And talking about that the the weight can also be changing judging a news I heard like a year or 2 ago, as everything got calibrated from the original stipulated kilogram which is losing weight by it self .

EDIT: I think its this year that they will revise the kilogram again .

 

[Dmafra]

Can I just enter rcm mode to remove the sd card and copy the parts, insert again to continue the dump?

 

[Dmafra]

How can I join all the parts of the eMMC raw? ( a noob way )

 

[mvmiranda]

Hello!
I have just decided to jump the Switch hack bandwagon
I'm on 6.1 and never used any microSD before.
Yesterday I did the tinfoil joycon mod, entered RCM, used hekate ipl v3 (rajkosto) to backup my NAND to a FAT32 microSD. I decided to do it before installing the exFAT using ChoiDujourNX just because!

I tried using the hekate2rawnand.sh on a Mac but I keep getting several "no such file or directory" error for everything else other than gpt_prefix.bin and gpt_suffix.bin.

What am I doing wrong?

Thank you, in advance, for your clarification!

 

[lordelan]

Hello!
I have just decided to jump the Switch hack bandwagon
I'm on 6.1 and never used any microSD before.
Yesterday I did the tinfoil joycon mod, entered RCM, used hekate ipl v3 (rajkosto) to backup my NAND to a FAT32 microSD. I decided to do it before installing the exFAT using ChoiDujourNX just because!

I tried using the hekate2rawnand.sh on a Mac but I keep getting several "no such file or directory" error for everything else other than gpt_prefix.bin and gpt_suffix.bin.

What am I doing wrong?

Thank you, in advance, for your clarification!

First of all, this is the thread everyone's using now and hekate 4.2 is the most recent version:
https://gbatemp.net/threads/rcm-payload-hekate-ctcaer-mod.502604/

Second: Don't use exFAT, really. Of course you can install the exFAT driver, but keep your mSD card on FAT32 to avoid any data corruption.

According your Mac I can't help you but read a few times that the way Mac OS handles files and folders is causing problems that lead to the circumstance that Switch homebrews don't work with it as intended. Either get yourself a Windows PC or try a VM when dealing with your card on your PC.

 

[mvmiranda]

First of all, this is the thread everyone's using now and hekate 4.2 is the most recent version:
https://gbatemp.net/threads/rcm-payload-hekate-ctcaer-mod.502604/

Second: Don't use exFAT, really. Of course you can install the exFAT driver, but keep your mSD card on FAT32 to avoid any data corruption.

According your Mac I can't help you but read a few times that the way Mac OS handles files and folders is causing problems that lead to the circumstance that Switch homebrews don't work with it as intended. Either get yourself a Windows PC or try a VM when dealing with your card on your PC.

Regarding the 4.2 version, gotcha! Will use that!
Now, to the exFAT thing. I didn't know that... does exFAT corrupt data? Does it have any specific scenario it can happen or just by using it you're already dealing with you luck (or bad luck)?

Thx!

 

[mdmachine]

Nintendo apparently implemented exFAT in a poor way. So exFAT just corrupts at random, with no real specific event to trigger it. Also due to this scenario some homebrew will corrupt data almost %100 of the time. Best to stay Fat32.

 

[mvmiranda]

Nintendo apparently implemented exFAT in a poor way. So exFAT just corrupts at random, with no real specific event to trigger it. Also due to this scenario some homebrew will corrupt data almost %100 of the time. Best to stay Fat32.

What about larger files support?
I mean, do we even hit that "problem" with the current Switch games, homebrews, and stuff?
Thx!

 

[Clydefrosch]

What about larger files support?
I mean, do we even hit that "problem" with the current Switch games, homebrews, and stuff?
Thx!

switch games range anywhere from a few mb to ~16gb (+updates)
but you can use file splitters to split them up into 4gb chunks to install.

as for when corruption happens, it does pretty much exclusively for homebrew when it reads and writes files (which happens a lot for emulators like retroarch for example). any of these actions coincide with a write to update journaling information (like last access/last change dates) and that journaling process seemingly is prone to error. if it messes up, files corrupt. fat32 kind of has a two layered journaling process, where, if corruption occurs, it can just retrieve the second layer backup. or something like that.

definitely better to just get fat32 and look for the splitter.

 

[Stoned]

switch games range anywhere from a few mb to ~16gb (+updates)
but you can use file splitters to split them up into 4gb chunks to install.

Or Tinfoil Usb Install.

 

[mvmiranda]

Good t

switch games range anywhere from a few mb to ~16gb (+updates)
but you can use file splitters to split them up into 4gb chunks to install.

Good to know!
Thx!

So, since FAT32 is the "native" file partition, I assume those split files will be handled by the installers just fine. Am I right?!

Well, if I am, enough questions for today!

Thank for all your time, guys!
You really helped me!

 

[mdmachine]

When you jninsta the nsp they automatically split into suitable chunks for fat32. I assume thankfully a byproduct of the system launching with fat32 to begin with .