From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web08.21617.1606496919568700476 for ; Fri, 27 Nov 2020 09:08:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PK7q6NQs; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606496918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MTApymZ97qPWVndcAzwoQORuQyof2ggL6abnSo60u+0=; b=PK7q6NQsWuSrbbf6IwXEAybvwF+sEPeDRB0xYKLoukVsN3cHiw+4R+jHuKYdFI0MOy7HWc /MBMHCE3ioZmMfvJKgAEBxG/8ZG2uvHS4fmfABpcSehzKPakKU+I2uRlBjEU6+IWTM3p32 SiZwym2dU4bYSRjwwfRM7ZoeaCyEkzg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-176-yA7A2KM3O9SVcMrLKAjkPg-1; Fri, 27 Nov 2020 12:08:35 -0500 X-MC-Unique: yA7A2KM3O9SVcMrLKAjkPg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ED82A185E49C; Fri, 27 Nov 2020 17:08:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-74.ams2.redhat.com [10.36.112.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 550BB5C1C2; Fri, 27 Nov 2020 17:08:32 +0000 (UTC) Subject: Re: [edk2-devel] Cannot boot ISO on RamDisk To: devel@edk2.groups.io, nahim.souza@fit-tecnologia.org.br References: From: "Laszlo Ersek" Message-ID: <5d89a9dc-ca50-fa6e-bdde-6e3ef3bd0b6a@redhat.com> Date: Fri, 27 Nov 2020 18:08:32 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 11/26/20 20:53, Nahim Souza via groups.io wrote: > Greetings! > > We are trying to implement an .efi application that receives an ISO file from an Android device, loads it into a buffer and try to boot an Operating System. To do this, we tested some implementations using Ram Disk but after creating the virtual disk and running BOOTX64.efi and found on the FAT32 partition, but some problems occur after boot, as if I did not find the other files in the ISO. To solve this problem, we tried some approaches: > > * Change the parameters when calling RamDiskProtocol->Register() function (GUID and DevicePath) > * Tried with different OS (Xubuntu, Windows 10, Windows 7, Ubuntu and OpenSuse) > * Compared with HttpBoot implementation from EDK2, where we saw that an ISO file could be loaded into memory to boot an OS, but the RamDisk implementation in HttpBootRegisterRamDisk was very similar to ours > Based on this, I have some questions: > > * In our understanding, HttpBoot downloads the ISO and boots the OS using the RamDisk. Is that correct? I think so. https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-boot-from-http > * We saw that RamDiskDxe has some dependencies from ACPI tables, since it uses NFIT (NVDIMM Firmware Interface Table) to save some persistent information. Is there some hardware/driver requirement to make the OS boot through RamDisk? Did we need to have this NVDIMM to support ACPI feature from RamDiskDxe? The booted operating system needs to understand where to look for files on the virtual disk. More precisely, the booted operating system must understand that the particular reserved memory range *is* a RAM disk. If there is no NFIT, the booted operating system will have no idea where to load other files from. A similar issue is discussed in this RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1671345 There, the problem was that the guest kernel in question didn't have a driver for consuming the NFIT table. Different reason, same result -- the information describing the UEFI-originated virtual disk to the OS was lost, so the OS couldn't finish booting. > * Would you have any other suggestions for solving this scenario? Make sure you have enough (contiguous) RAM, as the ISO can be large, and you still need enough RAM left after the reserved memory allocation, for booting the OS. https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size HTH Laszlo