Open ApacheThunder opened 11 months ago
oh god, this repo. Heads up, I don't recall that this ever worked (reliably?), and it never got the care and attention that the DS and 3DS based flashers did. Unfortunately I no longer remember why it didn't work well.
I'll take a look at the backup/restore mechanism real quick to see if I can figure out what's up.
EDIT: something I can tell you immediately is that it's not in flashcart_core, but in the flashers themselves, because flashcart_core only provides methods for reading and writing flash to/from memory buffers.
The only thing ntrboot_flasher tries to do is read from and write from ntrboot/ak2i-backup.bin
, so there's definitely something weird going on.
You mentioned that it is writing the wrong thing to the flashcard, so it's not in that component.
Should add a step that hashes the backup, so that you can at least confirm that it's the correct image that you're trying to write.
After writing one of these random unintentional backups, have you checked on your computer (or elsewhere) that the image on the card (still) matches the one that you intended to write?
I directly overwrote the section I intended to change via hex editor like HxD. There is no chance of a mixup here and I had double checked that I wrote the intended data to the file the flashers were using. I believe the ntrboothax installer for 3DS did some sorta of hashing thing? Because it doesn't always do a full flash of the backup file. The "DSi" port of the flasher was something lifehackerhansol wrote and it appears to impact that build too. I haven't been able to pin down in the code any issue that might be causing this. It's very weird. I don't recall the file changing back to the previous version either by the way. I could double check for that next time I go to flash something.
By the way lifehackerhansol mention the powerslaves library lacked card write support? Maybe this is why this tool didn't work correctly. I at one point tested a build of DeSmuME with powersaves dongle as a slot-1 option. At some stage it will hang during DLDI init for example so I guess maybe the library isn't feature complete yet...at least not enough for an emulator to fully communicate to a physical cart just yet. Would have been great for debugging certain flashcart DLDI drivers for example which was something I wanted to do with some old N-Card clones I have.
The newer DLDI driver with write support doesn't have any source available. (the one found on the internet is an old outdated one that doesn't work on cards using udisk 1.45 firmware as the file system format changed). N-Cards are old flashcarts that predated the R4 by the way. They used internal nand instead of MicroSD and I have found they like the DSXtreme store the main rom on nand and it is possible to do things like changing the banner they use. Though currently can't do that yet as we don't yet have working source for writing data to the nand. :(
Anyways starting to get offtopic. That was just one thing I had wanted to use this API for but it doesn't seem to work for that purpose currently. :(
The main repo I had tried for 3DS was this one by the way:
https://github.com/ntrteam/ntrboot_flasher
The DSi build I had tested:
https://github.com/DS-Homebrew/ntrboot_flasher_nds (I misremembered. lifehackerhansol had pushed a commit to this repo but I believe he wasn't the one responsible for creating it)
I even tested some builds of Decrypt9 that had some early support for flashing Acekard2i...and I recall it impacting that one too. Maybe my perticular Acekard 2i is just cursed or something.... :P
There is no chance of a mixup here and I had double checked that I wrote the intended data to the file the flashers were using
I'm not checking for a mixup here, I'm checking for weird things happening with the SD card or the filesystem.
One time, I eventually figured out that I was working with a bad USB drive by diffing a file that I copied to the drive, then synced it, unmounted it, unplugged and replugged, only to find that the file now differed and I had to copy it over again. This incident instilled within me a certain amount of paranoia when working with flash media of unknown status.
If you reinsert the card and the file is no longer correct, then it's an issue with the SD card (or the code writing to the SD card, but I doubt that). If you reinsert the card and it is correct, but we added code to compute a hash to the flasher and we're reading an older version of the file somehow, then it's an issue with the fat32 library we're using. If the hash is correct, then it would be the code that's writing to the flashcart. (i doubt it's the code writing to the flashcart though, because reformatting the SD card wouldn't really do anything)
powerslaves library lacked card write support
From my recollection, it lacks SPI support, because I was more focused on the main data bus. Most of the cards that we supported in flashcart_core don't use SPI (for flash modification, at least), so I don't think that was the issue.
I found the issue I opened on the powerslaves repo about this issue: https://github.com/kitlith/powerslaves/issues/5 which will be much more reliable than my memory.
tested a build of DeSmuME with powersaves dongle as a slot-1 option
I remember that build! I ended up running one of my DS cartridges off of a cart. Agreed that it could be useful for debugging if it was more complete (and more reliable)
The DSi build I had tested:
Thanks for listing it, I was unaware of that version. Backup file selection appears to work the same way, though.
Ahh I see. Well the issue followed me across several SD cards and MicroSD cards so I have ruled out filesystem problems.
As for that issue you posted...could be the powersaves dongle not giving the cart enough power? Some flashcarts use a bit more power then retail carts and maybe Datel was cheaping out on the hardware to just barely work well enough for retail carts....Just a guess though. :P
Would have to power the card from an external source to really confirm that though. I did notice when initially plugging the dongle into a USB port with my DSXtreme plugged in that the DSXtreme's LEDs don't turn on until I start up that custom build of Desume. That's what made me think maybe there's some power shenanigans happening here.
Also a bit of a tangent here but there is one other way to communicate to a physical cart (in theory at least):
https://github.com/ApacheThunder/nCard_USB_Examples (I updated the old source code to compile on newer libnds. These were positively ancient. 2006/2007 era stuff)
Some old homebrew N-Cards used for their special USB slot2 device. Their "uDisk" firmware also used this to allow putting files onto their flashcards. (They used internal nand like DSX and predated the first R4s). It's a shame no one has tried to figure out the USB API it uses so we could do other things like with the powerslaves API does. We don't have source to that though. :(
But N-Cards are kinda rare these days especially the USB Slot-2 device so I don't expect anyone to care enough to look into that.
It would be funny to have a whole DS Phat as a middle man for a emulator to talk to a physical cart though. It's definitely possible as there's some bits in the USB api code in those homebrew examples that would allow for it. I've already tested the DS Pad/Mouse examples and they still work on Windows 10 surprisingly so can use my DS Phat as a gamepad for emulators at least. :P
the issue followed me across several SD cards and MicroSD cards so I have ruled out filesystem problems.
Fair. I would still appreciate explicit confirmation the next time you have this happen to you, because an explicit "the image that was written to the flashcart is not what is currently on the SD card" is much stronger evidence than "I wrote stuff to the card and never checked it's exact contents again later"
could be the powersaves dongle not giving the cart enough power?
According to the issue, that was one of my first thoughts too! ^-^
Aside, on the ak2i: there's two headers/roms. Am I remembering correctly that the second one isn't pretending to be a game at all, and just claims to be an acekard2i? (I no longer have an ak2i to be able to check)
Yeah I will double check the files next time I do another update. As for the sections. The section near the start of the file is what the card uses for DS/DS Lite. The second section is what is used for DSi/3DS. Unlike the second section it seems the cart doesn't like if I try to use a different game code/blowfish key. Seems to be hardcoded to expect the ACEK gamecode for the first rom. The second one can be anything as long as the correct blowfish key is present.
Not really recommended to mess with the first one. It's smaller then what's considered useful for anything and there's a bit right after the rom section that WoodR4 seems to write to? (maybe some areas of this flash is used for game save or something?) so data gets overwritten there once you boot a retail game with WoodR4. (hasn't really tested if this happens with other kernels) A shame. Wanted to use it for something else for my DS Phat but the space I have to use for it is very small compared to the second rom section. Maybe a HW41 revision cart would be more useful in that case. I never owned one but I recall that one only having one rom section and probably has smaller flash chip too.
well, there's always writing a chainloader to load off a later section of flash. In any case, wanted to double check my original assumption that danny phantom was not the other rom on the cart, and that it wasn't performing a fallback like what can happen when you've got ntrboot installed.
Well I got a R4i SDHC Gold Pro (some sort of DSTTi clone?) and backups flash to it correctly without incorrect data appearing like with the AceKard...this makes me more inclined to believe there's some kind of problem with ntrboot flasher as I didn't do anything different when flashing backups to it. (or maybe my Acekard is just cursed if I'm the only one getting this issue)
(I had been getting TWL ntrboot working on the Gold Pro cart)
I have been unable to compile this. Likely related to libusb stuff? I haven't been able to get it to find the lib. Getting "error: '_hypot' was not declared in this scope" message. (my OS is Windows 10 Pro by the way)
Would like to see how this tool compares to the 3DS/DSi versions of flashcart-core. I have an odd issue that appears to impact all versions of flashcart core involving my Acekard2i (it's hw id 88). In most cases it fails to properly update the rom sections I have been trying to update on occasion. Got a custom SRL setup for the second rom section it uses to mount on 3DS/DSi. It has been a real pain updating it anytime I make a change.
Just about everytime it ends up reverting the rom section to a prior version that used to be on my SD card. I have no idea how it's doing this when I overwrote the bin file with the updated one. it's either not flashing it or it is somehow pulling a previous version off the SD card despite it having been replaced in the filesystem of my SD card. I suspect it's a combination of both? Or could even be an undocumented hardware issue with the cart...but I doubt that. It's very strange.
One example was I had previously put the original backup I made back to the cart. The one that had DSi section using the Danny Phantom exploited rom. I then at some point replaced that rom with a custom one. Then after that I tried to update it again with another change...which results in the danny phantom rom coming back despite it being OVERWRITTEN on my SD card. Basically any previous version of the flash backup that existed prior could end up being written to the card instead of the intended one.
I don't even know how it's doing this. The Danny Phantom rom is living up to it's name and being a phantom rom that just won't die... it is maybe some odd file system issue. I've only been able to get the intended data to show up if I do a full format of the SD/MicroSD card I had the backup bin file on....and that is very time consuming so this is a very annoying issue. It has put me off with doing any more updates to the bootstrap SRL I built for my cart. :(
This problem persists on both 3DS and DSi builds of ntrboothax installer so I suspect it's a problem with the flashcart core API.
I have been wanting to test this tool with my powersaves dongle to see if I could get around that problem with this tool. ... Haven't had any luck getting any of this stuff to compile though. :(