The MLO *file* is the first stage bootloader, which in turns sets up, or instructs uboot( the second stage boot loader ) how it can use the hardware. To a point. If you need a better explanation of that then you have google to help you. But if you need to know why you need to copy the MLO file into the MBR first, it's because the processor is designed to look in a specific place for the first stage boot loader. Perhaps, 1 of 2-3 different locations. I think you can technically load the first stage bootloader over serial too, but I'm not 100% sure about that.
The initrd is *not* used by uboot. The initrd is loaded by uboot, when it passes control to the Linux kernel. Again, if you need to know more information, google can help you more than I'd care to. Because a) I do not know everything, and b) I do not feel like writing a book on the subject in an email. In either case, device tree overlays have nothing to do with either the MLO file, or uboot. At least not in this context. Overlays live in a Linux, or potentially other operating systems file system. Where the two bootloaders can be on a FAT partition, or in the boot sector of the media used to boot from( flash media ). Although technically, now, overlay files can be loaded from uboot at boot time. This however is a recent development. On Sun, Mar 26, 2017 at 9:54 AM, <[email protected]> wrote: > I know that ROM code can understand boot pins and contains a jump vector > to some ram location to execute the first boot sector. I am using mmc boot > with MLO, as instruction to make CPU to look the MLO or the first 512 bytes > from boot sector. I have a couple of confusions about booting? > > 1. > > Is MLO the file that contains this 512 bytes ? > 2. > > Is MLO the boot sector? > 3. > > How do the cpu reads MLO and put its contents into RAM if it do not > have any mmc driver at this stage? > 4. > > Also I have observed that while copying MLO, uboot.img, uImage and > device tree blob, I have to copy MLO first.Why? > 5. > > Because in MLO there are no filesystem drivers cause it can have only > 512 bytes, we need to use U-boot.bin/img file? What if it can have more > storage within it to support all the useful functioality of uboot, in that > case do not have to use uboot stage? > 6. > > Is initial ramdisk image is used by U-boot to load kernel and driver > modules that kernel will use, or kernel uses ramdisk when its loaded? > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/d6393a95-d7a4-4226-979c-099a53ed8127%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/d6393a95-d7a4-4226-979c-099a53ed8127%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORr7ks-VX2L_yzWtPjKg4UpcGKKYwejy5EcVuX96OCxNCw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
