| stekern | blueCmd: no worries ;) | 03:06 |
|---|---|---|
| stekern | it does that when you pull via the web interface, if you would just have pushed your stage-upstream branch there it wouldn't | 03:07 |
| stekern | I removed the merge commit | 03:07 |
| stekern | the dummy one, that is | 03:08 |
| stekern | juliusb: another spr question, why does the tick timer and pic only ack on write requests? | 04:37 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/2b8d2fa995d0...bf52162f5ec4 | 05:23 |
| mor1kx | mor1kx/master 70dac5b Stefan Kristiansson: pic: ack all spr accesses, not only writes | 05:23 |
| mor1kx | mor1kx/master bf52162 Stefan Kristiansson: ticktimer: ack all spr accesses, not only writes | 05:23 |
| stekern | hmm, linux isn't exactly booting with my MMUs ;) | 05:42 |
| stekern | it get into a itlb miss loop | 05:42 |
| stekern | I probably should filter out itlb and ipagefault exceptions when doing rfe... | 09:32 |
| stekern | but there is something else that goes wrong, the translated addresses after the itlb miss handler have been run is not correct | 09:33 |
| stekern | aha, my immucfgr and dmmucfgr registers are 0 | 11:51 |
| LoneTech | so they indicate that you have onyl one TLB set, no ATB entries, no control registers. not the most useful mmu specs, I am guessing | 11:53 |
| stekern | right ;) | 11:57 |
| * microcode implements Itanium, takes a sip of the coffee | 11:58 | |
| stekern | well, actually, the sets information is the only real missing bit | 11:59 |
| LoneTech | ok | 12:00 |
| stekern | microcode: itanium, eh? :) | 12:13 |
| _franck_ | while compiling or1k toolchain, building newlib I get some "or1k-elf-cc" command not found | 12:24 |
| _franck_ | http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 12:24 |
| _franck_ | ?? | 12:24 |
| _franck_ | http://pastebin.com/pG8HUfxp | 12:24 |
| _franck_ | oups wait | 12:26 |
| _franck_ | :) | 12:26 |
| blueCmd | stekern: I'm unable to get ethoc working from mainline, it works using pgavin/or1k-linux | 13:06 |
| blueCmd | it detects the device (after patching the compatibles string) but it fails during autonegotiation | 13:06 |
| microcode | stekern: I have to say, Itanium had some really cool stuff | 13:07 |
| blueCmd | stekern: btw, sorry if I hilight you on everything - feel free to redirect me to someone else if you're tierd of my questions :) | 13:08 |
| microcode | Too bad nobody really figured out how to take good advantage of its flavour of ILP, and predicated execution | 13:10 |
| blueCmd | microcode: indeed. a lot of cool archs never make it sadly :( | 13:12 |
| microcode | It'd be nice to put time and care into developing an architecture though | 13:12 |
| microcode | and develop the software with it | 13:13 |
| blueCmd | or2k ;) | 13:13 |
| microcode | then again, I'm just an architecture hipster, not particularly useful in the space | 13:13 |
| microcode | as I don't have funds for an FPGA, or a willingness to jump through hoops just to run their bloody flashing tools | 13:13 |
| microcode | I, for one, see no reason why tools relevant only to one piece of hardware would ever be nonfree | 13:14 |
| microcode | might be interested in observing their operation though, and developing compatible implementations... | 13:17 |
| microcode | I'm somewhat tired of sitting around not being able to get into this space | 13:17 |
| microcode | \endsection | 13:21 |
| microcode | p'raps it's sleepytime, my heart is bleeding all over the place | 13:24 |
| blueCmd | microcode: hah, it's time for lunch here | 13:25 |
| microcode | yeah, for most here, it's about time for breakfast | 13:28 |
| microcode | lol | 13:32 |
| microcode | looking at some postings about people attempting to build free toolchains for FPGAs | 13:33 |
| microcode | it's funny seeing how all of the optimists are well-spoken, and correct | 13:33 |
| microcode | and the skeptics use broad and under-descriptive terms like "IP" in situations where no such law is even relevant | 13:33 |
| microcode | (confusing trade secrets with patents) | 13:33 |
| microcode | This makes me somewhat more optimistic. | 13:36 |
| stekern | blueCmd: there are ethoc changes made that never went upstream | 15:25 |
| stekern | as well as drivers for other cores as well | 15:26 |
| blueCmd | stekern: well I diffed ethoc with the one upstream | 15:26 |
| blueCmd | but the kernel is huge, i suppose there are a million stuff that could be the cause | 15:27 |
| stekern | ok, and using the other one with upstream didn't work? | 15:27 |
| blueCmd | the diff was minimal | 15:27 |
| blueCmd | I think it was MAC address generation and wishbone for BE systems | 15:27 |
| stekern | mkay | 15:28 |
| blueCmd | but I suppose the MDIO bus itself could be faulty or something like that | 15:28 |
| blueCmd | it's not important, I will use 3.4.0 for now. I just thought I would report it | 15:28 |
| stekern | yeah, I know ethernet in u-boot broke because our gcc doesn't calculate sizeof(ethernet_header) "right" | 15:30 |
| stekern | it pads it | 15:30 |
| stekern | the struct I mean | 15:31 |
| blueCmd | stekern: have you hacked with the elf32-or1k.c code? | 17:06 |
| blueCmd | I'm trying to understand what this is: | 17:06 |
| blueCmd | r_symndx = ELF32_R_SYM (rel->r_info); | 17:06 |
| blueCmd | if (r_symndx < symtab_hdr->sh_info) | 17:06 |
| blueCmd | What I want to do is to allocate 1 or 2 GOT frames when I have my TLS relocations. I copied the code for GOT16 in check_relocs, and that adds one got entry just fine. But I feel I need to understand the h->got.offset / elf_local_got_refcounts difference before hacking away | 17:11 |
| stekern | yeah, I hacked elf32-or1k.c, at least the got and plt stuff | 17:57 |
| stekern | I need to go back and look at it though, I'll do that latest tomorrow morning | 17:58 |
| stekern | (at sons fotball practice atm ;)) | 17:59 |
| blueCmd | stekern: great! no prob, I have loads of other stuff to hack on until then. | 18:00 |
| stekern | but the got offset is the offset in the got and the refcounts counts the number of references through got | 18:02 |
| stekern | I'm not sure if thats used for anything else than gc | 18:02 |
| blueCmd | yes, I figured that part out - what I really want is to know how the size is calculated | 18:03 |
| blueCmd | sort of, the offset as well I suppose | 18:03 |
| blueCmd | anyway - if you could plot down how got works in that file I would be eternally greatful | 18:04 |
| * blueCmd back to reading about dynamic loading and pending relocations | 18:05 | |
| stekern | pending relocations? | 18:09 |
| _franck_ | jeremybennett: the CGEN sim could be the problem, see: http://pastebin.com/MPSkf9nL | 18:09 |
| _franck_ | this is the first test of the testsuite | 18:09 |
| _franck_ | I need to make the or1k testsuite use or1ksim | 18:10 |
| blueCmd | stekern: I don't know a better word for it, but how to implement TLS in the dynamic loader. after linking TLS stuff you will probably (3 out of 4 TLS modes) have relocations left to do | 18:11 |
| stekern | aha | 18:12 |
| stekern | _franck_: you can probably use jeremys old boardscript for that | 18:14 |
| stekern | it's in svn | 18:14 |
| jeremybennett | _franck_: Doesn't look good. The simulator should return with the return code of the program when it exited. Breakpointing shouldn't cause the CGEN simulator to exit! | 18:15 |
| jeremybennett | As stekern says, you should be able to specify that the simulator is Or1ksim, rather than the CGEN simulator. | 18:16 |
| jeremybennett | I can't recall if it needs some sort of wrapper to make it have exactly the properties of a simulator for testing. | 18:16 |
| jeremybennett | Basically "sim <prog>" should run until <prog> exits, then exit with <prog>'s exit code. | 18:16 |
| jeremybennett | But we did it before, so somewhere in those boards (probably for ELF tool chain) is the magic to do this. | 18:17 |
| _franck_ | I'll try to do that. But now I'm sure I need to use or1ksim | 18:21 |
| stekern | wouldn't the cgen simulator need a debug unit for bp to work? | 18:22 |
| _franck_ | don't know | 18:24 |
| jeremybennett | The simulator interface understands about being used as a debugger. I guess it needs a sensible interpretation of l.trap. | 18:25 |
| jeremybennett | Not sure it can handle HW breakpoint - those should just be rejected. | 18:25 |
| jeremybennett | Most CGEN simulators work fine with GDB. | 18:25 |
| stekern | mmm, I guess it's the interpretation of l.trap that fails then | 18:27 |
| _franck_ | l.trap is known since I get into or1k32bf_exception with exnum == EXCEPT_TRAP | 18:38 |
| _franck_ | need to find the trap handler | 18:39 |
| _franck_ | ah ok handler is in the elf I just loaded..... :) | 18:44 |
| _franck_ | printf("handler_pc = %08X\n", handler_pc); gives me the trap handler address, so it goes at the right place | 18:52 |
| _franck_ | must be something else | 18:52 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!