Trying to improve x49gp

[3298]

(08-28-2018 02:51 AM)Claudio L. Wrote:  I tought everything ended up in my gihtub fork, if not then that explains it. I'll fix it by reapplying old patches too.

The patch 24 from May is the oldest one that didn't make it into your fork yet (Edit: the part you published on GitHub, at least). But looking at it again, I spotted what caused your troubles with patch 28: You inserted a patch adding -Wno-unused-result, which conflicted with the addition of -D_FORTIFY_SOURCE=1 in the same line. The unused results shouldn't happen anymore (as of patch 28), so you could probably revert that patch without causing problems.

(08-28-2018 02:51 AM)Claudio L. Wrote:  Sounds perfect. I did some tests with 'dd' to create the flash file manually and it's very straightforward but there's something else I didn't catch before:
1) Dump the new firmware at 0x4000 as we discussed.
2) Change the 16-byte string at 0x4000 from "KINPOUPDATEIMAGE" to "Kinposhcopyright" (case-sensitive!). This is a marker the bootloader uses to tell if there's a valid firmware installed or not.

Right, I forgot about that step. It's in the old Makefile though, so I can just use that as a guide. VCS history for the win.

(08-28-2018 02:51 AM)Claudio L. Wrote:  Also, there should be perhaps another option to wipe out with 0xff all the way to the end of flash. This is not needed for newRPL but stock firmware needs a clean flash after the binary, so it can initialize those banks.

Good point. I wanted to leave the flash intact and only overwrite what's necessary (to avoid overwriting the user banks when someone just switches between different versions of the same firmware), but another flag to force full reinitialization (as if the flash image was deleted) is not a terrible idea.

(08-28-2018 02:51 AM)Claudio L. Wrote:  PS: Can we add another command-line option '-r' to reset the CPU when x49gp starts? When you manually change the firmware you must trigger a reset, and if the change in firmware happens outside of x49gp, we need to tell x49gp that we need a reset. Otherwise it will try to resume execution with a completely different ROM, it's a sure crash (resolved by Reset from the menu, I know, but still, the idea is that when used as a debugger we should be able to start x49gp from a script to a well-known state).

I was just going to make the flash reinitialization code reboot automatically, but for debugging startup code it may indeed be beneficial having access to such a flag, even when not reinitializing the flash.