IRC logs for #openrisc Tuesday, 2016-05-24

--- Log opened Tue May 24 00:00:20 2016
SMDwrkYep, clearing mem with zeroes helped01:34
SMDwrkAlso tried to init ram with 0xabcdabcd. It worked.01:44
SMDwrkFor now ram contains "xxxxx", and when such value gets fetched it can poison pipeline. What do you think if we initialize ram with random values or 0xFFs? I don't speak about zeroes because it would be too easy.01:44
olofSMDwrk: Ah cool. That's good to know. I still would like to know why the software is trying to read uninitialized memory, but having an option to clear the ram is probably good to have too02:52
SMDwrkolof I thought gcc should have a key to init vars with zeroes but can't find one02:52
olofSMDwrk: I'm experimenting a bit with objcopy. It might be possible to do something like this02:58
olofor1k-elf-objcopy -O elf32-or1k --gap-fill 0 dhrystone_10.elf dhrystone_10.elf202:58
olofThat should fill the gaps between sections with a value02:59
olofAlso might be worth trying other options such as --pad-to02:59
SMDwrkGap-fill didn't work for me(03:26
olofSMDwrk: Well, now that we know that it works, I'm fine with an option to clear the mem on init03:27
olofHowever, I think we could put it in the testbench for now, just before the elf-loading03:27
SMDwrkolof I'll discuss that problem with my collegues when they come to work03:27
SMDwrkAnd that's why this problem doesn't show up with verilator03:28
olofI would assume so03:28
olofHave you been able to pinpoint which read from RAM that causes the error? Would be interesting to know why the sw does this in the first place03:29
SMDwrkyep, let me search for the pic03:30
SMDwrk here03:30
SMDwrk0x178f8 or something like this. I don't know why we read mem which has not been written yet and wasn't initialized also.03:32
SMDwrkbut we might get it from insn trace]03:32
SMDwrkThat  0x4e4700xx  we get because we previously written 3 bytes to that cell, but LSByte is still undefined03:34
olofHard to tell if this is a CPU or SW problem. As long as we don't rely on the result of the last byte, it should be ok to have it unitialized03:38
olofSo either mor1kx looks at the LSByte, even though it shouldn't care about its value03:38
olofOr the sw assumes that the last byte is 003:38
SMDwrkolof yep, but in real hw uninit bit(byte) is either 0 or 1, but not x03:38
SMDwrk>Or the sw assumes that the last byte is 003:39
SMDwrkThat could be one problem, yes03:39
olofYeah. True. It's starting to become more of an academic problem :)03:39
olofSMDwrk: I'll push an option to clear the RAM for the mor1kx-generic system during simulation03:40
SMDwrkThere is question that should be answered: why sw reads from mem which has not been written. Either it thinks it's already initialized then we have to find out why it hasn't, or sw reads random mem address and expects to read "trash" from there, but it reads a bunch of "xxxx" and then pipeline is crashed. In the last case we should init mem03:41
olofYep. That's what I think too03:42
olofBut to get around the problem for now, I'll add a command-line option to clear the mem for that system03:42
SMDwrkI guess people most of the time use verilator03:43
olofYeah, for pure mor1kx simulations at least. When you're having peripherals and more clocks it's getting trickier to use verilator03:44
olofCould also put in an option to set the init value to anything, but we can do that later if needed03:50
SMDwrkolof what do you think about adding total cycles passed for the simulation after it ends?03:50
olofIt's a good idea. I often wonder how many cycles that has been run. I think that could be implemented as a new option in vlog_tb_utils03:51
SMDwrkolof, huh, I think I have an idea03:51
SMDwrkMaybe it's cache issue: we could read let's say 0x1234 address and it will fill cache with 1238 and so on, thus we see that mem reads03:53
SMDwrkbut next question why we use one of that results03:53
olofSMDwrk: I'm about to test my fix now. What is supposed to happen without the clearing? Will it just hang, or do I get a wrong result?03:57
SMDwrkFor that dhrystone binary and current pipeline implementation it gets into infinite loop after "int comp should be 17"03:58
olofah cool.03:58
olofLooks like my patch works. I'm past the Int_Comp test now03:58
olofyep. dhrystone completed03:59
SMDwrkolof do you have that .vcd file I posted?04:01
olofNo, I haven't looked at it04:01
SMDwrkOk, then I'll update issue ticket with things I find interesting to look at04:01
SMDwrkMy question now is: if we store to cache some non-init values(i.e. mem locations which are never written, now we can do that, it's ok i guess), why then we use that values from cache. And I have some values to search/look for in that .vc04:03
olofSMDwrk: I pushed two patches now04:06
olofJust add --clear_ram at the end of the argument list04:06
SMDwrkolof also I suggest to add tick number to the trace log. It could help to estimate what's going on in the pipeline04:18
olofSMDwrk: Hmm.. I thought there already was one, but maybe that was for the old or1200 monitor04:20
olofThere's a slightly ugly way you could do something similar right now actually04:20
olofIf you set the heartbeat parameter, e.g. add --heartbeat=100, you will get an indication every 100th time unit04:21
olofIf you also do --trace_enable and --trace_to_screen, you will dump the trace to the screen, together with the heartbeat04:21
olofNot saying it's pretty, but at least it should work with what is there nwo04:22
SMDwrkI'd like to relate .vcd and insn trace to get idea what code executes at 996500 time and why04:22
olofYeah. That's nice to have.04:23
olofI got some ideas how to do that, but they require a little effort04:23
SMDwrkMaybe we could expand that insn trace file with extra info(i.e. stall signals, cache misses and etc) which will help to debug things in future.04:24
SMDwrkI think I could do it myself later when I study code and make PCU04:25
olofYes. We could put a lot of nice stuff in there. Feel free to hack it if you want. It's in mor1kx/bench/verilog/mor1kx_monitor.v I think04:25
SMDwrkolof buggy code is in strlen. I don;t know how it's implemented in libc, bug I guess there's a while loop untill \0  is met. And for some reason it doesn't stop where it's intended and that's why it reads mem and cache further, get corrupted values and hangs04:43
olofSMDwrk: Good find!04:44
olofI wonder if they skip writing \0 and just assume that it's zero to begin with04:45
SMDwrkIt's more like a guess now but looks reasonable for me) Yep, that's the question. Where should I look for it, gcc?04:45
olofI think you would find strlen somewhere in newlib04:46
olofBut I guess gcc would be responsible to \0-terminating the string04:47
SMDwrkolof, yep every string goes with \0 and gcc doesn't rely something is already init with zero. So we need to find out why \0 is missing.04:54
SMDwrkoh, I think I get it04:56
SMDwrkSo, the answer is the following. There is \0 in 0x4e4700xx, but that "xx" ruins everything04:59
SMDwrkIf it's initialized, we can correctly detect \0 and exit from strlen(), while it has "xx" in it pipeline gets mad and can't correctly calculate result.05:01
olofah ok05:08
olofThat's a mor1kx bug then05:08
stekernumm, how does the 'xx' come to ruin things?05:10
SMDwrkI think here: assign {adder_carryout, adder_result} = a + b_mux + {{OPTION_OPERAND_WIDTH-1{1'b0}}, carry_in}; if a is 0x112233xx result woul be 0xXXXXXXXX05:11
stekernbut isn't the memory position read with a byte load?05:12
olofstekern: For strlen, I assume it would be much quicker to read words and shift05:12
olofor mask05:13
SMDwrkI guess it's done with lwz, yep05:13
stekernmaybe, but then the 'xx' would be masked out05:13
SMDwrkCode from strlen: l.lwz r5,0(r4); l.ori r2,r2,0xfeff; l.add r6,r5,r2;05:15
SMDwrkLet's assume r5 is loaded with 0x112233xx05:15
SMDwrkthen add will fail as I described, right?05:16
stekernmm, that seems right05:17
stekernbut where is that string located then?05:17
stekernis it the last thing in memory (or in some section)05:17
stekernif so, I would say it'd be a bug in the program loader05:17
olofstekern: Or end of stack perhaps?05:17
SMDwrkOr it could be copied from bss(?, where all static vars are) to the mem and then compared?05:18
SMDwrkand while we copy, we update mem on byte basis05:19
olofHmm.. do we track memory writes in the trace log?05:19
stekernolof: all stack writes are 4 byte aligned, so the data has to have been read from uninitialized memory in the first place then too (I think at least)05:19
olofstekern: True05:20
olofI also think that end of the section is a possibility05:22
olofbut otoh, the elf-loader also only writes full words05:22
olofSo it should zero-extend05:22
stekernSMDwrk: can you look up where the string is located?05:23
SMDwrkI guess it's in .rodata05:30
SMDwrk "blabla SOME blabla"05:31
SMDwrkI think we do smth like memcopy(strlen()) or strcpy() and copy given sting by byte and then we finish with 0x4e4700xx in ram/cache(
stekerncan't look at pastebin from here...05:45
stekernbut that could of course be the case, if it's copied byte by byte from one place to another05:46
stekernnot sure how you would prevent the x'es in any other way than initializing the memory to something first05:47
SMDwrkwhy don't you want to initialize mem?05:50
stekernit might take a long time to initialize all of it if you have a large mem05:52
SMDwrkYou can init it only for iverilog and tell verilator to treat non-init values either as 0, or 1, or even random values each time you build project05:53
olofstekern: But we might be able to solve this in mor1kx.07:25
stekernhow, when the problem is that x'es are read from uninitialized memory?07:26
olofstekern: But isn't the problem really that mor1kx looks at the x bits, even though it shouldn't?07:38
stekernno, the code is doing an add, it has to use the 'x' bits for that07:38
stekernif it would have been a byte load or an AND operation, then I'd claim it's a mor1kx bug07:39
stekernwe could have a insert-random-bit-on-x module on the bus to avoid having to initialize the memory ;)07:41
olofah ok. Hmm... but if there is something non-zero in that location, we will get the wrong result, right?07:43
stekernno, I don't think so07:43
stekernif *that* would be the case, then it's a bug in the sw07:43
olofBut if we do an add, where part of one of the operands is unknown... how would that ever work reliably?07:44
SMDwrkwe could initialize mem with random values and still get correct result, problem is with 'xx'. So either we init mem with any values, or we insert x-to-smth on the mem bus07:45
stekernolof: the code sequence that SMDwrk showed was: l.lwz r5,0(r4); l.ori r2,r2,0xfeff; l.add r6,r5,r2;07:47
olofAnd the data @r4 has xx in LSByte?07:49
olofThen I still don't understand how we could trust the contents of r6 after the add, if part of one of the operands could be anything07:50
SMDwrkI think we can't.07:51
olofThen I would say it's a software bug07:52
SMDwrkbut hw is responsible for that xx being in LSByte, not sw07:52
stekernyes, but since they are 'xx' in practice they could be random07:53
SMDwrkthat's more like particular sim error07:54
SMDwrkI mean on verilator you won't see that kind of error and also on real hw/fpga.07:55
stekernbut then lsb != 0 should be fine07:56
stekernotherwise you might see the error on hw07:56
SMDwrkwhy? lsb could be anythin except 'x', because in 0x4e4700xx there is already \007:57
SMDwrkactually we just don't care about last byte07:58
stekernexactly, then lsb != 0 should be fine07:59
olofIt works fine in icarus with RAM initialized to 0xff07:59
SMDwrklsb != x should be fine08:00
olofYeah. I agree. Just trying to figure out where in mor1kx it breaks08:00
SMDwrkit breaks on add when we can't predict what add(0x112233xx, 12341234) would be and then we get xxxxxxxx as result and then pipe goes mad08:01
stekernno, lsb != 'x' shouldn't be fine when fed to an add operation08:06
stekernno, scratch that, I'm not concentrating...08:07
stekernI read that as lsb == 'x' ;)08:07
GeneralStupidhi, is there a list of papers about openrisc (like from TU munich)?10:24
SMDwrkGeneralStupid: do you need arch manual or smth else?10:31
-!- Netsplit *.net <-> *.split quits: mafm, pecastro10:42
GeneralStupidSMDwrk: i need to find a master thesis and i have three options, doing smthg interesting with openrisc or doing something in medical robotics or doing something boring10:42
SMDwrkGeneralStupid: I think you'd better ask wallento or others from universities, and I don't know european requirements for the thesis10:44
GeneralStupid SMDwrk its my first master thesis, so i dont know them, too. :)10:45
SMDwrkGeneralStupid: I mean in russia your thesis must have some r&d part and some math10:47
SMDwrkI'd say this paper one looks like great thesis to me
GeneralStupida bit too short as a master thesis :)10:48
GeneralStupidi really would like to spend some time for this project, because i have no free time atm...10:49
SMDwrkyou could use bigger font size ;)10:50
GeneralStupidnice idea :D10:51
SMDwrkI can teach you a lot how to enlarge your thesis :310:52
SMDwrks/teach/tell , I guess10:54
GeneralStupidi hope i dont need that -.- but i still have 2 or 3 months to decie what to do11:04
-!- Netsplit *.net <-> *.split quits: mafm, pecastro11:57
-!- Netsplit over, joins: mafm, pecastro12:06
shorneHi All, wallento, olofk there are still 2 pull requests pending for gdb and newlib.  Want me to do anything with them before they are merged? I think once we get through all the test results we can work to push upstream.19:06
shorneBut no harm merging, so others can get them, unless I need to fix my commit messages or something.19:06
shorneStill working through test results. I groups by failure count here:19:07
--- Log closed Wed May 25 00:00:22 2016

Generated by 2.15.2 by Marius Gedminas - find it at!