Thread (59 messages) 59 messages, 7 authors, 2017-11-15

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 0000ff02
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help