| --- Log opened Fri Jul 25 00:00:34 2014 | ||
| stekern | heh, is this the kernel folks new strategy to kill off the systemd project? | 03:59 |
|---|---|---|
| stekern | http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00492.html | 03:59 |
| stekern | blueCmd: I actually had a feeling that something was off when I saw r9 in the end of your clone function | 04:35 |
| stekern | because I had a vague recollection that I had avoided using r9 in the end of mine for some reason | 04:37 |
| stekern | I was just too tired yesterday to figure it out ;) | 04:37 |
| stekern | I screamma for less quit/joins from gbaway in the mornings | 04:48 |
| blueCmd | stekern: subtle things | 06:51 |
| stekern | obviously it breaks easily in qemu. in mor1kx it'd break even more subtle, it works until you hit an exception in the delay slot | 06:57 |
| blueCmd | *sigh* ctype init crashes. that means with 99% certainty that this segfault is TLS related | 06:59 |
| stekern | but you are our TLS expert, should be a piece of cake for you to sort out! ;) | 07:02 |
| stekern | hmm, can you turn off support for instructions in or1ksim? | 07:04 |
| stekern | doesn't seem you can | 07:10 |
| blueCmd | stekern: well, as your expert I can tell you it's a pain to debug :P | 07:22 |
| ysionneau | 05:59 < stekern> http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00492.html < it's a bit mean | 08:24 |
| ysionneau | to the poster and to gnome/systemd | 08:26 |
| blueCmd | current_locale: 00000001 | 09:06 |
| blueCmd | that's not right | 09:06 |
| blueCmd | very bad address | 09:06 |
| stekern | ysionneau: perhaps, but not uncalled for =P | 09:14 |
| ysionneau | =) | 09:18 |
| olofk | Does anyone have a nice and clean synchronous FIFO? I want to avoid going through hundreds of potential candidates | 10:08 |
| olofk | Need configurable depth and width + an element counter | 10:09 |
| stekern | olofk: single clock? | 10:09 |
| olofk | yep | 10:09 |
| stekern | wait | 10:09 |
| stekern | https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_store_buffer.v | 10:10 |
| stekern | I remembered that I would have seperated it more though | 10:11 |
| stekern | but a single clock fifo is so trivial | 10:11 |
| stekern | then there's this: https://github.com/skristiansson/wb_sdram_ctrl/blob/master/rtl/verilog/dual_clock_fifo.v | 10:12 |
| olofk | Yes, it's trivial, but it still takes a little time do one and test it | 10:12 |
| olofk | stekern: None of those have element counters exposed | 10:13 |
| stekern | oh, I missed that | 10:13 |
| olofk | I can still just compare the pointers myself though. It's just one of those things that I assume we have somewhere :) | 10:13 |
| olofk | And if I get a nice and clean one, I'll do a .core for it as well | 10:14 |
| olofk | Looking at the wayback machine I must say that opencores looked better 2003-2007 than it does today | 10:25 |
| olofk | I guess that is true for a lot of sites though | 10:26 |
| stekern | mmm | 10:38 |
| stekern | back then it was easier to find quality stuff too | 10:39 |
| stekern | we used this core in a couple of projects at our university back in 2002-2003: http://opencores.org/project,ax8 | 10:41 |
| stekern | I have some changes to that make it a90s8535 compatible | 10:45 |
| stekern | among the changes is an addition of a SPI slave | 10:49 |
| stekern | http://pastie.org/9419851 | 10:51 |
| * stekern get back from nostalgia lane | 10:54 | |
| rah | stekern: what course did you study? | 10:56 |
| rah | if you don't mind me asking? :-) | 10:56 |
| stekern | hmm... I think it was called 'digital design' or something | 10:57 |
| rah | I mean, what degree? | 10:57 |
| stekern | aha, EE master | 10:58 |
| rah | I see | 10:58 |
| blueCmd | stekern: what uni? | 11:50 |
| stekern | midsweden, in sundsvall | 11:57 |
| blueCmd | stekern: fix the openrisc | 12:00 |
| blueCmd | I get crashes when accessing my int with address 0x1 | 12:00 |
| blueCmd | I'm sure it's not a software fault, so it must be in the specification | 12:01 |
| * blueCmd is super-duper serious | 12:01 | |
| rah | sundsvall looks like a nice place | 12:02 |
| rah | on openstreetmap | 12:02 |
| * stekern disconnects the alignment exception and exclaims, fixed! | 12:02 | |
| stekern | rah: it was pretty nice, a small city, but not *too* small. I decided to study there instead of in stockholm (where I was living when I applied), because I wanted to get out of my parents house and get at least a taste of student life. | 12:05 |
| stekern | I was kind of lucky when it came to the studies there too, they made some changes right when there was time for the third year. Instead of normal lecture type of studies, we were assigned an open office space with our own desks and the studies were in the form of projects that ended in 'products' | 12:07 |
| stekern | I think they only did that for a couple of years though. | 12:09 |
| blueCmd | stekern: pretty sure I need something mapped to 0x0 as well | 12:12 |
| blueCmd | better just disable bus errors | 12:12 |
| stekern | let's just disable all exceptions, they are just distractions from the code we wnat to run anyway, right? | 12:13 |
| blueCmd | stekern: | 12:19 |
| blueCmd | how can I do multi-threads without exceptions?! | 12:19 |
| blueCmd | stupid idea | 12:20 |
| rah | stekern: interesting mode of teaching | 13:06 |
| rah | and I can understand wanting to get away from parents :-) | 13:07 |
| * rah did the same | 13:07 | |
| fnunes | stekern: Hi, good afternoon. The other day you posted a .cfg file for a Digilent Atlys board for OpenOCD. Could you please poste it again ? It's tha tmy computer broke down and I lost it. Thanks. | 13:38 |
| stekern | fnunes: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-07-22.log.html#t15:57 | 13:52 |
| fnunes | stekern: Thanks a lot stekern. | 13:55 |
| maxpaln | What a week! The archived project that successfully boots Linux has been sent to customer :-) Thanks a LOT to those of you who helped me debug this far - I owe you a beer in Munich! Have a good weekend all - next marks the start of the transition to newer code ... ooooh! | 14:51 |
| blueCmd | so whyyy doesn't TLS sections get loaded properly... | 15:37 |
| dalias | bluecmd, ? | 15:51 |
| blueCmd | I have this: | 15:51 |
| blueCmd | __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale; | 15:51 |
| blueCmd | &global_locale: 302c2af8 | 15:52 |
| blueCmd | this is loaded into something called 'current_locale' on thread startup | 15:52 |
| blueCmd | first thread: | 15:52 |
| dalias | are global_locale and _nl_global_locale the same? | 15:52 |
| blueCmd | current 302c2af8 | 15:52 |
| blueCmd | dalias: yes | 15:52 |
| dalias | ok | 15:52 |
| blueCmd | second thread: | 15:52 |
| blueCmd | current 00000001 | 15:52 |
| dalias | sounds like pthread_create is either setting the thread pointer wrong, or not copying TLS right | 15:53 |
| blueCmd | it gets a value (or just reuses memory) | 15:53 |
| dalias | this is in glibc i assume? | 15:53 |
| blueCmd | dalias: yes, glibc | 15:53 |
| dalias | i would check clone | 15:53 |
| dalias | and make sure it's passing the right pointer | 15:53 |
| blueCmd | setting the TP is the kernel job, but sure | 15:54 |
| blueCmd | I'll make sure r10 is correct | 15:54 |
| dalias | well you have to _pass_ the right value for the kernel to set the right one | 15:54 |
| dalias | also you might, in gdb, do x/16x $r10 | 15:54 |
| blueCmd | yes, it's a good point | 15:54 |
| blueCmd | sure, If I had gdb | 15:54 |
| dalias | well you could use inline asm to read r10 and then print an array startin there | 15:55 |
| blueCmd | I don't really know what the real value should be though | 15:56 |
| dalias | well for example if you saw it being off by a few slots, you'd know that there was just a wrong constant offset somethere | 16:02 |
| blueCmd | I looked at the memory around it, it has data but nothing that looks correct | 16:02 |
| blueCmd | I _think_ this broke when I rebased stuff to 2.19 | 16:07 |
| blueCmd | but I have no easy way to test that hypothesis | 16:07 |
| olofk | blueCmd: Why no gdb? | 16:14 |
| blueCmd | olofk: because I haven't set it up and I don't think anybody implemented userland support | 16:14 |
| olofk | userland support? (I know close to zero about gdb) | 16:16 |
| blueCmd | olofk: running stuff in userspace | 16:21 |
| olofk | Still don't understand, but I also realize I'm not _that_ interested in the subject. Just thought that we had a proper gdb port | 16:24 |
| blueCmd | olofk: I don't think you can run gdb on or1k, that's what I'm saying | 16:25 |
| olofk | ah yes.. you need to run it on target | 16:25 |
| blueCmd | dalias: I think I found my TLS problem | 16:35 |
| blueCmd | it was in the rebase | 16:35 |
| dalias | something glibc changes in the layout of the TLS-related stuff? | 16:39 |
| blueCmd | https://github.com/bluecmd/or1k-glibc/blob/121f056932594385bd9e09e8eeffd15b942e4e99/sysdeps/unix/sysv/linux/or1k/nptl/createthread.c | 16:39 |
| blueCmd | that override isn't needed for 2.19 | 16:39 |
| blueCmd | so I removed it | 16:40 |
| blueCmd | I forgot to move TLS_VALUE to what is now called TLS_DEFINE_INIT_TP | 16:40 |
| blueCmd | and the default is just (char *) pd | 16:40 |
| dalias | yeah figured it was something like thast | 16:40 |
| dalias | (wrong adjustment passed to clone) | 16:40 |
| dalias | that's why i suggested printing a range around the thread pointer and trying to see how much it was off by | 16:41 |
| blueCmd | dalias: right, but that wouldn't have worked | 16:41 |
| blueCmd | 1) it's wrong by much | 16:41 |
| blueCmd | 2) this is pointer->pointer->pointer | 16:41 |
| blueCmd | the possibility of having a crash when scanning 2 is quite big | 16:42 |
| blueCmd | anyway, this works now \o/ | 16:42 |
| olofk | Using emacs is a pain with a half-working ctrl k | 18:33 |
| olofk | ey | 18:33 |
| olofk | I hate that I can't decide if parameters should be uppercase or lowercase in verilog | 18:54 |
| stekern | uppercase | 19:01 |
| olofk | LOWERCASE | 19:02 |
| olofk | But yes, uppercase is better. They are constants after all | 19:02 |
| stekern | you can also consider eLiTE | 19:03 |
| olofk | Good thinking, but we should reserve that for mostly static signals, like reset | 19:04 |
| blueCmd | olofk: clock is static | 19:08 |
| blueCmd | no? | 19:08 |
| blueCmd | stekern: did you see that kernel guy's other patches? | 19:09 |
| stekern | you mean the fix mes? yeah | 19:34 |
| stekern | those were more sad than funny though, but they probably fueled the funny one | 19:38 |
| blueCmd | stekern: yeah | 20:06 |
| stekern | the all time funniest lkml post is this though: https://lkml.org/lkml/1996/3/6/65 | 20:27 |
| stekern | and the follow-up: https://lkml.org/lkml/1996/3/7/97 | 20:27 |
| hansfbaier | Hello folks, openocd already seems to have USB Blaster II support: http://openocd.sourceforge.net/doc/doxygen/html/usb__blaster_8c_source.html | 20:36 |
| hansfbaier | But looks like https://github.com/openrisc/openOCD | 20:37 |
| hansfbaier | did not pull those changes yet. | 20:37 |
| olofk | stekern: ps. sheesh, i hope these mails dont get archived! :) | 20:37 |
| olofk | hansfbaier: Good to hear from you. Are you leaving asia for the upcoming OpenRISC conference? :) | 20:37 |
| hansfbaier | olofk: I'd like to, but it's quite expensive... | 20:42 |
| hansfbaier | stekern: How is sublime doing? I am quite into synthesis right now (bought an Novation UltraNova) | 20:42 |
| hansfbaier | olofk: Wow, it's in Munich, so close to home. | 20:43 |
| olofk | hansfbaier: Yes, I can understand that it might be a bit hard on the wallet. Some day we'll hopefully move this road show to a location near your hideout | 20:43 |
| hansfbaier | olofk: Bali might be a great choice ;) | 20:44 |
| hansfbaier | olofk: Or Kuala Lumpur a very cost effective one | 20:44 |
| hansfbaier | Thanks to Air Asia | 20:44 |
| olofk | hansfbaier: Very good idea. We really should take the opportunity to host the conference where the weather is nice | 20:44 |
| olofk | Cambridge was surprisingly warm though | 20:45 |
| olofk | Is there any reason to allow writes to a full FIFO? I'm a bit inspired by AXI4 stream, where it's not really possible to overflow and underflow FIFOs | 20:47 |
| blueCmd | so somewhere I have some code that passes the wrong fini when linked with -pie | 20:50 |
| olofk | stekern: Do you know if mor1kx_simple_dpram_sclk.v uses FFs for small FIFO sizes? | 20:51 |
| olofk | and maps to tech-specific RAMs otherwise | 20:52 |
| blueCmd | \o/ fixed | 21:00 |
| hansfbaier | olofk: Is orpsocv3 superseded by fusesoc? | 21:14 |
| olofk | hansfbaier: Yes | 21:14 |
| hansfbaier | thanks | 21:14 |
| blueCmd | hansfbaier: i think it's techincally a rename, but olofk can correct me there | 21:16 |
| olofk | That's true. There isn't anything OpenRISC-related in the codebase, so I wanted a new name to indicate that it can be used for FPGA stuff in general | 21:17 |
| olofk | Renaming stuff is always a pain. I think stekern called it confusesoc :) | 21:19 |
| hansfbaier | olofk: The Readme still contains links to orpsocv3 | 21:19 |
| olofk | doh :( | 21:19 |
| hansfbaier | olofk: sorry wrong | 21:20 |
| hansfbaier | I should go to bed again... | 21:20 |
| olofk | :) | 21:20 |
| blueCmd | stekern: I get super-weird lockups in qemu with virtio | 21:31 |
| blueCmd | i I have threads that just stop and wait for reads on my 9p virtfs mount, the way to make them continue is to do "ls " or something else that "touches" the mount and everythign continues | 21:32 |
| blueCmd | so I have a while [ true ]; ls /srv/build/; done in another ssh session running | 21:33 |
| blueCmd | poke53281: have you heard of something like that? | 21:34 |
| blueCmd | stekern: also, I get these ethoc lockups from time to time (they resolve themselves after a while, might be related): http://78220df5d984d274.paste.se/ | 21:52 |
| blueCmd | yeah now it deadlocked to the point where sshd would just refuse connections | 22:13 |
| blueCmd | but existing sessions were alive so I could look at /proc/interrupt to see ethoc interrupts go up, but not virtio | 22:14 |
| poke53281 | blueCmd: I am currently programming a virtio device for jor1k. | 22:28 |
| poke53281 | exactly on 9p :) | 22:28 |
| poke53281 | According to what I know, that shouldn't happen | 22:29 |
| rah | free hardware designs have an economic advantage over proprietary designs in that they leverage the work of many people, bazaar style | 22:30 |
| rah | so why aren't free hardware chip designs taking over the silicon industry? | 22:30 |
| poke53281 | blueCmd: 9p should raise the interrupt every time it has finished one request. | 22:31 |
| poke53281 | might be a strange problem with the big endianness. | 22:31 |
| blueCmd | poke53281: hm weird | 22:31 |
| blueCmd | yeah | 22:32 |
| blueCmd | poke53281: how are you tackling that btw? | 22:32 |
| blueCmd | I just s/readl/ioread32be/g | 22:32 |
| poke53281 | the virtioring must be swapped. The 9p commands are already in small endian as far as I see. | 22:32 |
| poke53281 | How do I tackle this? Trial and error. And everytime I have to test it I ask myself who the hell made the initial definition for openrisc to make it big endian and what was he thinking. | 22:33 |
| blueCmd | :-) | 22:34 |
| poke53281 | So far I think you are correct with the substitution. | 22:34 |
| poke53281 | I am still at the init part of the 9p filesystem. But I want to implement a small hello world filesystem (like http://fuse.sourceforge.net/helloworld.html) this weekend. Then I hopefully know more. | 22:36 |
| poke53281 | If I encounter any further endianess problem I will tell you. | 22:36 |
| blueCmd | poke53281: please do, thanks | 22:36 |
| poke53281 | So far 9p seems to be fine. | 22:36 |
| poke53281 | So everything send and received is small endian. | 22:36 |
| blueCmd | poke53281: I think what I'm having problems with are general lockups though, something that seems to be locking parts of the system | 22:36 |
| blueCmd | not sure what that is | 22:36 |
| blueCmd | ethoc spits out that its trasmit queue is stuck every now and then | 22:37 |
| poke53281 | So far the virtio descriptors in the virtioring are big endian. Therefore qemu doesn't know how to handle this. I am not sure if this is a bug in Linux or a bug in Qemu. | 22:37 |
| poke53281 | Yes, there is a limit of the buffer. 9p must handle all requests, otherwise the transmit buffer will be full. | 22:39 |
| blueCmd | for ethoc? | 22:39 |
| poke53281 | No | 22:39 |
| blueCmd | that sounds unrelated :P | 22:39 |
| poke53281 | the virtio ring. | 22:39 |
| blueCmd | but yeah, might be related | 22:39 |
| blueCmd | I got lockups when I used NFS over ethoc as well IIRC | 22:39 |
| blueCmd | that was a while ago though | 22:39 |
| poke53281 | Let's see if I can implement my filesystem without such problems. But I don't use ethoc. I use the virtio memory device. | 22:40 |
| blueCmd | poke53281: don't you offer connectivity to the outside world? | 22:40 |
| poke53281 | I do | 22:40 |
| blueCmd | through? | 22:41 |
| poke53281 | Through a "anonymous" proxy in the USA. | 22:41 |
| blueCmd | well, through ethoc? | 22:41 |
| poke53281 | Yes | 22:41 |
| blueCmd | right, then our setups are the same | 22:41 |
| blueCmd | I'm using virio for /dev/sda (root), virtfs for /srv/build and /home/bluecmd/or1k-devel and ethoc for connectivity | 22:42 |
| poke53281 | Yes, but I don't run 9p over ethernet. I run it over the virtio memory device. According to one your last emails you did the same. | 22:42 |
| blueCmd | yes, I run it mmio | 22:42 |
| blueCmd | yes, I run virtio over mmio* | 22:43 |
| blueCmd | ethoc is just standard ethoc whatever that is | 22:43 |
| blueCmd | https://github.com/bluecmd/or1k-devel/blob/master/tests/qemu-system | 22:43 |
| blueCmd | that's my configuration for qemu | 22:43 |
| poke53281 | But do you rund virtfs (9p) over virtio/mmio? | 22:44 |
| blueCmd | yes | 22:44 |
| poke53281 | Yes, then our configurations are indeed the same. I will tell you about any lookup problems. But I don't hope so. I want to run everything from virtfs in future. | 22:46 |
| blueCmd | cool! I haven't attempted running root over it, I saw some notice / patch to do that though | 22:47 |
| poke53281 | NFS as rootfs is also possible. So, why not 9p. | 22:48 |
| poke53281 | I can run a script which mounts this via chroot. | 22:48 |
| blueCmd | that should work yes | 22:49 |
| poke53281 | Unfortunately I need a small initramfs for this. But Ok. | 22:49 |
| blueCmd | should be possible to do without that, that's the patch I saw | 22:50 |
| poke53281 | Unfortunetly the patch for virtio-framebuffer from 2009 never made it into the kernel. Don't know why. | 22:51 |
| poke53281 | Also there is no virtio-sound. | 22:51 |
| poke53281 | Both would be great additions. | 22:51 |
| blueCmd | Indeed | 22:51 |
| poke53281 | But there is a virtio-pci. | 22:51 |
| blueCmd | but that's PCI slave right? not complex? (or what it's called for pci) | 22:52 |
| blueCmd | I think virtio-pci is a "replacement" for virtio-device/mmio | 22:52 |
| poke53281 | Not sure. Probably it works only with simple devices. | 22:52 |
| poke53281 | No, I think, this is for using real pci devices from the host inside the guest. | 22:53 |
| blueCmd | Default to -virtfs is to use virtio-pci I think, and not mmio | 22:53 |
| blueCmd | hm, maybe | 22:53 |
| poke53281 | http://www.ibm.com/developerworks/library/l-virtio/ | 22:53 |
| poke53281 | figure 3 | 22:53 |
| poke53281 | the virtio-pci is a normal device like bulk,net,console | 22:54 |
| blueCmd | ah, I'm thinking of virtio-9p-pci I think | 22:55 |
| blueCmd | yes | 22:55 |
| blueCmd | sorry for the confusion | 22:55 |
| -!- Netsplit *.net <-> *.split quits: ssvb, jeremybennett | 23:29 | |
| poke53281 | blueCmd: There might be indeed a problem with virtio. | 23:40 |
| poke53281 | and big endian | 23:40 |
| poke53281 | you changed only the mmio part? | 23:40 |
| poke53281 | so only drivers/virtio/virtio_mmio.c? | 23:41 |
| blueCmd | poke53281: https://github.com/bluecmd/or1k-linux/commit/b1d42a4c86262d46007c4c2245be40b6147689cf | 23:43 |
| blueCmd | that's the only thing I changed I think | 23:43 |
| poke53281 | I am not quite sure, but one problem is, that this only one part. The other part is the virtioring, a buffer which the host reads and writes. | 23:46 |
| poke53281 | And of course, there is an endian problem as well. | 23:47 |
| poke53281 | But it looks like, that qemu tackles this. | 23:47 |
| poke53281 | But is this part well tested in QEMU? The host has to "consume" descriptors in order to free the buffer. | 23:48 |
| blueCmd | stuff is working for me, except for the lockup, so I wouldn't think that something with the data transfer is broken | 23:48 |
| --- Log closed Sat Jul 26 00:00:36 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!