| --- Log opened Sat Oct 17 00:00:29 2015 | ||
| stekern | andrzejr: no, that would be considered a bug | 02:22 |
|---|---|---|
| stekern | but what do you mean crossing boundaries of 128B? | 02:23 |
| stekern | the granularity is 4 bytes, not 128 bytes (or did you mean bits? so 16 bytes) | 03:19 |
| blueCmd_ | check/ws 11 | 05:19 |
| blueCmd_ | bah | 05:19 |
| andrzejr | stekern, yes, 128 bits. Sorry. | 08:04 |
| andrzejr | I run a simple test in HW (just in case) - no misaligned accesses detected. | 08:07 |
| andrzejr | I think it is probably an error in DDR2 controller/wrapper but I cannot reproduce it in simulation due to long run times. | 08:10 |
| stekern | andrzejr: ok, but still, what do you mean by "no transactions crossing 16 bytes"? | 08:53 |
| stekern | accesses are only aligned to 4 bytes | 08:53 |
| stekern | cache line refills will be aligned to either 16 or 32 bytes though | 08:55 |
| andrzejr | yes, 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 |
| andrzejr | anyway, I checked there are no such cases when booting linux or barebox. | 08:59 |
| GeneralStupid | okok | 16:28 |
| GeneralStupid | anyone remember my openrisc problems? My LED is not on... I checked everything... | 16:29 |
| GeneralStupid | the address is ok, the generated WB bus looks ok, the GPIO instance already worked ... But now, nothing happens. | 16:29 |
| GeneralStupid | is there some example c code, i think that i may do really stupid stuff... | 16:30 |
| olofk | GeneralStupid: 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 thing | 17:51 |
| GeneralStupid | olofk: wait a moment | 18:15 |
| promach | Hi, anyone ? I am a beginner in openRISC and I have encountered a simulation problem on hello.c | 18:18 |
| GeneralStupid | Info (169086): Pin key_pad_i[3] not assigned to an exact location on the device | 18:18 |
| promach | I am sorry if I have interrupted | 18:19 |
| GeneralStupid | olofk: aha... led_r_pad_o is stuck at GND :/ | 18:19 |
| GeneralStupid | olofk: ohh ok looks fine 0 to 7 are assigned | 18:19 |
| promach | Hi, I am using musl library for hello.c However I am having problem with vvp realloc() | 19:29 |
| promach | arch% 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 https://github.com/openrisc/or1200/archive/master.tar.gz 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: Prepar | 19:30 |
| promach | Program 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 |
| andrzejr | promach, that looks like a problem with icarus (vvp) or the elf-loader code. | 19:34 |
| promach | I have reinstalled iverilog just to make sure | 19:35 |
| promach | can I use musl library for hello.c ? | 19:35 |
| promach | if I want to post the files for debug, where should I post them ? | 19:38 |
| andrzejr | not sure, I haven't tried it. The simulation works here for me with newlib | 19:39 |
| GeneralStupid | dpaste.com | 19:39 |
| promach | ok | 19:39 |
| promach | which file (file name) would it be ? | 19:39 |
| promach | here you go : http://dpaste.com/0CQFAXZ | 19:41 |
| GeneralStupid | what about these: | 19:45 |
| GeneralStupid | Warning (13410): Pin "sdram_cs_n_pad_o" is stuck at GND | 19:45 |
| GeneralStupid | Warning (13410): Pin "sdram_cke_pad_o" is stuck at VCC | 19:45 |
| andrzejr | promach, 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://github.com/steveicarus/iverilog.git | 19:50 |
| andrzejr | the released version is fairly old, the one in git fixed many of the issues I had with icarus | 19:51 |
| promach | arch% iverilog -V Icarus Verilog version 10.0 (stable) (v10_0) Copyright 1998-2015 Stephen Williams | 19:52 |
| andrzejr | the above assumes the error is not on our side (elf-loader), where it can very well be. | 19:52 |
| andrzejr | oh, they have released 0.10, Good to know. It should be fairly new. then. | 19:54 |
| promach | I am using https://www.archlinux.org/packages/community/x86_64/iverilog/ | 19:55 |
| andrzejr | btw, cores/elf-loader/elf-loader.c calls realloc twice, so the error may be in the vpi module | 19:56 |
| promach | hmm, how should I proceed ? | 20:01 |
| andrzejr | promach, if that is correct: http://stackoverflow.com/questions/8436898/realloc-invalid-next-size-when-reallocating-to-make-space-for-strcat-on-char it may be difficult to fix | 20:08 |
| andrzejr | as 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 |
| andrzejr | Something like: | 20:11 |
| GeneralStupid | ok ok ok | 20:11 |
| GeneralStupid | my cpu now crashes if i start to flash something... https://dpaste.de/xZjN | 20:12 |
| andrzejr | if (max_paddr == 0) {buffer = realloc(buffer, 1000000); ...} | 20:13 |
| promach | do 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 |
| promach | it goes back to original state before change right after the vvp error appears | 20:18 |
| andrzejr | yes, modify these parts (both of them) | 20:18 |
| promach | elf_loader.c ? | 20:19 |
| andrzejr | yes | 20:19 |
| promach | I have changed | 20:19 |
| andrzejr | btw, before you do it, can you try another fix? | 20:19 |
| promach | yet it goes back to original | 20:19 |
| andrzejr | Replace "if (phdr.p_paddr >= max_paddr) {" | 20:20 |
| andrzejr | with "if (phdr.p_paddr + phdr.p_filesz >= max_paddr) {" | 20:20 |
| andrzejr | This looks suspicious and can be causing heap corruption and subsequently realloc failure | 20:21 |
| andrzejr | The second case would be "if (shdr.sh_addr >= max_paddr) {" => "if (shdr.sh_addr + shdr.sh_addr >= max_paddr) {" | 20:22 |
| promach | if (phdr.p_paddr + phdr.p_filesz >= max_paddr) { still gives error | 20:22 |
| andrzejr | can you try with if (shdr.sh_addr + shdr.sh_addr >= max_paddr) { as well? | 20:24 |
| promach | both give vvp error and return elf-loader.c to original state | 20:25 |
| andrzejr | too bad, heap corruption may come from many places, even from inside icarus. Try the workaround, then. | 20:26 |
| andrzejr | if (max_paddr == 0) {buffer = realloc(buffer, bignumber); ... in both cases | 20:27 |
| andrzejr | wait, that won't work. Sorry | 20:27 |
| GeneralStupid | ATM iam using OR1200, is that recommended? | 20:29 |
| andrzejr | try 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 |
| andrzejr | leave the second realloc as is for now, the error you see is coming from the first one (judging by your log) | 20:31 |
| promach | I still have *** Error in `vvp': realloc(): invalid next size: 0x000000000282d3b0 *** | 20:35 |
| andrzejr | just to make sure, check if build/.../elf-loader/ contains the modified version | 20:38 |
| promach | this file always go back to original state right after vvp error appears | 20:40 |
| andrzejr | ah, so you were editing the file in build/...? | 20:41 |
| promach | no matter which workaround you suggested to be done on this file | 20:41 |
| andrzejr | you should modify cores/elf-loader/... | 20:41 |
| andrzejr | build/<system>/src is recreated every time you run fusesoc | 20:42 |
| promach | I am sorry | 20:42 |
| promach | elf-loader: /home/dell/Documents/FPGA/openRISC/orpsoc-build/hello.elf was loaded Loading 0 words | 20:46 |
| promach | if (max_paddr == 0) | 20:46 |
| promach | buffer = realloc(buffer, 1000000); | 20:46 |
| promach | max_paddr = phdr.p_paddr + phdr.p_filesz; | 20:46 |
| andrzejr | that's not good, try the previous fix (that with if (phdr.p_paddr + phdr.p_filesz >= max_paddr) {) | 20:48 |
| promach | elf-loader: /home/dell/Documents/FPGA/openRISC/orpsoc-build/hello.elf was loaded Loading 4531 words | 20:50 |
| promach | should be 9595 words | 20:51 |
| andrzejr | why? | 20:52 |
| promach | https://github.com/embecosm/chiphack/wiki/OpenRISC-SoC-Practical-Session-Instructions | 20:52 |
| andrzejr | anyway, does it mean that vvp doesn't crash anymore? | 20:53 |
| promach | yes, thanks | 20:53 |
| promach | but no printour | 20:53 |
| promach | printout of "hello world" | 20:53 |
| promach | missing printout | 20:54 |
| andrzejr | well that's with a different libc so the sizes could be different. | 20:55 |
| andrzejr | you should probably try with the newlib toolchain first. just to check other parts of the flow are OK | 20:56 |
| andrzejr | _franck_ can you have a look at the elf-loader.c? ^ | 20:57 |
| promach | thanks, I will try with newlib and let you know | 20:58 |
| promach | give me some time to install newlib | 20:59 |
| andrzejr | sure, I don't expect you to come back with a result today :-) | 21:03 |
| andrzejr | cool, barebox stopped working and I don't know what has changed. Time to sleep. | 21:43 |
| olofk | GeneralStupid: It's probably better to use mor1kx instea of or1200. We haven't done any work on or1200 for a long time | 23:05 |
| --- Log closed Sun Oct 18 00:00:31 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!