Free60Project
Corona/Winchester 4 GB support
LibXenon doesn't seem to have full support for 4 GB eMMC systems, meaning you can't use things like rawflash in XeLL Reloaded.
This was recently implimented by 15432 here: https://github.com/15432/libxenon/tree/emmc_support, so it could be nice if it was implimented in this repository at some point in the future.
I didn't realize someone had already taken a stab at it, ive been working on a WIP myself.
The linked code looks incomplete and appears to break existing SFCX consoles. It also uses PIO transfers which are slow.
I have a more comprehensive WIP using DMA transfers up at https://github.com/sk1080/libxenon/tree/emmc
Ill create a PR once its a bit more flushed out, but it does appear to be working in its current state. Preferably would like buyin from another libxenon member as ive been out of the game too long.
Also, I haven't tested this on a "true" eMMC console, just one using the phison - it really needs to be tested on all known configurations.
The linked code looks incomplete and appears to break existing SFCX consoles.
It's in use by people in a downstream fork of libxenon and XeLL that hasn't changed anything else about it, so if it's broken SFCX it doesn't seem to have manifested in any way that has people talking about it.
I do prefer the way it's structured in your fork, splitting it into its own file and set of APIs rather than latching onto the SFCX APIs. Personally I think this is the way forward, having them be seperate (except for the rawflash API) and up to the application to handle the difference for anything else since they handle data differently for the read/write process. This also means that it's safer to assume it won't break SFCX support.
Any sort of update on this subject?
If so, I rather wait a bit more rather than opening and wiring the hardware flasher to unbrick my Corona 4G, which would take miles more effort than just loading up my working XeLL, loading a working Corona 4G flash XeLL and flashing my fixed eMMC image...
@SecondNewtonLaw there's always the option of compiling either of the above forks of XeLL/Libxenon and loading the 4gb compatible XeLL lv2 from a USB.
I've tested the 15432 fork on my personal corona, seems to work fine.
@SecondNewtonLaw there's always the option of compiling either of the above forks of XeLL/Libxenon and loading the 4gb compatible XeLL lv2 from a USB.
I've tested the 15432 fork on my personal corona, seems to work fine.
After compiling and loading stage2.elf and renaming it into xenon.elf, it appears to simply raise a segmentation fault on my 2013 XeLL reloaded build that's present on the system, I guess I will be forced to yes or yes open it up and flash it using a PicoFlasher, thanks though!
You need the bin files, not the elf
I was able to achieve it by testing something else, just had to load stripped symbols and now it finally loaded into this new build, currently flashing