IRC logs for #openrisc Saturday, 2015-10-17

--- Log opened Sat Oct 17 00:00:29 2015
stekernandrzejr: no, that would be considered a bug02:22
stekernbut what do you mean crossing boundaries of 128B?02:23
stekernthe granularity is 4 bytes, not 128 bytes (or did you mean bits? so 16 bytes)03:19
blueCmd_check/ws 1105:19
andrzejrstekern, yes, 128 bits. Sorry.08:04
andrzejrI run a simple test in HW (just in case) - no misaligned accesses detected.08:07
andrzejrI think it is probably an error in DDR2 controller/wrapper but I cannot reproduce it in simulation due to long run times.08:10
stekernandrzejr: ok, but still, what do you mean by "no transactions crossing 16 bytes"?08:53
stekernaccesses are only aligned to 4 bytes08:53
stekerncache line refills will be aligned to either 16 or 32 bytes though08:55
andrzejryes, that's what I was assuming when coding the WB<->DDR ctrl bridge. Just wanted to double-check it because the bridge would fail if there was a 32b access to 0x10*N+(0xd, 0xe, or 0xf).08:58
andrzejranyway, I checked there are no such cases when booting linux or barebox.08:59
GeneralStupidanyone remember my openrisc problems? My LED is not on... I checked everything...16:29
GeneralStupidthe address is ok, the generated WB bus looks ok, the GPIO instance already worked ... But now, nothing happens.16:29
GeneralStupidis there some example c code, i think that i may do really stupid stuff...16:30
olofkGeneralStupid: Have you checked the synthesis logs for things unexpected things that have been removed? Often happens to me that I have forgot to connect something and the synthesis tool just removes the whole thing17:51
GeneralStupidolofk: wait a moment18:15
promachHi, anyone ? I am a beginner in openRISC and I have encountered a simulation problem on hello.c18:18
GeneralStupidInfo (169086): Pin key_pad_i[3] not assigned to an exact location on the device18:18
promachI am sorry if I have interrupted18:19
GeneralStupidolofk: aha... led_r_pad_o is stuck at GND :/18:19
GeneralStupidolofk: ohh ok looks fine 0 to 7 are assigned18:19
promachHi, I am using musl library for hello.c However I am having problem with vvp realloc()19:29
promacharch% or1k-linux-musl-gcc hello.c -o hello.elf                 arch% fusesoc sim or1200-generic --elf-load hello.elf --vcd      INFO:  Preparing mmuart INFO:  Preparing or1200 INFO:  Checking out revision master to /home/dell/.cache/fusesoc/or1200 INFO:  Preparing ram_wb INFO:  Preparing uart16550-1.5 INFO:  Preparing uart16550_model INFO:  Preparing vlog_tb_utils INFO:  Prepar19:30
promachProgram header 0: addr 0x00002034, size 0x000000E0 Program header 1: addr 0x000025A6, size 0x00000017 Program header 2: addr 0x00002000, size 0x00000608 Program header 3: addr 0x00004608, size 0x000000C4 *** Error in `vvp': realloc(): invalid next size: 0x00000000029423b0 ***19:30
andrzejrpromach, that looks like a problem with icarus (vvp) or the elf-loader code.19:34
promachI have reinstalled iverilog just to make sure19:35
promachcan I use musl library for hello.c ?19:35
promachif I want to post the files for debug, where should I post them  ?19:38
andrzejrnot sure, I haven't tried it. The simulation works here for me with newlib19:39
promachwhich file (file name) would it be ?19:39
promachhere you go :
GeneralStupidwhat about these:19:45
GeneralStupidWarning (13410): Pin "sdram_cs_n_pad_o" is stuck at GND19:45
GeneralStupidWarning (13410): Pin "sdram_cke_pad_o" is stuck at VCC19:45
andrzejrpromach, can't help you with that. You may want to file a bug report in icarus - they were quick to fix my issues in the past. Also, try to build a version from git: git://
andrzejrthe released version is fairly old, the one in git fixed many of the issues I had with icarus19:51
promacharch% iverilog -V Icarus Verilog version 10.0 (stable) (v10_0)  Copyright 1998-2015 Stephen Williams19:52
andrzejrthe above assumes the error is not on our side (elf-loader), where it can very well be.19:52
andrzejroh, they have released 0.10, Good to know. It should be fairly new. then.19:54
promachI am using
andrzejrbtw, cores/elf-loader/elf-loader.c calls realloc twice, so the error may be in the vpi module19:56
promachhmm, how should I proceed ?20:01
andrzejrpromach, if that is correct: it may be difficult to fix20:08
andrzejras a workaround you may want to try to modify realloc() lines so that they only allocate memory once and the size is big enough for your data.20:11
andrzejrSomething like:20:11
GeneralStupidok ok ok20:11
GeneralStupidmy cpu now crashes if i start to flash something...
andrzejrif (max_paddr == 0) {buffer = realloc(buffer, 1000000); ...}20:13
promachdo you mean if (phdr.p_paddr >= max_paddr) { buffer = realloc(buffer, phdr.p_paddr + phdr.p_filesz); max_paddr = phdr.p_paddr + phdr.p_filesz; }20:17
promachit goes back to original state before change right after the vvp error appears20:18
andrzejryes, modify these parts (both of them)20:18
promachelf_loader.c ?20:19
promachI have changed20:19
andrzejrbtw, before you do it, can you try another fix?20:19
promachyet it goes back to original20:19
andrzejrReplace "if (phdr.p_paddr >= max_paddr) {"20:20
andrzejrwith "if (phdr.p_paddr + phdr.p_filesz >= max_paddr) {"20:20
andrzejrThis looks suspicious and can be causing heap corruption and subsequently realloc failure20:21
andrzejrThe second case would be "if (shdr.sh_addr >= max_paddr) {" => "if (shdr.sh_addr + shdr.sh_addr >= max_paddr) {"20:22
promachif (phdr.p_paddr + phdr.p_filesz >= max_paddr) {     still gives error20:22
andrzejrcan you try with if (shdr.sh_addr + shdr.sh_addr >= max_paddr) { as well?20:24
promachboth give vvp error and return elf-loader.c to original state20:25
andrzejrtoo bad, heap corruption may come from many places, even from inside icarus. Try the workaround, then.20:26
andrzejrif (max_paddr == 0) {buffer = realloc(buffer, bignumber); ... in both cases20:27
andrzejrwait, that won't work. Sorry20:27
GeneralStupidATM iam using OR1200, is that recommended?20:29
andrzejrtry this:20:30
andrzejr                if (max_paddr == 0)20:30
andrzejr                        buffer = realloc(buffer, 1000000);20:30
andrzejr                max_paddr = phdr.p_paddr + phdr.p_filesz;20:30
andrzejrleave the second realloc as is for now, the error you see is coming from the first one (judging by your log)20:31
promachI still have *** Error in `vvp': realloc(): invalid next size: 0x000000000282d3b0 ***20:35
andrzejrjust to make sure, check if build/.../elf-loader/ contains the modified version20:38
promachthis file always go back to original state right after vvp error appears20:40
andrzejrah, so you were editing the file in build/...?20:41
promachno matter which workaround you suggested to be done on this file20:41
andrzejryou should modify cores/elf-loader/...20:41
andrzejrbuild/<system>/src is recreated every time you run fusesoc20:42
promachI am sorry20:42
promachelf-loader: /home/dell/Documents/FPGA/openRISC/orpsoc-build/hello.elf was loaded Loading           0 words20:46
promachif (max_paddr == 0)20:46
promach        buffer = realloc(buffer, 1000000);20:46
promachmax_paddr = phdr.p_paddr + phdr.p_filesz;20:46
andrzejrthat's not good, try the previous fix (that with if (phdr.p_paddr + phdr.p_filesz >= max_paddr) {)20:48
promachelf-loader: /home/dell/Documents/FPGA/openRISC/orpsoc-build/hello.elf was loaded Loading        4531 words20:50
promachshould be 9595 words20:51
andrzejranyway, does it mean that vvp doesn't crash anymore?20:53
promachyes, thanks20:53
promachbut no printour20:53
promachprintout of "hello world"20:53
promachmissing printout20:54
andrzejrwell that's with a different libc so the sizes could be different.20:55
andrzejryou should probably try with the newlib toolchain first. just to check other parts of the flow are OK20:56
andrzejr_franck_ can you have a look at the elf-loader.c? ^20:57
promachthanks, I will try with newlib and let you know20:58
promachgive me some time to install newlib20:59
andrzejrsure, I don't expect you to come back with a result today :-)21:03
andrzejrcool, barebox stopped working and I don't know what has changed. Time to sleep.21:43
olofkGeneralStupid: It's probably better to use mor1kx instea of or1200. We haven't done any work on or1200 for a long time23:05
--- Log closed Sun Oct 18 00:00:31 2015

Generated by 2.15.2 by Marius Gedminas - find it at!