From: "Mara Sophie Grosch" <littlefox@lf-net.org>
To: devel@edk2.groups.io
Subject: Re: [edk2-devel] Running and Testing Modules and Applications
Date: Sat, 4 Jun 2022 01:00:39 +0200 [thread overview]
Message-ID: <YpqSlxNQXHQUWxNR@LF-T470> (raw)
In-Reply-To: <42fc9038-82b7-692d-58e6-0b9d293d7bb3@hpe.com>
[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]
In addition to mtools, I wrote a tool to package a set of files into a
fresh VFAT image - kinda like tar, but fat32 as output format. I'm using
it in my hobby OS project. It's a single C file but seems to work great,
albeit only tested in my workflow so far. Called it `fatcreate`, it's
available on my Gitlab [1] or on GitHub[2].
Best, Mara
[1] https://praios.lf-net.org/littlefox/lf-os_amd64/-/blob/main/util/fatcreate.c
[2] https://github.com/LittleFox94/lf-os_amd64/blob/main/util/fatcreate.c
Am Fri, Jun 03, 2022 at 05:06:50PM -0500 schrieb Brian J. Johnson:
>Qemu's virtual VFAT (vvfat) disk type is a convenient way to test UEFI
>applications. It presents a folder on the host as a VFAT file system
>to the guest. It's not the fastest or the most stable disk type (be
>careful not to modify files from the host while the guest is running),
>but it's really handy.
>
>Another way to put a file on a UEFI VFAT disk image for qemu is to use
>mtools (https://www.gnu.org/software/mtools/), a set of user-mode
>programs which can manipulate FAT disk images. You can write some
>scripts around them to automate your workflow, similarly to uefi-run.
>I've done that quite a bit in the past.
>
>Good luck,
>Brian J. Johnson
>
>-------- Original Message --------
>From: Ayush Singh [mailto:ayushdevel1325@gmail.com]
>Sent: Friday, June 3, 2022, 11:49 AM
>To: edk2-devel-groups-io <devel@edk2.groups.io>
>Subject: [edk2-devel] Running and Testing Modules and Applications
>
>Hello everyone, I wanted to ask everyone how most modules and
>applications are run/tested in edk2. I will be working on Adding Rust
>support for edk2 during GSoC and thus will probably have to do a lot
>of primitive testing. I did look at the EmulationPkg but didn't really
>understand how to use it. It simply drops me into gdb, although maybe
>that's what it is supposed to do?
>
>There were also some GUI programs (VisualUefi) that can be used in
>windows, but since I am in Linux, they aren't much useful. I also
>found a tutorial to run it in a physical machine
>(https://tait.tech/2021/04/18/uefi-development-environment/ ), but
>that
>seems more for the final testing rather than testing during
>development.
>
>I have also tried using qemu for running applications, and I guess I
>was somewhat successful by using the script:
>`https://github.com/Richard-W/uefi-run` to test out uefi applications
>in qemu. However, it builds a FAT filesystem around the EFI
>application, so I was wondering if there was a better and simpler way
>to do it.
>
>Ayush Singh
>
>
>
>
>
>
>
>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-06-03 23:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 16:49 Running and Testing Modules and Applications Ayush Singh
2022-06-03 22:06 ` [edk2-devel] " Brian J. Johnson
2022-06-03 23:00 ` Mara Sophie Grosch [this message]
2022-06-04 19:32 ` Ayush Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YpqSlxNQXHQUWxNR@LF-T470 \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox