| --- Log opened Tue Apr 11 00:00:25 2017 | ||
| mithro | shorne_: That is really hard when you don't have a working serial console :-P | 00:05 |
|---|---|---|
| shorne_ | yeah, a lot of times the system boots and I dont get console output | 00:09 |
| shorne_ | I have to look at traces and variables manually | 00:09 |
| shorne_ | this would be helpful | 00:09 |
| shorne_ | but for me curent issue is system works fine in qemu, but is failing on hardware | 00:10 |
| shorne_ | + openocd debugger is a bit buggy | 00:10 |
| shorne_ | so, i am working on sorting those out | 00:10 |
| mithro | shorne_: any idea why zone_sizes_init would be trying to use the same memory location as the page table? -- it seems to be just assuming it can use the last page? | 01:02 |
| mithro | As far as I can see, the page tables are successfully registered in the memblock | 01:12 |
| shorne_ | yes, first memblock, then handed off to main mm | 01:13 |
| mithro | shorne_: So I dump the memblock just before entering zone_sizes_init | 01:17 |
| mithro | http://paste.debian.net/926964/ | 01:17 |
| mithro | I feel like there is something really obvious I'm missing here | 01:38 |
| shorne_ | its hitting the watchpoint in memmap_init_zone() | 01:48 |
| shorne_ | ? | 01:48 |
| shorne_ | but the line it stops on is 'if (!(pfn & (pageblock_nr_pages - 1)))' | 01:48 |
| shorne_ | which is not really writing to anything | 01:49 |
| mithro | shorne_: It's stepped past the actual modification | 01:51 |
| shorne_ | thats what I was thinking | 01:51 |
| shorne_ | what did you set the watchpoint on? | 01:52 |
| mithro | http://paste.debian.net/926967/ | 01:52 |
| shorne_ | you set it on page->lru? or that is what 0xc3ffc016 points to? | 01:55 |
| -!- shorne_ is now known as shorne | 01:55 | |
| mithro | I set it on writing to 0xc3ffc016 | 01:56 |
| mithro | It thinks that page=0xc3ffc000 | 01:56 |
| shorne | oh... i didnt scroll down your last trace enough | 01:57 |
| mithro | But that location is where the ptes have been stored.... | 01:57 |
| mithro | That seems to come from | 01:59 |
| mithro | |5276 struct page *page = pfn_to_page(pfn); | | 01:59 |
| mithro | Where are the "struct page" objects suppose to be stored? | 02:27 |
| shorne | I am nt sure, as you see it says pfn_to_page() | 02:29 |
| shorne | include/asm-generic/memory_model.h | 02:30 |
| shorne | for openrisc | 02:30 |
| shorne | oh... looks like there are a few config options for that | 02:31 |
| shorne | mem_map + ((pfn) - ARCH_PFN_OFFSET) | 02:32 |
| mithro | shorne: Which of the memory models are you using? | 02:32 |
| shorne | I think CONFIG_FLATMEM | 02:35 |
| shorne | let me see | 02:35 |
| shorne | yet | 02:36 |
| shorne | yes | 02:36 |
| shorne | so... where is mem_map supposed to be | 02:37 |
| shorne | https://www.kernel.org/doc/gorman/html/understand/understand005.html | 02:38 |
| shorne | Initialising mem_map ... I remember going through all of this last year when doing memblock stuff | 02:39 |
| shorne | I cant really remember much now :( | 02:39 |
| mithro | (gdb) p mem_map | 02:39 |
| mithro | $22 = (struct page *) 0xc3bb6000 | 02:39 |
| mithro | (gdb) p *mem_map | 02:39 |
| mithro | $23 = {flags = 0, {mapping = 0x0, s_mem = 0x0, compound_mapcount = {counter = 0}}, {index = 0, freelist = 0x0}, {counters = 0, {{_mapcount = {counter = 0}, active = 0, {inuse = 0, objects = 0, frozen = 0}, units = 0}, _refcount = { | 02:39 |
| mithro | counter = 0}}}, {lru = {next = 0x0, prev = 0x0}, pgmap = 0x0, {next = 0x0, pages = 0, pobjects = 0}, callback_head = {next = 0x0, func = 0x0}, {compound_head = 0, compound_dtor = 0, compound_order = 0}}, {private = 0, | 02:39 |
| mithro | slab_cache = 0x0}} | 02:39 |
| shorne | ARCH_PFN_OFFSET (PAGE_OFFSET >> PAGE_SHIFT) | 02:41 |
| shorne | #define PAGE_SHIFT 13 | 02:41 |
| shorne | #define PAGE_OFFSET 0xc0000000 | 02:42 |
| shorne | in your trace, pfn=140032 | 02:43 |
| shorne | and page=0xc3ffc000 | 02:43 |
| shorne | does that make sense then? I guess so | 02:43 |
| shorne | why is pfn 140032 | 02:46 |
| shorne | but still mem_map is empty | 02:47 |
| shorne | I see. maybe is this ARCH_PFN_OFFSET? | 02:47 |
| shorne | you need to include your physical offset there too? | 02:48 |
| mithro | Yeah - I'm wondering that | 02:48 |
| shorne | pfn should start at ARCH_PFN_OFFSET | 02:48 |
| mithro | Looking at arc/microblaze/include/asm/page.h | 02:49 |
| shorne | which is p/x (0xc0000000 >> 13) | 02:49 |
| shorne | $35 = 0x60000 | 02:49 |
| shorne | p/x 140032 | 02:49 |
| shorne | $36 = 0x22300 | 02:50 |
| mithro | https://github.com/mithro/linux/blob/master/arch/microblaze/include/asm/page.h#L165-L172 | 02:51 |
| shorne | if we look at arm they use physical offsets | 02:52 |
| shorne | right | 02:53 |
| shorne | what is pfn, the first time it gets to that function? | 02:53 |
| shorne | i.e. memmap_init_zone | 02:54 |
| shorne | its... there | 02:54 |
| shorne | memmap_init_zone (size=<optimized out>, nid=nid@entry=0, zone=zone@entry=0, start_pfn=<optimized out> | 02:54 |
| mithro | shorne: Yeah, I had to chuck some volatiles onto those values to see them :-P | 02:55 |
| shorne | what is the start_pfn? | 02:57 |
| mithro | http://paste.debian.net/926973/ | 03:04 |
| shorne | that seems 70mb ram? | 03:05 |
| shorne | p 0x2300 << 13 | 03:06 |
| shorne | $38 = 73400320 | 03:06 |
| mithro | 64Megabytes of ram? | 03:06 |
| shorne | what is size? | 03:07 |
| shorne | memmap_init_zone (size=<optimized out> | 03:07 |
| mithro | 0x22000 | 03:07 |
| shorne | shouldnt size be (64mb >> 13) i.e. the amount of pages? | 03:09 |
| shorne | maybe I am completely wrong | 03:09 |
| shorne | i.e. 0x2000 | 03:11 |
| mithro | Yeah - I think something is assuming that pfn's start at zero? | 03:12 |
| shorne | from the pfn_to_page() function it looks like its assumng they start at 0x60000? | 03:15 |
| shorne | but yours is showing 0x20000 | 03:15 |
| mithro | shorne: So setting ARCH_PFN_OFFSET to (PHYSICAL_START >> PAGE_SHIFT) stops the memory trashing, but I'm worried it is just trashing a totally different area | 03:22 |
| shorne | yeah, it doesnt really seam right | 03:24 |
| shorne | mithro: but what its passing for you is PHYSICAL_START >> PAGE_SHIFT | 03:26 |
| shorne | os then it will just index into mem_map | 03:26 |
| mithro | http://paste.debian.net/926979/ | 03:27 |
| shorne | oh... thats pretty much the end | 03:27 |
| mithro | shorne: Yeah - but if it is just happens to be writing to a random unused location in memory now, that will work until something much worse :-P | 03:28 |
| shorne | oh... include/asm-generic/memory_model.h:#define ARCH_PFN_OFFSET (0UL) | 03:28 |
| shorne | thats what is is for openrisc | 03:29 |
| shorne | include/asm-generic/page.h:#define ARCH_PFN_OFFSET (PAGE_OFFSET >> PAGE_SHIFT) | 03:29 |
| shorne | it shouldnt be that one | 03:29 |
| shorne | mithro: so it might not really be random, it would be correctly writing into the mem_map | 03:30 |
| shorne | but... how did you get a gzip image in there without configuring gzip into the kernel? | 03:31 |
| mithro | Tjere osm | 03:31 |
| mithro | Bah | 03:31 |
| mithro | Is that trying to load initrd? | 03:32 |
| shorne | mithro: sorry computer just rebooted for some reason | 03:35 |
| shorne | seemed like a power outage | 03:36 |
| mithro | shorne: Well, with gz compiled in -> http://paste.debian.net/926983/ | 03:36 |
| shorne | hmm, why cant I resolve paste.debian.net now... | 03:39 |
| shorne | did you compile in a initrd? | 03:42 |
| shorne | Usually I do like this... | 03:42 |
| shorne | ake -j5 CROSS_COMPILE=or1k-linux- CONFIG_INITRAMFS_SOURCE="../openrisc/openrisc_os/initramfs ../openrisc/openrisc_os/initramfs.devnodes" | 03:42 |
| mithro | Nope | 03:43 |
| mithro | Just trying with an initrd now | 03:43 |
| mithro | shorne: Need to figure out why it's disabling the litex console | 03:44 |
| shorne | 0.560000] Lite-X UART driver initialized | 03:44 |
| shorne | [ 0.000000] console [tty0] enabled | 03:45 |
| shorne | [ 0.000000] bootconsole [litex0] disabled | 03:45 |
| mithro | shorne: Yeah, why is it doing that :-P | 03:45 |
| shorne | console [ttyS0] enabled | 03:46 |
| shorne | bootconsole [uart0] disabled | 03:46 |
| shorne | I think its normal | 03:46 |
| shorne | it stop "bootconsole" and switches to "console" | 03:46 |
| shorne | above is what I see on qemu normal | 03:47 |
| shorne | mithro: on my x86 box [ 0.000000] console [tty0] enabled | 03:47 |
| shorne | no bootconsole | 03:48 |
| shorne | earlycon: litex0 at MMIO 0xe0001000 (options '115200') | 03:48 |
| mithro | Probably need something like | 03:48 |
| mithro | console=tty0 console=ttyS0 | 03:48 |
| shorne | maybe, did you not get any output on the litex UART? | 03:49 |
| mithro | Not after that | 03:50 |
| shorne | how did you specify litex uart? | 03:50 |
| shorne | mithro: are you using the same devicetree you posted before? | 03:52 |
| mithro | http://paste.debian.net/926987/ | 03:52 |
| mithro | [ 2.050000] Warning: unable to open an initial console. | 03:52 |
| mithro | That is with console=ttySLX0 | 03:53 |
| shorne | passed as args to qemu? or in devicetree? | 03:53 |
| mithro | devicetree | 03:54 |
| shorne | serial0: serial@e0001000 { | 03:55 |
| shorne | compatible = "litex,uart"; | 03:55 |
| shorne | reg = <0xe0000800 0x100>; | 03:55 |
| shorne | bootargs = "earlycon=litex,0xe0001000,115200"; | 03:56 |
| shorne | you have 2 addresses here? | 03:56 |
| shorne | mithro: in https://github.com/mithro/linux/blob/master/arch/openrisc/boot/dts/or1klitex.dts | 03:56 |
| shorne | 0xe0000800 vs 0xe0001000 | 03:57 |
| mithro | Fixed - but there is something wrong with it registering the tty from what I can see | 04:12 |
| mithro | I have to run, thanks for all your help! | 04:12 |
| mithro | shorne: Will try and clean up the patches - run them by someone who knows about this stuff and then send them to you | 04:12 |
| shorne | mithro: cool, have a good evening | 04:13 |
| olofk_web | mithro, shorne : Reading last week's backlog. Sounds like you've made a lot of progress. Great work! | 04:44 |
| olofk_web | Saw the note about single stepping in OpenOCD. I've been getting the impression that this fails for me too | 04:45 |
| olofk_web | I'll take a look at your fix and see if that changes anything | 04:45 |
| shorne | olofk_web: I got it working | 04:45 |
| olofk_web | shorne: Awesome! | 04:45 |
| shorne | but not sure if its working on my latest changes of adb_debug_if | 04:45 |
| shorne | maybe I broken it when I changed the configuration patches I sent you | 04:46 |
| olofk_web | I made some changes to adv_debug_sys recently too, FYI | 04:46 |
| shorne | ok, well the change on openocd side is really simple | 04:46 |
| olofk_web | hmm... your changes to adv_debug_sys shouldn't have affected any funcitonality, right? | 04:46 |
| shorne | olofk, they shouldnt have as far as I could tell. but maybe I made a mistake? | 04:48 |
| shorne | I can try with and without my patches | 04:48 |
| olofk_web | cool | 04:49 |
| shorne | but my patch for openocd is... https://github.com/stffrdhrn/openocd/commit/6312596cd73c2b7b8a8949a9de814098f8fdf77f | 04:50 |
| shorne | basically, if I am in gdb, and just do 'ni' stepping | 04:50 |
| shorne | it wont work unless there is a breakpoint set somewhere | 04:50 |
| shorne | I guess thats usually the case.. but not always | 04:51 |
| olofk_web | Aha. Interesting. I haven't used gdb in a while. Uses openocd directly, but I guess it's the same problem there? | 05:02 |
| shorne | yes, I guess so | 05:02 |
| shorne | single stepping uses the same logic | 05:02 |
| olofk_web | Has anyone seen this? https://github.com/openrisc/community-wiki/issues/2#issuecomment-291783466 | 05:45 |
| olofk_web | Don't know if it's a bug or just some drive-by comment | 05:45 |
| shorne | olofk_web: strange place to put a comment, wbx might know something about it | 11:17 |
| shorne | it mentions uclibc, which he has brought back to life | 11:18 |
| shorne | I put a comment on it | 11:21 |
| wbx | shorne_: i am sure this does not happen with uClibc-ng. there are some gcc options generating an abort() call in some situations. | 12:41 |
| mor1kx | [mor1kx] wallento created traceexec-jump (+1 new commit): https://github.com/openrisc/mor1kx/commit/1dea99f0dc32 | 13:59 |
| mor1kx | mor1kx/traceexec-jump 1dea99f Stefan Wallentowitz: Extend execution traceport with jumps... | 13:59 |
| mor1kx | [mor1kx] wallento opened pull request #50: Extend execution traceport with jumps (master...traceexec-jump) https://github.com/openrisc/mor1kx/pull/50 | 13:59 |
| wallento | stekern, shorne_, can you have a look at the PR | 14:15 |
| wallento | it should not affect the normal core usage and OpTiMSoC can finally switch to upstream mor1kx | 14:15 |
| wallento | I would fix all linter warnings in return :) | 14:16 |
| shorne_ | wallento: it looks reasonable, what does this traceport interface with? I could search a bit... but what I have used for debugging is adv debug-unit stuff. | 19:16 |
| shorne_ | Ill have more look on the train into work today | 19:16 |
| -!- psychotr1pe is now known as psychotrope | 22:12 | |
| stekern | wallento: lgtm | 23:00 |
| --- Log closed Wed Apr 12 00:00:26 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!