| --- 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 | |
| stekern | Findeton: you need to set the address in your linux session "manually" | 06:50 |
|---|---|---|
| Findeton | uhm | 06:51 |
| Findeton | you mean in the openrisc linux right? | 06:51 |
| stekern | yes | 06:52 |
| stekern | this 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 |
| stekern | Findeton: so someting like: ifconfig eth0 10.0.2.16 | 06:55 |
| stekern | the 192.168.1.100 is in some startup script, you can change it there too | 06:56 |
| Findeton | stekern I'm editing linuc/arch/openrisc/support/initramfs/etc/network/interfaces | 06:56 |
| Findeton | lets see if that works :) | 06:57 |
| stekern | I don't think that's used | 06:58 |
| stekern | arch/openrisc/support/initramfs/etc/init.d/rcS | 06:58 |
| stekern | that's where the 192.168.1.100 is set | 06:58 |
| Findeton | oh | 06:59 |
| Findeton | it is not used | 07:00 |
| Findeton | yeeeeeeeeeees | 07:06 |
| Findeton | it worked! | 07:06 |
| Findeton | now I need to know how to stop the ping command because I do the ctrl+C and it doesn't work xd | 07:07 |
| stekern | yeah, iirc the xterm thing is a bit dumb... I usually use the telnet connection | 07:15 |
| Findeton | ah ok | 07:17 |
| Findeton | but how do I send ^C to the openrisc machine? | 07:30 |
| Findeton | because 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 telnet | 07:31 |
| stekern | hmm, I remembered that it did work, but maybe I'm remembering wrong | 07:31 |
| stekern | yeah, you're right it's not... | 07:36 |
| stekern | what does work though, is if you telnet into the machine on the 10.0.2.16 ip | 07:37 |
| Findeton | ah | 07:38 |
| Findeton | yeah but the thing is that I modified the rcS script you mentioned and I still get the 192 | 07:41 |
| Findeton | 192.168.1.100 IP from the start | 07:41 |
| stekern | did you rebuild the kernel after you modify it? | 07:41 |
| Findeton | oh no | 07:41 |
| Findeton | I didn't haha | 07:41 |
| Findeton | ok thanks lets try | 07:42 |
| stekern | don't worry I've made that blunder a couple of times too ;) | 07:42 |
| Findeton | anyway, is it normal that when I quit telnet, I cannot start another telnet session with the openrisc linux? | 07:42 |
| Findeton | okay I rebuilt it and now ^C works the way you said! | 07:46 |
| Findeton | and I can connect through telnet as many times as I want lol | 07:47 |
| stekern | great | 07:58 |
| stekern | I've got the cgen simulator to understand the atomic instructions now | 08:01 |
| Findeton | that sounds good | 08:14 |
| Findeton | so, 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 |
| stekern | yes, 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 idea | 08:23 |
| stekern | I've used nfs for that for example | 08: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 | |
| stekern | hmm, 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: https://github.com/openrisc/or1k-src/blob/or1k/cpu/or1korbis.cpu#L603 | 09:45 |
| stekern | I think that should be: (+ opc-op rA rB simm16-split) | 09:47 |
| stekern | maybe that is not used for anything important... | 09:53 |
| blueCmd | stekern: hah, ouch | 12:01 |
| blueCmd | stekern: before gcc crashes it managed to call or1k_atomic 15987 times | 12:20 |
| blueCmd | stekern: so I'm quite excited about having the instructions instead of the system call :) | 12:21 |
| stekern | =) | 12:59 |
| Findeton | stekern the openrisc linux that we are using is not a busybox, but a modified linux arch right? | 16:28 |
| Limb | Is anyone familiar with the old school wishbone arbiters before the new wb_intercon system? | 16:40 |
| Limb | trying to update the nexys3 cellular ram code, but I'm having a hard time converting it to the newer system | 16:40 |
| Limb | for example the following assignments: https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/boards/xilinx/nexys3/rtl/verilog/orpsoc_top/orpsoc_top.v#L1154 | 16:41 |
| olofk | blueCmd: 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 eyesight | 17:06 |
| Limb | juliusb: if you are around I'd love your help on trying to update the cellular ram code :) | 17:36 |
| olofk | Limb: That looks like a simple two-port arbiter | 17:40 |
| Limb | olofk: 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.v | 17:41 |
| Limb | And I'm not sure exactly if whats it's doing is logic that has been replaced by the wb_intercon generator | 17:41 |
| olofk | Limb: That logic looks at wb_cyc and wb_stb from the outputs of the dbus and ibus arbiters | 17:44 |
| olofk | Take a look at wb_intercon.conf in or1200-generic | 17:45 |
| olofk | That is probably what you need | 17:45 |
| Limb | olofk: that is how I have mine setup | 17:45 |
| olofk | Limb: But it's not working? | 17:46 |
| Limb | olofk: but if I understand correctly, the arbiters are in wb_intercon.v and I only include wb_intercon.vh | 17:46 |
| Limb | so I don't have access to the actually wires it is calling? | 17:46 |
| olofk | wb_intercon.vh is just an instatiation template | 17:46 |
| olofk | You can copy the contents from wb_intercon.vh into your orpsoc_top if you find that more readable | 17:47 |
| olofk | But I'm not sure why you need the internal wires | 17:47 |
| Limb | olofk: but how do i get access to the wb_intercon modules wires? | 17:47 |
| olofk | Hmm. I'm still not sure I understand what you mean | 17:48 |
| Limb | wb_m2s_or1k_i_cyc | 17:49 |
| olofk | That one should go directly to your CPU | 17:49 |
| Limb | olofk: correct, there is no exposed memory data and instruction bus wires | 17:49 |
| Limb | those wires are inside the wb_intercon module | 17:50 |
| olofk | But you don't need that. You just need to connect the wb_[ms]2[sm]_mem_* wires to you cellram controller | 17:50 |
| olofk | The T | 17:50 |
| olofk | The old interconnect stuff had a separate arbiter for instruction and data busses | 17:51 |
| olofk | The new structure (wb_intercon) just uses one | 17:51 |
| Limb | olofk: correct. That's whats throwing me off | 17:51 |
| Limb | its trying to access the seperate arbiters, but I only have one now | 17:52 |
| Limb | this is what I came up with, but it doesnt work: http://pastebin.com/3EZcJeEZ | 17:52 |
| olofk | Well, that should work :) | 17:53 |
| stekern | Findeton: in the intramfs you are using, it's busybox | 18:10 |
| Findeton | oh | 18:11 |
| Findeton | so when I want to get something into the openrisc linux, I have to follow the busybox doc right? | 18:12 |
| Findeton | for example if I want to install python and so on | 18:12 |
| stekern | yes and no, I don't think busybox have any docs on compiling and installing python | 18:13 |
| Findeton | also, 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 |
| Findeton | so maybe nfs is not the way to go in this case | 18:14 |
| stekern | I think I must have missed something blueCmd said, I don't get what olofk is talking about | 18:14 |
| stekern | Findeton: well, nfs was just an example, you can use any media you want | 18:14 |
| Findeton | well maybe I should do it with C instead of python, it'll run faster and it has an easier config from where I am | 18:19 |
| olofk | stekern: http://storage.googleapis.com/bluecmd-openrisc/de0_orpsoc_asm.jpg | 18:22 |
| Findeton | wow now I see, the busybox simply is a multitask bin lol | 18:25 |
| Findeton | basically, 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 |
| stekern | olofk: it got to be real, or he's overly pedant with his 3d-renderings, creating scratches and stuff on the glass table ;) | 18:28 |
| stekern | Findeton: right, but the whole initramfs is contained in RAM, i.e. not a good idea to store large amount of data there | 18:28 |
| Findeton | uh I understand | 18:29 |
| stekern | my nfs rootfs was 300MB+ | 18:29 |
| Findeton | so I could use one rootfs (but not nfs, maybe ext2/ext3 or something) | 18:30 |
| stekern | right, something like that | 18:35 |
| blueCmd | olofk: it's real, it's the first prototype | 18:51 |
| olofk | blueCmd: That's so cool. Really got to get myself a nano now. Are you planning on selling them? | 19:06 |
| blueCmd | olofk: if there is any interest we have discussed it | 19:07 |
| blueCmd | it's a coworker that has designed and built it, so all creds to him | 19:07 |
| olofk | blueCmd: Give him a hug from me :) | 19:07 |
| blueCmd | haha, I will | 19:07 |
| blueCmd | we're thinking of adding a display of some kind using the bottom connector as well | 19:08 |
| blueCmd | the 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 bottom | 19:09 |
| olofk | That would be cool. Biggest problem would be getting enough bandwidth to the display I guess | 19:13 |
| olofk | stekern: Gettin undefined values on dbus data out from mor1k. Any ideas what it could be? | 19:20 |
| stekern | olofk: perhaps, if you define what you are doing better ;) | 19:21 |
| olofk | ahh.. I think that _franck_'s led_blink doesn't clear r0 | 19:22 |
| olofk | stekern: Running led_blink through modelsim | 19:22 |
| stekern | ah, ok | 19:23 |
| stekern | anything compiled with libgloss will fail as well | 19:24 |
| stekern | ...in the eventdriven simulators | 19:24 |
| stekern | I'm still puzzled why that worked in orpsocv2 though... | 19:25 |
| olofk | I cheated a bit and added http://pastie.org/private/lm0sjy6i0je4if1ll97w to mor1kx_rf_ram | 19:28 |
| olofk | stekern: Doesn't libgloss clear that either? | 19:28 |
| stekern | yes, it does, but it reads _board_mem_base before bss is cleared | 19:35 |
| stekern | and if _board_mem_base == 0, it'll be in bss | 19:36 |
| skip_ | hey | 19:45 |
| 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 project | 19: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 work | 19:48 |
| olofk | skip_: Sounds reasonable | 19:57 |
| olofk | It's a pretty straight-forward RISC machine | 19:57 |
| olofk | led_blink works in simulator now | 20:11 |
| olofk | on lx9_microboard | 20:11 |
| --- Log closed Mon Apr 14 00:00:04 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
