Hi, Arnd and Ard, On Wed, Jul 28, 2021 at 1:54 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tue, Jul 27, 2021 at 6:22 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Tue, 27 Jul 2021 at 15:14, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > On Tue, Jul 27, 2021 at 2:51 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Tue, 27 Jul 2021 at 14:41, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > On Tue, Jul 27, 2021 at 1:53 PM Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > > > > > > > How is other information passed from grub to the efi stub > > > and from there to the kernel on loongarch? > > > > I don't think this architecture boots via EFI at all - it looks like a > > data structure is created in memory that looks like an EFI system > > table, and provided to the kernel proper without going through the > > stub. This is not surprising, given that the stub turns the kernel > > into a PE/COFF executable, and the PE/COFF spec nor the EFI spec > > support the LoongSon architecture. > > A lot of upstream projects are still missing loongarch support completely. > I already pointed out the lack of kernel support when the musl and > qemu patches got posted first, and the lack of toolchain support for the > kernel, so it's possible this one is just another missing dependency that > they plan to post later but really should have sooner. > > > This is problematic from a maintenance point of view, given that the > > interface between the kernel proper and the EFI stub is being promoted > > from an internal interface that we can freely modify to one that needs > > to remain stable for compatibility of new kernels with older firmware. > > I don't think we should be going down this path tbh. > > Agreed. Having a reliable boot interface is definitely important here, > and copying from arch/mips was probably not the best choice in this > regard. They can probably look at what was needed for RISC-V to > add this properly, as that was done fairly recently. Now the boot information passed to kernel is like this: 1, kernel get a0, a1 and a2 from bootloader. 2, a0 is "argc", a1 is "argc", so "cmdline" comes from a0/a1 3, a2 is "envrion", which is a pointer to a "struct bootparamsinterface" 4, "struct bootparamsinterface" include "systemtable" pointer, whose type is "efi_system_table_t". Most information, include ACPI tables, come from here. 5, initrd path is specified in grub.cfg, but its load address and size is calculated dynamically by grub, so grub appends parameters to cmdline. Huacai > > Arnd
