From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Fri, 14 May 2021 08:10:47 +0200 Subject: [PATCH 1/1] sandbox: ensure that state->ram_buf is in low memory In-Reply-To: References: <20210511190316.29710-1-xypron.glpk@gmx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 5/14/21 1:56 AM, Simon Glass wrote: > Hi Heinrich, > > On Thu, 13 May 2021 at 08:53, Heinrich Schuchardt wrote: >> >> On 5/13/21 4:36 PM, Simon Glass wrote: >>> Hi Heinrich, >>> >>> On Wed, 12 May 2021 at 15:28, Heinrich Schuchardt wrote: >>>> >>>> Am 12. Mai 2021 18:01:17 MESZ schrieb Simon Glass : >>>>> Hi Heinrich, >>>>> >>>>> On Tue, 11 May 2021 at 13:03, Heinrich Schuchardt >>>>> wrote: >>>>>> >>>>>> Addresses in state->ram_buf must be in the low 4 GiB of the address >>>>> space. >>>>>> Otherwise we cannot correctly fill SMBIOS tables. This shows up in >>>>> warnings >>>>>> like: >>>>>> >>>>>> WARNING: SMBIOS table_address overflow 7f752735e020 >>>>> >>>>> This sounds like a bug in the smbios-table code. For sandbox it should >>>>> perhaps use addresses instead of pointers. >>>>> >>>>> I think that code (that I unfortunately wrote) was an expeditious way >>>>> of getting it running, but is not correct. >>>> >>>> The field you are filling is only 32bit wide. I wonder how that table is meant to work on systems where the lowest memory address is above 4 GiB. Such ARMv8 systems exist. >>> >>> map_to_sysmem() will give you a 32-bit wide address. Yes SMBIOS is >>> legacy and designed for 4GB. >> >> I know map_to_sysmem(). But you wrote in lib/smbios.c:487: >> >> /* >> * We must use a pointer here so things work correctly on sandbox. The >> * user of this table is not aware of the mapping of addresses to >> * sandbox's DRAM buffer. >> */ >> >> For testing you could start a binary with command 'bootefi' or 'booti' >> and that binary would analyze the table. So yes, your comment holds true >> and you must not use map_to_sysmem() here. > > Yes, that is a good point. Perhaps I was not mad when I wrote that. > What is using the tables on sandbox? The UEFI shell has a command smbiosview to display the SMBIOS table. With the current U-Boot sandbox it crashes. I do not know what the cause is: FS0:\> smbiosview Segmentation violation pc = 0x7fb0df88d17e, pc_reloc = 0x7fb0cf88d17e UEFI image [0x00007fb0df836000:0x00007fb0df920c5f] pc=0x5717e '/Shell_x64.efi' Here is some of the output for my laptop: SMBIOS Entry Point Structure: Anchor String: _SM_ EPS Checksum: 0xEE Entry Point Len: 31 Version: 3.1 Number of Structures: 62 Max Struct size: 145 Table Address: 0x986E9000 Table Length: 2316 Entry Point revision: 0x0 SMBIOS BCD Revision: 0x31 Inter Anchor: _DMI_ Inter Checksum: 0x4E Formatted Area: 00000000: 00 00 00 00 00 *.....* ========================================================= Query Structure, conditions are: QueryType = Random QueryHandle = Random ShowType = SHOW_DETAIL Enter to continue, :q to exit, :[0-3] to change mode, /? for help $ ========================================================= Type=18, Handle=0x0 Dump Structure as: Index=0,Length=0x19,Addr=0x986E9019 00000000: 12 17 00 00 03 02 02 00-00 00 00 00 00 00 80 00 *................* 00000010: 00 00 80 00 00 00 80 00-00 *.........* Enter to continue, :q to exit, :[0-3] to change mode, /? for help $Structure Type: 32-bit Memory Error Information Format part Len : 23 Structure Handle: 0 32-bit Memory Error Information - Type: OK Memory Error - Error granularity: Unknown Memory Error - Error Operation: Unknown VendorSyndrome: 0x0 MemoryArrayErrorAddress: 0x80000000 DeviceErrorAddress: 0x80000000 ErrorResolution: 0x80000000 Best regards Heinrich