validate_mempak() => always -3 (bad or unformatted)

[ottelo9]

I actually try to figure out why the "show Mempak" function in Altra64 doesnt work for me and my two original Controller Paks (NUS-004). The functionality is 1:1 copied from the [mptest.c] https://github.com/DragonMinded/libdragon/blob/trunk/examples/mptest/mptest.c) except Altra only search for mempaks on port 0. I can backup the data or format the mempak without any problems. And I can see the contents with saturnus Mempak Tool. Even @ariahiro64 have problems with it.

I checked the Mempak content (header) of my mempak and its 1:1 the same as format_mempak() writes in it.

[bryc]

Can you provide a dump of Controller Pak data (32 KiB .MPK file) for any one which gives you a -3?

[ottelo9]

Can you provide a dump of Controller Pak data (32 KiB .MPK file) for any one which gives you a -3?

@bryc
https://drive.google.com/file/d/1LobhFJjZ4aqrn7dOY_NYjWVDAUUxBO-A/view?usp=sharing

[ottelo9]

@bryc
Do you need anything else?

[bryc]

Hi, just now had some time to look into it.

I'm not really good with C, but I know a lot about MPK file format, so I can maybe help narrow the problem:

First of all, your MPK data is fully valid, so the problem must be the code.

I checked validate_mempak and identified two areas where it returns the value -3 when a check fails:

1. __validate_header: https://github.com/DragonMinded/libdragon/blob/trunk/src/mempak.c#L671
2. __validate_toc: https://github.com/DragonMinded/libdragon/blob/trunk/src/mempak.c#L690

Now I checked the code, and I can confirm it's doing the validation logic correctly, i.e. the math.

So what this means is, if the data supplied is actually valid (which it should be), these errors shouldn't happen.

This makes me wonder if somehow the MPK data isn't being read into data array correctly? But that isn't something I know how to help test, someone else would have to do it.

I think it would help to create a hex dump on screen (or console?), of what data contains before __validate_header to verify whether it's being read from MPK correctly.

Related functions:

1. https://github.com/DragonMinded/libdragon/blob/trunk/src/mempak.c#L65
2. https://github.com/DragonMinded/libdragon/blob/trunk/src/controller.c#L637

Or you could hard-code data right before __validate_header to be already-valid data, and see if it changes the result (idk):

data[256] = {
	0x81, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B,
	0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
	0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, 0xFF, 0xFF, 0xFF, 0xFF,
	0x05, 0x1A, 0x5F, 0x13, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x01, 0xFF,
	0x66, 0x25, 0x99, 0xCD, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xFF, 0xFF, 0xFF, 0xFF, 0x05, 0x1A, 0x5F, 0x13, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0x01, 0xFF, 0x66, 0x25, 0x99, 0xCD, 0xFF, 0xFF, 0xFF, 0xFF,
	0x05, 0x1A, 0x5F, 0x13, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x01, 0xFF,
	0x66, 0x25, 0x99, 0xCD, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xFF, 0xFF, 0xFF, 0xFF, 0x05, 0x1A, 0x5F, 0x13, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0x01, 0xFF, 0x66, 0x25, 0x99, 0xCD, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00
};

Other than that, that's all I got.

[ottelo9]

Thanks for your investigations. I can fork this repo and change the code. But I actually dont know how to get the change into my Altra64 dev build docker image. I think I have to edit the setup-docker.sh and change these lines to my fork:

# Pull the latest libdragon source code and make a build directory
git clone https://github.com/dragonminded/libdragon.git
# set to correct commit
cd libdragon && git checkout --force b26fce6 && cd ..

But then every change in libdragon will take ~1h to build the docker image again.

[anacierdem]

You shouldn't need to build the toolchain everytime you change something in the library if you configure things correctly. Even if you download the repository fresh everytime, docker COPY only checks the file contents and should not invalidate your layer cache. b/c you copy the build script, it seems to invalidate the whole thing whenever you change it. I think you can just base your dockerfile on the official docker image so that this is not an issue for you anymore unless you are changing the toolchain itself.

[ottelo9]

Ok thanks for your answer. But I even dont know how to edit things (in my case libdragon\mempak.c and controller.c) inside my docker image that was generated via github actions. Im still a rookie regardings docker and github.

Do you know how to do that?

[anacierdem]

I suggest building the libdragon example instead and try to verify the data without altra64. The instructions at https://github.com/DragonMinded/libdragon are very helpful in general but we can help if you need any assistance.