| --- Log opened Sat Apr 08 00:00:20 2017 | ||
| mithro | gdb doesn't really like this whole virtual/physical addressing stuff from what I can tel | 00:23 |
|---|---|---|
| mithro | futarisIRCcloud: Well, I've gotten the boot process as far as enabling the mmu | 00:34 |
| mithro | Then it hits ITLB miss exception and jumps to the wrong address :-P | 00:36 |
| mithro | futarisIRCcloud: running to get some lunch | 01:00 |
| mithro | Be back in 30 minutes | 01:00 |
| mithro | I think I've gotten the mmu init working | 01:00 |
| mithro | I'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 all | 01:29 |
| shorne | mithro: the virtual/physical stuff you can doing via qemu? | 01:29 |
| mithro | shorne: Hrm? | 01:30 |
| shorne | I have a patch for that | 01:30 |
| shorne | https://github.com/stffrdhrn/qemu/commit/93f7ef78432ebaa2ca6dc961b3f32df7bf94729d | 01:30 |
| shorne | I mean, you said "gdb doesn't really like this whole virtual/physical addressing stuff from what I can tel" | 01:30 |
| shorne | if you are connecting gdb to qemu, then it might be related to the patch I posted | 01:30 |
| shorne | basically gdb sends the address to qemu, and qemu needs to read the memory, currently it assumes a virtual address | 01:31 |
| shorne | I made a change to fallback and see if the address is physical | 01:31 |
| mithro | shorne: That is definitely possible | 01:32 |
| mithro | I need to rebase our stuff onto a less ancient qemu | 01:32 |
| shorne | mithro: ah, ITLB jumps to wrong address, which one does it jump to? | 01:33 |
| mithro | shorne: It jumps to the 0xa00 | 01:34 |
| mithro | Which has nothing there :-P | 01:34 |
| mithro | It appears that the only reason our firmware boots is that we are not using interrupts/exceptions anywhere | 01:34 |
| shorne | I gess, 0xa00 | 01:35 |
| shorne | yeah | 01:35 |
| mithro | shorne: Yeah - I patched qemu to jump to the right address temporarily, just looking at if I can just use EVBAR | 01:35 |
| mithro | Hrm... EVBAR doesn't seem to exist... | 01:37 |
| shorne | oh, yeah lots of features are not implemented in qemu, I had to implement some to get stuff working | 01:37 |
| shorne | its usually been pretty easy | 01:38 |
| mithro | Hrm, we might not be enabling EVBAR on hardware anyway... | 01:38 |
| mithro | shorne: yeah, looks pretty easy to implement | 01:40 |
| * mithro goes on a yak shave | 01:46 | |
| mithro | shorne: Any idea where gen_helper_mfspr comes from in qemu? | 01:58 |
| mithro | I don't quite get how l.mfspr works? | 02:12 |
| mithro | The 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 |
| mithro | How do I figure out the "address" of a spr? | 02:15 |
| mithro | Ahh, there seems to be a table in that doc shorne linked | 02:22 |
| shorne | mithro: did you find get_helper_mfspr? | 02:23 |
| mithro | shorne: I found something in sys_helper which looks like what is being used? | 02:24 |
| shorne | arget/openrisc/helper.h | 02:24 |
| shorne | there is | 02:24 |
| shorne | DEF_HELPER_FLAGS_4(mfspr, TCG_CALL_NO_WG, tl, env, tl, tl, tl) | 02:25 |
| shorne | and sys_helper.c | 02:25 |
| shorne | there are two sides in qemu | 02:25 |
| shorne | the translate/generator sdie and the executor side | 02:25 |
| shorne | helper.h creates all the gen_helper*() functions | 02:26 |
| shorne | sys_helper.c has the implementions | 02:26 |
| shorne | all you should have to touch is sys_helper.c | 02:27 |
| shorne | and maybe cpu.h to add the register | 02:27 |
| mithro | yeah | 02:27 |
| mithro | I'm now trying to actually use it in code somewhere :-P | 02:28 |
| shorne | ok, so you got it :) | 02:28 |
| mithro | shorne: https://github.com/mithro/qemu-litex/commit/896516368f3aee78c659fdf1d5674869d47660be | 02:30 |
| shorne | yeah, it look right to me | 02:33 |
| shorne | I added some minor comments | 02:33 |
| mithro | shorne: I think I want this code | 02:33 |
| mithro | https://www.irccloud.com/pastebin/hmJxMfsy/ | 02:34 |
| shorne | I think you dont need the second line | 02:36 |
| shorne | and just 3rd line | 02:36 |
| shorne | l.mtspr r0,r6,SPR_EVBAR | 02:37 |
| mithro | Oh | 02:37 |
| mithro | I understand how it is used now | 02:37 |
| mithro | I was thinking that the immediate value was ORed with the data being written | 02:38 |
| shorne | its ored with the spr address offset register | 02:39 |
| shorne | but I guess you get that now | 02:40 |
| mithro | Hrm, the assembler doesn't seem to like SPR_EVBAR - is it called something else? | 02:43 |
| shorne | I think its just a variable in openrisc/include/spr.. | 02:44 |
| mithro | Yeah, just found that | 02:44 |
| mithro | It's not set there | 02:44 |
| mithro | Well, it looks like it hit boot_dtlb_miss_handler and boot_itlb_miss_handler a couple of times before jumping to 0x00000000 | 02:49 |
| shorne | ah :( | 02:51 |
| shorne | but looks like vector offset is working | 02:51 |
| shorne | which is good | 02:51 |
| shorne | got to go again | 02:52 |
| mithro | Yeah | 02:54 |
| mithro | Exception 0x9 - vectoring to 0x40000900 | 02:54 |
| mithro | Exception 0xa - vectoring to 0x40000a00 | 02:54 |
| mithro | Exception 0xa - vectoring to 0x40000a00 | 02:54 |
| mithro | /* set up DTLB with no translation for EA <= 0xbfffffff */ | 03:01 |
| mithro | set up ITLB with no translation for EA <= 0x0fffffff | 03:02 |
| mithro | That I don't think will work for us? | 03:02 |
| mithro | As 0x40000000 > 0x0fffffff | 03:04 |
| shorne | mithro: isnt that setup due to the tophys() call? | 03:24 |
| mithro | The address this seems to be translating is | 03:25 |
| mithro | 0x40326114 | 03:25 |
| mithro | tophys just translated that to 0xc0326114 | 03:26 |
| mithro | This seems the wrong way around? | 03:27 |
| mithro | It just took a physical address and translated it to a virtual one? | 03:27 |
| shorne | hmm, seems wrong | 03:28 |
| mithro | If 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 |
| mithro | What does EA stand for? | 03:29 |
| mithro | Ahh Effective address | 03:29 |
| shorne | yeah, it should be that | 03:29 |
| shorne | but it seems like translating 0x40326114 to 0xc0326114 is wrong | 03:30 |
| mithro | so why does the boot_itlb_miss_handler doing any translation? | 03:30 |
| shorne | let me see, maybe you are right | 03:31 |
| shorne | give me a second | 03:31 |
| shorne | hea, right if address is below 0x0fffffff, its direct translation | 03:34 |
| shorne | your address is 0x40326114, is should not be translated | 03:34 |
| shorne | but its not below 0x0fffffff, so it gest mapped | 03:34 |
| mithro | Yeah | 03:36 |
| mithro | What is above 0x0fffffff that should get mapped? | 03:36 |
| mithro | shorne: Well, it just set up the data page table and I'm hitting the bug your patch fixes | 03:37 |
| shorne | well, thats all of the sybols like starting with 0xc00000000 | 03:37 |
| shorne | I guess you could hack it with below 0x5fffffff | 03:38 |
| shorne | the gdb/qemu bug? | 03:38 |
| shorne | i.e. between 0x40000000 and 0x60000000 your initial kernel init code is there | 03:39 |
| shorne | but thats a bit of a hack, there should be a better way | 03:39 |
| shorne | or just 0x4fffffff | 03:39 |
| mithro | shorne: I just added the PHYSICAL_START to it for now | 03:42 |
| shorne | the better way is as the comment says, move all code that is run with mmu enabled into entry.S | 03:44 |
| shorne | but yeah, for now just adding that offset would be good | 03:44 |
| mithro | Which code is run with the mmu enable? | 03:44 |
| shorne | i.e. when mmu is turned on | 03:45 |
| shorne | its running at i.e. 0x00033450 | 03:45 |
| shorne | the next instrcution will cause itlb miss | 03:45 |
| shorne | so 0x00030000 page needs to get added to tlb 0x00030000 0x00030000 | 03:46 |
| shorne | so no translation | 03:46 |
| mithro | Oh, yeah I understand | 03:46 |
| shorne | but its a bit tricky, I would have to look at how other archs do it | 03:50 |
| mithro | "load magic from fdt into r3" | 03:51 |
| mithro | my r25 seems to be empty | 03:51 |
| mithro | I'm guessing because I didn't pass any kernel parameters | 03:51 |
| mithro | The fdt is embedded inside the kernel? | 03:52 |
| shorne | Yes, but fdt is usually built into the kernel | 03:52 |
| shorne | yes, so empty is good | 03:52 |
| shorne | as long as you do have it built in | 03:52 |
| shorne | it supports external fdt (device tree file) | 03:53 |
| shorne | openrisc doesnt support external initrd yet though... I am thinking I want to do that | 03:53 |
| mithro | The DTLB has a similar hack regarding the memory addresses? | 03:55 |
| shorne | yeah, but it says 0xbfffffff | 03:55 |
| mithro | Ahh, I had a miss because it tried to load data pointed at by r25 which as address 0 | 03:56 |
| shorne | I guess that should already work for you? | 03:56 |
| mithro | Looks like I'm about to jump to a virtual address | 03:58 |
| mithro | r24 == 0xc032d0bc | 03:58 |
| mithro | l.jalr r24 | 03:58 |
| mithro | what s a link register? | 03:59 |
| futarisIRCcloud | Sorry. 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 |
| shorne | its the return address | 04:00 |
| shorne | its r9 if I remember correctly | 04:00 |
| mithro | futarisIRCcloud: Well, if you get that serial port driver working, I'm getting closer to having this kernel booting | 04:00 |
| shorne | i.e. it will jump to *r24, then put the next address (after jump in r9( | 04:00 |
| shorne | when you do return, it will jump to r9 | 04:01 |
| futarisIRCcloud | Other 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 |
| futarisIRCcloud | But usually that would come from the bootloader (redboot, u-boot, etc) | 04:01 |
| futarisIRCcloud | I will just try to get serial output working now. | 04:01 |
| shorne | futarisIRCcloud: yeah, I think openrisc has to get patched to handle physical start other than 0x0 (what mithro is working on) | 04:02 |
| mithro | welp, it seems like it just translated the output correctly... | 04:02 |
| shorne | it will be good to look at other archs to figure out the best way | 04:02 |
| mithro | 0xc032d0bc in or32_early_setup () | 04:03 |
| shorne | mithro: good, I am looking at arch/openrisc/mm/init.c and arch/openrisc/mm/fault.c | 04:03 |
| futarisIRCcloud | We shouldn't need to have SERIAL_EARLYCON / SERIAL_UART_LITEX_CONSOLE ... So I'll get late console working first. | 04:03 |
| shorne | in a few places they either check if the interrupt vectore was i.e. 0x500 | 04:04 |
| shorne | or they actually write core to switch the itlb routine to the more advanced one | 04:05 |
| shorne | anyway... that might need to be updated to support the 0x40000000 offset too | 04:05 |
| shorne | I guess you will get there | 04:05 |
| mithro | Welp, it tried to read the fdt at 0x0 and QEMU said nope... | 04:07 |
| mithro | I'm in the printk function now... | 04:20 |
| mithro | This sure does use a lot of instructions to print something.... | 04:25 |
| futarisIRCcloud | A lot of layers between printk and character output. | 04:29 |
| shorne | yeah | 04:29 |
| mithro | shorne: That mask in DTLB is actually PAGE_OFFSET-1 | 04:34 |
| mithro | Breakpoint 2, printk (fmt=0xc02d7e78 "KERNEL: Illegal instruction (SIGILL) 0x%.8lx\n") at kernel/printk/printk.c:1837 | 04:41 |
| mithro | hrm.... | 04:41 |
| mithro | args=0xc030be24 | 04:44 |
| mithro | I need to figure out how to print a va_list in gdb... | 04:46 |
| shorne | what does p *0xc030be24 show? | 04:54 |
| mithro | It seems to be happening at | 04:56 |
| mithro | #0 0xc032db68 in set_bit (addr=<optimized out>, nr=<optimized out>) at ./arch/openrisc/include/asm/bitops/atomic.h:18 | 04:56 |
| mithro | l.lwa | 04:59 |
| mithro | Load Single Word Atomic | 05:00 |
| mithro | I don't see qemu having support for that instruction? | 05:05 |
| mithro | shorne: Has Linux been booted on qemu? | 05:08 |
| futarisIRCcloud | I can boot linux or1ksim on your qemu. | 05:09 |
| mithro | futarisIRCcloud: I wonder why.... | 05:09 |
| mithro | Ahh | 05:10 |
| mithro | When those instructions are not available emulation is provided. | 05:10 |
| futarisIRCcloud | It's possible that the compiler is generating a new instruction that qemu doesn't currently support, because of the different memory layout. | 05:10 |
| mithro | Hrm.... | 05:15 |
| mithro | gdb doesn't like me at the moment | 05: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 |
| mithro | This is weird | 05:26 |
| mithro | #0 do_illegal_instruction (regs=0xc030bec4 <init_thread_union+7876>, address=16404) at arch/openrisc/kernel/traps.c:507 | 05:26 |
| mithro | (gdb) p/x address | 05:26 |
| mithro | $1 = 0x4014 | 05:26 |
| futarisIRCcloud | Just checking /proc/interrupts. Nothing is on IRQ 0 in or1ksim usually. | 05:26 |
| shorne | mithro: I boot linux on qemu every linux build | 05:27 |
| shorne | I mean after every linux built | 05:27 |
| shorne | the l.lwa you need either | 05:27 |
| shorne | 1. a new version of qemu (I and Richard patched in 2.9) | 05:28 |
| shorne | 2. a new version of the kernel (maybe 4.10?) We added l.lwa emulation to the kernel | 05:28 |
| mithro | Yeah, I have l.lwa emulation in the kernel | 05:28 |
| mithro | This appears to be something else | 05:28 |
| shorne | qemu illegal instruction emulation was broken | 05:29 |
| shorne | I patched that too | 05:29 |
| mithro | Oh? | 05:29 |
| mithro | shorne: What branch should I be looking at on your qemu repo? | 05:30 |
| shorne | https://github.com/qemu/qemu/commit/c56e3b86701501364a4756201b6a9db9454463ab | 05:30 |
| shorne | everything is upstream | 05:30 |
| shorne | my repo just has some stuff for gdb debug and multicore | 05:30 |
| shorne | just or1k-next has those | 05:30 |
| shorne | but the emulation fix is upstream | 05:31 |
| shorne | you can probably just patchyourself | 05:31 |
| shorne | its a very small change | 05:31 |
| mithro | shorne: Missing that patch would explain why my address is 0x4014 | 05:31 |
| futarisIRCcloud | :) | 05:32 |
| shorne | mithro: also for the gdb error "internal-error or1k_frame_cache" | 05:32 |
| shorne | I fixed in gdb too :) | 05:32 |
| shorne | but all my changes are squashed into this.... https://github.com/stffrdhrn/binutils-gdb/tree/or1k-upstream | 05:33 |
| shorne | the gist of the fix is just to remove that assert, but you can also just take my gdb repo | 05:34 |
| mithro | I wonder how it's working for futarisIRCcloud? | 05:35 |
| futarisIRCcloud | I've got buildroot patches. | 05:35 |
| mithro | shorne: Is that stuff in openrisc/binutils-gdb.git too? | 05:36 |
| futarisIRCcloud | https://github.com/buildroot/buildroot/tree/2017.02.x/board/qemu/or1k/patches/linux | 05:36 |
| mithro | Ahh, I'm just using upstream Linux kernel | 05:38 |
| mithro | shorne: So I want or1k-upstream branch of your binutils-gdb repo? | 05:38 |
| shorne | mithro: its not in the openrisc/binutils-gdb... I do too many rebases and really removed a bunch of code | 05:38 |
| shorne | (as part of gdb upstreaming reviews) once its all done I will update openrisc/binutils-gdb | 05:39 |
| mithro | shorne: Having or1k upstream would be awesome :-P | 05:39 |
| mithro | Wish we had a solution for gcc | 05:40 |
| shorne | mithro: yes, that will work. but you will only probably notice the failure when doing stack traces in interrupt routines | 05:40 |
| shorne | mithro: for gdb its almost there, just finished one more review from gdb team. A few minor issues to fix it looks like. | 05:41 |
| shorne | for gcc, I wish too | 05:41 |
| shorne | sorry... I need to head away again | 05:42 |
| mithro | No worries | 05:45 |
| mithro | futarisIRCcloud: Any luck with that uart driver? :-P | 05:58 |
| futarisIRCcloud | It'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 |
| mithro | futarisIRCcloud: Can you try using polling first? | 06:13 |
| futarisIRCcloud | Yeah, 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 |
| futarisIRCcloud | Can someone double check that the PIC for openrisc will let you use interrupt 0 (in Linux)? | 06:24 |
| mithro | futarisIRCcloud: Hrm? | 06:25 |
| mithro | In openrisc assemble, what is the easiest way to skip the next instruction if a register value is zero? | 06:34 |
| futarisIRCcloud | Litex uart is on irq 0 according to the dtb. | 06:37 |
| mithro | futarisIRCcloud: I would not trust that at all | 06:38 |
| mithro | futarisIRCcloud: looks like you are right | 06:40 |
| mithro | build/mimasv2_base_or1k/software/include/generated/csr.h:#define UART_INTERRUPT 0 | 06:40 |
| mithro | futarisIRCcloud: There is no guarantee that I wired up the IRQs correctly.. | 06:40 |
| futarisIRCcloud | Yeah, 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 |
| mithro | It doesn't look like anything in our baremetal firmware is actually using IRQs.... | 06:41 |
| mithro | futarisIRCcloud: I would start by putting a printf in the qemu code which handles the IRQs | 06:42 |
| mithro | futarisIRCcloud: See if anything is triggering it first | 06:42 |
| futarisIRCcloud | Ok | 06:43 |
| mithro | Well, getting further | 06:51 |
| mithro | 164 panic("No compatible CPU found in device tree...\n"); | 06:51 |
| mithro | Hrm... | 06:52 |
| futarisIRCcloud | Is cpus the same as in https://github.com/torvalds/linux/blob/master/arch/openrisc/boot/dts/or1ksim.dts ??? | 06:59 |
| mithro | Yeah | 07:00 |
| futarisIRCcloud | And the compatible section at the top. | 07:00 |
| mithro | I don't think it's finding devicetree at all - but not really sure how to provide that yet | 07:01 |
| mithro | So, this seems to have allocated a pointer to 0xffffd00 | 07:17 |
| mithro | So, the kernel just allocated memory at the correct address | 07:54 |
| mithro | But now it is converting it to a virtual address and the value seems to overflow? | 07:54 |
| mithro | Which means these mmu functions don't do the conversion... | 07:57 |
| mithro | Well I'm into calibrate_delay now | 10:14 |
| mithro | and it doesn't think I have a clock-frequency value in my device tree | 10:15 |
| mithro | I just got a timer exception.... | 10:22 |
| mithro | Welp, I think I need a uart now | 10:47 |
| mithro | futarisIRCcloud: I assume your not still around? | 10:53 |
| mithro | This is where I got too -> https://github.com/mithro/HDMI2USB-misoc-linux/commit/432a1b12dfbed4c8296960a6d1805c3fedc0bd5e | 10:57 |
| mithro | Heading home to bed now | 10:58 |
| wbx | oh. upstream qemu finally fixed qemu-system name | 14:50 |
| wbx | shorne: works! Thanks a lot. | 15:04 |
| shorne | wbx: no worries | 17:16 |
| shorne | mithro: I would recomment building in device tree, in kernel config CONFIG_OPENRISC_BUILTIN_DTB="simple_smp" | 17:17 |
| shorne | has anyone else noticed single stepping doesnt work in openocd? | 17:26 |
| shorne | I fixed it... you need to enable the trap exception in DSR, i.e. in gdb 'set $dsr = 1 << 13' | 17:27 |
| shorne | Ill fix in openocd config too | 17:27 |
| --- Log closed Sun Apr 09 00:00:21 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!