| --- Log opened Mon May 12 00:00:44 2014 | ||
| stekern | blueCmd: yeah, I agree, I should probably have split that in two ;) | 03:46 |
|---|---|---|
| stekern | and not agile?! you should know that I pair programmed it with my daughter! | 03:47 |
| stekern | she had all kinds of ideas about pinky pies, princesses and unicorns that I had to fight off! | 03:49 |
| olofk | stekern: Why? :( | 05:40 |
| olofk | We have way too few unicorns in the project | 05:41 |
| stekern | olofk: hmm, maybe you're right, perhaps I was to hasty brushing off her ideas as nonsense.. | 06:09 |
| stekern | she usually come with strong arguments though, the other day she proclaimed "I'm a princess, and I will hit you in the face!" | 06:10 |
| blueCmd | stekern: you're a brave man fighting off a princess that will hit you in the face | 06:23 |
| blueCmd | http://s2.hubimg.com/u/6748285_f520.jpg < just add that in the commit message or something | 06:24 |
| stekern | if the generic gpio driver pulled of getting weird ascii art mainline, so can I! | 06:33 |
| stekern | http://lxr.free-electrons.com/source/drivers/gpio/gpio-generic.c | 06:33 |
| olofk | haha. I hadn't seen that :) | 06:41 |
| stekern | hmm, I wonder what is best when implementing an atomic test_and_set_bit | 07:07 |
| stekern | unconditionally setting the bit, or actually test before setting? | 07:08 |
| stekern | the test is a couple of more instructions, but you can avoid looping on a failing l.swa | 07:08 |
| stekern | ...but otoh, with the couple of more instructions, the risk of an l.lwa interruption increases when the test fails. | 07:10 |
| wallento | stekern: I rebased and our thread is lost now. find the update pull request here: https://github.com/openrisc/or1k-src/pull/7 | 07:37 |
| stekern | wallento: yes, that's a bit annoying that github does that :( | 07:41 |
| wallento | i also searched around a bit what people suggest for modifications of pull requests | 07:41 |
| stekern | but as for the pull request itself, I think it looks good now | 07:42 |
| wallento | that would be an awesome thing, as the basic idea of pull requests is, that thay typically need changes :) | 07:42 |
| stekern | I've created a "newlib" team and added you as a member to it, you should be able to push your changes to or1k-src yourself | 07:42 |
| wallento | perfect, thank you | 07:43 |
| stekern | the only way I can come up with to "work-around" the github behaviour is to push the new changes to a different branch, open a new pull-request and then close the old one | 07:44 |
| wallento | yes, that is also an option, but then people might get even more confused. I think the best is handling this properly on the github site | 07:44 |
| wallento | like detecting force writes on branches in pull requests | 07:45 |
| wallento | but I think they may come up with something, seeing what else they got going | 07:46 |
| stekern | true | 07:52 |
| wallento | I worked on the snooping, may commit it the next days | 07:53 |
| wallento | we changed a lot and especially made the cache handle writes, so I re-worked it for the current mor1kx cache | 07:53 |
| wallento | problem is you instantly have to react on a snoop, but I think there are no problems with it so far. But it needs some testing now.. | 07:54 |
| stekern | wallento: oh, that sounds cool. I'm playing with the Linux stuff currently | 07:55 |
| stekern | I've got a WIP branch of it here: http://git.openrisc.net/cgit.cgi/stefan/linux/log/?h=smp | 07:56 |
| stekern | I haven't got very far with it yet ;) | 07:58 |
| wallento | yeah, see my recent mail on the scratch reg issue | 08:00 |
| stekern | ah, it hasn't arrived here yet, but will when it does | 08:00 |
| wallento | best would indeed be something that does not require significnat arch spec or ABI changes | 08:01 |
| wallento | best would be if it can be checked with UPR | 08:01 |
| wallento | or so | 08:01 |
| stekern | yes, or just a CONFIG_ | 08:01 |
| stekern | (in the kernel case) | 08:02 |
| stekern | checking uprs isn't really an option, since you'd need free regs to check it runtime ;) | 08:02 |
| wallento | i mean at boot time then | 08:02 |
| wallento | like linux multicore will simply not boot (or not boot the other cores) | 08:02 |
| stekern | yes... but what will you do with the information? | 08:02 |
| stekern | ah... ok you mean like that | 08:03 |
| wallento | if there is openrisc silicon out there, this would be a sane check I think | 08:03 |
| stekern | yeah, that could of course work (and is not exclusive to the CONFIG_ option) | 08:04 |
| wallento | just gave a second thought to the snooping, turned out it is +8 lines only :) | 08:22 |
| wallento | i will push it as soon as I am sure that really no state transition is missed | 08:22 |
| LoneTech | stekern: thought just a bit more on the PLT. it would seem to me that its function is to keep trampolines so function pointers are still simple pointers whether going to static or dynamic symbols | 08:36 |
| LoneTech | but the existence of a nameN value implies that we can find sufficient information with one instruction; we can pass the GOT+nameN address instead of reloc_offsetN and save one word per PLT entry | 08:38 |
| LoneTech | the whole construct is a kludge to work around the linker not being able to lock a code page (in which case the PLT section would not need to look in a separate GOT table) | 08:39 |
| LoneTech | oh my. or32_trampoline_init seems to set up (some sort of) closures by writing code on the stack, per the documentation | 08:53 |
| LoneTech | where do I find the actual code generation for the PLT? | 08:58 |
| stekern | LoneTech: do you mean this? https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-or1k.c;h=956ec387ec14f7361e95812f72e7463e0a21b592;hb=HEAD#l30 | 09:00 |
| LoneTech | that looks right, yes. thanks :) | 09:00 |
| LoneTech | I think I can't cut it down to less than 12 bytes | 09:05 |
| stekern | yes, and a note on that, I was mostly concentrated on "making it work" rather than "making it optmized" when I implemented those | 09:06 |
| LoneTech | understandable | 09:06 |
| stekern | =) | 09:06 |
| stekern | for instance, I guess you could have different sized entries for the pic/non-pic case, but I took the easy path and made them same sized, even if that meant some 'useless' padding in the PIC case | 09:08 |
| LoneTech | I'm not used to seeing ld.so in /usr | 09:16 |
| stekern | no.. I don't think that's even used | 09:17 |
| blueCmd | stekern: cmpxchg works for 1, 2 and 4 now. | 09:17 |
| stekern | so, 3 is missing? | 09:19 |
| stekern | or were there more? | 09:19 |
| blueCmd | well, do you really want to support 3 byte operations? ;) | 09:20 |
| blueCmd | in filenames it would be -1, -2 and -3 | 09:20 |
| stekern | haha, ok | 09:20 |
| blueCmd | and -4 and -5 are for 64 and 128 bit operations | 09:20 |
| stekern | I though you were speaking about the filenames | 09:21 |
| stekern | +t | 09:21 |
| blueCmd | yes, I can be a bit vauge at times | 09:23 |
| blueCmd | it's wonderful that searching for 'openrisc 1000 architecture' gets me to the old site and requires 4 clicks to get to the pdf | 09:31 |
| blueCmd | and the second hit on google is a very old mirror of the document | 09:31 |
| stekern | it's not a remedy for the problems you point out, but I usually go to http://opencores.org/or1k and click on the link there when I want the arch spec | 09:37 |
| stekern | I don't know why we don't have a direct link to the document there though..? | 09:38 |
| olofk | One down! http://opencores.org/or1k/Architecture_Specification#Atomic_operations | 09:44 |
| stekern | I should perhaps push the updated spec too... | 09:48 |
| olofk | stekern: Will that be rev 1.0-1 ? | 09:55 |
| olofk | IIRC juliusb had some ideas on how to keep arch spec and implementation versions in syn | 09:55 |
| olofk | c | 10:01 |
| LoneTech | it's rather sad how many hardcoded offsets go into the linker code | 10:01 |
| stekern | olofk: 1.1-0 | 10:20 |
| stekern | I think the last digit can only be used for changes that not change the architecture | 10:21 |
| stekern | like fixing typos, reorganizing text, clarifications etc | 10:21 |
| stekern | ... and the implementations have an arch ver reg, that claims what version of the arch spec it's compatible with | 10:29 |
| stekern | (well, at least the post 1.0 implementations) | 10:30 |
| olofk | ah yes. This is definitely a cause for updating the arch rev | 10:31 |
| stekern | *ver | 10:33 |
| stekern | last digit is the rev ;) | 10:33 |
| stekern | major.minor-rev | 10:33 |
| olofk | ah fuck it. I'm not going to comment on this topic anymore. It's way over my head :) | 10:33 |
| blueCmd | hm | 10:35 |
| blueCmd | add_fetch and sub_fetch are not trivial to implement for 1 and 2 bytes | 10:35 |
| blueCmd | i guess it will need to be something like: l.lwa, l.slr, l.and 0xff, l.add, l.and 0xff, l.sll, l.or (combine l.lwa and the result of the computation), l.swa | 10:42 |
| blueCmd | and there needs to be a xor or something to clear the old value before the l.or | 10:42 |
| stekern | hmm... is the opencores web svn slow, or why doesn't the commit I just did show? | 10:52 |
| stekern | olofk: as for the de0_nano sim question, the answer is as simple as - There are no support for sim with de0_nano implemented yet | 10:54 |
| stekern | at least I haven't got around to add the support for it | 10:55 |
| olofk | aha :) | 10:59 |
| olofk | I guess FuseSoC should detect this | 11:00 |
| olofk | and I guess we should add a tb | 11:00 |
| olofk | stekern: Remind me about request #46. It was updated after I commented on adding an if to check for an env var, right? | 11:02 |
| olofk | (starting to understand the irritation over dropped conversations on github) | 11:03 |
| olofk | AH.. Just found something good about git starting ranges after the specified commit | 11:07 |
| olofk | I can do git cherry-pick HEAD..FETCH_HEAD after I have fetched a branch for a pull request | 11:08 |
| stekern | olofk: yes, #46 should be good to go now | 11:10 |
| olofk | I assumed that and pulled it already :) | 11:11 |
| stekern | blueCmd: it's time for your daily SMP commit: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=52a3c9208c1ca003999f032f0ec2e0fc09271655 | 11:11 |
| stekern | that link revealed a bit of whitespace damage in that commit I think | 11:13 |
| blueCmd | stekern: lgtm :) | 11:15 |
| blueCmd | I appriciate the daily commits | 11:15 |
| stekern | next milestone - spinlocks | 11:16 |
| blueCmd | I have no idea how to make this nice.. | 11:17 |
| blueCmd | My problem: | 11:17 |
| blueCmd | I have four insns: op_and_fetch, fetch_and_op, nand_and_fetch, fetch_and_nand | 11:17 |
| blueCmd | op is a iterator for [plus, minus, ior, xor, and] (might have forgotten a couple, not important) | 11:18 |
| blueCmd | those work nicely for 4 byte operations | 11:18 |
| blueCmd | I can do some optimization for things that are not artithmetic (two masked logical operations will not touch things outside the mask, 3 & 3 = 3, 3 + 3 = 6 however) | 11:19 |
| blueCmd | since I have 4 insns any way I go will either 1) make it slower for the 4 byte case, or 2) explode the insns into at least 8 insns | 11:20 |
| blueCmd | This would be much nicer if I could just have a skeleton and use C instead of the weird RTL templating shit | 11:21 |
| stekern | haha | 11:24 |
| stekern | I didn't get the "I have 4 insns", where's that restriction? | 11:24 |
| blueCmd | it's not a restriction per se, but that's how I implemented it | 11:31 |
| blueCmd | I might be able to consolidate them down to 2. hm | 11:32 |
| blueCmd | op_and_fetch and fetch_and_op are quite similar. I expanded them to 2 different insn since I got some weird errors, but I found a bug in the register contraints now, so it might be worth revisiting | 11:36 |
| rah | is it possible to test in-core power management strategies, like power gating, on an FPGA? | 11:55 |
| rah | I'm guessing not? | 11:55 |
| blueCmd | rah: I think it is | 11:57 |
| blueCmd | at least for stuff like "disabling the clock to part X" | 11:58 |
| rah | ah right | 11:58 |
| rah | that's clock gating | 11:58 |
| blueCmd | right, yeah. | 11:58 |
| blueCmd | power gating would be harder I guess | 11:58 |
| rah | waye | 11:59 |
| rah | err.. aye :-) | 11:59 |
| blueCmd | that said, I doubt the whole fpga is powered all the time, so maybe it has some way of doing 'block level' power gating | 11:59 |
| rah | "Power gating uses low-leakage PMOS transistors as header switches to shut off power supplies to parts of a design in standby or sleep mode. NMOS footer switches can also be used as sleep transistors. ... Typically, high-Vt sleep transistors are used for power gating, in a technique also known as multi-threshold CMOS (MTCMOS). The sleep transistor sizing is an important design parameter." | 12:01 |
| rah | https://en.wikipedia.org/wiki/Power_gating | 12:01 |
| rah | which all sounds very much like it's specific to the silicon circuit | 12:01 |
| rah | I don't understand how FPGAs work but it sounds like this kind of fine-grained power gating is done at a lower level than the usual IP put into an FPGA | 12:02 |
| rah | out | 12:03 |
| rah | just out of interest, are there any openrisc implementations that do clock gating? | 12:03 |
| blueCmd | stekern: stop cherrypicking and repeating the correct thing all the time | 12:04 |
| blueCmd | now I'm down to 2 insn | 12:04 |
| stekern | blueCmd: wut? | 12:05 |
| stekern | ;) | 12:05 |
| blueCmd | :D | 12:05 |
| stekern | where's the cherries? | 12:07 |
| blueCmd | the cherrypicking would be 'I have 4 insns' | 12:10 |
| blueCmd | (which, interestingly enough, were the first words I wrote) | 12:11 |
| * stekern is completely lost now | 12:11 | |
| stekern | bare in mind, I don't have the code you are poking around in front of me ;) | 12:12 |
| blueCmd | stekern: I know! just forget about what I said :P | 12:13 |
| blueCmd | you helped me, that's all you need to know :) | 12:13 |
| stekern | great! =) | 12:13 |
| blueCmd | stekern: waste 1 instruction (actual CPU instruction) and make the code easier to follow - or duplicate a bunch of code and save 1 insn | 12:14 |
| stekern | umm, depends how often that insn is used ;) | 12:15 |
| blueCmd | it's in the critical section between lwa and swa | 12:15 |
| stekern | ok, maybe it's worthwile a bit dirty code for that | 12:15 |
| stekern | ...but, since I asked a similar question this morning, you should know that I don't really know :P | 12:16 |
| blueCmd | haha | 12:16 |
| blueCmd | more details: | 12:16 |
| blueCmd | a = 1 byte, b = 1 byte. a OP b should be one byte. that is true for all logical but not arithmetical operations | 12:17 |
| blueCmd | for artihmetical I need to mask the result | 12:17 |
| blueCmd | doing that mask for all insn or just the artihmetical ones is what I'm wondering about. | 12:17 |
| stekern | tough call ;) | 12:22 |
| blueCmd | gonna go with easy code for now | 12:24 |
| olofk | rah: There are a lot of silicon-agnostic power management things that can be done | 14:11 |
| olofk | And all the FPGA vendors have some power analyzing tool. Especially Lattice are very focused on low-power FPGA | 14:11 |
| olofk | But for the OpenRISC and it's IP cores there hasn't really been enough demand for it yet | 14:12 |
| rah | olofk: I see | 14:17 |
| rah | thanks | 14:17 |
| rah | olofk: can I ask what silicon-agnostic things are there beyond clock gating? | 14:18 |
| olofk | rah: I was mostly thinking about clock gating actually | 14:20 |
| olofk | Well, lowering clock speeds would of course help too | 14:21 |
| LoneTech | there are other ways to reduce toggling | 14:22 |
| LoneTech | like unrolling sequences so you can slow the registers | 14:23 |
| LoneTech | gate level design is rather different from fpgas though; you can do things like use transmission gates to not drive unused paths, leaving their input capacitance to hold it. in fpga design you're mostly limited to needing a mux, which sometimes translates to a lut, and it hurts timing, power and area. | 14:27 |
| olofk | LoneTech: True. | 14:27 |
| olofk | But there are some easy targets, like making sure to only enable block RAM when you actually need them. I suspect a lot of those are always on | 14:28 |
| LoneTech | yes | 14:28 |
| rah | I see | 14:44 |
| mohessaid | hello, I am facing rigt now a problem "segmentation fault" on running asterisk in or1ksim. the probelm is due to system configuration (must have root privileges)? | 15:25 |
| mohessaid | asterisk was compiled with glibc toolchain and linux(asterisk on it) with or1k-elf toolchain. I tried to lanch in startup using inittab and the same thing was happing. | 15:29 |
| rah | "Another notable feature is a rich set of SIMD instructions intended for digital signal processing." | 16:19 |
| rah | https://en.wikipedia.org/wiki/OpenRISC | 16:19 |
| rah | OpenRISC has a rich set of SIMD instructions? :-) | 16:20 |
| stekern | "yes", but no implementations of them ;) | 16:20 |
| rah | stekern: are you joking or are there really SIMD instructions in the spec? | 16:21 |
| * rah has never read it | 16:21 | |
| rah | "OpenRISC Vector/DSP eXtension (ORVDX64)" | 16:24 |
| rah | ZOMG! | 16:24 |
| stekern | ok, micro-hdmi cable *check*, micro-sdcard *check*, let's see if we can blow some life into the parallella | 17:03 |
| juliusb | quick Q, does fusesoc support running modelsim? | 17:11 |
| stekern | quick A, yes! ;) | 17:15 |
| juliusb | cool, a grep for modelsim in fusesoc/ gave me 1 hit | 17:16 |
| stekern | I think it required two lines to be commented out if you want to run it on a 64-bit machine though | 17:16 |
| juliusb | OK, so I'll instlal it with the VM that I'mp reparing for this workshop | 17:16 |
| juliusb | this bloody simulator takes up 4GB! Insane | 17:17 |
| stekern | wallentos mor1kx-dualcore demo worked with modelsim at least (and with verilator too) | 17:17 |
| stekern | that's the only fusesoc thing I've tried together with modelsim | 17:18 |
| olofk | I'm running modelsim from time to time in FuseSoC | 17:27 |
| olofk | Interesting with just one hit in the code base. I take that as a good thing and say it's because the amount of modelsim-specific stuff is very little | 17:29 |
| olofk | But I'm getting 10 hits | 17:29 |
| stekern | olofk: I tried running fusesoc in cygwin today btw | 17:30 |
| stekern | ...didn't go to well | 17:30 |
| olofk | Good to know. I have wanted to try that out, but I haven't got access to a windows machine | 17:31 |
| olofk | Can you run cygwin in wine? :) | 17:31 |
| stekern | I'm not sure what was the problem, but the svn checkouts didn't create all the files for some reason | 17:31 |
| stekern | could be the windows svn client too | 17:31 |
| olofk | That's weird | 17:31 |
| stekern | I'll take a closer look at some point | 17:32 |
| olofk | omeone else noticed an issue some months ago. Setting up the quartus files for de0_nano worked fine, but the windows version expected \\ instead of | 17:39 |
| olofk | (I wrote that in #opencores by mistake) | 17:39 |
| stekern | yeah, I didn't get that far | 17:42 |
| stekern | maybe I'd be better off with the cygwin svn version | 17:43 |
| stekern | I first had some intentions trying to get things to run natively | 17:43 |
| stekern | but gnuwin32 is just too outdated to be useful anymore... | 17:44 |
| olofk | What's gnuwin32? | 17:44 |
| stekern | gnu tools natively compiled for windows | 17:44 |
| stekern | http://gnuwin32.sourceforge.net/ | 17:45 |
| olofk | ah ok | 17:47 |
| stekern | they're (or were) great, it's a pity no-one is maintaining them anymore | 17:48 |
| olofk | otoh, I wouldn't rule out the shaky openrisc repository either | 17:52 |
| stekern | true, it can have been a momentary issue right then when I tried it | 17:54 |
| rfajardo | BlueCmd, compiling Linux with the development toolchain didn’t solve the problem: “Warning: Ethernet packet length 0 too small.” | 17:54 |
| olofk | rfajardo: You're holding it wrong | 17:56 |
| stekern | rfajardo: are you actually trying to use the ethernet with a tun/tap device or does that happen even if you disable ethoc? | 17:59 |
| rfajardo | I didn’t try to disable it | 17:59 |
| rfajardo | Is ethoc the driver, or the configuration for the simulator? | 18:01 |
| stekern | try disable it in (comment it out) in arch/openrisc/boot/dts/or1ksim.dts | 18:02 |
| rfajardo | I will try that soon, thanks. | 18:04 |
| -!- rfajardo is now known as rschmidlin | 18:32 | |
| olofk | :) | 18:33 |
| _franck_ | olofk: are you the one who know how the openrisc ethernet MAC works ? | 21:31 |
| _franck_ | can we have a tx bd len not multiple of 4 ? I'm asking this because the wb master hardcode wb_sel = 4'hf | 21:37 |
| _franck_ | and if I send this ARP packet: http://pastie.org/9169818 last two bytes are not read from the memory | 21:38 |
| _franck_ | must be a software bug. With Linux a get an extra 32 bits read. | 21:45 |
| _franck_ | (I'm working on barebox) | 21:48 |
| --- Log closed Tue May 13 00:00:46 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
