aboutsummaryrefslogtreecommitdiff
path: root/lib/efi_loader/efi_memory.c
AgeCommit message (Collapse)AuthorFilesLines
2022-01-19doc: replace @return by Return:Heinrich Schuchardt1-2/+2
Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-10-21efi_loader: Fix loaded image alignmentIlias Apalodimas1-0/+52
We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-08-17efi_loader: use correct type for AllocatePages, AllocatePoolHeinrich Schuchardt1-2/+3
Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass1-0/+1
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-01-13efi_loader: remove outdated TODO in efi_memory.cHeinrich Schuchardt1-2/+0
In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-09-18efi_memory: refine overlap_only_ram descriptionMaxim Uvarov1-1/+1
Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-08-01efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-systemHeinrich Schuchardt1-1/+1
The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-05-18common: Drop net.h from common headerSimon Glass1-0/+1
Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-17efi_loader: round the memory area in efi_add_memory_map()Michael Walle1-14/+40
Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-03-11efi_loader: get_memory_map: return parameters whenever possibleAKASHI Takahiro1-6/+6
Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-12-02common: Move board_get_usable_ram_top() out of common.hSimon Glass1-0/+1
Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-11-12efi_loader: call add_u_boot_and_runtime() on sandboxHeinrich Schuchardt1-4/+5
On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-09-05efi_loader: Extract adding a conventional memory in separate routinePark, Aiden1-32/+50
Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-16efi_loader: fix comment for struct efi_pool_allocationHeinrich Schuchardt1-5/+9
Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-16efi_loader: Change return type of efi_add_memory_map()Bryan O'Donoghue1-12/+20
We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-06-14efi_loader: AllocatePages() must accept addr == 0Heinrich Schuchardt1-3/+3
It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-06-10efi_loader: event signaling in ExitBootServicesHeinrich Schuchardt1-1/+1
ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-06-04efi_loader: notify memory map changesHeinrich Schuchardt1-0/+11
When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-12efi_loader: simplify efi_allocate_pages()Heinrich Schuchardt1-28/+15
Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-12efi_loader: AllocateAdress error handlingHeinrich Schuchardt1-6/+13
If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-12efi_loader: out of resources in AllocatePages()Heinrich Schuchardt1-2/+2
According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-12efi_loader: check memory address before freeingHeinrich Schuchardt1-5/+47
When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-02efi_loader: FreePages() must fail with pages = 0Heinrich Schuchardt1-1/+1
The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-23efi_loader: check memory type in AllocatePages()Heinrich Schuchardt1-0/+4
The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-12efi_loader: update virtual address in efi_mem_carve_outHeinrich Schuchardt1-0/+2
Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-07efi_loader: EFI_PRINT instead of debug for memory servicesHeinrich Schuchardt1-2/+2
For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-07efi_loader: sanity checks when freeing memoryHeinrich Schuchardt1-18/+58
Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-03-20efi_loader: correct parameter size in efi_allocate_poolHeinrich Schuchardt1-2/+3
efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-02-13efi_loader: fix memory allocation on sandboxHeinrich Schuchardt1-0/+6
Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02efi_loader: Align runtime section to 64kbAlexander Graf1-3/+17
The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02efi_loader: macro efi_size_in_pages()Heinrich Schuchardt1-3/+3
When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02efi_loader: eliminate sandbox addressesHeinrich Schuchardt1-5/+4
Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02efi_loader: Reserve unaccessible memoryAlexander Graf1-3/+29
On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
2018-12-02efi_loader: correct efi_add_known_memory()Heinrich Schuchardt1-6/+14
If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02efi_loader: Ensure memory allocations are page alignedAlexander Graf1-0/+6
When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-23efi_loader: Merge memory map entriesAlexander Graf1-0/+45
We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-23Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""Stephen Warren1-1/+1
This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-10Remove <inttypes.h> includes and PRI* usages in printf() entirelyMasahiro Yamada1-2/+1
In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-08-21efi: Fix truncation of constant valueEugeniu Rosca1-4/+3
Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-20efi_loader: avoid NULL dereference in efi_get_memory_map()Heinrich Schuchardt1-1/+3
We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-20Revert "efi_loader: efi_allocate_pages is too restrictive"Stephen Warren1-1/+1
This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi_loader: check map_key in ExitBootServicesHeinrich Schuchardt1-1/+7
The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi_loader: check parameters of GetMemoryMapHeinrich Schuchardt1-10/+15
Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi_loader: check parameters in memory allocationHeinrich Schuchardt1-0/+6
If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi_loader: Expose U-Boot addresses in memory map for sandboxAlexander Graf1-6/+7
We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi: sandbox: Adjust memory usage for sandboxSimon Glass1-3/+10
With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi_loader: efi_allocate_pages is too restrictiveHeinrich Schuchardt1-1/+1
When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de>
2018-06-03efi_loader: efi_mem_carve_out should return s64Heinrich Schuchardt1-14/+18
efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-06-03efi_loader: avoid anonymous constants for AllocatePagesHeinrich Schuchardt1-3/+5
Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-06-03efi_loader: remove unnecessary includeHeinrich Schuchardt1-1/+0
asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
generated by cgit v1.1 at 2024-09-08 03:43:43 +0000