IRC logs for #openrisc Tuesday, 2017-04-11

--- Log opened Tue Apr 11 00:00:25 2017
mithroshorne_: That is really hard when you don't have a working serial console :-P00:05
shorne_yeah, a lot of times the system boots and I dont get console output00:09
shorne_I have to look at traces and variables manually00:09
shorne_this would be helpful00:09
shorne_but for me curent issue is system works fine in qemu, but is failing on hardware00:10
shorne_+ openocd debugger is a bit buggy00:10
shorne_so, i am working on sorting those out00:10
mithroshorne_: 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
mithroAs far as I can see, the page tables are successfully registered in the memblock01:12
shorne_yes, first memblock, then handed off to main mm01:13
mithroshorne_: So I dump the memblock just before entering zone_sizes_init01:17
mithroI feel like there is something really obvious I'm missing here01:38
shorne_its hitting the watchpoint in memmap_init_zone()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 anything01:49
mithroshorne_: It's stepped past the actual modification01:51
shorne_thats what I was thinking01:51
shorne_what did you set the watchpoint on?01:52
shorne_you set it on page->lru?  or that is what 0xc3ffc016 points to?01:55
-!- shorne_ is now known as shorne01:55
mithroI set it on writing to 0xc3ffc01601:56
mithroIt thinks that page=0xc3ffc00001:56
shorneoh... i didnt scroll down your last trace enough01:57
mithroBut that location is where the ptes have been stored....01:57
mithroThat seems to come from01:59
mithro   |5276                            struct page *page = pfn_to_page(pfn);                                                                                                                                                                     |01:59
mithroWhere are the "struct page" objects suppose to be stored?02:27
shorneI am nt sure, as you see it says pfn_to_page()02:29
shornefor openrisc02:30
shorneoh... looks like there are a few config options for that02:31
shornemem_map + ((pfn) - ARCH_PFN_OFFSET)02:32
mithroshorne: Which of the memory models are you using?02:32
shorneI think CONFIG_FLATMEM02:35
shornelet me see02:35
shorneso... where is mem_map supposed to be02:37
shorneInitialising mem_map ... I remember going through all of this last year when doing memblock stuff02:39
shorneI cant really remember much now :(02:39
mithro(gdb) p mem_map02:39
mithro$22 = (struct page *) 0xc3bb600002:39
mithro(gdb) p *mem_map02: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#define PAGE_SHIFT      1302:41
shorne#define PAGE_OFFSET     0xc000000002:42
shornein your trace, pfn=14003202:43
shorneand page=0xc3ffc00002:43
shornedoes that make sense then? I guess so02:43
shornewhy is pfn 14003202:46
shornebut still mem_map is empty02:47
shorneI see.  maybe is this ARCH_PFN_OFFSET?02:47
shorneyou need to include your physical offset there too?02:48
mithroYeah - I'm wondering that02:48
shornepfn should start at ARCH_PFN_OFFSET02:48
mithroLooking at arc/microblaze/include/asm/page.h02:49
shornewhich is p/x  (0xc0000000 >> 13)02:49
shorne$35 = 0x6000002:49
shornep/x 14003202:49
shorne$36 = 0x2230002:50
shorneif we look at arm they use physical offsets02:52
shornewhat is pfn, the first time it gets to that function?02:53
shornei.e. memmap_init_zone02:54
shorneits... there02:54
shornememmap_init_zone (size=<optimized out>, nid=nid@entry=0, zone=zone@entry=0, start_pfn=<optimized out>02:54
mithroshorne: Yeah, I had to chuck some volatiles onto those values to see them :-P02:55
shornewhat is the start_pfn?02:57
shornethat seems 70mb ram?03:05
shornep 0x2300 << 1303:06
shorne$38 = 7340032003:06
mithro64Megabytes of ram?03:06
shornewhat is size?03:07
shornememmap_init_zone (size=<optimized out>03:07
shorneshouldnt size be (64mb >> 13) i.e. the amount of pages?03:09
shornemaybe I am completely wrong03:09
shornei.e. 0x200003:11
mithroYeah - I think something is assuming that pfn's start at zero?03:12
shornefrom the pfn_to_page() function it looks like its assumng they start at 0x60000?03:15
shornebut yours is showing 0x2000003:15
mithroshorne: 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 area03:22
shorneyeah, it doesnt really seam right03:24
shornemithro: but what its passing for you is PHYSICAL_START >> PAGE_SHIFT03:26
shorneos then it will just index into mem_map03:26
shorneoh... thats pretty much the end03:27
mithroshorne: 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 :-P03:28
shorneoh... include/asm-generic/memory_model.h:#define ARCH_PFN_OFFSET              (0UL)03:28
shornethats what is is for openrisc03:29
shorneinclude/asm-generic/page.h:#define ARCH_PFN_OFFSET              (PAGE_OFFSET >> PAGE_SHIFT)03:29
shorneit shouldnt be that one03:29
shornemithro: so it might not really be random, it would be correctly writing into the mem_map03:30
shornebut... how did you get a gzip image in there without configuring gzip into the kernel?03:31
mithroTjere osm03:31
mithroIs that trying to load initrd?03:32
shornemithro: sorry computer just rebooted for some reason03:35
shorneseemed like a power outage03:36
mithroshorne: Well, with gz compiled in ->
shornehmm, why cant I resolve now...03:39
shornedid you compile in a initrd?03:42
shorneUsually I do like this...03:42
shorneake -j5 CROSS_COMPILE=or1k-linux- CONFIG_INITRAMFS_SOURCE="../openrisc/openrisc_os/initramfs ../openrisc/openrisc_os/initramfs.devnodes"03:42
mithroJust trying with an initrd now03:43
mithroshorne: Need to figure out why it's disabling the litex console03:44
shorne0.560000] Lite-X UART driver initialized03:44
shorne[    0.000000] console [tty0] enabled03:45
shorne[    0.000000] bootconsole [litex0] disabled03:45
mithroshorne: Yeah, why is it doing that :-P03:45
shorneconsole [ttyS0] enabled03:46
shornebootconsole [uart0] disabled03:46
shorneI think its normal03:46
shorneit stop "bootconsole" and switches to "console"03:46
shorneabove is what I see on qemu normal03:47
shornemithro: on my x86 box [    0.000000] console [tty0] enabled03:47
shorneno bootconsole03:48
shorneearlycon: litex0 at MMIO 0xe0001000 (options '115200')03:48
mithroProbably need something like03:48
mithroconsole=tty0 console=ttyS003:48
shornemaybe, did you not get any output on the litex UART?03:49
mithroNot after that03:50
shornehow did you specify litex uart?03:50
shornemithro: are you using the same devicetree you posted before?03:52
mithro[    2.050000] Warning: unable to open an initial console.03:52
mithroThat is with console=ttySLX003:53
shornepassed as args to qemu? or in devicetree?03:53
shorneserial0: serial@e0001000 {03:55
shornecompatible = "litex,uart";03:55
shornereg = <0xe0000800 0x100>;03:55
shornebootargs = "earlycon=litex,0xe0001000,115200";03:56
shorneyou have 2 addresses here?03:56
shornemithro: in
shorne0xe0000800 vs 0xe000100003:57
mithroFixed - but there is something wrong with it registering the tty from what I can see04:12
mithroI have to run, thanks for all your help!04:12
mithroshorne: Will try and clean up the patches - run them by someone who knows about this stuff and then send them to you04:12
shornemithro: cool, have a good evening04:13
olofk_webmithro, shorne : Reading last week's backlog. Sounds like you've made a lot of progress. Great work!04:44
olofk_webSaw the note about single stepping in OpenOCD. I've been getting the impression that this fails for me too04:45
olofk_webI'll take a look at your fix and see if that changes anything04:45
shorneolofk_web: I got it working04:45
olofk_webshorne: Awesome!04:45
shornebut not sure if its working on my latest changes of adb_debug_if04:45
shornemaybe I broken it when I changed the configuration patches I sent you04:46
olofk_webI made some changes to adv_debug_sys recently too, FYI04:46
shorneok, well the change on openocd side is really simple04:46
olofk_webhmm... your changes to adv_debug_sys shouldn't have affected any funcitonality, right?04:46
shorneolofk, they shouldnt have as far as I could tell. but maybe I made a mistake?04:48
shorneI can try with and without my patches04:48
shornebut my patch for openocd is...
shornebasically, if I am in gdb, and just do 'ni' stepping04:50
shorneit wont work unless there is a breakpoint set somewhere04:50
shorneI guess thats usually the case.. but not always04:51
olofk_webAha. Interesting. I haven't used gdb in a while. Uses openocd directly, but I guess it's the same problem there?05:02
shorneyes, I guess so05:02
shornesingle stepping uses the same logic05:02
olofk_webHas anyone seen this?
olofk_webDon't know if it's a bug or just some drive-by comment05:45
shorneolofk_web: strange place to put a comment, wbx might know something about it11:17
shorneit mentions uclibc, which he has brought back to life11:18
shorneI put a comment on it11:21
wbxshorne_: 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):
mor1kxmor1kx/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)
wallentostekern, shorne_, can you have a look at the PR14:15
wallentoit should not affect the normal core usage and OpTiMSoC can finally switch to upstream mor1kx14:15
wallentoI 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 today19:16
-!- psychotr1pe is now known as psychotrope22:12
stekernwallento: lgtm23:00
--- Log closed Wed Apr 12 00:00:26 2017

Generated by 2.15.2 by Marius Gedminas - find it at!