IRC logs for #openrisc Saturday, 2017-04-08

--- Log opened Sat Apr 08 00:00:20 2017
mithrogdb doesn't really like this whole virtual/physical addressing stuff from what I can tel00:23
mithrofutarisIRCcloud: Well, I've gotten the boot process as far as enabling the mmu00:34
mithroThen it hits ITLB miss exception and jumps to the wrong address :-P00:36
mithrofutarisIRCcloud: running to get some lunch01:00
mithroBe back in 30 minutes01:00
mithroI think I've gotten the mmu init working01:00
mithroI'm guessing that nobody has used EVBAR (Exception vector base address register) in qemu before - because it doesn't look like it's implemented at all01:29
shornemithro: the virtual/physical stuff you can doing via qemu?01:29
mithroshorne: Hrm?01:30
shorneI have a patch for that01:30
shorneI mean, you said "gdb doesn't really like this whole virtual/physical addressing stuff from what I can tel"01:30
shorneif you are connecting gdb to qemu, then it might be related to the patch I posted01:30
shornebasically gdb sends the address to qemu, and qemu needs to read the memory, currently it assumes a virtual address01:31
shorneI made a change to fallback and see if the address is physical01:31
mithroshorne: That is definitely possible01:32
mithroI need to rebase our stuff onto a less ancient qemu01:32
shornemithro: ah, ITLB jumps to wrong address, which one does it jump to?01:33
mithroshorne: It jumps to the 0xa0001:34
mithroWhich has nothing there :-P01:34
mithroIt appears that the only reason our firmware boots is that we are not using interrupts/exceptions anywhere01:34
shorneI gess, 0xa0001:35
mithroshorne: Yeah - I patched qemu to jump to the right address temporarily, just looking at if I can just use EVBAR01:35
mithroHrm... EVBAR doesn't seem to exist...01:37
shorneoh, yeah lots of features are not implemented in qemu, I had to implement some to get stuff working01:37
shorneits usually been pretty easy01:38
mithroHrm, we might not be enabling EVBAR on hardware anyway...01:38
mithroshorne: yeah, looks pretty easy to implement01:40
* mithro goes on a yak shave01:46
mithroshorne: Any idea where gen_helper_mfspr comes from in qemu?01:58
mithroI don't quite get how l.mfspr works?02:12
mithroThe contents of the special register, defined by contents of general-purpose rA logically ORed with immediate value, are moved into general-purpose register rD.02:15
mithroHow do I figure out the "address" of a spr?02:15
mithroAhh, there seems to be a table in that doc shorne linked02:22
shornemithro: did you find get_helper_mfspr?02:23
mithroshorne: I found something in sys_helper which looks like what is being used?02:24
shornethere is02:24
shorneDEF_HELPER_FLAGS_4(mfspr, TCG_CALL_NO_WG, tl, env, tl, tl, tl)02:25
shorneand sys_helper.c02:25
shornethere are two sides in qemu02:25
shornethe translate/generator sdie and the executor side02:25
shornehelper.h creates all the gen_helper*() functions02:26
shornesys_helper.c has the implementions02:26
shorneall you should have to touch is sys_helper.c02:27
shorneand maybe cpu.h to add the register02:27
mithroI'm now trying to actually use it in code somewhere :-P02:28
shorneok, so you got it :)02:28
shorneyeah, it look right to me02:33
shorneI added some minor comments02:33
mithroshorne: I think I want this code02:33
shorneI think you dont need the second line02:36
shorneand just 3rd line02:36
shornel.mtspr r0,r6,SPR_EVBAR02:37
mithroI understand how it is used now02:37
mithroI was thinking that the immediate value was ORed with the data being written02:38
shorneits ored with the spr address offset register02:39
shornebut I guess you get that now02:40
mithroHrm, the assembler doesn't seem to like SPR_EVBAR - is it called something else?02:43
shorneI think its just a variable in openrisc/include/spr..02:44
mithroYeah, just found that02:44
mithroIt's not set there02:44
mithroWell, it looks like it hit boot_dtlb_miss_handler and boot_itlb_miss_handler a couple of times before jumping to 0x0000000002:49
shorneah :(02:51
shornebut looks like vector offset is working02:51
shornewhich is good02:51
shornegot to go again02:52
mithroException 0x9 - vectoring to 0x4000090002:54
mithroException 0xa - vectoring to 0x40000a0002:54
mithroException 0xa - vectoring to 0x40000a0002:54
mithro /* set up DTLB with no translation for EA <= 0xbfffffff */03:01
mithroset up ITLB with no translation for EA <= 0x0fffffff03:02
mithroThat I don't think will work for us?03:02
mithroAs 0x40000000 > 0x0fffffff03:04
shornemithro: isnt that setup due to the tophys() call?03:24
mithroThe address this seems to be translating is03:25
mithrotophys just translated that to 0xc032611403:26
mithroThis seems the wrong way around?03:27
mithroIt just took a physical address and translated it to a virtual one?03:27
shornehmm, seems wrong03:28
mithroIf I understand this, previously as the kernel was initially below 0x0fffffff we didn't translate the address and just set a direct mapping?03:28
mithroWhat does EA stand for?03:29
mithroAhh Effective address03:29
shorneyeah, it should be that03:29
shornebut it seems like translating 0x40326114 to 0xc0326114 is wrong03:30
mithroso why does the boot_itlb_miss_handler doing any translation?03:30
shornelet me see, maybe you are right03:31
shornegive me a second03:31
shornehea, right if address is below 0x0fffffff, its direct translation03:34
shorneyour address is 0x40326114, is should not be translated03:34
shornebut its not below 0x0fffffff, so it gest mapped03:34
mithroWhat is above 0x0fffffff that should get mapped?03:36
mithroshorne: Well, it just set up the data page table and I'm hitting the bug your patch fixes03:37
shornewell, thats all of the sybols like starting with 0xc0000000003:37
shorneI guess you could hack it with below 0x5fffffff03:38
shornethe gdb/qemu bug?03:38
shornei.e. between 0x40000000 and 0x60000000 your initial kernel init code is there03:39
shornebut thats a bit of a hack, there should be a better way03:39
shorneor just 0x4fffffff03:39
mithroshorne: I just added the PHYSICAL_START to it for now03:42
shornethe better way is as the comment says, move all code that is run with mmu enabled into entry.S03:44
shornebut yeah, for now just adding that offset would be good03:44
mithroWhich code is run with the mmu enable?03:44
shornei.e. when mmu is turned on03:45
shorneits running at i.e. 0x0003345003:45
shornethe next instrcution will cause itlb miss03:45
shorneso 0x00030000 page needs to get added to tlb 0x00030000 0x0003000003:46
shorneso no translation03:46
mithroOh, yeah I understand03:46
shornebut its a bit tricky, I would have to look at how other archs do it03:50
mithro"load magic from fdt into r3"03:51
mithromy r25 seems to be empty03:51
mithroI'm guessing because I didn't pass any kernel parameters03:51
mithroThe fdt is embedded inside the kernel?03:52
shorneYes, but fdt is usually built into the kernel03:52
shorneyes, so empty is good03:52
shorneas long as you do have it built in03:52
shorneit supports external fdt (device tree file)03:53
shorneopenrisc doesnt support external initrd yet though... I am thinking I want to do that03:53
mithroThe DTLB has a similar hack regarding the memory addresses?03:55
shorneyeah, but it says 0xbfffffff03:55
mithroAhh, I had a miss because it tried to load data pointed at by r25 which as address 003:56
shorneI guess that should already work for you?03:56
mithroLooks like I'm about to jump to a virtual address03:58
mithror24 == 0xc032d0bc03:58
mithrol.jalr r2403:58
mithrowhat s a link register?03:59
futarisIRCcloudSorry. Been away for the past 5 hours or so. FDT is in the kernel for openrisc. qemu doesn't pass on the args to the kernel, the args always come from the fdt.04:00
shorneits the return address04:00
shorneits r9 if I remember correctly04:00
mithrofutarisIRCcloud: Well, if you get that serial port driver working, I'm getting closer to having this kernel booting04:00
shornei.e. it will jump to *r24,  then put the next address (after jump in r9(04:00
shornewhen you do return, it will jump to r904:01
futarisIRCcloudOther archs usually set PHYSICAL_START. IIRC, that's what I had to do, when we had RAM at a different address on an armv4t.04:01
futarisIRCcloudBut usually that would come from the bootloader (redboot, u-boot, etc)04:01
futarisIRCcloudI will just try to get serial output working now.04:01
shornefutarisIRCcloud: yeah, I think openrisc has to get patched to handle physical start other than 0x0 (what mithro is working on)04:02
mithrowelp, it seems like it just translated the output correctly...04:02
shorneit will be good to look at other archs to figure out the best way04:02
mithro0xc032d0bc in or32_early_setup ()04:03
shornemithro: good, I am looking at arch/openrisc/mm/init.c and arch/openrisc/mm/fault.c04:03
futarisIRCcloudWe shouldn't need to have SERIAL_EARLYCON / SERIAL_UART_LITEX_CONSOLE ... So I'll get late console working first.04:03
shornein a few places they either check if the interrupt vectore was i.e. 0x50004:04
shorneor they actually write core to switch the itlb routine to the more advanced one04:05
shorneanyway... that might need to be updated to support the 0x40000000 offset too04:05
shorneI guess you will get there04:05
mithroWelp, it tried to read the fdt at 0x0 and QEMU said nope...04:07
mithroI'm in the printk function now...04:20
mithroThis sure does use a lot of instructions to print something....04:25
futarisIRCcloudA lot of layers between printk and character output.04:29
mithroshorne: That mask in DTLB is actually PAGE_OFFSET-104:34
mithroBreakpoint 2, printk (fmt=0xc02d7e78 "KERNEL: Illegal instruction (SIGILL) 0x%.8lx\n") at kernel/printk/printk.c:183704:41
mithroI need to figure out how to print a va_list in gdb...04:46
shornewhat does p *0xc030be24 show?04:54
mithroIt seems to be happening at04:56
mithro#0  0xc032db68 in set_bit (addr=<optimized out>, nr=<optimized out>) at ./arch/openrisc/include/asm/bitops/atomic.h:1804:56
mithroLoad Single Word Atomic05:00
mithroI don't see qemu having support for that instruction?05:05
mithroshorne: Has Linux been booted on qemu?05:08
futarisIRCcloudI can boot linux or1ksim on your qemu.05:09
mithrofutarisIRCcloud: I wonder why....05:09
mithro    When those instructions are not available emulation is provided.05:10
futarisIRCcloudIt's possible that the compiler is generating a new instruction that qemu doesn't currently support, because of the different memory layout.05:10
mithrogdb doesn't like me at the moment05:23
mithro../../gdb/or1k-tdep.c:1651: internal-error: or1k_frame_cache: Assertion `or1k_analyse_l_addi (inst, &rd, &ra, &simm) && (OR1K_FP_REGNUM == rd) && (OR1K_SP_REGNUM == ra) && (simm == frame_size)' failed.05:23
mithroThis is weird05:26
mithro#0  do_illegal_instruction (regs=0xc030bec4 <init_thread_union+7876>, address=16404) at arch/openrisc/kernel/traps.c:50705:26
mithro(gdb) p/x address05:26
mithro$1 = 0x401405:26
futarisIRCcloudJust checking /proc/interrupts. Nothing is on IRQ 0 in or1ksim usually.05:26
shornemithro: I boot linux on qemu every linux build05:27
shorneI mean after every linux built05:27
shornethe l.lwa you need either05:27
shorne1. a new version of qemu (I and Richard patched in 2.9)05:28
shorne2. a new version of the kernel (maybe 4.10?) We added l.lwa emulation to the kernel05:28
mithroYeah, I have l.lwa emulation in the kernel05:28
mithroThis appears to be something else05:28
shorneqemu illegal instruction emulation was broken05:29
shorneI patched that too05:29
mithroshorne: What branch should I be looking at on your qemu repo?05:30
shorneeverything is upstream05:30
shornemy repo just has some stuff for gdb debug and multicore05:30
shornejust or1k-next has those05:30
shornebut the emulation fix is upstream05:31
shorneyou can probably just patchyourself05:31
shorneits a very small change05:31
mithroshorne: Missing that patch would explain why my address is 0x401405:31
shornemithro: also for the gdb error "internal-error or1k_frame_cache"05:32
shorneI fixed in gdb too :)05:32
shornebut all my changes are squashed into this....
shornethe gist of the fix is just to remove that assert, but you can also just take my gdb repo05:34
mithroI wonder how it's working for futarisIRCcloud?05:35
futarisIRCcloudI've got buildroot patches.05:35
mithroshorne: Is that stuff in openrisc/binutils-gdb.git too?05:36
mithroAhh, I'm just using upstream Linux kernel05:38
mithroshorne: So I want or1k-upstream branch of your binutils-gdb repo?05:38
shornemithro: its not in the openrisc/binutils-gdb... I do too many rebases and really removed a bunch of code05:38
shorne(as part of gdb upstreaming reviews) once its all done I will update openrisc/binutils-gdb05:39
mithroshorne: Having or1k upstream would be awesome :-P05:39
mithroWish we had a solution for gcc05:40
shornemithro: yes, that will work.  but you will only probably notice the failure when doing stack traces in interrupt routines05:40
shornemithro: for gdb its almost there, just finished one more review from gdb team.  A few minor issues to fix it looks like.05:41
shornefor gcc, I wish too05:41
shornesorry... I need to head away again05:42
mithroNo worries05:45
mithrofutarisIRCcloud: Any luck with that uart driver? :-P05:58
futarisIRCcloudIt's compiling, but I haven't gotten it outputting things yet. I was trying to double check interrupt registration before. I am not sure that qemu is setup correctly for multiple serial ports after my patches. I didn't try two 8250s (normal openrisc uart) in the device tree.06:11
mithrofutarisIRCcloud: Can you try using polling first?06:13
futarisIRCcloudYeah, shouldn't matter too much for write. For read, if you don't have an irq event then you have to enable another kernel option. I forget the name of the option...06:15
futarisIRCcloudCan someone double check that the PIC for openrisc will let you use interrupt 0 (in Linux)?06:24
mithrofutarisIRCcloud: Hrm?06:25
mithroIn openrisc assemble, what is the easiest way to skip the next instruction if a register value is zero?06:34
futarisIRCcloudLitex uart is on irq 0 according to the dtb.06:37
mithrofutarisIRCcloud: I would not trust that at all06:38
mithrofutarisIRCcloud: looks like you are right06:40
mithrobuild/mimasv2_base_or1k/software/include/generated/csr.h:#define UART_INTERRUPT 006:40
mithrofutarisIRCcloud: There is no guarantee that I wired up the IRQs correctly..06:40
futarisIRCcloudYeah, I thought the csr.h would be right. Not sure that the Linux side will accept that IRQ though. Haven't looked at it.06:41
mithroIt doesn't look like anything in our baremetal firmware is actually using IRQs....06:41
mithrofutarisIRCcloud: I would start by putting a printf in the qemu code which handles the IRQs06:42
mithrofutarisIRCcloud: See if anything is triggering it first06:42
mithroWell, getting further06:51
mithro164                     panic("No compatible CPU found in device tree...\n");06:51
futarisIRCcloudIs cpus the same as in ???06:59
futarisIRCcloudAnd the compatible section at the top.07:00
mithroI don't think it's finding devicetree at all - but not really sure how to provide that yet07:01
mithroSo, this seems to have allocated a pointer to 0xffffd0007:17
mithroSo, the kernel just allocated memory at the correct address07:54
mithroBut now it is converting it to a virtual address and the value seems to overflow?07:54
mithroWhich means these mmu functions don't do the conversion...07:57
mithroWell I'm into calibrate_delay now10:14
mithroand it doesn't think I have a clock-frequency value in my device tree10:15
mithroI just got a timer exception....10:22
mithroWelp, I think I need a uart now10:47
mithrofutarisIRCcloud: I assume your not still around?10:53
mithroThis is where I got too ->
mithroHeading home to bed now10:58
wbxoh. upstream qemu finally fixed qemu-system name14:50
wbxshorne: works! Thanks a lot.15:04
shornewbx: no worries17:16
shornemithro: I would recomment building in device tree, in kernel config CONFIG_OPENRISC_BUILTIN_DTB="simple_smp"17:17
shornehas anyone else noticed single stepping doesnt work in openocd?17:26
shorneI fixed it... you need to enable the trap exception in DSR, i.e. in gdb 'set $dsr = 1 << 13'17:27
shorneIll fix in openocd config too17:27
--- Log closed Sun Apr 09 00:00:21 2017

Generated by 2.15.2 by Marius Gedminas - find it at!