| --- Log opened Tue May 20 00:00:56 2014 | ||
| stekern | this is annoying, my chrome at work has grown insane... | 05:44 |
|---|---|---|
| stekern | pressing the back button does nothing, it just causes the browser to infinitely load the page | 05:45 |
| stekern | it's like it's trying to tell me - "don't look back stekern, just go forward!" | 05:47 |
| -!- _franck__ is now known as _franck_ | 05:51 | |
| blueCmd | stekern: yes, it's a feature | 08:17 |
| stekern | blueCmd: https://asciinema.org/a/9661 | 09:54 |
| stekern | 4 rows of output running dual-core ;) | 09:55 |
| stekern | I guess something goes wrong when the timer starts running... | 09:57 |
| stekern | wonder how that should be setup | 09:57 |
| blueCmd | stekern: ooooh! :D | 10:27 |
| stekern | ...and it's a nice subtle bug to investigate, both cores are running happily it seems, but the boot isn't making forward progress ;) | 10:31 |
| blueCmd | haha | 10:31 |
| stekern | but the timer is only initialized on cpu 0, so it's a good point-of-poking-entry | 10:33 |
| wallento | hey guys. are there any plans to keep the current toolchain compatible to old or1k implementations? | 10:54 |
| wallento | especially with regard to lwa/swa? | 10:54 |
| stekern | yes, there are still nothing that isn't afaik | 10:55 |
| wallento | shouldn't there be something like -mno-atomic | 10:56 |
| wallento | and then use macros: #define SWA l.swa <-> #define SWA l.sw | 10:56 |
| wallento | just a wild guess | 10:56 |
| stekern | that sounds dangerous ;) | 10:56 |
| wallento | yes, it does | 10:57 |
| blueCmd | wallento: no, there shouldn't be | 10:57 |
| stekern | the support in binutils doesn't break older implementations | 10:57 |
| wallento | and people should know what they are doing | 10:57 |
| wallento | okay, how is that? | 10:57 |
| blueCmd | wallento: but an mno-atomic should probably be added to disable expansion of the atomic builtins | 10:57 |
| blueCmd | so that ./configure-tests doesn't detect the builtins | 10:58 |
| stekern | the support in gcc (builtins) can't work without l.swa/l.lwa, so I don't think there's a point making that 'backwards compatible' | 10:58 |
| blueCmd | having code that assume atomicity suddenly implicitly being compiled into a non-atomic binary is the worst solution IMO | 10:59 |
| blueCmd | stekern: +1 | 10:59 |
| stekern | ... ./configure-tests might be a valid argument against that though | 10:59 |
| wallento | i am a bit lost | 10:59 |
| wallento | lets say I have an or1200 silicon | 10:59 |
| stekern | yup | 11:00 |
| wallento | I can't use or1k-elf-gcc -mnewlib any more, correct? | 11:00 |
| stekern | why not? | 11:00 |
| wallento | as it contains invalid isntructions | 11:00 |
| wallento | l.lwa and l.swa | 11:00 |
| stekern | does it? | 11:00 |
| stekern | did you put them there? | 11:00 |
| wallento | no, not until now | 11:00 |
| wallento | they are in the multicore branch | 11:01 |
| wallento | but in fact l.lwa and l.swa is not multicore specific | 11:01 |
| stekern | no, but do they make a lot of sense in newlib (apart for your very special purposes?) | 11:02 |
| stekern | I would imagine that running threaded baremetal applications isn't very common | 11:02 |
| wallento | crt0.S uses them for -mmulticore | 11:03 |
| wallento | I think | 11:03 |
| wallento | and there are or1k-support convenience functions | 11:03 |
| stekern | yes, but that doesn't answer the question ;) | 11:03 |
| wallento | like or1k_sync_cas() | 11:03 |
| wallento | but you will not use the function if you don't know you have support I suppose | 11:04 |
| wallento | I can make it that this is only included with -mmulticore I think | 11:05 |
| wallento | and binutils/gcc doesn't emit them whatsoever? | 11:06 |
| wallento | lwa and swa | 11:06 |
| stekern | binutils 'emits' them if you create asm with them in it | 11:07 |
| wallento | okay, got it | 11:07 |
| stekern | blueCmd have just added the atomic builtins to gcc | 11:07 |
| stekern | ...but, programs that would have required that would have failed to compile up until now anyway (right bluecmd) | 11:08 |
| stekern | ? | 11:08 |
| stekern | so the only issue with that is that ./configure scripts might detect them now | 11:08 |
| wallento | okay, let me then shortly summarize: The way to go is to create a multilib for -mmulticore, that uses the special SPRs and lwa and swa, correct? | 11:09 |
| stekern | ...that said, IMO the lack of l.lwa/l.swa should be handled with emumlation routines in the invalid instruction exception | 11:10 |
| stekern | hmm, -mmulticore? | 11:15 |
| stekern | that's a flag you added to gcc, right? | 11:15 |
| wallento | yes, at the moment simply for different crt0.S | 11:15 |
| wallento | I think for most stuff it is okay to use the multicore implementation as the standard implementation, like the reentrancy stuff | 11:18 |
| wallento | crt0.S only has lwa and swa for the exit case: https://github.com/wallento/or1k-src/blob/multicore/libgloss/or1k/crt0.S#L623 | 11:20 |
| wallento | i think I can avoid this | 11:20 |
| stekern | yeah, I guess that sounds ok, as long as you keep what makes sense for "normal" people and what only makes sense for "you" seperated. | 11:21 |
| wallento | define "sense" ;) | 11:22 |
| stekern | heh | 11:22 |
| stekern | I guess what I'm saying is, running a multithreaded newlib on several cores probably only makes sense to a very small amount of people | 11:23 |
| stekern | if we add changes that doesn't add on a lot of cruft to support that, fine | 11:23 |
| stekern | but if it means adding a lot of code for that small use case that makes our toolchains ports harder to maintain, then not so fine | 11:27 |
| wallento | mmh, okay. There are essentially the following changes: | 11:28 |
| wallento | mmh, I need to rethink and will write up a short mailing list mail | 11:30 |
| wallento | :) | 11:30 |
| stekern | =) | 11:30 |
| stekern | wallento: did you see the inter-process interrupt discussion me and olofk had btw? | 11:45 |
| stekern | *inter-processor | 11:46 |
| wallento | I saw some parts, but have to read the entire discussion | 11:48 |
| stekern | to summarize, I have this proof-of-concept core: http://pastie.org/9192442 | 11:49 |
| stekern | which is very simple, it consists of a set of per-cpu control and status regs | 11:49 |
| stekern | and a set of irq-lines to each cpu | 11:49 |
| wallento | and its a shared slave module accessed via the bus? | 11:49 |
| stekern | yes | 11:49 |
| wallento | and each cores addresses it with its offset | 11:49 |
| wallento | okay | 11:49 |
| stekern | right | 11:50 |
| wallento | sounds good | 11:50 |
| stekern | I guess the question is, does it need to be more complex, or is such a simple one sufficient? | 11:50 |
| stekern | at least, from what I can tell, that will fulfill what Linux needs | 11:51 |
| wallento | I had something similar in mind, that also had input interrupts | 11:51 |
| wallento | and the cores can switch those peripheral irqs to their interrupt lines | 11:51 |
| wallento | like APIC i think | 11:52 |
| stekern | I think this core will be a part of a bigger multi-processor irq-core | 11:52 |
| wallento | ah, okay | 11:52 |
| wallento | yeah, for communication its okay | 11:52 |
| wallento | could be some mailboxes, but not really necessary | 11:52 |
| stekern | right, that would be the "more complex" | 11:53 |
| wallento | with your core: what if two cores send an interrupt? | 11:54 |
| wallento | to the same DST | 11:54 |
| wallento | that would require N*N registers to be fully flexible | 11:55 |
| stekern | yeah, that's a caveat... the solution so far is that the SRC need to check bit 30 in the DST status reg to be sure that it's free | 11:56 |
| wallento | but for linux it works because there is no wild itnerrupt sending, but essentially some master/slave approach? | 11:56 |
| wallento | checking and setting is not atomar :) | 11:57 |
| stekern | well, it is to be seen if it "works", so far I've got 4 lines of console output with it ;) | 11:57 |
| stekern | yeah, but usually that operation is done under a lock | 11:58 |
| wallento | okay | 11:58 |
| stekern | as far as I understand that should work? | 11:58 |
| wallento | yes, if you secure it on this level | 11:58 |
| stekern | as an example, how the ipi send is done for the arm gic: http://lxr.free-electrons.com/source/drivers/irqchip/irq-gic.c#L650 | 11:59 |
| stekern | but, the dual-core case is of course a special one, there the situation can't occur | 12:02 |
| stekern | since a cpu is not going to send ipi to itself ;) | 12:02 |
| blueCmd | stekern: hm? can you rephrase the question / statement / whatever regarding atomics? | 12:04 |
| blueCmd | I'm a bit slow today for some reason | 12:04 |
| stekern | just that, gcc doesn't wildly emit the atomic builtins, unless someone is explicitly calling them, right? | 12:04 |
| blueCmd | kind of | 12:05 |
| blueCmd | if gcc is compiled with atomics builtin, c++ might emit them | 12:05 |
| blueCmd | if it's compiled without, it will not | 12:05 |
| stekern | hmm, ok... how do you compile it without? | 12:05 |
| blueCmd | so we might need to change something | 12:05 |
| blueCmd | stekern: well, currently you don't | 12:06 |
| stekern | ah.. ok, so that's a bit of an issue | 12:06 |
| blueCmd | yes | 12:07 |
| blueCmd | we might even need to define a target for that | 12:08 |
| stekern | hmmm... can't it be handled with the suggested -mno-atomic? | 12:09 |
| stekern | similar to -mno-hard-div et al? | 12:09 |
| blueCmd | I don't know how you would pass it to gcc to compile itself with it | 12:11 |
| blueCmd | CFLAGS='-mno-atomics' ./configure ? | 12:11 |
| stekern | hmm, I think I don't understand what "compiled with atomics builtin" means | 12:13 |
| stekern | isn't the builtins emitted similar to how instructions are emitted? | 12:14 |
| blueCmd | sorry, afk for a bit - need to do some actual work :) | 12:16 |
| stekern | no hurry :) | 12:17 |
| zakato | Salut! Anyone ever tried to run linux compiled for openrisc on qemu? | 18:05 |
| stekern | yes | 18:07 |
| zakato | I found a history in this channel about this topic but all the link are died | 18:08 |
| zakato | I tried to do it by using qemu-system-or32 -m 256 -nographic -kernel vmlinux ==> it print a message about connect to 127.0.0.1:5900 or so | 18:10 |
| stekern | links to where? | 18:10 |
| zakato | links to some patches | 18:10 |
| stekern | ah | 18:12 |
| stekern | your command line works here | 18:12 |
| zakato | I used vnc to connect to the address but it give me hand to a command line "qemu> " | 18:13 |
| stekern | aha, yeah I thought that 5900 sounded familiar ;) | 18:14 |
| stekern | so... why does it start a vnc server? | 18:14 |
| zakato | I don't know, I just compiled the kernel with defconfig and then run it with qemu, I think I must change the configuration to work with qemu. Or what do you think? | 18:16 |
| stekern | I think I might have built from this repo though: https://github.com/bluecmd/or1k-qemu | 18:16 |
| zakato | you was able to run the linux with qemu? | 18:17 |
| stekern | but I don't think there's anything in there that would make a big difference for what you are trying to do | 18:17 |
| stekern | yes, it even automatically got an IP via dhcp and booted debian via my nfs share | 18:17 |
| stekern | I've actually never tried that before ;) | 18:18 |
| zakato | if I must change in the configuration files or .config of my kernel what should I add to the default one (I mean or1ksim_defconfig) to run with qemu correctly? | 18:19 |
| stekern | I think the odd vnc configuration is a qemu configuration one | 18:20 |
| zakato | Aha! | 18:20 |
| stekern | if you can drop me your vmlinux, I can try to run that in my qemu to rule that out | 18:20 |
| zakato | ok, I will send it to you when I meet my working pc :). sorry for this. | 18:22 |
| zakato | I will return after some minutes, I hope you will wait. | 18:24 |
| stekern | sure, no hurry | 18:24 |
| blueCmd | oh, I didn't even know we had full sytem qemu for or1k | 18:39 |
| zakato | ok, now I am in my pc. this is my vmlinux http://snk.to/f-ct9ex0wl | 18:57 |
| zakato | hope you can test it and provide me the result soon. | 18:58 |
| zakato | something else, before the kernel I was trying to test a simple hello world program compiled with or1k-elf-gcc. and the qemu-o32 print just some addresses! no hello world. | 19:00 |
| stekern | hmmm... 59MB? | 19:02 |
| zakato | it contain thte user space in it, | 19:03 |
| zakato | I can give you another without the user space http://snk.to/f-cdclr803 it is around 3 mb | 19:04 |
| stekern | yeah, neither of those boot | 19:06 |
| stekern | http://oompa.chokladfabriken.org/openrisc/vmlinux.bin | 19:08 |
| stekern | that was the one I tried with | 19:08 |
| stekern | err | 19:08 |
| stekern | http://oompa.chokladfabriken.org/openrisc/vmlinux | 19:09 |
| zakato | ok, thanks | 19:31 |
| zakato | I will try yours | 19:31 |
| zakato | your image print the same as mine | 19:37 |
| zakato | VNC server running on `127.0.0.1:5900' | 19:37 |
| zakato | and the same thing with the vnc viewer | 19:38 |
| stekern | yeah, the vncserver thing doesn't happen here | 19:39 |
| stekern | but something is off with your image too | 19:39 |
| zakato | ok, I will spend more time playing with qemu to figure something out. | 19:40 |
| zakato | thank you for everything. | 19:41 |
| stekern | my pleasure | 19:43 |
| _franck_ | http://pastie.org/9193859 | 20:02 |
| _franck_ | r8 = 0x114 | 20:02 |
| _franck_ | I was expecting r8 to be 0x118 | 20:02 |
| _franck_ | ? | 20:02 |
| blueCmd | does anyone here know what the female connector to this one is named? https://drive.google.com/file/d/0By6mHN3SVc5_RllWZGQ5S2lzWWM/edit?usp=sharing | 20:05 |
| _franck_ | something like this: http://www.molex.com/molex/products/listview.jsp?query=&path=cHome%23%23-1%23%23-1~~ncPCBHEADERS%23%230%23%238o&offset=0&autoNav=1&sType=z&filter=&fs=categoryid%3Apcbheaders%2Cproductname%3A%22mini-fit+jr.%22%2Capplication%3Awire-to-board%2Corientation%3Avertical%2Cnumberofrows%3A2&channel=Products | 20:07 |
| blueCmd | hm | 20:08 |
| blueCmd | yes | 20:08 |
| blueCmd | http://www.amazon.co.uk/Startech-ATX12V-4-Pin-Power-Extension/dp/B000O7WFHA/ref=pd_sim_computers_10?ie=UTF8&refRID=1BVQ6EFD30B4JSRSH34S | 20:12 |
| blueCmd | that seems to be something I can use | 20:12 |
| blueCmd | I want http://www.amazon.co.uk/Pin-Molex-ATX-Splitter-Cable/dp/B002VW9I3A/ref=sr_1_1?s=electronics&ie=UTF8&qid=1400616783&sr=1-1&keywords=atx+p4+molex but the other way around :( | 20:14 |
| _franck_ | you can just order two cables with needed end, cut them up and then solder the two parts you want together :) | 20:15 |
| blueCmd | yeah, I guess that's what I need to do | 20:15 |
| blueCmd | rmii to mii | 20:54 |
| blueCmd | on altera | 20:54 |
| blueCmd | Surely there is a core for that already? | 20:54 |
| _franck_ | stekern: I modified the relocation code of u-boot to make it work when the cpu boots from my CFI (or from any other memory which is not at 0x0) | 21:19 |
| _franck_ | http://pastie.org/private/yx20vdkoqkjoqyuygh8qbg | 21:19 |
| _franck_ | tell me what you think before I send a patch upstream | 21:19 |
| _franck_ | as you are the openrisc maintainer | 21:19 |
| blueCmd | _franck_: why not jal instead of reading the SPR_NPC? | 21:20 |
| _franck_ | well, I could do that and get the ins address in r9, what's the difference ? | 21:22 |
| _franck_ | to be honest, I didn't think about this | 21:22 |
| blueCmd | I don't know, to me it feels nicer and that's how we usually do it, but that might be to avoid having the defines for the SPRs | 21:23 |
| blueCmd | in that case you already do stuff with the SPRs so I guess it doesn't matter | 21:23 |
| _franck_ | ok, fair enough | 21:24 |
| --- Log closed Wed May 21 00:00:57 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!