Actually it depends on how far you want to go. You can jump to protected mode with a few lines more. But you won't have a very interesting exercise.
Basically, one would have to setup multiple registers like the GDT which sets the protection on different memory ranges (hence protected mode). Once you have your GDT setup, set a few bits in CR registers and execute a long jump to the code segment of the GDT (provided you have instructions loaded there).
Then once in protected mode, everything changes. The system allows you to set interrupts habdlndlers through the LIDT, to enable memory paging and you'll have to reload the GDT again. But no more access to the convenient BIOS functions.
You also set up the PIC of your system to get a ticking clock for scheduling your kernel operations. Once you got all that is where the fun begins and you can start implementing memory managers and allocators, writing a disk operations layer and implement (or write your own!) filesystem.
OS Dev is truly a fascinating subject because there's so much to learn. Even more with 64-bit, and multiple core initialization and usage.
I don't know how all of this works on ARM, but I might order myself an experimentation board to get my hands on.
The traditional ARM answer is that at a low level and at bootup the details are all very board specific -- what kind of BIOS equivalent you have (if any), where it starts you off, whether there's a bootloader like u-boot involved, where devices like the serial port are: all these things vary by board. For 64-bit ARM things are moving a bit more towards a standard setup with UEFI. In general, ARM assumes that the initial boot code will be customised for the specific chip, so unlike x86 which starts out looking like an 8086 until you flip it into protected mode, a 64-bit ARM CPU will start out in 64-bit and you can get at the backwards-compatibility 32-bit support by dropping down from 64-bit to 32. Back-compat is for applications, not OSes and bootloaders :-)
this is a terrible hack, but if you leave the bios areas alone, you can make a system call like machine that downshifts back into real mode, makes the call, and shifts back up into protected mode (or all the way back up into 64 bit mode)
its not _really_ worth it, but if you're just noodling around and want to send packets or write to disks you don't have to write drivers. of course you have to have dedicated buffers visible in both spaces.
the only other reason i can think of to use real mode is to actually explore the segment model rather than just treating it as trash you have to walk over to get something up from reset...but it would probably be better just to invent some kind of segmented virtual machine
About this much more complex -- https://github.com/charlesap/bootpager
(example legacy boot block that jumps into protected mode, enables paging, and pages in and executes arbitrary code, no bios used.)
As mentioned above the trick is what to do once you're there. And it is a UEFI world now, might as well just write 64-bit PE kernel and be done with it.
Depends. If you use a bootloader like grub that will put you in protected mode (The GDT is a bit undefined, but in general you can probably get away with just leaving it for simple programs). However, when you go to protected mode you lose access to the BIOS interrupts (and DOS interrupts if you're using them) and gain access to other features, so the range of things that are easy vs. hard changes a fair amount.
But if you're just planning on writing very simple text programs in ASM, then the only things that are really relevant is the text display, keyboard, and possibly disk/floppy. The text display is exactly the same (assuming the GDT from grub places it at the same location), but the keyboard is a fair amount more involved, and floppy is basically impossible (without writing a fairly involved driver). An IDE driver is surprisingly simple though (But still requires an interrupt, as does the keyboard). Both of these things are basically functions calls when you still have the BIOS around, so it does create a bit of a problem.
