Activity for Pete Batard
-
Pete Batard posted a comment on ticket #2446
But I'm note sure what is based on. Is it Zero based? If it's the same field as the one in PVD, it should be the size of the volume, in logical sectors (i.e. in blocks of 2048 bytes). Not sure what you mean by zero based, but no, an ISO volume occupying 10 blocks would not have 9 in that field, it would have 10. So this field can be used like an LSN/RBA to tell us the virtual LSN/RBA of a subsequent El Torito image, if there was any, when expanding per the UEFI specs. And we can have many descriptors....
-
I don't remember iso format details. So it's difficult for me to change something in that code. Well, as far as I can see, this should be mostly around this section of the 7-zip code (sorry for using a GitHub mirror, but I couldn't find a repo here). What way we can detect that we must increase size of file to full image size? This is something I have recently added to libcdio, most specifically in this section (and while the code is GPLv3 licensed, since I am the author of these changes, I am happy...
-
I don't remember iso format details. So it's difficult for me to change something in that code. Well, as far as I can see, this should be mostly around this section of the 7-zip code (sorry for using a GitHub mirror, but I couldn't find a repo here). What way we can detect that we must increase size of file to full image size? This is something I have recently added to libcdio, most specifically in this section (and while the code is GPLv3 license, since I am the author of these changes, I am happy...
-
For completion, I'll point out that if you want to generate an ISO yourself using xorriso, you can follow these instructions.
-
32MB+ ISO-9660/El-Torito images, as defined by the UEFI specs, are not supported
-
Well, considering that a fix for this issue has now "magically" appeared in https://github.com/rhboot/gnu-efi/commit/9e6cb2150bee08e83ec0cdfb8d6c2f83975dd3df, which has been integrated into gnu-efi, and that none of the people responsible for the regression bothered to notify about this fix in the original bug report, I guess I'm going to entitle myself to some further snide remarks by pointing out what a nice "rolling the software forwards" this has been, when it looks like none the 3+ developers...
-
Just going to add that on a vanilla Ubuntu 23.04 system (that was released a couple weeks ago and is recent enough to come with binutils 2.40), the default gnu-efi apps are still broken. apt install git build-essential gcc-aarch64-linux-gnu git clone https://git.code.sf.net/p/gnu-efi/code gnu-efi cd gnu-efi aarch64-linux-gnu-objcopy --version # reports: "GNU objcopy (GNU Binutils for Ubuntu) 2.40" export CROSS_COMPILE=aarch64-linux-gnu- make apps Trying to run the resulting t.efi (a simple "Hello,...
-
Yes, my statement is imposing. First of all, you are being singled out here because you are the author of the commit that broke compatibility. And I'm also seeing two major things that one should fully expect to have seen happening from a BREAKING change (or at least one that you rightfully expected/knew would break compatibility with older platforms): Trying to detect the binutils version of support for whatever newer option you need as part of the build process, and only use the new approach in...
-
I'm sorry, but you just broke current Debian, so I don't see how we can go with this approach. Current up to date Debian uses binutils 2.35, not 2.38, and you can't just go around breaking other up to date distros, just because OpenSUSE happens to be using a super recent binutils. Heck, even if Debian or Ubuntu had just upgraded to 2.38 I would tell you that this is a poor practice, because you'd leave plenty of people stranded (sorry but the, "don't upgrade... and don't benefit from important fixes"...
-
AARCH64 (and possibly other archs) generation is broken
-
For the record, I submitted a patch for it in https://sourceforge.net/p/gnu-efi/patches/88/
-
riscv64: fix efibind.h missing/duplicate types
-
riscv64: finalize efibind.h
-
Fix VS2019 Code Analysis warnings
-
[PATCH] Define UnicodeSPrint/UnicodeVSPrint as our main SPrint/VSPrint calls
-
[PATCH] Use EFI_FILE_SYSTEM_VOLUME_LABEL rather than EFI_FILE_SYSTEM_VOLUME_LABEL_INFO
-
[PATCH] Define BASE_CR as a duplicate of the _CR macro
-
[PATCH] Fix CopyMem() not handling overlaps
-
Thanks for applying this series -- Much appreciated!
-
[PATCH] Remove the need for other include paths besides <gnu-efi>/inc
-
[PATCH] Always define HAVE_USE_MS_ABI for MSVC compilers
-
[PATCH] Add AsciiPrint and AsciiVSPrint
-
[PATCH] Always prefer the external <stdarg.h> for MSVC compilation
-
Hi Igor. Thanks a lot for the ARM builds! Attached are the ARM64, ARM and x86 test results on a Raspberry Pi 4 running at the default frequency of 1.5 GHz. Note that the default installation directory for ARM version was Program Files (x86) instead of Program Files (Arm), so this might be something you want to look at. The default installation directories for the other installers were fine. For the record, that last x86 test literally took hours to execute on that hardware, so I don't think you'll...
-
But it's not simple now, while I can't test all things in real arm64 system. I'm just going to point out that if you have a Raspberry Pi 4 (preferably the 4 or 8 GB model) then you can install and run Windows 10 ARM64 on it, which makes it a great inexpensive platform to test Windows ARM64 applications... As the developer of Rufus, this is how I test the ARM64 version of it on real hardware. Btw, since I needed 7-zip on that platform to run some of my testing, I can confirm that the ARM64 version...
-
Since I have it, and in case this can be useful, I am also adding a sample function, for reference, to illustrate how the new SMBIOS 3.0 support can be used in a UEFI application to report the BIOS and hardware information: EFI_STATUS PrintSmbiosInfo(VOID) { EFI_STATUS Status; SMBIOS_STRUCTURE_POINTER Smbios; SMBIOS_STRUCTURE_TABLE* SmbiosTable; SMBIOS3_STRUCTURE_TABLE* Smbios3Table; // Try SMBIOS v3.x first and fall back to v1.x if not available Status = LibGetSystemConfigurationTable(&SMBIOS3TableGuid,...
-
Add SMBIOS 3.0 support
-
Fix conversion from 'UINTN' to 'UINT8' warnings
-
Move memcpy/memset definition to global init.c
-
Add EFI_DRIVER_ENTRY_POINT support for MSVC/ARM64
-
Updating this patch to v2, since it turns out MSVC will also emit memset and memcpy intrinsics that we can use an implementation for. This is true for both ARM and ARM64. To make this work, I'm defining __SIZE_TYPE__ to UINTN if not already defined.
-
Fix ARM64 support for Visual Studio 2017
-
remove double typedef of EFI_UNICODE_COLLATION_PROTOCOL
-
move ARM's DivU64x32() into math.c
-
Personally, my vote would be for Option 1, especially as I think the compiler switch...
-
Align ReallocatePool() parameters with EDK2?
-
fix a GNU ar warning about deterministic mode
-
fix an AARCH64 gcc error with 'const' qualifers
-
Thanks Nigel. In case you're curious, the whole point of this last series of patches...
-
Sorry about that. Here's v3
-
Actually, EFI_DEBUGGER_CONFIGURATION_PROTOCOL should not have been part of the previous...
-
add Debugger protocol support
-
add EBC (EFI Byte Code) protocol support
-
OK, here's a better version that adds the required definition in efipciio.h. Note...
-
Scratch that - there already exists an efipciio.h with most of these definitions....
-
Add support for PCI Root Bridge I/O protocol
-
Bridge more gaps between EDK and gnu-efi
-
Update global protocol GUIDs definitions to match EDK2
-
Oops - forgot the 'extern EFI_GUID DevicePathFromTextProtocol;' in efilib.h. This...
-
Add support for some UEFI 2.0 protocols
-
Thanks Nigel -- much appreciated!
-
Complete protocol struct/type/define renaming to match specs
-
fix an MSVC warning
-
add DivU64x32 assembly definition for MinGW on ia32
-
Make ARM's EFI_DRIVER_ENTRY_POINT compatible with MSVC
-
Avoid an implicit memcpy() in event.c
-
Fix an MSVC external reference to __allmul
-
Only enable -fpic for non MinGW compilers
-
MSVC/ARM compilation fixes
-
Much appreciated. Thanks!
-
Fix MinGW breakage in setjmp.S
-
Fix MSVC compilation
-
I will not be able to maintain these files if/when new functionality is added to...
-
French localization
-
Sounds good. I went ahead and applied the latest from ms-sys onto my internal version,...
-
you can call (is_zero_mbr_with_other_windows_disk_signature() || is_zero_mbr()) That's...
-
Hi Henrik, Thanks for applying the patches. I've fetched the latest from CVS and...
-
Here are the new patches rebased on latest CVS. The new branch is at https://github.com/pbatard/ms-sys/commits/rufus2...
-
1a) I was talking about the splitting of these various similar calls in fat32##.h/.c....
-
Hi Henrik, Thanks for reviewing the patches. Here are my comments on your points:...
-
4 patches for ms-sys
-
Fix MSVC breakage due to GNU align extensions in setjmp
-
Fixes needed to silence VS2015 compilation warnings
-
Thanks. Since I have moved to using gnu-efi + Visual Studio to build EFI drivers...
-
fixes needed for MSVC (VS2013) compilation
-
I have now added binaries for exFAT and XFS drivers, along with an updated version...
-
I have now added binaries for exFAT and XFS drivers, along with an updated version...
-
Or, if you don't want to build it yourself, you can also download the binary version...
1