Forgot to write to out if no other pages were found.

In D20347#441879, @kib wrote:

In D20347#441878, @manu wrote:

In D20347#441757, @kib wrote:

This all looks fine, except one detail. I reviewed UEFI 2.8 description of EFI_BOOT_SERVICES.GetMemoryMap() but did not found a mention that they require the map ordered by phys address. Did you miss the code to sort the map ?

In chapter 4.6, EFI_MEMORY_ATTRIBUTES_TABLE it is said : The list must be sorted by physical start address in ascending order.

I am even more confused. The description said that about EFI_MEMORY_ATTRIBUTE, not about memory map. And you correctly use memory map, because MEMORY_ATTRIBUTE seems to be some after-thought patch only applicable to EFI runtime code and data.

qsort the efi map
If out is supplied, search for the last page with the same attributes as the requested out and write the address in out.

In D20347#441757, @kib wrote:

This all looks fine, except one detail. I reviewed UEFI 2.8 description of EFI_BOOT_SERVICES.GetMemoryMap() but did not found a mention that they require the map ordered by phys address. Did you miss the code to sort the map ?

return (0) -> return (false)

Use bsearch and address kib's comments.

In D20348#441192, @dougm wrote:

You could build a table of descriptors with EFI_MD_ATTR_RT set, sorted by md_virt value, and do a binary search on that table to find which range, and thus which descriptor, had the address you're looking for.
I don't know anything about EFI, so I don't know if the ranges come in sorted order already, or whether we'd have to sort them. And I don't know if this is something that could be done once in efirt.c:efi_init, or would need to be done in efirt_machdep.c:eft_create_1t1_map for each architecture. In any case, it seems not too hard to replace a linear search with a binary search.

LGTM, I'll try to find to time to test today on armv7 and armv6.

So with a pctrie (I can post the code somewhere if you want) I have 14 non-leaf node
db> show pctrienode efi_map_trie_zone
node 0xffff000000ad3f90, owner fffffd0010d0b540, children count 19408, level 4305:
slot: 0, val: 0xffff000001568060, value: 0, clev: 4305
slot: 1, val: 0xbfffd3ff18, value: 0, clev: 4305
slot: 2, val: 0xbfffd3fb18, value: 0, clev: 4305
slot: 3, val: 0xfffffdbf7fd30018, value: 0, clev: 4305
slot: 5, val: 0xffff000000760795, value: 0xffff000000760794, clev: 4305
slot: 6, val: 0x1030000, value: 0, clev: 4305
slot: 7, val: 0xfffffdbf6a38b200, value: 0, clev: 4305
slot: 9, val: 0xfffffd00101a2c40, value: 0, clev: 4305
slot: 10, val: 0xfffffd0010b9e400, value: 0, clev: 4305
slot: 12, val: 0x1dcd6500, value: 0, clev: 4305
slot: 13, val: 0xfffffd0010b9e380, value: 0, clev: 4305
slot: 14, val: 0xfffffd0010b9d200, value: 0, clev: 4305

Address kib comments.
Note that based on some comment on D20348 I might change this revision so efi_memory_attribute won't use the efi map directly.

remove a blank line removal.

Default to DEVICE and while here check is XP atttribute is set and set UXN/PXN if it is.

Correct the mapping in pmap_kenter based on the requested one and the one in the efi map

good for me, please just commit with the baudrate 0 comment preserved, I'm sure this will help someone in the future.

Add helper function that get the memory map from efi.
Remove some debugs printf that weren't supposed to be there.

In D20348#438893, @kib wrote:

In D20348#438886, @manu wrote:

In D20348#438878, @kib wrote:

I think this change should be somewhat improved by taking the most strong attr mode between pair of what is reported by UEFI memory map, and what is requested by a caller. For instance, if caller requests uncacheable, while UEFI reports write-combining, uncacheable should win.

I don't really understand, the caller of pmap_mapbios never request the mapping attr.

I mean that any mapping created by pmap_mapXXX() functions should take the UEFI map attributes. In particular, pmap should not change DMAP attributes in a way incompatible with the firmware requirements.

In D20348#438878, @kib wrote:

Can you do the same for amd64 ?

Tinh Nguyen from Ampere tested and it doesn't seems to make usb working (xhci controller is discovered but nothing more), I've tried on my overdrive in FDT mode and it works.
In acpi mode this doesn't but it doesn't without this patch too, looks like the acpi table is missing info about interrupts, I'll do one more test on the macchiatobin and then commit this.

In D20173#434910, @brd wrote:

I would rather just finish moving these as appropriate.. but I can do that later if you want to get this in sooner.

It missed the phy, so currently this works because u-boot already setup it for us.

Commited as r481798