On Fri, Jun 07, 2019 at 10:21:31AM +0200, Jan Stary wrote: > On Jun 06 14:43:59, mark.kette...@xs4all.nl wrote: > > > Date: Thu, 6 Jun 2019 14:00:13 +0200 > > > From: Jan Stary <h...@stare.cz> > > > > > > On May 25 02:34:36, i...@ce.gl wrote: > > > > I suspect this might be DTB related, I will take a look sometime soon. > > > > > > It is still there in current. > > > > We now use the EFI memory map to determine what memory is available. > > It now correctly excludes memory regions excluded for things like > > framebuffers and EFI runtime services. In addition to that, the code > > that processes the EFI memory map is fairly conservative and does not > > consider the memory that is in use by U-Boot as "free". We probably > > should change that, but in that case we need to be careful not to > > overwrite data passed by U-Boot to the kernel and the kernel itself. > > Thanks for the insight. > > Is this related to these boot lines? > > > > type 0x7 pa 0x82000000 va 0x80000000 pages 0x6000 attr 0x8 > > > type 0x4 pa 0x88000000 va 0x88000000 pages 0xa attr 0x8 > > > type 0x7 pa 0x8800b000 va 0x80000000 pages 0x147af attr 0x8 > > > type 0x2 pa 0x9c7ba000 va 0x9c7ba000 pages 0x4 attr 0x8 > > > type 0x2 pa 0x9c7be000 va 0x9c7be000 pages 0x4 attr 0x8 > > I didn't see those with the previous kernels on this machine.
Yes, exactly. We print out the EFI memory map on bootup, so you seeing this means we do parse and use the supplied EFI memory map. Patrick
