Nds-bootstrap: Fails to build with devkitARM r46 & libnds 1.6.1

[WinterMute]

Please update your tools/libraries and submit libnds additions you need upstream.

ndstool in devkitARM r46 produces dsiware compatible binaries without "patching" the output.

if you need help please email, drop by #devkitPro on irc.blitzed.org or leave a message on devkitPro forums.

Fragmenting libraries is bad for everyone.

[ahezard]

Well I will try to do that.

[ahezard]

I will start with NitroHax / NTR_Launcher though because nds-bootstrap will be more tricky.

[ahezard]

The main problem I have here is that libnds divide the HW into 2 mode : dsi or ds mode, this is not so simple. For nds-bootstrap I want a ds mode (ram, bios, touchscreen, sound configured as in ds mode) but with SDMMC access and extended WRAM. This is perfectly doable (it works) but libnds does not make this simple. I will see what I can do to improves this point.

I am not even sure that this dsi binary idea is a good one, nintendo does that but it can be managed in other ways, do I have access to dsi functions in the normal binary?

[WinterMute]

separating the binaries makes better use of memory by not loading DSi specific code in DS mode.

What you're describing is DSi mode with DS mode compatibility settings. I don't really see an issue.

It's probably going to be easier to discuss this on IRC though if you can.

[ahezard]

I am trying to port it :
https://github.com/ahezard/nds-bootstrap/commit/7b5a4098595d6525de95b008f94fb7e9fa6aa288

[ahezard]

I have an error during linking (I am using master libnds) :
linking nds-bootstrap.elf
e:/devkitpro/devkitarm/bin/../lib/gcc/arm-none-eabi/6.3.0/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00008010
e:/devkitPro/libnds/lib\libnds7.a(interrupts.o): In function irqInitHandler': e:/Dev/libnds/arm7/../source/common/interrupts.c:125: undefined reference to__irq_vector'
e:/devkitPro/libnds/lib\libnds7.a(interruptDispatcher.o): In function IntrRet': e:/Dev/libnds/arm7/../source/common/interruptDispatcher.s:55: undefined reference to__irq_flags'
e:/Dev/libnds/arm7/../source/common/interruptDispatcher.s:63: undefined reference to __irq_flagsaux' collect2.exe: error: ld returned 1 exit status make[2]: *** [/e/dev/nds-bootstrap/nds-bootstrap/arm7/nds-bootstrap.elf] Error 1 make[2]: Leaving directory/e/dev/nds-bootstrap/nds-bootstrap/arm7/build'
make[1]: * [build] Error 2
make[1]: Leaving directory `/e/dev/nds-bootstrap/nds-bootstrap/arm7'
"make": * [arm7/nds-bootstrap.elf] Error 2

[ahezard]

I am not using the custom specs/ld file anymore since you fixed the issue I had with the default one

[ahezard]

Well I found the problem, I was stupid : I have to specify that I use the default specs file!

[ahezard]

Now https://github.com/ahezard/nds-bootstrap/tree/devKitArmR46 compiles but it is broken on HW and into no$gba (white screen). I am analyzing the header and the binary to see what is breaking it.

[WinterMute]

Being brutally honest you probably need to look at redoing an awful lot of this from scratch. There are some horrible cut & paste jobs in here :(

You run the risk of ending up with bodges on top of bodges and making it harder to maintain.

I'd really recommend stripping it all back and attempting to do one thing well - i.e. either "old" homebrew or commercial games but not both. Ideally old homebrew should just be recompiled so it works properly instead of attempting to patch it and/or disable various bits of hardware.

[ahezard]

Only a small part of old homebrews have source available and even the one that have source available are almost impossible to recompile or port to latest devKitArm release. It did not happened in the past and it will not happened now. The compatibility of latest release with homebrew is not bad at all and retail games works pretty well now.

[ahezard]

The arm7 is blocking on
installSystemFIFO();

[ahezard]

No it is actually blocking on irqInit();

[ahezard]

Ok the problem is linked to the arm7 & arm9 initMBK();
This make sense.

Which address are you using on the 0x03700000 area on arm7? Are you using some special mirror address?

[WinterMute]

Only a small part of old homebrews have source available and even the one that have source available are almost impossible to recompile or port to latest devkitARM release. It did not happened in the past and it will not happened now. The compatibility of latest release with homebrew is not bad at all and retail games works pretty well now.

This isn't a reason to do one thing at a time and try to do it well. Most of the pirate cards had issues attempting to support both homebrew and commercial game dumps in the same code path,

No it is actually blocking on irqInit();

That seems unlikely. There's no code in irqInit to wait for anything.

[ahezard]

Ok it seems that you are using the 0x03000000 mirror. Can you explain why? Default .ld states that you use 0x037f8000

[WinterMute]

Which address are you using on the 0x03700000 area on arm7? Are you using soem special mirror address?

We're using 256K of WRAM-A mapped to 0x03000000 for arm7 code in DSi mode. Much the same as Nintendo do.

[ahezard]

Ok, I was using a different setup. Not a big deal, I can adapt.
And what are you using this region for exactly?

[ahezard]

I have request : would it be possible to avoid nand init? That beaks no$gba, this is useless and I prefer also to not touch nand at all for safety reason

[ahezard]

So you refused my requests,
https://github.com/devkitPro/libnds/issues/22
https://github.com/devkitPro/libnds/issues/23

I will try to port to latest devKitArmR46 but I will continue to recommend my fork of libnds to build my projects until the above issues are fixed.

Since that you do not acknowledge the fact that there is no such thing as TWL/DSI mode but rather a set of independent features that can be activated or not it will be difficult to work together anyway. The 3DS NitroHax port, NTR_Launcher, TWLoader, the Robz8 forwarders and nds-bootstrap are all based around this possibilities unlocked and discovered initially by the the twl_firm research project ( https://github.com/ahezard/twl_firm_patcher ). I will also probably go back searching into twl_firm in order to try to unlock other HW features and I suppose you will not support that as well (the virtual slot 2 used in agb_firm for example could be a nice addition, it would benefit some existing homebrews and retail SW).

[WinterMute]

Since that you do not acknowledge the fact that there is no such thing as TWL/DSI mode but rather a set of independent features that can be activated or not it will be difficult to work together anyway.

You misunderstand what's going on here.

We don't think forcing a particular configuration on an application is the way to do this. Rather than attempting to limit the features available to a launcher in order to suit the applications it launches it would be better for the launcher to have full access and then the launcher should restrict and/or adjust the feature set available for the launched application.

Also bear in mind that the 3DS twl firmware is not the same environment as a normal DSi and we don't want to break code running on either DSi or DS hardware. If your code stops libnds working on DS or DSi it's not going to get accepted.

[ApacheThunder]

...And this is why your toolchain will continue to be fragmented. I imagine the majority of the DS/DSi homebrew users who still use homebrew on this platform is using a 3DS. If you plan to make no accommodations for cross compatibility on a 3DS in TWL_FIRM's environment, then expect people to continue to use custom libnds implementations.

At the very least you should give us more control of what ndstool sets in the header. (This is mostly inconsequential for DSi since people can't boot things direct from DSi System Menu anyways). There's no reason to not at least do that. It doesn't directly impact compatiblity on DSi anyway because the stuff triggered by the header is already hardset by any game being exploited for homebrew on a DSi anyways....

The only homebrew that will need custom DSi header settings will be stuff being booted on a 3DS.

[ahezard]

We don't think forcing a particular configuration on an application is the way to do this. Rather than attempting to limit the features available to a launcher in order to suit the applications it launches it would be better for the launcher to have full access and then the launcher should restrict and/or adjust the feature set available for the launched application.

I fully agree with you, I do not want to break ds/dsi mode compatibility of libnds. I just want to have the full access to the HW capabilities from libnds and that means having libnds working properly in the intermediate mode between dsi and ds. This can implemented without breaking anything.

For the touchscreen mode I have no other solution currently and I am obligated to force controller in NTR mode.

[WinterMute]

@ApacheThunder

...And this is why your toolchain will continue to be fragmented. I imagine the majority of the DS/DSi users who still use homebrew on this platform on a 3DS. If you plan to make no accommodations for cross compatiblity on a 3DS in TWL_FIRM's environment, then expect people to continue to use custom libnds implementations.

This is completely unreasonable.

At the very least you should give us more control of what ndstool sets in the header. (This is mostly inconsequential for DSi since people can't boot things direct from DSi System Menu anyways). There's no reason to not at least do that. It doesn't directly impact compatiblity on DSi anyway because the stuff triggered by the header is already hardset by any game being exploited for homebrew on a DSi anyways...

And at the very least you should stop making assertions of what you think is happening and provide us with tests that illustrate precisely what is happening.

I can't just add stuff to the tools on your say so, especially when you're not even explaining how you know what you claim to know.

@ahezard

For the touchscreen mode I have no other solution currently and I am obligated to force controller in NTR mode.

But people are claiming you have code somewhere to enable whatever is producing a DS mode compatible touchscreen interface.

And surely if you've been digging through twlfirm and you've discovered how these header entries affect the touchscreen then you can extract the code?

This is the part I have trouble with. There's no supporting evidence for these assertions both of you are making.

It doesn't make sense to put the hardware into a non standard mode then modify libnds to cope with that non standard mode just to suit the state you want to end up in when you launch something else from your application. Leaving the first application with full access to the hardware so it can modify the hardware as appropriate is the best way to do this. Not breaking DS/DSi homebrew in the process is essential.

[ApacheThunder]

I did minimal changes to Nitrohax to work on 3DS for testing touchscreen and other things. I tested the 0x1bf region enough to know that with the original code Nitrohax has anyways that touchscreen doesn't work if that was set to 00 but does work when set to 01. This has a direct impact on retail games booted from NitroHax too. If set to 01 DS games no longer have functional touchscreen. I've done enough testing to rule out any code I've added that could have caused this issue. So I'm 99.9% sure it's libnds that's causing this because right now it defaults to using TWL mode touchscreen code which doesn't work for our project.

You don't want to fix anything then fine. We'll use our own implementation of libnds. Maybe you should at least test this stuff on 3DS hardware yourself and confirm it yourself. We don't just spout this as nonsense. We've tested it. I would have thought you would be intelligent enough to assume what testing conditions we were using, but I guess I assumed wrong.

[ahezard]

But people are claiming you have code somewhere to enable whatever is producing a DS mode compatible touchscreen interface.

Who is this? I do not have such code, I am relying on the bit 24 of the 0x1BC register

And surely if you've been digging through twlfirm and you've discovered how these header entries affect the touchscreen then you can extract the code?

Yes I have but the code is complex, this not just some SCFG registers manipulation like the others header bit. This is a code that initialize the touchscreen controller, I cannot just simply revert what have been done. Maybe Martin Korth could help.

This is the part I have trouble with. There's no supporting evidence for these assertions both of you are making.

You are being paranoid again. I am able to boot retail games and 10 years old homebrews from the 3ds sd card, all of this thanks to the flexibility of the TWL hardware. I know the SFGs registers by heart but there is no other way in order to avoid the broken touchscreen than to set the bit 24 of the 0x1BC register to 0. I understand that you would prefer another solution, that would be great for dsi but for 3ds there is a solution available so let's use it.

[WinterMute]

But the touchscreen is only broken when you attempt to run DS applications in DSi mode ...

If we do it your current way then the touchscreen won't work on all currently public methods to run code on DSi hardware where the touchscreen has already been initialised in a different way. I appreciate it's easier for you to just set stuff up the way you want it and not worry about anyone else but surely you can understand why we want to preserve functionality in other places?

We can't just force libnds to use the DS mode code and expect it to work.

[Stack3r]

@wintermule Why can't you just try ahezards way and see what it does then if it doesn't work just go with the other way. Unless its that hard to write the code and such.

[ApacheThunder]

As for the touchscreen, libnds could detect what state the touchscreen is in and simply load the correct code for it. The less assumptions libnds makes the better for every one. No need to hardcode DS mode touchscreen. That would break things with homebrew used on DSi. But WinterMute seems uninterested in doing that so we'll make do with what we have.

[WinterMute]

@Stack3r because we've aready done that and homebrew running on DSi and DS hardware ceases to work correctly.

@ApacheThunder

So rather than arguing the toss over what you are and aren't doing why hasn't one of you provided code that does that?

Official libnds detects when it's running on DSi and, not unreasonably, uses a codepath which reads touchscreen values properly when running on DSi hardware. This works in no$gba in DSi mode, it works on DSi hardware booted with any of the DSiWare hax or the gamecard savesploits available. It works on a bog standard DS and it works on a 3DS running in DSi mode using the same methods as normal DSi hardware and it works when we convert homebrew compiled with latest official tools and libraries to a CIA, install it on a 3DS and run it that way.

Clearing a flag in the nds header which locks out SCFG registers then forcing libnds to use the DS mode codepath isn't the correct solution. It's a bodge that only works for your particular use case and prevents full access to DSi mode hardware.

[ahezard]

You are right let's discuss about code and not philosophical aspect.

Please consider this commit :
https://github.com/ahezard/libnds/commit/f2fc472f42361b0322142b80b33d7ed2de92ce1c

With this code the touchscreen is working properly (tested via the touch_test example) either with sudokuhax / hmbenu 0.6 runned via your bootstrap.cia and TWLoader so it is not breaking anything.

[ahezard]

devKitArmR46 branch is now fully working