look it the makefile for the LDFLAGS. the init=0xblablabla part is the important bit.
this is taken from a project which starts at way up in mem2 at 0x91f00000
Code:
LDFLAGS = -g $(MACHDEP) -Wl,-Map,$(notdir $@).map -Wl,--section-start,.init=0x91f00000
HBC will refuse to load this project, but it can be loaded by other means, and works fine. when adjusting the entrypoint for what you are needing to do, you need to take into account the actual size and start of the initial loader, the secondary dol, and the final program which you are trying to load.
so assume that you have priiloader, a forwarder dol, and usbloader GX which the forwarder is to load.
priiloader starts at 0x81000000 and is around 600kB.
usbloader GX starts at 0x80B00000 and is around 4.2mB
this means that you must see how big your forwarder dol is and then adjust it to not intersect with any of the memory used by either of those other programs. (and also it must only use a valid memory address so 0x79999999 is not allowed).
so if our forwarder comes out to 200kB, you can put it between 0x80000000 and (0x80b000000 - 200kB). so lets pick 0x8000d000. this way it will be able to be started from HBC so we can test it out and also it will be low enough that we can freely change it by adding sounds and images and dont have to worry about changing it later.
everything is fine and dandy.... but wait... along come some people who want to use this forwarder for another purpose. they want to use the same dol so put in a ISO so they can start usbloader GX from within another usb loader for whatever reason. but the new usb loader starts at 0x8000cff0 and is 3mB. what will happen is that when the new usb loader tries to boot the forwarder dol, there is a clash because both the loader and the dol which it is trying to boot want to have 0x8000d000 - 0x8003f000. these people must adjust the start of the forwarder to avoid problems and not try to use the exact same memory range to work with every wii app ever made.