IRC logs for #openrisc Sunday, 2014-04-13

--- Log opened Sun Apr 13 00:00:03 2014
-!- Netsplit *.net <-> *.split quits: poke53281, ysionneau, rah, enghong, chad__, stekern, olofk, julzmb_, FreezingCold, xlro, (+19 more, use /NETSPLIT to show all of them)03:33
-!- Netsplit *.net <-> *.split quits: jeremybennett, zama, Limb, bentley`04:57
stekernFindeton: you need to set the address in your linux session "manually"06:50
Findetonyou mean in the openrisc linux right?06:51
stekernthis cgen stuff is getting less tricky as I'm slowly picking up a bit of scheme, I guess it's a bit of prerequisite knowing that =)06:54
stekernFindeton: so someting like: ifconfig eth0
stekernthe is in some startup script, you can change it there too06:56
Findetonstekern I'm editing linuc/arch/openrisc/support/initramfs/etc/network/interfaces06:56
Findetonlets see if that works :)06:57
stekernI don't think that's used06:58
stekernthat's where the is set06:58
Findetonit is not used07:00
Findetonit worked!07:06
Findetonnow I need to know how to stop the ping command because I do the ctrl+C and it doesn't work xd07:07
stekernyeah, iirc the xterm thing is a bit dumb... I usually use the telnet connection07:15
Findetonah ok07:17
Findetonbut how do I send ^C to the openrisc machine?07:30
Findetonbecause if I enter ^C on telnet it doesn't work well, the ping just keeps on going on the linux machine, it simply doesn't show the output on the telnet07:31
stekernhmm, I remembered that it did work, but maybe I'm remembering wrong07:31
stekernyeah, you're right it's not...07:36
stekernwhat does work though, is if you telnet into the machine on the ip07:37
Findetonyeah but the thing is that I modified the rcS script you mentioned and I still get the 19207:41
Findeton192.168.1.100 IP from the start07:41
stekerndid you rebuild the kernel after you modify it?07:41
Findetonoh no07:41
FindetonI didn't haha07:41
Findetonok thanks lets try07:42
stekerndon't worry I've made that blunder a couple of times too ;)07:42
Findetonanyway, is it normal that when I quit telnet, I cannot start another telnet session with the openrisc linux?07:42
Findetonokay I rebuilt it and now ^C works the way you said!07:46
Findetonand I can connect through telnet as many times as I want lol07:47
stekernI've got the cgen simulator to understand the atomic instructions now08:01
Findetonthat sounds good08:14
Findetonso, if I want the openrisc linux to have certain files when it starts, where should I put them, in arch/openrisc/support/initramfs?08:15
stekernyes, you could have them there, but if you're going to build a build rootfs, using the initramfs for that isn't such a good idea08:23
stekernI've used nfs for that for example08:24
-!- Netsplit *.net <-> *.split quits: poke53281, LoneTech, ysionneau, rah, Findeton, enghong, chad__, stekern, phoohb_, olofk, (+24 more, use /NETSPLIT to show all of them)09:18
-!- Netsplit over, joins: trem, Findeton, ssvb, stekern, chad__, julzmb_, heroux, rokka, rah, olofk (+24 more)09:20
stekernhmm, I found a bug in the cgen description for l.sw, but I don't get how it can have worked with that bug present:
stekernI think that should be: (+ opc-op rA rB simm16-split)09:47
stekernmaybe that is not used for anything important...09:53
blueCmdstekern: hah, ouch12:01
blueCmdstekern: before gcc crashes it managed to call or1k_atomic 15987 times12:20
blueCmdstekern: so I'm quite excited about having the instructions instead of the system call :)12:21
Findetonstekern the openrisc linux that we are using is not a busybox, but a modified linux arch right?16:28
LimbIs anyone familiar with the old school wishbone arbiters before the new wb_intercon system?16:40
Limbtrying to update the nexys3 cellular ram code, but I'm having a hard time converting it to the newer system16:40
Limbfor example the following assignments:
olofkblueCmd: That's a sweet board. Is it built already, or is that a fancy 3d-mockup? Honestly, I can't tell anymore. Stupid technology getting better than my eyesight17:06
Limbjuliusb: if you are around I'd love your help on trying to update the cellular ram code :)17:36
olofkLimb: That looks like a simple two-port arbiter17:40
Limbolofk: I think I understand what it's doing, but I don't see how I can access the signals its using. They're burried in wb_intercon.v17:41
LimbAnd I'm not sure exactly if whats it's doing is logic that has been replaced by the wb_intercon generator17:41
olofkLimb: That logic looks at wb_cyc and wb_stb from the outputs of the dbus and ibus arbiters17:44
olofkTake a look at wb_intercon.conf in or1200-generic17:45
olofkThat is probably what you need17:45
Limbolofk: that is how I have mine setup17:45
olofkLimb: But it's not working?17:46
Limbolofk: but if I understand correctly, the arbiters are in wb_intercon.v and I only include wb_intercon.vh17:46
Limbso I don't have access to the actually wires it is calling?17:46
olofkwb_intercon.vh is just an instatiation template17:46
olofkYou can copy the contents from wb_intercon.vh into your orpsoc_top if you find that more readable17:47
olofkBut I'm not sure why you need the internal wires17:47
Limbolofk: but how do i get access to the wb_intercon modules wires?17:47
olofkHmm. I'm still not sure I understand what you mean17:48
olofkThat one should go directly to your CPU17:49
Limbolofk: correct, there is no exposed memory data and instruction bus wires17:49
Limbthose wires are inside the wb_intercon module17:50
olofkBut you don't need that. You just need to connect the wb_[ms]2[sm]_mem_* wires to you cellram controller17:50
olofkThe T17:50
olofkThe old interconnect stuff had a separate arbiter for instruction and data busses17:51
olofkThe new structure (wb_intercon) just uses one17:51
Limbolofk: correct. That's whats throwing me off17:51
Limbits trying to access the seperate arbiters, but I only have one now17:52
Limbthis is what I came up with, but it doesnt work:
olofkWell, that should work :)17:53
stekernFindeton: in the intramfs you are using, it's busybox18:10
Findetonso when I want to get something into the openrisc linux, I have to follow the busybox doc right?18:12
Findetonfor example if I want to install python and so on18:12
stekernyes and no, I don't think busybox have any docs on compiling and installing python18:13
Findetonalso, it is my understanding that nfs is for networking but the configuration I wanna build is for a computer with no network (although as I am using a simulator right now I'll keep it there)18:13
Findetonso maybe nfs is not the way to go in this case18:14
stekernI think I must have missed something blueCmd said, I don't get what olofk is talking about18:14
stekernFindeton: well, nfs was just an example, you can use any media you want18:14
Findetonwell maybe I should do it with C instead of python, it'll run faster and it has an easier config from where I am18:19
Findetonwow now I see, the busybox simply is a multitask bin lol18:25
Findetonbasically, what I see is that anything that I put on initramfs is going to be found on my linux, but you say there are better ways to install things there right?18:27
stekernolofk: it got to be real, or he's overly pedant with his 3d-renderings, creating scratches and stuff on the glass table ;)18:28
stekernFindeton: right, but the whole initramfs is contained in RAM, i.e. not a good idea to store large amount of data there18:28
Findetonuh I understand18:29
stekernmy nfs rootfs was 300MB+18:29
Findetonso I could use one rootfs (but not nfs, maybe ext2/ext3 or something)18:30
stekernright, something like that18:35
blueCmdolofk: it's real, it's the first prototype18:51
olofkblueCmd: That's so cool. Really got to get myself a nano now. Are you planning on selling them?19:06
blueCmdolofk: if there is any interest we have discussed it19:07
blueCmdit's a coworker that has designed and built it, so all creds to him19:07
olofkblueCmd: Give him a hug from me :)19:07
blueCmdhaha, I will19:07
blueCmdwe're thinking of adding a display of some kind using the bottom connector as well19:08
blueCmdthe board linked replaces the glass on the de0 nano on the top side, and the HDMI / embedded display (whatever we chose to do) would be on the bottom19:09
olofkThat would be cool. Biggest problem would be getting enough bandwidth to the display I guess19:13
olofkstekern: Gettin undefined values on dbus data out from mor1k. Any ideas what it could be?19:20
stekernolofk: perhaps, if you define what you are doing better ;)19:21
olofkahh.. I think that _franck_'s led_blink doesn't clear r019:22
olofkstekern: Running led_blink through modelsim19:22
stekernah, ok19:23
stekernanything compiled with libgloss will fail as well19:24 the eventdriven simulators19:24
stekernI'm still puzzled why that worked in orpsocv2 though...19:25
olofkI cheated a bit and added to mor1kx_rf_ram19:28
olofkstekern: Doesn't libgloss clear that either?19:28
stekernyes, it does, but it reads _board_mem_base before bss is cleared19:35
stekernand if _board_mem_base == 0, it'll be in bss19:36
skip_I'm thinking of making a computer emulator with the aim of making it complete enough to boot linux, I guess a bit like the jor1k project19:46
skip_is openrisc a good architecture to attempt something like this on?19:47
skip_to me it looks simpler than x86 and arm, and having the neat kernel image with embedded busybox image saves several steps of work19:48
olofkskip_: Sounds reasonable19:57
olofkIt's a pretty straight-forward RISC machine19:57
olofkled_blink works in simulator now20:11
olofkon lx9_microboard20:11
--- Log closed Mon Apr 14 00:00:04 2014

Generated by 2.15.2 by Marius Gedminas - find it at!