Hi Leif, > From: Leif Lindholm [mailto:[email protected]] > Sent: Friday, September 18, 2015 9:38 PM
> Hi Bhupesh, > > On Fri, Sep 18, 2015 at 02:03:10PM +0000, Sharma Bhupesh wrote: > > I have been trying my hands-on on replacing the current Legacy BDS > > loader with the EFI_STUB on a Freescale ARM64 SoC to load Linux and > > utilize the features of the EFI_STUB. > > > > I am taking a reference from ARM juno support, where I am getting > > confused about a couple of points: > > > > 1. Legacy Linux Loader: > > > > I see the following INF inclusion in 'ArmPlatformPkg.dsc'. What do we > > mean exactly by Legacy Linux Loader here? Is it the built-in Linux > > Loader which ignores the stub (as you refer to it, in a HiKey related > > discussion: > > https://lists.96boards.org/pipermail/dev/2015-March/000083.html) > > > > ArmPlatformPkg.dsc > > ---------------------- > > # Legacy Linux Loader > > ArmPkg/Application/LinuxLoader/LinuxLoader.inf > > Yes, this is the anti-UEFI. Ok, got it. So are there any plans down-the-road to move the Juno and friends to the actual UEFI stub support. What exactly will it look like - will it be a extension to support GRUB2 which can then be used to pass the control to the kernel? > > 2. Passing a initramfs/initird to the kernel: > > > > Using the reference from Juno board, I have added the following to my > > .dsc. This allows me to specify a ARM64 Image + DTB placed on NOR > > flash to the kernel and I see that using the BootMenu, I can boot the > > kernel partially with the same: > > > > gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"EFI Linux from > NOR flash" > > > gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"MemoryMapped(0x0,0x > 61100000,0x62000000)/Image" > > > gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths|L"MemoryMapped(0x0,0x63000000,0 > x638FFFFF)/fsl-dtb.dtb" > > > gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"console=ttyS0,115200 > root=/dev/ram0 earlycon=uart8250,0x21c0500,115200" > > > > However, I cannot find a way to provide a .cpio based initramfs/initrd > > kept on the NOR flash to the kernel. > > > > Will I need to use other booting media like a SD card (rather than the > > NOR flash) and keep the Root-file-system there and invoke all the > > components via a "startup.nsh" like script: > > > > fs0:\Image dtb=fsl-dtb.dtb rootwait console=ttyS0,115200 > > root=/dev/ram0 earlycon=uart8250,0x21c0500,115200 root=/dev/sda1 > > Well, first of all, you should not be supplying a dtb via the command > line (if you enabled Secure Boot, it would just be ignored anyway); you > should register it as a configuration table. Ok. Sure. > Secondly, specifying console= on the command line is redundant these days > - just add a stdout-path entry to your dtb's chosen node. Similarly for > the earlycon - just "earlycon" is sufficient if you have a stdout-path. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Docu > mentation/devicetree/bindings/chosen.txt Right. I am still using a old 3.19 kernel. On the latest kernel I am building right now, I will use the 'stdout-path' as you suggested. > Thirdly, if you're happy with the hardcoding, you could just create your > own linux,initrd-start (inclusive) and linux,initrd-end > (exclusive) entries in chosen. Right, I can fixup the FDT to provide the 'chosen' node with the desired initrd-start and initrd-end address. > At which point root=/dev/ram should be redundant, and you would end up > with arguments: > > earlycon root=/dev/sda1 Great. Not sure what you imply by root=/dev/sda1 here - that the Root-file-system is placed on a SD/MMC card? Regards, Bhupesh _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
