Welcome to the land of ARM
Back in the day, I could compile for i386, i386+i387, i486(dx), i486sx, i487, Pentium, Pentium MMX and the AMD/VIA variations. I could also compile for any subset of them at the cost of reducing performance. Debian has ports for two variations to keep the size of the repositories sane. (Gentoo supports your exact hardware by downloading the source code and compiling it). ARM is just about leave a period of diversity that used to afflict x86. Debian has two ARM ports: armel (much older hardware than Pi1) or armhf (a little too modern for Pi1). Rasbian (a Debian port specifically for Pi1) is needed to get reasonable performance out of an old Pi. A Pi2 should be able to use the standard armhf port without a significant performance loss.
ARM SoCs have something resembling a BIOS: an on-chip ROM than can just about read a boot loader from SDHC or SATA or whatever device exists. At this point, things get unpleasant. Each ROM works differently, and the documentation is usually secret, missing, non-existent, badly translated and full of errors. Where there is a standard, it is often outright hostile to prevent you from installing Linux on a landfill RT tablet. The fix is called Das U-Boot. If there is a branch for your SoC, Das U-Boot can be compiled and installed on flash where and how your particular boot ROM expects it.
The next disaster is that every SoC has a different mix of on chip components, and usually far more than can access the outside world because there are not enough pins on the chip. The actual hardware available depends on what verison of the PCB the SoC is soldered onto. On modern x86 systems, most devices can be found from their PCI id, or by hoping the BIOS will tell you (gray beards can regale with tales of ISA and plug 'n pray). On ARM, you can create flattened device trees (lists of available hardware) when you compile the kernel.
Getting an ARM to boot requires partitioning some flash device the way the boot ROM expects, installing the correct branch of U-Boot where the ROM expects it, and pointing U-Boot at the right FDT and you distribution's partition. The kernel itself can be the standard one from your distribution.
The current system may be vile, but it could easily be worse. When BIOS was the 'standard', some manufacturers implemented it so badly that the Linux BIOS project was created to replace it (that project suffered from all the horrors we currently see with ARM). There are standard boot sequences for ARM, usually designed to lock you into Chrome, RT, Android, Winphone or whatever you want to replace the day you get the device.
The real solution is the same as it has always been: research the install process and state of hardware support before you make a purchase decision.
Biting the hand that feeds IT
