> > > > > So screen_info is a global variable in the core kernel. For the zboot > > > > > case (our own implementation, not sure about the proposing new > > > > > method), efistub may be able to fill this info, but while > > > > > decompressing, screen_info will be overwritten. I think. > > > > > > > > > > > > > Right. So you can drop it then. > > > OK, then can we rename LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID to > > > LINUX_EFI_SCREEN_INFO_TABLE_GUID and avoid define a dedicated GUID for > > > each arch? > > > > > > > If you use the arm64 approach, you don't need a GUID at all. > Oh, I misunderstood. > OK, I will use the arm64 approach now, my problem only exists when the > order is "stub, decompression, core-kernel". If the new zboot way is > "decompression, stub, core-kernel", then there is no problem. > Indeed. I am trying to port the generic EFI zboot support to LoongArch, but I am running into a problem: The zboot EFI image consists of zImage.o, created with objcopy -O binary zboot-header.o, created using the assembler libstub.a, created as usual This results in errors such as arch/loongarch/boot/zboot-header.o: can't link different ABI object. failed to merge target specific data of file arch/loongarch/boot/zboot-header.o which I think is caused by the fact that objcopy does not set the LP64 soft float flags on the ELF object it creates. Do you see any way around this limitation?
