> From: Simon Glass <s...@chromium.org> > Date: Mon, 23 Oct 2023 00:04:14 -0700 > > Hi Caleb, > > On Sat, 21 Oct 2023 at 01:43, Caleb Connolly <caleb.conno...@linaro.org> > wrote: > > > > Hi Simon, > > > > On 21/10/2023 01:45, Simon Glass wrote: > > > U-Boot typically sets up its malloc() pool near the top of memory. On > > > ARM64 systems this can result in an SMBIOS table above 4GB which is > > > not supported by SMBIOSv2. > > > > > > Work around this problem by providing a new option to choose an address > > > just below 4GB, if needed. > > I may well be missing something here, but I don't quite understand the > > justification behind the original patch [1] which caused this regression. > > > > I'm currently preparing support for a few different Qualcomm boards > > which have different memory layouts, so far it's been possible to avoid > > having any fixed addresses, so the same u-boot image can be used on all > > of them (with just a different DTB). > > What sort of memory layout do you have? I could enhance the patch to > find the top of a memory bank below 4GB, perhaps? E.g. see the > 'bdinfo' command. > > > > > As I mentioned before, efi_allocate_pages() seems to work fine from > > install_smbios_table(), I haven't delved into the code too much but I > > wonder if this could be an acceptable solution? > > Unfortunately that function is EFI-specific. The function can only be > called once EFI is inited. We only want to do that if booting with > EFI. > > The tables are written at the start of U-Boot, partly because that is > how it is done on x86 and partly so the 'acpi' command actually works. > > The EFI code ended up writing a separate set of tables, which is of > course not correct. > > I did look at creating an API in U-Boot to alloc memory below 4GB but > then decided that for just this one use case it might not be worth it. > > > > > Barring that, could we use an environment variable to pass this address > > in? Although I think that might not be a very desirable solution. > > > > I appreciate you taking the time to prepare this patch and CC me. If > > nobody else objects to this patch then I'd prefer to avoid blocking it. > > In either case, I'd greatly appreciate any input on the above > > suggestions so that I can implement a solution for my boards. > > I would like it to be automatic. I assumed on ARM64 that there is > memory available at 3.99GB if U-Boot has relocated to above 4GB, but > as above I could make this more clever.
There is absolutely no guarantee that arm64 machines have memory below 4GB. Examples of SoCs that have no memory below 4GB are AMD's Opteron A1100 SoC and all the recent Apple SoCs. Cheers, Mark
