IRC logs for #openrisc Tuesday, 2014-05-20

--- Log opened Tue May 20 00:00:56 2014
stekernthis is annoying, my chrome at work has grown insane...05:44
stekernpressing the back button does nothing, it just causes the browser to infinitely load the page05:45
stekernit'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
blueCmdstekern: yes, it's a feature08:17
stekern4 rows of output running dual-core ;)09:55
stekernI guess something goes wrong when the timer starts running...09:57
stekernwonder how that should be setup09:57
blueCmdstekern: ooooh! :D10: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
stekernbut the timer is only initialized on cpu 0, so it's a good point-of-poking-entry10:33
wallentohey guys. are there any plans to keep the current toolchain compatible to old or1k implementations?10:54
wallentoespecially with regard to lwa/swa?10:54
stekernyes, there are still nothing that isn't afaik10:55
wallentoshouldn't there be something like -mno-atomic10:56
wallentoand then use macros: #define SWA l.swa <-> #define SWA l.sw10:56
wallentojust a wild guess10:56
stekernthat sounds dangerous ;)10:56
wallentoyes, it does10:57
blueCmdwallento: no, there shouldn't be10:57
stekernthe support in binutils doesn't break older implementations10:57
wallentoand people should know what they are doing10:57
wallentookay, how is that?10:57
blueCmdwallento: but an mno-atomic should probably be added to disable expansion of the atomic builtins10:57
blueCmdso that ./configure-tests doesn't detect the builtins10:58
stekernthe 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
blueCmdhaving code that assume atomicity suddenly implicitly being compiled into a non-atomic binary is the worst solution IMO10:59
blueCmdstekern: +110:59
stekern... ./configure-tests might be a valid argument against that though10:59
wallentoi am a bit lost10:59
wallentolets say I have an or1200 silicon10:59
wallentoI can't use or1k-elf-gcc -mnewlib any more, correct?11:00
stekernwhy not?11:00
wallentoas it contains invalid isntructions11:00
wallentol.lwa and l.swa11:00
stekerndoes it?11:00
stekerndid you put them there?11:00
wallentono, not until now11:00
wallentothey are in the multicore branch11:01
wallentobut in fact l.lwa and l.swa is not multicore specific11:01
stekernno, but do they make a lot of sense in newlib (apart for your very special purposes?)11:02
stekernI would imagine that running threaded baremetal applications isn't very common11:02
wallentocrt0.S uses them for -mmulticore11:03
wallentoI think11:03
wallentoand there are or1k-support convenience functions11:03
stekernyes, but that doesn't answer the question ;)11:03
wallentolike or1k_sync_cas()11:03
wallentobut you will not use the function if you don't know you have support I suppose11:04
wallentoI can make it that this is only included with -mmulticore I think11:05
wallentoand binutils/gcc doesn't emit them whatsoever?11:06
wallentolwa and swa11:06
stekernbinutils 'emits' them if you create asm with them in it11:07
wallentookay, got it11:07
stekernblueCmd have just added the atomic builtins to gcc11:07
stekern...but, programs that would have required that would have failed to compile up until now anyway (right bluecmd)11:08
stekernso the only issue with that is that ./configure scripts might detect them now11:08
wallentookay, 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 exception11:10
stekernhmm, -mmulticore?11:15
stekernthat's a flag you added to gcc, right?11:15
wallentoyes, at the moment simply for different crt0.S11:15
wallentoI think for most stuff it is okay to use the multicore implementation as the standard implementation, like the reentrancy stuff11:18
wallentocrt0.S only has lwa and swa for the exit case:
wallentoi think I can avoid this11:20
stekernyeah, 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
wallentodefine "sense" ;)11:22
stekernI guess what I'm saying is, running a multithreaded newlib on several cores probably only makes sense to a very small amount of people11:23
stekernif we add changes that doesn't add on a lot of cruft to support that, fine11:23
stekernbut if it means adding a lot of code for that small use case that makes our toolchains ports harder to maintain, then not so fine11:27
wallentommh, okay. There are essentially the following changes:11:28
wallentommh, I need to rethink and will write up a short mailing list mail11:30
stekernwallento: did you see the inter-process interrupt discussion me and olofk had btw?11:45
wallentoI saw some parts, but have to read the entire discussion11:48
stekernto summarize, I have this proof-of-concept core:
stekernwhich is very simple, it consists of a set of per-cpu control and status regs11:49
stekernand a set of irq-lines to each cpu11:49
wallentoand its a shared slave module accessed via the bus?11:49
wallentoand each cores addresses it with its offset11:49
wallentosounds good11:50
stekernI guess the question is, does it need to be more complex, or is such a simple one sufficient?11:50
stekernat least, from what I can tell, that will fulfill what Linux needs11:51
wallentoI had something similar in mind, that also had input interrupts11:51
wallentoand the cores can switch those peripheral irqs to their interrupt lines11:51
wallentolike APIC i think11:52
stekernI think this core will be a part of a bigger multi-processor irq-core11:52
wallentoah, okay11:52
wallentoyeah, for communication its okay11:52
wallentocould be some mailboxes, but not really necessary11:52
stekernright, that would be the "more complex"11:53
wallentowith your core: what if two cores send an interrupt?11:54
wallentoto the same DST11:54
wallentothat would require N*N registers to be fully flexible11:55
stekernyeah, 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 free11:56
wallentobut for linux it works because there is no wild itnerrupt sending, but essentially some master/slave approach?11:56
wallentochecking and setting is not atomar :)11:57
stekernwell, it is to be seen if it "works", so far I've got 4 lines of console output with it ;)11:57
stekernyeah, but usually that operation is done under a lock11:58
stekernas far as I understand that should work?11:58
wallentoyes, if you secure it on this level11:58
stekernas an example, how the ipi send is done for the arm gic:
stekernbut, the dual-core case is of course a special one, there the situation can't occur12:02
stekernsince a cpu is not going to send ipi to itself ;)12:02
blueCmdstekern: hm? can you rephrase the question / statement / whatever regarding atomics?12:04
blueCmdI'm a bit slow today for some reason12:04
stekernjust that, gcc doesn't wildly emit the atomic builtins, unless someone is explicitly calling them, right?12:04
blueCmdkind of12:05
blueCmdif gcc is compiled with atomics builtin, c++ might emit them12:05
blueCmdif it's compiled without, it will not12:05
stekernhmm, ok... how do you compile it without?12:05
blueCmdso we might need to change something12:05
blueCmdstekern: well, currently you don't12:06
stekernah.. ok, so that's a bit of an issue12:06
blueCmdwe might even need to define a target for that12:08
stekernhmmm... can't it be handled with the suggested -mno-atomic?12:09
stekernsimilar to -mno-hard-div et al?12:09
blueCmdI don't know how you would pass it to gcc to compile itself with it12:11
blueCmdCFLAGS='-mno-atomics' ./configure ?12:11
stekernhmm, I think I don't understand what "compiled with atomics builtin" means12:13
stekernisn't the builtins emitted similar to how instructions are emitted?12:14
blueCmdsorry, afk for a bit - need to do some actual work :)12:16
stekernno hurry :)12:17
zakatoSalut! Anyone ever tried to run linux compiled for openrisc on qemu?18:05
zakatoI found a history in this channel about this topic but all the link are died18:08
zakatoI tried to do it by using qemu-system-or32 -m 256 -nographic -kernel vmlinux ==> it print a message about connect to or so18:10
stekernlinks to where?18:10
zakatolinks to some patches18:10
stekernyour command line works here18:12
zakatoI used vnc to connect to the address but it give me hand to a command line "qemu> "18:13
stekernaha, yeah I thought that 5900 sounded familiar ;)18:14
stekernso... why does it start a vnc server?18:14
zakatoI 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
stekernI think I might have built from this repo though:
zakatoyou was able to run the linux with qemu?18:17
stekernbut I don't think there's anything in there that would make a big difference for what you are trying to do18:17
stekernyes, it even automatically got an IP via dhcp and booted debian via my nfs share18:17
stekernI've actually never tried that before ;)18:18
zakatoif 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
stekernI think the odd vnc configuration is a qemu configuration one18:20
stekernif you can drop me your vmlinux, I can try to run that in my qemu to rule that out18:20
zakatook, I will send it to you when I meet my working pc :). sorry for this.18:22
zakatoI will return after some minutes, I hope you will wait.18:24
stekernsure, no hurry18:24
blueCmdoh, I didn't even know we had full sytem qemu for or1k18:39
zakatook, now I am in my pc. this is my vmlinux
zakatohope you can test it and provide me the result soon.18:58
zakatosomething 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
stekernhmmm... 59MB?19:02
zakatoit contain thte user space in it,19:03
zakatoI can give you another without the user space it is around 3 mb19:04
stekernyeah, neither of those boot19:06
stekernthat was the one I tried with19:08
zakatook, thanks19:31
zakatoI will try yours19:31
zakatoyour image print the same as mine19:37
zakatoVNC server running on `'19:37
zakatoand the same thing with the vnc viewer19:38
stekernyeah, the vncserver thing doesn't happen here19:39
stekernbut something is off with your image too19:39
zakatook, I will spend more time playing with qemu to figure something out.19:40
zakatothank you for everything.19:41
stekernmy pleasure19:43
_franck_r8 = 0x11420:02
_franck_I was expecting r8 to be 0x11820:02
blueCmddoes anyone here know what the female connector to this one is named?
_franck_something like this:
blueCmdthat seems to be something I can use20:12
blueCmdI want 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
blueCmdyeah, I guess that's what I need to do20:15
blueCmdrmii to mii20:54
blueCmdon altera20:54
blueCmdSurely 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_tell me what you think before I send a patch upstream21:19
_franck_as you are the openrisc maintainer21: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 this21:22
blueCmdI 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 SPRs21:23
blueCmdin that case you already do stuff with the SPRs so I guess it doesn't matter21:23
_franck_ok, fair enough21:24
--- Log closed Wed May 21 00:00:57 2014

Generated by 2.15.2 by Marius Gedminas - find it at!