Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755527AbdIGQQ5 (ORCPT ); Thu, 7 Sep 2017 12:16:57 -0400 Received: from muru.com ([72.249.23.125]:40036 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754958AbdIGQQz (ORCPT ); Thu, 7 Sep 2017 12:16:55 -0400 Date: Thu, 7 Sep 2017 09:16:51 -0700 From: Tony Lindgren To: Joonsoo Kim Cc: Pavel Machek , pali.rohar@gmail.com, sre@kernel.org, kernel list , linux-arm-kernel , linux-omap@vger.kernel.org, khilman@kernel.org, aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com, patrikbachan@gmail.com, serge@hallyn.com, abcloriens@gmail.com, "Aneesh Kumar K.V" , Vlastimil Babka , Andrew Morton , Stephen Rothwell , Russell King Subject: Re: n900 in next-20170901 Message-ID: <20170907161650.GP5024@atomide.com> References: <20170903203737.GA12475@amd> <20170905201314.GE5024@atomide.com> <20170905233241.GA19231@js1304-P5Q-DELUXE> <20170906133057.GH5024@atomide.com> <20170907073038.GA2111@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170907073038.GA2111@js1304-P5Q-DELUXE> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1588 Lines: 44 * Joonsoo Kim [170907 00:30]: > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Joonsoo Kim [170905 16:32]: > > > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > > > CONFIG_HAVE_MEMBLOCK_NODE_MAP=y. In this case, the MOVABLE_ZONE can > > > be *!highmem*. Could you check that your configuration have above > > > options? > > > > CONFIG_HIGHMEM is set yeah. > > > > > And, could you check that following patch works for you? > > > > Does not seem to help, tried against next with just 9caf25f996e8 > > revert and also with 9caf25f996e8. > > Oops. I misunderstood your problem. Could you test with > CONFIG_DEBUG_VIRTUAL? Sure. > After commit 9caf25f996e8, user for CMA memory should use to check > PageHighmem in order to get proper virtual address of the page. If > someone doesn't use it, it is possible to use wrong virtual address > and it then causes the use of wrong physical address. > CONFIG_DEBUG_VIRTUAL would catch this case. OK, no extra output of current next with CONFIG_DEBUG_VIRTUAL=y. Booting of n900 hangs with just the same error: save_secure_sram() returns 0000ff02 > If it doesn't help, is there a way to test n900 configuration in QEMU? I doubt that QEMU n900 boots in secure mode but instead shows the SoC as general purpose SoC. If so, you'd have to patch the omap3_save_secure_ram_context() to attempt to save secure RAM context in all cases. If that works then debugging with any omap3 board like beagleboard in QEMU should work. Regards, Tony