IRC logs for #openrisc Tuesday, 2014-08-26

--- Log opened Tue Aug 26 00:00:23 2014
stekernpoke53282: for this particular bug? I'm fairly certain that this hw bug is what has been responsible02:51
stekernI need to restart the tests, they had stopped during the night due to an old debug trap I had inserted. But the trap was giving a false positive.02:57
stekernmaybe I can give running prboom a try soon on this setup ;)02:58
poke53282Would be nice to see something which is already heavily parallelized.03:46
poke53282something like x264. But this would look boring.03:48
stekernyeah, the prboom thing is more that I want to give that a try, and this is the platform I'm working on at the moment03:50
poke53282do you need my compile script?03:54
stekernI need to get mouse and keyboard from the silicon-heater (the ARM hps) to the openrisc core though03:54
stekernsure, if you could share that, it'd be great03:55
poke53282three patches lines. I think all of them solved by googling03:57
poke53282Three patched lines. All of the problems solved by googling.03:59
stekerncool, thanks04:13
stekernall gcc execute tests ran without crashing now05:09
poke53282great. Did they run already parallel?05:13
poke53282make -j 2 or so.05:13
poke53282take a look at your smp branch. Doesn't look like you had to change much. Shadow registers, ompic and 200 lines of codes for basic functionality.05:26
poke53282Are the timers synced in some place?05:28
poke53282Would be also nice if the number of cpus can be determined automatically during boot that you don't need the .dts file.05:33
stekernpoke53282: timers are synced, but that's a local hack I have05:42
stekernI need to fix that, I think it'll be better to just use a completely external timer05:43
stekernbut our arch/ code currently makes some assumptions about the tick timer being available05:44
poke53282But doesn't is make sense to have a timer for each cpu? then each cpu can wake up independently. Linux sends some core to sleep for a full second.  I think they have their own timer then.05:48
poke53282An external timer is Ok, but an internal timer interrupt for each core.05:50
stekernyeah, my point was just that I will need an external (accesible) timer anyway, so it might make sense to implement per-cpu timers in that as well then05:55
stekernor, rather. per-cpu interrupts from the external timer05:55
stekernbecause, the per-cpu timers need to be in sync (AFAICT)05:56
stekernthe current hack I'm using is to have a free running external timer, and then when I enable the internal tick timers, I set the timer value to the value of the external free running timer05:57
stekernso they are roughly in sync05:58
stekern <- hack06:00
poke53282That's a hack :)06:12
poke53282It looks like you plan that the spr registers will be fully independent for each core.06:12
stekernwell, it's not something I plan, that's the way things are ;)06:13
poke53282Well, I liked the idea to have the pic and the timer directly in the cpu architecture.06:17
poke53282Of course this is bad for externsions like smp06:18
olofkYeah, I would remove the PIC and timers from the CPU if I could06:19
poke53282But I wouldn't have thought, that we this feature so early.06:19
poke53282...we get this...06:20
olofkWhat feature?06:20
poke53282So far, timer and pic worked well.06:20
olofkah ok... Yes. There have been a lot of progress lately, but to be fair, it took 15 years in total ;)06:21
stekernearly? only ~15 years after the architecture was conceived ;)06:21
stekernolofk: stop stealing my sentences06:22
poke53282Ok, for me it is early. Two years ago not even Linux was running06:22
poke53282Linux 3.1 as far as I know06:23
stekern(out of tree) Linux port has been around a lot longer than that, 2.6.37 was alredy pretty stable06:24
olofkAnd we have had uclinux for quite some time before that06:24
olofkstekern: hmm... I just made a defconfig with your linux tree, and when I make menuconfig, the first option I see is 64-bit kernel enabled06:26
olofkAhh.. do I need to run menuconfig with ARCH=openrisc as well?06:27
poke53282make ARCH=openrisc menuconfig06:27
olofkYep, that changed things. I'll update the wiki06:27
olofkAnd cross-compiler tool prefix? What is that? It's set to or32-linux-06:28
poke53282It changed for some reason. But I don't care.This is the usual way for all architectures.06:28
olofkYeah, that's the linker script, right06:29
olofkBut under General setup, there's an option for Cross-compiler tool prefix. I would have assumed that it should be or1k-elf- (toolchain for building the kernel), but I might misunderstand something06:30
poke53282That's the second important place. in .config06:31
poke53282But this is his development branch.06:32
olofkIt says or1k-linux-musl- there.06:32
olofkI'm still not sure what that option is used for. Is it the prefix for building the kernel, or something that is used once the kernel is built?06:33
poke53282Yes, , not sure about the wiki06:33
poke53282it's the prefix of the toolchain06:33
olofkIf it's the first case, I would change it to or1k-elf-, but otherwise I don't know what to use06:33
poke53282or1k-linux-musl-objdump and so on06:34
olofkThe host toolchain, or the target toolchain?06:34
olofkahh.. I just realized I could read the help text in menuconfig. I get it now :)06:35
poke53282As far as I understodd, you don't need the -elf- toolchain anymore for compiling linux.06:35
olofkIt's the only one I got right now, so it's easiest for me to use it06:36
stekernyou can override it on the command line too: ARCH=openrisc CROSS_COMPILE=or1k-elf- make06:36
poke53282I amstill unsure, which Linux version you mean? In the wiki it is still the link to  git://
olofkstekern: Yeah, I saw that in the help text06:37
olofkFuck! Forgot to change branch06:37
olofkstekern: How is your master branch?06:37
stekernhmm... it's at least missing one important fix if your userspace contains l.lwa/l.swa06:39
olofkI'll switch. Compilation is quick06:40
stekernnow that's in master too06:42
olofkThere are some warnings for missing casts. Is that anything openrisc-specific?06:43
stekernin what parts?06:43
olofkDifferent parts, but many are quite similar06:44
olofksmall snippet ->
poke53282Doesn't seem to be related to or1k06:46
olofkNo, it looks like generic code to me too06:47
olofkhmm... the kernel panics in or1ksim06:48
poke53282update or1ksim too06:48
poke53282l.swa and l.lwa06:48
stekern...I have a half-baked kernel emulation for that06:50
olofkYep. New or1ksim did the trick09:14
olofkNothing happens when I telnet to the running instance. I just see the commands being echoed09:23
stekerntelnet to Linux or telnet to or1ksim?09:26
olofkDon't know if I should blame busybox or my telnet connection09:26
olofkshould be to linux09:26
olofkI'm using 10084 (the port from the uart section channel tag)09:26
olofkwell.. or1ksim then I mean09:27
olofkOr what do you mean exactly? :)09:27
stekernexactly that09:28
stekernnot that I know why that doesn't work for you09:28
stekernI can try your image here if you want09:28
olofkcool. I'll fax it!09:29
stekernhold your horses, I'll turn on the fax modem first09:29
stekernall set09:29
olofkGreat. You should be able to see it soon09:29
stekerngrrr... you put it in the wrong way around...09:30
olofkAh no! I forgot it's big endian09:30
olofkI left a copy here as well, in case something goes wrong
stekernI doubt that'll be needed, can't imagine what people need that fancy InterNet for09:32
stekernworks here09:34
olofkAs usual, there's a slight possibility that I need to turn on some use flag in a package somewhere :)09:35
stekernthat's the right attitude, who needs fancy pancy internet when you have a good trusty mora-knife09:36
stekernsanity-check, you did try to type the commands in the session where you typed 'telnet localhost 10084', right?09:40
stekernI'm asking, because typing in the session where you started or1ksim will behave just as you described09:42
stekernto be clear, I don't think you deliberately typed in that, but might you have done that by mistake?09:43
stekern(I for sure have done it many times)09:43
olofkYes, I did09:46
olofkWeird that everything is echoed in the or1ksim instance09:47
olofkMakes me think that the telnet connection works09:47
stekernyes, maybe you have some crumbs under your enter key?09:48
mor1kx[mor1kx] skristiansson pushed 4 new commits to multicore:
mor1kxmor1kx/multicore 16bfd84 Stefan Kristiansson: dcache: minor whitespace fixes09:49
mor1kxmor1kx/multicore 6ec4169 Stefan Kristiansson: dcache: change OPTION_DCACHE_SNOOP checks from "ENABLED" to "NONE"...09:49
mor1kxmor1kx/multicore 5b27fcd Stefan Kristiansson: dcache: remove check for dc_enable_i to to snoop_hit...09:49
olofkhaha.. It worked much better when I removed my local hacks from peripherals/channels/fd.c :)09:51
stekernwallento: important bug-fix:
wallentocool, did this fix your bug?11:18
stekernyes, it's stable as a rock now ;)11:24's probably the hardest mor1kx bug to crack I've encountered so far11:25
stekernso it's rather satisfying to have it solved11:25
stekernso, I will play around with this system a bit more, then I want to start moving multicore stuff over to master11:28
stekernI will probably move them over in a completely different order than how they landed in the multicore branch, but I'm thinking that I can try to pull together the stuff you've done into seperate commits with you as author.11:30
stekerndoes that sound ok?11:30
stekernwallento: oh, and another thing. I will probably want to move the snoop_valid logic out of mor1kx into the 'snoop unit', does that makes sense to you?11:34
wallentommh, what do you mean with snoop unit?13:55
stekernwallento: well, in your case, your bus arbiter15:10
stekernin my case, a couple of lines in the top module15:11
stekernbut, my point is, how that is implemented should be transparent to mor1kx15:11
stekernerr... I mean, that mor1kx shouldn't need to care about how it's implemented15:13
stekernoh, two penguins15:33
stekernprboom runs15:41
poke53282how fast?15:45
stekernit's a bit choppy, but I'm only running the cores at 50MHz15:55
stekernand fb is 640x48015:55
stekernand I don't have a keyboard15:55
stekernand running top:
LoneTechI'd note that Doom was designed for 25MHz 486es and the like, though it was carefully hand-optimized for 320x200 iirc. It literally had to be rewritten for higher resolutions.16:05
poke53282Yes, you can't compare prboom with the old doom.16:24
poke53282you work also with 32 Bit per Pixel and not just 8 Bit.16:26
poke53282stekern: Approx. how many instructions per cycle do you have?16:37
stekernwhy would you work with 32 bit/pixel?17:02
stekernmor1kx is approx 1 IPC17:02
daliaslonetech, higher res did not really require much work. the basic algorithms work for any res17:20
poke53282Well, I think your framebuffer is 32bit/pixel. So the transformation takes already time. And I am not sure whether prboom still uses 8Bit/pixel and a palette like in the old days.18:09
poke53282copying of 1 MB into the framebuffer every second takes at least 4% of your total time.18:18
stekernthe framebuffer can be configured to 8-bit palette mode (and I'm using that)18:27
olofkHas anyone tried to use gdb on an icarus simulation lately?21:07
olofkahh... I need openocd as a proxy between gdb and the sim. Forgot that21:08
olofkHmm... I get "Target ready..." from openocd and "Waiting for client connection...ok" from icarus, but gdb seems to be stuck21:35
olofkahh.. I probably tried to connect to the port between openocd and the sim21:39
olofkSo... which port should gdb connect to then? 50001 gives me timeout21:39
olofkFuck it. Probably solved tomorrow21:41
-!- Netsplit *.net <-> *.split quits: stekern, sb0, simoncook22:37
-!- Netsplit *.net <-> *.split quits: enghong22:43
-!- clopez_ is now known as clopez22:50
--- Log closed Wed Aug 27 00:00:25 2014

Generated by 2.15.2 by Marius Gedminas - find it at!