Hacking XorTroll working on USB HDD Feature

[Mokiki]

Is their a quick guide to compiling this

 

[Naminave]

That little interest has been given to this, when more has been requested ... I am still not clear about the function of fsp-usb. Can you run homebrew from USB ?, including backup
?

 

[JoseUg]

how can i compile this?

 

[duckbill007]

@XorTroll, just a small question - where should I put fsp-usb.nsp on SD?

 

[XorTroll]

If you want to test it, create in /contents/ a directory named 0100000000000BEF, inside it create another directory named flags, inside it create an empty file named boot2.flag. Place the nsp inside the 0100... directory named as exefs.nsp. Thus, you should have:

- contents/0100000000000BEF/exefs.nsp
- contents/0100000000000BEF/flags/boot2.flag

 

[duckbill007]

Thank you

 

[reman]

It's good for it.Thank for it.

 

[duckbill007]

@XorTroll, I do not understand how to open file:


FsFileSystem drvfs;
rc = fspusbOpenDriveFileSystem(drive_iface_id, &drvfs);
fsdevMountDevice("usbdrv", drvfs);
FsFile file;
char fname[FS_MAX_PATH] = "/test.txt";
rc = fsFsOpenFile(&drvfs, fname, FsOpenMode_Read, &file);

And I got atmosphere panic on last line. Other operations (dir listing as in your test) works perfect.

 

[Dracari]

@XorTroll unless im missing something or have an outdated lib, not sure where im failing, any Compiling dependancies on your Atmosphere fork that contains your moved fsp-usb work (as stated in the readme.md)

Spoiler

C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c: In function 'sdmmc_sd_decode_scr':
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:349:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp[3] = *(uint32_t *)&tmp[4];
^~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:350:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp[2] = *(uint32_t *)&tmp[0];
^~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c: In function 'sdmmc_sd_decode_ssr':
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:384:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp1[3] = *(uint32_t *)&tmp[12];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:385:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp1[2] = *(uint32_t *)&tmp[8];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:386:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp1[1] = *(uint32_t *)&tmp[4];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:387:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp1[0] = *(uint32_t *)&tmp[0];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:388:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp2[3] = *(uint32_t *)&tmp[28];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:389:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp2[2] = *(uint32_t *)&tmp[24];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:390:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp2[1] = *(uint32_t *)&tmp[20];
^~~~~
C:/Users/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary/src/sdmmc/sdmmc.c:391:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
resp2[0] = *(uint32_t *)&tmp[16];
^~~~~
cc1.exe: all warnings being treated as errors
make[4]: *** [/opt/devkitpro/devkitARM/base_rules:85: sdmmc.o] Error 1
make[3]: *** [Makefile:124: build] Error 2
make[3]: Leaving directory '/home/xiond/Documents/GitHub/Atmosphere/fusee/fusee-primary'
make[2]: *** [Makefile:96: check_fusee] Error 2
make[2]: Leaving directory '/home/xiond/Documents/GitHub/Atmosphere/stratosphere/boot'
make[1]: *** [Makefile:10: boot] Error 2
make[1]: Leaving directory '/home/xiond/Documents/GitHub/Atmosphere/stratosphere'
make: *** [Makefile:21: stratosphere] Error 2

C:\Users\xiond\Documents\GitHub\Atmosphere>

(Edit: full log/output: https://pastebin.com/XWVUHPEx )

 

[Tackskull]

Guys I am not following the entire topic, but I just want to know if atmosphere is getting the feature to read games from an external hard disk drive

 

[Resaec]

Atmosphere is not aimed at pirates. So a feature currently only interesting to pirates will not get developed by the atmos team.
If someone else creates one than there are no barriers keeping them from achieving that goal.

 

[Pokfan1]

So are they developing a usb hdd support? Just to install games from usb or even load games?

 

[smf]

Atmosphere is not aimed at pirates. So a feature currently only interesting to pirates will not get developed by the atmos team.

What about backups of legitimately purchased games?

 

[Resaec]

What about backups of legitimately purchased games?

What about them?

 

[smf]

What about them?

They'd be interested in it too, they aren't pirates.

If it were easy then atmosphere would have it.

 

[Raugo]

So are they developing a usb hdd support? Just to install games from usb or even load games?

Only to use it with homebrews and maybe mods with layeredfs..

 

[Resaec]

They'd be interested in it too, they aren't pirates.

Since any feature enabling the creation of "backups" would inevitably lead to piracy, so this feature is not implemented into the CFW.
While I think that private backups of permanently owned cartridges are ok, the industry does not. As such it is better for anyone involved in the project if Atmosphere in no way enables the creation or execution of "backups" by itself.
This is why you need additional patches to create and execute "backups" and backups

To continue this in respect of USB loading. For that very reason there is no interest in XCI compatibility. Homebrew comes in nro or nsp format. Healthy use cases of the ability to run your legal backups will not really be limited by the amount of space you have on your 200GB microSD. (big games: 200GB/32GB ~ 6 Games, average: 200GB/10GB ~ 20) + 1 Cartridge in slot
I do agree that the ability to install your nsp from USB would be a useful external feature, but there is no need since installing new backups should not happen that often.

 

[nWo]

Could it be possible to play music, videos and comics from USB in the future? Sorry if the question is silly, but I just read the first page of comments and this one.

 

[XorTroll]

The point of this feature is being able to browse stuff from drives, basically the same you can currently do with the SD card, except for a proper exFAT and not being able to install titles there. That's it, being able to browse, what opens many doors fro homebrew such as RetroArch, Goldleaf, video and music players, other emulators...

 

[Resaec]

Are there projects for proper exFAT support? I don't think we should expect/rely on any improvements from Nintendo.
I regard "docked" drives via the dock for video, music and emulation to be the most interesting. But I'm not up to date regarding passthrough.