n900 in next-20170901
From: Joonsoo Kim <hidden>
Date: 2017-09-13 07:53:55
Also in:
linux-omap, lkml
On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote:
* Joonsoo Kim [off-list ref] [170907 00:30]:quoted
On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote:quoted
Hi, * Joonsoo Kim [off-list ref] [170905 16:32]:quoted
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.quoted
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.quoted
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 0000ff02quoted
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.
Sorry for late response. I tried to emulate beagle board by using QEMU and now I find the way and it works. However, it doesn't call omap3_save_secure_ram_context() due to different omap_type(). And, even if I call it forcibly, the system dies with prefetch abort regardless of commit 9caf25f996e8. Could you let me know the better way to test your situation? Anyway, could you test linux-next with 'CONFIG_HIGHMEM = n'? I'd like to know if the issue is related to the change that all CMA memory is managed like as highmem. Thanks.