IRC logs for #openrisc Thursday, 2013-01-24

stekernblueCmd: no worries ;)03:06
stekernit does that when you pull via the web interface, if you would just have pushed your stage-upstream branch there it wouldn't03:07
stekernI removed the merge commit03:07
stekernthe dummy one, that is03:08
stekernjuliusb: 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:
mor1kxmor1kx/master 70dac5b Stefan Kristiansson: pic: ack all spr accesses, not only writes05:23
mor1kxmor1kx/master bf52162 Stefan Kristiansson: ticktimer: ack all spr accesses, not only writes05:23
stekernhmm, linux isn't exactly booting with my MMUs ;)05:42
stekernit get into a itlb miss loop 05:42
stekernI probably should filter out itlb and ipagefault exceptions when doing rfe...09:32
stekernbut there is something else that goes wrong, the translated addresses after the itlb miss handler have been run is not correct09:33
stekernaha, my immucfgr and dmmucfgr registers are 011:51
LoneTechso they indicate that you have onyl one TLB set, no ATB entries, no control registers. not the most useful mmu specs, I am guessing11:53
stekernright ;)11:57
* microcode implements Itanium, takes a sip of the coffee11:58
stekernwell, actually, the sets information is the only real missing bit11:59
stekernmicrocode: itanium, eh? :)12:13
_franck_while compiling or1k toolchain, building newlib I get some "or1k-elf-cc" command not found12:24
_franck_oups wait12:26
blueCmdstekern: I'm unable to get ethoc working from mainline, it works using pgavin/or1k-linux13:06
blueCmdit detects the device (after patching the compatibles string) but it fails during autonegotiation13:06
microcodestekern: I have to say, Itanium had some really cool stuff13:07
blueCmdstekern: 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
microcodeToo bad nobody really figured out how to take good advantage of its flavour of ILP, and predicated execution13:10
blueCmdmicrocode: indeed. a lot of cool archs never make it sadly :(13:12
microcodeIt'd be nice to put time and care into developing an architecture though13:12
microcodeand develop the software with it13:13
blueCmdor2k ;)13:13
microcodethen again, I'm just an architecture hipster, not particularly useful in the space13:13
microcodeas I don't have funds for an FPGA, or a willingness to jump through hoops just to run their bloody flashing tools13:13
microcodeI, for one, see no reason why tools relevant only to one piece of hardware would ever be nonfree13:14
microcodemight be interested in observing their operation though, and developing compatible implementations...13:17
microcodeI'm somewhat tired of sitting around not being able to get into this space13:17
microcodep'raps it's sleepytime, my heart is bleeding all over the place13:24
blueCmdmicrocode: hah, it's time for lunch here13:25
microcodeyeah, for most here, it's about time for breakfast13:28
microcodelooking at some postings about people attempting to build free toolchains for FPGAs13:33
microcodeit's funny seeing how all of the optimists are well-spoken, and correct13:33
microcodeand the skeptics use broad and under-descriptive terms like "IP" in situations where no such law is even relevant13:33
microcode(confusing trade secrets with patents)13:33
microcodeThis makes me somewhat more optimistic.13:36
stekernblueCmd: there are ethoc changes made that never went upstream15:25
stekernas well as drivers for other cores as well15:26
blueCmdstekern: well I diffed ethoc with the one upstream15:26
blueCmdbut the kernel is huge, i suppose there are a million stuff that could be the cause15:27
stekernok, and using the other one with upstream didn't work?15:27
blueCmdthe diff was minimal15:27
blueCmdI think it was MAC address generation and wishbone for BE systems15:27
blueCmdbut I suppose the MDIO bus itself could be faulty or something like that15:28
blueCmdit's not important, I will use 3.4.0 for now. I just thought I would report it15:28
stekernyeah, I know ethernet in u-boot broke because our gcc doesn't calculate sizeof(ethernet_header) "right"15:30
stekernit pads it15:30
stekernthe struct I mean15:31
blueCmdstekern: have you hacked with the elf32-or1k.c code?17:06
blueCmdI'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
blueCmdWhat 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 away17:11
stekernyeah, I hacked elf32-or1k.c, at least the got and plt stuff17:57
stekernI need to go back and look at it though, I'll do that latest tomorrow morning17:58
stekern(at sons fotball practice atm ;))17:59
blueCmdstekern: great! no prob, I have loads of other stuff to hack on until then.18:00
stekernbut the got offset is the offset in the got and the refcounts counts the number of references through got18:02
stekernI'm not sure if thats used for anything else than gc18:02
blueCmdyes, I figured that part out - what I really want is to know how the size is calculated18:03
blueCmdsort of, the offset as well I suppose18:03
blueCmdanyway - if you could plot down how got works in that file I would be eternally greatful18:04
* blueCmd back to reading about dynamic loading and pending relocations18:05
stekernpending relocations?18:09
_franck_jeremybennett: the CGEN sim could be the problem, see:
_franck_this is the first test of the testsuite18:09
_franck_I need to make the or1k testsuite use or1ksim18:10
blueCmdstekern: 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 do18:11
stekern_franck_: you can probably use jeremys old boardscript for that18:14
stekernit's in svn18: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
jeremybennettAs stekern says, you should be able to specify that the simulator is Or1ksim, rather than the CGEN simulator.18:16
jeremybennettI can't recall if it needs some sort of wrapper to make it have exactly the properties of a simulator for testing.18:16
jeremybennettBasically "sim <prog>" should run until <prog> exits, then exit with <prog>'s exit code.18:16
jeremybennettBut 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 or1ksim18:21
stekernwouldn't the cgen simulator need a debug unit for bp to work?18:22
_franck_don't know18:24
jeremybennettThe simulator interface understands about being used as a debugger. I guess it needs a sensible interpretation of l.trap.18:25
jeremybennettNot sure it can handle HW breakpoint - those should just be rejected.18:25
jeremybennettMost CGEN simulators work fine with GDB.18:25
stekernmmm, I guess it's the interpretation of l.trap that fails then18:27
_franck_l.trap is known since I get into or1k32bf_exception with exnum == EXCEPT_TRAP18:38
_franck_need to find the trap handler18: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 place18:52
_franck_must be something else18:52

Generated by 2.15.2 by Marius Gedminas - find it at!