About the only major stuff I know of in the wiki. Not sure if you have checked it out is:
http://wiki.osdev.org/Category:ARM
I added some stuff and expanded some things. But, basically, for phones it is the same type stuff. The ARM core on a phone is going to start execution at a specific address and this area of memory it starts can be mapped to a ROM chip which would contain the main boot code for loading the rest of the system from whatever storage devices exist such as a SD card.
I would check out QEMU and a port of linux for ARM. The problem is the boot code for each actual device may be different and very hard to find. You know most phones have some sort of security protection to keep you from easily loading a custom ROM. You could get around that by finding an interface directly into a specific phone such as by actually wiring into the phone or directly to the serial (most common) ROM chip. I have done this with x86 ROM chips using an FTDI device/chip and basically bit bang it
Each phone device may boot differently or have a different ROM. So your first goal is actually finding a way to write your own code into the ROM and from there the standard ARM architecture follows. As for the hardware well it is going to be different for each device/phone so your not going to find a one solution works for all devices. But, basically this right here is what keeps you from finding a tutorial out there unless it is written for a specific device.
But, if you can find a way to get your code executed either from start up of the processor or in some way afterward you can get your foot in the door to start experimenting.
ARM is just the processor just like X86/X64 is just the processor. You do not have BIOS on an ARM platform like you do on the X86/X64 platforms, and the BIOS is what gives you that ability to have at least some standard functionality for various hardware from the beginning with out needing specific device drivers. So on ARM you have to talk directly to the hardware from the beginning to get it to do anything.
All these reasons are why there is no standard way or tutorial that works for every device, and the reason many tutorials do not exist. But, starting where Linux starts would be a good start to trying to target a lot of devices since you could just leverage their existing boot process, but like I said you have to find a way to write to the storage device to put your own kernel in there (even if its not a Linux kernel).
<edit>
Just to give you an example. I have a Samsung SCH-i510 Droid Charge 4G LTE which runs on an Samsung S5PC111 Exynos 3110 which is a SOC (system on a chip). I am unable to find a datasheet anywhere? I mean if I looked long enough I could find one, but why? Well, Samsung has no need to devote resources to publish the datasheet for their custom SOC. So basically I would have to find the drivers that the Linux kernel is using and then hope they are open source so I can see how they work, and if they are not I would be left having to reverse compile the binary code to find out how they worked. Then, I have to find a way to root the phone so I can modify the kernel with my own, or modify the ROM which initially boots the phone. These steps are difficult as there is likely not any information all laid out nice and neat on how to do this. Now, if I could accomplish this then, yeah, I could write an OS or port my hopefully simple OS to run on it with custom drivers to work with the display, storage device, and everything else. But, I am going to have to repeat this process for almost every phone out there. Now, a lot of phones might be similar by Samsung so I might be able to use the same technique on a few of them, but that requires actually having the devices to actually test and tweak it.
Writing a OS for x86 is already hard because you have to write a device driver for just about every piece of hardware, but now you take a phone/tablet/device and it is kind of like writing a driver for each device.
I think picking up where Linux starts is really a great solution, but the fact that each device out there uses some type of protection to keep you from easily replacing the kernel is creating the biggest hurdle because each user would have a different series of steps and that in conjunction with the ability to brick the device makes it even harder. It would be nice if device makers made an easy way to upload ROMs or kernels with some nice fail safes to recover but that requires support, resources, and time on their part and they have no motivation to do so.
So, that is why you do not see a tutorial for a wide range of devices like you do with the X86/X64 platforms. But, you know if all devices had a system boot menu item to select an arbitrary kernel image then it would make it more like developing for the X86/X64 platforms and you would likely find more tutorials. But, you still have to figure the hardware out! Which would be fun of course!
</edit>