GRUB4EFI: addresses to get free memory?
deomsh opened this issue · 17 comments
With GRUB4DOS I can use following addresses to get free memory: *0x8298/ *0x82C0 (memory below/ above 4GB)
These addresses are not working (for me) with GRUB4EFI.
Are there other (fixed) memory addresses can use in case of GRUB4EFI? I need these addresses in a script.
In the UEFI environment, memory is generally not available for arbitrary use.
Provide the required dimensions and allocate them by internal functions.
To be more specific, what is the purpose of using these parameters in the script.
What is the maximum requirement for allocating memory?
I am working on a script to read-out ISO-9660/ UDF CD/DVD/image files (mapped to a ram-disk too), and for UDF also on a hd-device.
In case of ISO-9660 needed memory is only a few sectors to parse 'path' etcetera.
In case of UDF I need/ use memory for the Virtual File Allocation Table (CD-R/DVD+/-R), the Sparing Table (CD-RW/DVD-RW), addressing the Metadata Partition (UDF v2.50/v2.60) if more than one Extent, and in case of Files/ File Identifier Descriptors with more than one Allocation Descriptor (Extents normally NOT contiguous in this case).
At the start of the script I have a line (GRUB4DOS)/ need a line (GRUB4EFI) to investigate if there is enough free memory starting at 64MB (sector 0x20000). With a command-line switch this 'mdbase' can be set to another address (minimum 0x19000, which is assumed to be a 'safe' value in GRUB4DOS v0.46a). For now I think normal operation of this script will not need more than 0x10000 sectors of memory, probably less.
However, in special cases (if a special command-line switch is set) a maximum of about 2GB could be needed to dd-copy a File with more than one Allocation Descriptor to a contiguous memory region, to get direct access to this file. In a sub-routine for the (Extended) File Entry I have a line (GRUB4DOS)/ need a line (GRUB4EFI) for this case.
Normally internal function 'blocklist' is preferred here, but UDF-support of GRUB4DOS/ GRUB4EFI seems to be limited to 'plain' UDF and maximum version 2.01.
To make things more clear a print-screen of the DIR-function on a 8GB partition, a test-VHD formatted with UDF version 2.50 (Metadata Duplicate Flag is set) and attached in Virtual Box 7:
Need 2Gb of free space? It's too exaggerated.
It is possible to judge layer by layer and reuse the same memory.
Memory can be allocated indirectly using a map. Example:
map (md)0+0x500 (3)
map --status=3
%?%=Start_Sector
Did you also try the command
map --status=3
As suggested. The one you used is not what was suggested
I just saw my error while watching my post again on my smartphone. Thanks!
yaya2007, thanks a lot for your idea using 'map'
Everything seems to work:
I will try to use this in my script.
About the 2GB: it's only a 'practical' maximum, and only needed to have direct access to a fragmented file. If the Information Length of the file is above the maximum, the script should throw some error message.
I experienced two problems with this 'map' approach.
-
GRUB4EFI freezes if mapping 2GB, I had to reboot.
But 2GB - one 512 byte sector is okay. If there is enough memory, mapping is working to just below 2GB.
If I set total amount of memory at 2GB in VBox, I see error message 'out of map memory: 9', which seems to be 'good' in this case. -
If I unmap '(3)' with the line 'map --unmap=3' the mapping table is empty again, but memory is not given back according to 'displaymem -s'.
If I map a much lower amount of memory (32MB): same result!
If remaining memory seems to be too low, I get the error message again.
From the first image, it can be seen that the maximum available memory size is 0x3BF5F0.
You assign 0x3FFFFF, which is greater than 0x3BF5F0, of course not.
The function map -- unmap has an error and has now been corrected.
Of course it won't fit. That's why I said the error message is 'good' in this case. The problem I mentioned is that GRUB4EFI freezes if mapping the full 2GB, instead of throwing the same error message of 'out of map memory'
I tried to download the archive you uploaded, but I got only 9 bytes with 'Not Found' inside.
Thanks a lot, memory is indeed 'given back' after unmap now:
What I still do not understand how it is possible to map more than half of available memory?In my case 3454 MB is free, so half is 1727 MB, while 2 GB - 512 byte is mapped. According to 'map --status' even rounded up to 0x400000 = 2GB !
Or is the content of memory (md)0+0x3FFFFF not (fully) mapped?
Changed equipment? The maximum available memory of the previous device was 0x3BF5F0, and the maximum available memory of the current device is 0x6BF5F0.
You can currently:
map (md)0+0x6BF5F0 (3)
That is, the maximum memory that can be used now is 0x6BF5F0 sector, 0xD7EBE000 bytes, 3453Mb.
One thing to note: memory is allocated in pages, that is, aligned in 8 sectors (4096 bytes).
I used Virtual Box for testing. In the earlier print-screen the amount of memory was set lower, to force the 'out of map memory' error.
The FIRST problem I mentioned is still unsolved: mapping an amount of memory from 2GB upwards fully freezes the system.
To check if Virtual Box could be the root of the problem, I booted a real EFI motherboard. On my USB drive was an older version of GRUB4EFI, no problems with mapping 2GB memory or higher.
After booting that motherboard with the latest test-version you provided in this thread: same problem as in Virtual Box, I even needed a hard reset. Ctrl+Alt+Delete didn't work anymore.
Booting with the older version (2023-02-23) in Virtual Box: FIRST problem was gone too, no freezing anymore.
So version 2023-02-23 has NO problems mapping 2GB or more memory, with versions 2024-02-26 and 2024-03-23 system is freezing.
See print-screen below:
Today is a rare opportunity to reproduce the problem!
It's not a crash, it's writing data to newly allocated memory. Writing 2-3GB of data takes time.
Now add a switch parameter.
map --alloc-only (md)0+0x6BF5F0 (3)
Nice switch, and rather fast. Problem of 'memory allocation only' seems to be solved.
But if someone (not me for now) wants to really map memory: if it is not a crash, it is something else. With 2GB (0x400000) I am still waiting.....
I did some quick tests. Problem with REAL mapping of +2GB memory seems to be starting with version 2023-06-09:
I am testing on the QEMU virtual machine, 0x1b61b0, which takes 57 seconds.
My system is quite old: 960GC-GS FX (2013) with AMD Bulldozer and Windows 10, but Virtual Box is rather fast.
I wanted to do vhd->ram but even without 32gigs of memory it crashes in efi mode as soon as you issue the map command