--- Log opened Mon Jun 16 00:00:36 2014 | ||
stekern | olofk: spend cycles, when you do what? | 04:33 |
---|---|---|
stekern | I assume during boot in this case, but those functions are called *a lot* from cpu_idle(), so we want to make sure that we're not optimizing for that ;) | 04:35 |
stekern | I wonder if gcc's register allocator somehow get thrown off by the calls to mfspr()/mtspr() that later get inlined. | 04:39 |
stekern | otoh... r2 is only used between the two call sites, so it should be able to use a temp reg there anyway | 04:41 |
stekern | which are number number 1-5 on your list btw? | 04:45 |
stekern | blueCmd: isn't this misleading? https://github.com/bluecmd/or1k-glibc/blob/master/ports/sysdeps/or1k/nptl/tls.h#L65-L69 | 05:42 |
stekern | doesn't tp actually point at the beginning of TCB? | 05:43 |
stekern | or... maybe you actually put it *after* the TCB? | 06:10 |
stekern | I think you do, is there some grand reason for that? | 06:11 |
olofk | stekern: We will have the fastest cpu_idle() of all the arches :) | 06:28 |
stekern | ;) | 06:30 |
olofk | stekern: https://www.dropbox.com/s/62dvhlkliszdnyn/trace.txt | 06:39 |
olofk | Sorted by number of cycles | 06:39 |
olofk | But as you know, this is just part of the boot, so I assume that it will be quite different for a real workload | 06:39 |
olofk | First column is decimal address btw | 06:39 |
stekern | cool | 06:50 |
stekern | looks like my tlb miss handler optimizations wasn't misplaced ;) | 06:51 |
olofk | I think there's a udiv64 inside _parse_integer that takes a lot of time. Can we accelerate that somehow? | 06:56 |
stekern | yes | 07:03 |
blueCmd | stekern: it makes relocations in easier and not dependent on the PRE/TCB parts | 08:17 |
blueCmd | well, on the size of them at least | 08:17 |
blueCmd | Code to initially initialize the thread pointer. * * Set TP to the address _after_ tcbhead_t. This will allow us * to change the size of tcbhead_t without having to re-link everything. | 08:20 |
stekern | hmm, ok... but you use the TCB size in the dynamic linker | 08:22 |
blueCmd | sure, but recompiling the dynamic linker is easy, if the generated assembly / relocations would need to compensate for the tcbhead it would suck | 08:23 |
blueCmd | it's kind of like TLS variant II, but inverted | 08:24 |
stekern | yeah, I see | 08:24 |
stekern | well, it's variant I, but with tp after TCB | 08:24 |
blueCmd | in retrospect I could probably have done variant II straight off, but i don't see any downsides with this | 08:24 |
stekern | maybe not, other than it was confusing for me when I was reading this and I was trying to figure out which you actually used: http://www.akkadia.org/drepper/tls.pdf | 08:26 |
blueCmd | stekern: yeah, sorry about that | 08:28 |
stekern | I'm also confused wether the mips and powerpc 0x7000 offset is calculated from the beginning or the end of their TCB | 08:32 |
stekern | and, where does other archs put their pthread? | 08:47 |
stekern | in relation to TCB I mean? | 08:47 |
stekern | wallento: what's the status on the cache coherency stuff you were working on? | 12:42 |
stekern | if you have anything remotely working, I'd be interesting in beating it around a bit | 12:43 |
wallento | hi, still buggy, I hope I will find time this week, but I can push it this evening | 12:43 |
stekern | that'd be great, it doesn't matter if it's not completely working, I figured I might be of some help debugging it | 12:44 |
wallento | yep, sounds good | 12:44 |
wallento | I recently added a PR, maybe you can shortly check it | 12:44 |
stekern | I've got Linux running reliably on the de0 nano with dual core | 12:44 |
wallento | cool! | 12:45 |
stekern | the or1k-src pr you mean? | 12:45 |
wallento | this sounds like a proper long run test ;) | 12:45 |
wallento | yes | 12:45 |
stekern | go ahead and push that, it's obviously correct | 12:45 |
wallento | on or1k-src/multicore the dynamic reent is screwed, spent the whole morning, but can't figure it out | 12:46 |
wallento | if you add assertions it gets link order issues again | 12:46 |
stekern | ok, I haven't used that for anything but to compile your test demo ;) | 12:47 |
wallento | Maybe I might ask the newlib guys on the mailing list how god/they intended to use this whole thing.. | 12:47 |
stekern | ...iow I'm of little assistance on that issue | 12:47 |
wallento | maybe I can ask jeremy, I think he did it before | 12:48 |
_franck__ | if anyone has some time to test openocd JTAG uart support: http://openocd.zylin.com/#/c/2162/ | 12:53 |
stekern | _franck__: will do | 12:59 |
stekern | do I need to change something in the adv_debug_config? | 13:00 |
_franck__ | thanks, don't forget this JTAG uart has 32 bits access port | 13:00 |
_franck__ | no change in adv_debug_config | 13:00 |
stekern | it has always been enabled? | 13:00 |
_franck__ | https://github.com/fjullien/orpsoc-cores/commit/b09708258140f47ab8c00d576e6c80978c4a7f97 | 13:01 |
_franck__ | yes | 13:01 |
stekern | do you use some special driver for it (e.g. in barebox)? | 13:02 |
_franck__ | no, it's a 16550 compatible UART | 13:03 |
stekern | ah, ok | 13:03 |
_franck__ | apply also this http://openocd.zylin.com/#/c/2163/ when you try it | 13:05 |
stekern | hmm, do you have a ready branch somewhere I could just pull from? | 13:06 |
_franck__ | try this: https://github.com/fjullien/openOCD/commits/jsp_rebased | 13:08 |
_franck__ | but that's not the very last version of the patch. I would prefer you get the patch from gerrit | 13:09 |
_franck__ | you can cherry-pick it: | 13:10 |
_franck__ | git fetch http://openocd.zylin.com/openocd refs/changes/62/2162/2 && git cherry-pick FETCH_HEAD | 13:10 |
_franck__ | "download" on the upper right corner | 13:11 |
stekern | ok, will do | 13:12 |
_franck__ | great | 13:14 |
olofk | _franck_: Looks like your jsp patch killed stekern :( | 15:11 |
stekern | _franck_: I get this when I try to compile openocd: hla_transport.c:55:3: error: initialization from incompatible pointer type [-Werror] | 17:22 |
stekern | completely unrelated to your changes | 17:23 |
stekern | oh... I think I screwed up the cherry-picking... | 17:25 |
_franck_ | you need to update jimtcl | 17:29 |
_franck_ | git update submodule ? | 17:29 |
_franck_ | submodule update ? | 17:29 |
stekern | no, I managed to copy and run the checkout command instead of the cherry-pick | 17:32 |
stekern | and then it was based on some random old version | 17:32 |
stekern | now I have a fail that's perhaps related to your stuff | 17:33 |
stekern | /home/stefan/openrisc/openocd/openocd/src/target/openrisc/or1k_du_adv.c:209: undefined reference to `jsp_init' | 17:33 |
stekern | do I need some config flag to enable the jsp? | 17:34 |
_franck_ | damned | 17:34 |
_franck_ | no config flag, just a bug somewhere | 17:34 |
stekern | but jsp_init is in src/target/openrisc/jsp_server.c | 17:35 |
_franck_ | strange error because gerrit would have caught it (the online build tool) | 17:36 |
stekern | http://pastie.org/9295694 | 17:36 |
_franck_ | cooking right now, can't help you | 17:36 |
stekern | ok, I'll help myself ;) | 17:36 |
stekern | ...try at least | 17:36 |
stekern | ah... perhaps this is my fault, I probably need to ./bootstrap it | 17:38 |
stekern | yup | 17:40 |
olofk | n900 saves the day!!!! | 17:43 |
stekern | ? | 17:50 |
olofk | The touch sensor broke on my android yesterday. Can still see everything, but only top 10% of the touchscreen works. Managed to pair it to my n900 so I could fire up BlueMaemo to use as a HID controller | 17:51 |
olofk | So I can now emulate mouse movements on my android phone | 17:51 |
olofk | It finally has the role it should have had all along. A puny slave to the great n900 master | 17:52 |
stekern | I thought you lost/broke your n900? | 17:52 |
olofk | Nah. It works. Only the mobile part that doesn't work | 17:52 |
stekern | and don't you have a Jolla? | 17:52 |
olofk | Stupid fucking shit phone | 17:53 |
olofk | Reboots every five minutes | 17:53 |
olofk | No keyboard | 17:53 |
stekern | heh... but you can ssh into it | 17:53 |
olofk | Yes! | 17:53 |
olofk | Btw, can I ssh into an android if I root it? | 17:53 |
stekern | yes | 17:54 |
stekern | there's dropbear for android at least | 17:54 |
olofk | Great. I won't let this device keep my data hostage like this again | 17:54 |
olofk | Actually, android is pretty nice with a mouse | 18:02 |
stekern | _franck_: so, how do I connect to it? you telnetted to 9999, but that doesn't work | 18:36 |
stekern | aha! 7777 | 18:39 |
stekern | hmm, but it doesn't seem to work out of the box | 18:47 |
_franck_ | stekern: I forgot to tell you that you need to update your orpsoc-cores repo | 19:02 |
stekern | ok, what's there? | 19:02 |
_franck_ | https://github.com/openrisc/orpsoc-cores/commit/0bd89cb3b974748c2fd1b037d09c6bee93b3ea6a | 19:02 |
stekern | ok | 19:03 |
stekern | I think something else is broke in my build too though, I don't get the normal uart working with it neither | 19:04 |
stekern | why is it even looking at the byte enable and adr[2:0] if it's 32-bit accesses? | 19:05 |
stekern | or, is it still byte accessed, but over a 32-bit bus? | 19:06 |
_franck_ | yes it's byte access | 19:07 |
stekern | ok, I thought the stride would be 32-bit too | 19:07 |
stekern | oh... great... svn: E020014: Can't find a temporary directory: Internal error | 19:10 |
stekern | if I connect the wb_jsp port, things break | 19:51 |
stekern | 'things break' = I don't get any output on the 'normal' uart | 19:52 |
_franck_ | jtag uart is blocking | 19:53 |
stekern | yes, but when I try to use the 'normal | 19:53 |
_franck_ | it means your soft will wait until tx buffer is emptied by you connecting to the server | 19:53 |
stekern | ' uart, I'm not trying to access the jtag uart | 19:54 |
_franck_ | ah ok I thought you have both in parallel | 19:54 |
_franck_ | I mean working at the same time | 19:55 |
stekern | well, I do, but I configured the jtag uart as uart1, and I'm not trying to access it | 19:55 |
_franck_ | and nothing is written to uart1 ? | 19:56 |
stekern | if I comment out the wb_jsp ports, it works | 19:56 |
stekern | no, nothing is written to uart1 | 19:56 |
stekern | and I'm sure of that, because commenting out wb_jsp would cause accesses to it to stall | 19:57 |
_franck_ | weird | 20:00 |
olofk | Running on target or in sim? | 20:13 |
stekern | target | 20:13 |
stekern | seems like removing the irq signal is enough | 20:14 |
olofk | Could it be level/edge problem? | 20:14 |
_franck_ | may be, I did try it with barebox which doesn't use interrupts | 20:15 |
olofk | What's the funny nop replacer btw? How funny is it? Many questions here | 20:17 |
_franck_ | I could try what's going on in simulation. I'll try to do this tomorrow | 20:20 |
_franck_ | *to see | 20:20 |
stekern | let's try if it works without the irq | 20:22 |
stekern | early boot uart doesn't use that | 20:22 |
stekern | hmm... that didn't work | 21:11 |
stekern | does baudrate etc matter? | 21:11 |
stekern | bah, since I manually added adbg to the caceh, your patch didn't get applied | 21:14 |
olofk | The cache stuff desperately needs some love :/ | 21:49 |
--- Log closed Tue Jun 17 00:00:37 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!