--- Log opened Tue Oct 15 00:00:40 2013 | ||
stekern | olofk: I just encountered a bug in wb_intercon, setting size to 0x3000 yields a mask of 0xfffd0000 | 03:20 |
---|---|---|
stekern | if we assume base is at 0x0, 0x10000 will not match that | 03:23 |
stekern | sorry, size to 0x30000 | 03:26 |
stekern | and it's because how the masking in wb_mux works. so I'd say the bug is in wb_intercon_gen, that allows for unsupported value | 03:35 |
stekern | it should probably issue warning: "Warning: unsupported size 0x30000, padding to 0x40000!" | 03:36 |
poke53281 | stekern: Today I have tried to figure out why QEMU is so slow (in my opinion). I have tried some benchmarks. The results are interesting. Take a look: http://pastie.org/8402921# | 04:10 |
poke53281 | The QEMU i386 emulation is around two times faster then the or1k emulation. I think one of the main reasons is the tlb refill. | 04:12 |
stekern | yes, the hardware tlb refill hack I did indicated the same | 04:12 |
poke53281 | The other one prbably the optimized compiler and instruction set for the i386 CPU | 04:13 |
poke53281 | I compared also the gcc compiling speed. And it is terrible frotz takes more than 45 minutes. | 04:13 |
poke53281 | In jor1k less than 8 minutes | 04:13 |
poke53281 | And this I don't understand. | 04:13 |
poke53281 | QEMU uses the JIT compiler to translate the opcodes. | 04:14 |
poke53281 | And my Javascript compiler is faster. | 04:14 |
stekern | but do you have the hw tlb refill enabled in jor1k? | 04:14 |
poke53281 | Yes, but you miss the point. It help speedup QEMU by a factor of two. Not more. | 04:15 |
poke53281 | It would be still much slower than jor1k. | 04:15 |
poke53281 | And I have looked in the source of the openrisc part of QEMU. There is nothing really wrong. Nothing which could speed up everything by a factor of ten or so. | 04:16 |
stekern | no, in my tests where I compiled a simple hello_world.c I got 40s down to 10s with hw tlb refill hack | 04:16 |
poke53281 | Hmm, do you have it to test my image? | 04:17 |
poke53281 | Ah, this won't work without the correct patches. | 04:17 |
poke53281 | for the kernel. | 04:17 |
stekern | which is about the same difference in your comparison between qemu and jor1k compiling frotz | 04:17 |
poke53281 | But then this is still a terrible result for QEMU or a fantastic result for jor1k. Depends on the perspective. | 04:19 |
poke53281 | QEMU is supposed to be at least 10 times faster than jor1k | 04:19 |
poke53281 | But even the x86 emulation is slower than jor1k. | 04:20 |
poke53281 | I have tested two version of qemu in two operating systems. | 04:20 |
stekern | yes, I agree, it's still slow | 04:20 |
poke53281 | My original plan was to build something like an image with native compiler and so on to put it on the website as an easier alternative for the toolchain. | 04:21 |
poke53281 | But with this terrible results for compiling something I can forget it. | 04:23 |
stekern | yes, that's why I was interested in qemu in the first place too, to be able to natively compile stuff | 04:24 |
poke53281 | As an comparison I will compile frotz in the i386 Emulation. | 04:25 |
poke53281 | Because I think this is the reference. | 04:26 |
stekern | but it's odd that the x86 is slow too | 04:26 |
poke53281 | And then maybe in Bochs. | 04:26 |
stekern | yes, that will be interesting | 04:26 |
stekern | is it easy to compile the bytemark tests btw? | 04:26 |
poke53281 | Yes, very easy | 04:26 |
poke53281 | But you must be careful | 04:26 |
stekern | good, I'd like to run them on mor1kx | 04:26 |
poke53281 | Change the makefile to set the correct pointer size in pointer.h | 04:27 |
poke53281 | Look at the output of make. | 04:27 |
stekern | ok, thanks for the headsup | 04:27 |
poke53281 | It will think that the compiler is 64 Bit. But it's not. | 04:27 |
poke53281 | Change Makefile and then "make CC=or1k-linux-gcc" | 04:28 |
poke53281 | That should work. | 04:28 |
stekern | cool, thanks | 04:29 |
stekern | did you run them under jor1k too? | 04:29 |
poke53281 | No, because the timer is not implemented to compare. | 04:29 |
stekern | ah, right | 04:30 |
poke53281 | And I think the bytemark is computing everything part for a certain time. | 04:30 |
poke53281 | or1ksim as well does not work. | 04:30 |
stekern | true, coremark and other tests does not work there neither | 04:31 |
poke53281 | But the compiling of Frotz should be an every of memory, integer and logical operations. A good comparison. | 04:31 |
poke53281 | should be an average ... | 04:31 |
stekern | yes | 04:31 |
stekern | compiling hello_world.c on real hardware is sloow too, and hw tlb refill didn't help *that* much there | 04:32 |
poke53281 | hello world is too easy in my opinion as a real benchmark. | 04:32 |
poke53281 | the loading of the files could be too important here. | 04:33 |
stekern | yes, but I still wonder why that is so slow | 04:33 |
poke53281 | By the way, I didn't use NFS. | 04:33 |
stekern | perhaps a modern gcc is just that big | 04:33 |
poke53281 | ramfs | 04:33 |
stekern | it takes around 40s without hw tlb refill and 30s with on mor1kx | 04:34 |
stekern | running at 50MHz | 04:34 |
poke53281 | Frotz compiles in 50 seconds using QEMU using an x86. Now I am a little bit confused. I will try ncurses again | 06:00 |
poke53281 | 45 min using openrisc vs 50 seconds using x86 | 06:01 |
poke53281 | more than a factor of 50 | 06:02 |
poke53281 | I mean nbench, not ncurses | 06:04 |
poke53281 | stekern: http://pastie.org/8403110 | 06:23 |
poke53281 | This is more realistic. | 06:23 |
poke53281 | nbench is this time compiled with the compiler for i386 | 06:24 |
poke53281 | with the same compiler version for i386 | 06:24 |
poke53281 | I would like to see the same results with tlb refill. | 06:25 |
stekern | yes, that looks sane | 06:33 |
poke53281 | maybe you can send me the patches for Qemu you are using. I think the patches for Linux you have already send to the mailing list. | 06:35 |
poke53281 | I can write it myself too. No problem. | 06:43 |
stekern | http://pastie.org/8403135 | 06:45 |
stekern | that's the git diff of my working dir | 06:45 |
poke53281 | Thanks. I will try to compile it tomorrow. | 06:48 |
rah | http://www.indiegogo.com/projects/pengpod-1040-quad-core-linux-android-dual-booting-tablets | 08:28 |
rah | seen this? | 08:28 |
rah | "Embedded Controller: AR100, an OpenRISC controller. Manages deep powersave modes. " | 08:29 |
rah | http://linux-sunxi.org/AR100 | 08:29 |
hansfbaier | rah: Yes, it's in the Allwinner A31 | 08:31 |
hansfbaier | rah: You also can buy it in a heap of chinese tablets: http://www.aliexpress.com/wholesale?SearchText=Allwinner+A31&catId=0&initiative_id=SB_20131015003201 | 08:32 |
hansfbaier | rah: for about $100 you already can get an OpenRISC in a tablet... | 08:32 |
rah | hansfbaier: I know, I have 2 A31 tablets :-) | 08:33 |
rah | (although I didn't pay cash for them) | 08:33 |
rah | and an A31 set-top box | 08:34 |
hansfbaier | rah: Where did you get the set-top box? | 08:34 |
rah | hansfbaier: it is part-payment for services rendered | 08:35 |
rah | hansfbaier: it came from a supplier in China | 08:35 |
rah | hansfbaier: it's a Mele A1000G | 08:35 |
rah | (the company that paid me with it was American rather than Chinese, they just sent it from a supplier in China) | 08:35 |
Powermaniac | Wait you can get OpenRISC tablets...Where when how!? | 08:36 |
rah | Powermaniac: you can't | 08:36 |
rah | Powermaniac: don't get excited :-) | 08:36 |
Powermaniac | =( aww | 08:36 |
rah | Powermaniac: the or1k core is used for power management within the Allwinner A31 ARMv7 chip | 08:36 |
Powermaniac | Ohh | 08:37 |
hansfbaier | rah: Linux/Android dual boot is really cool | 08:38 |
* hansfbaier gets tempted | 08:38 | |
Powermaniac | Was getting excited that someone may have done what I wished before me... | 08:38 |
hansfbaier | Powermaniac: You can hackishly access the AR100, stekern wrote a little tool that probes the AR100 chip for features | 08:39 |
Powermaniac | AR100? | 08:39 |
Powermaniac | hansfbaier: It also sounds like (as I've been reading) that you are planning to do what I was planning to do. Make an open source computer that is... | 08:40 |
Powermaniac | open hardware* I should say | 08:40 |
Powermaniac | Although you seem one step ahead and actually have a FPGA board to work on already | 08:41 |
Powermaniac | And have implememented ORSoCv3 on it already as well. | 08:41 |
hansfbaier | Powermaniac: https://github.com/hansfbaier/openrisc-sockit-tutorial | 08:42 |
Powermaniac | I plan to get a Digilent Atlys as it has all the ports I need to connect up a full computer type system | 08:42 |
rah | hansfbaier: if you can get ((349000 - 50875) / 294) - 1 = 1013 friends interested by Friday, you might be able to get one :-) | 08:42 |
hansfbaier | Powermaniac: the de0_nano is a great way to get started though | 08:42 |
Powermaniac | HDD, Mouse, Keyboard, Monitor etc. | 08:42 |
hansfbaier | Powermaniac: too expensive for me: Twice the price for less than half the size of FPGA, including retarded Xilinx software (no Chipscope). | 08:44 |
rah | eerie | 08:44 |
Powermaniac | hansfbaier: Oh okay, Stekern advised me to get the Digilent Atlys as it was the best value for money for what I'm trying to do | 08:45 |
rah | I was thinking exactly the same thing about the Digilent Atlys | 08:45 |
Powermaniac | Oh and connect wifi. | 08:45 |
rah | though I then saw it only has 45k cells | 08:45 |
hansfbaier | Powermaniac: Atlys - 45k Cells, Sockit = 115k cells | 08:45 |
Powermaniac | Holy | 08:45 |
hansfbaier | Sockit = only half the price of Atlys | 08:45 |
Powermaniac | Oh but I will get an Academic discount heh heh... | 08:46 |
rah | I still find this "bridging" business dubious | 08:46 |
* rah suspects it will be far from trivial | 08:46 | |
rah | hansfbaier: is it possible to bridge the HPS-connected peripherals to the FPGA with the HPS core disabled? | 08:47 |
hansfbaier | rah: You mean shut down? Good question. Don't know. You don't have to run anything on the HPS cores though. | 08:49 |
rah | or is the AXI bus dependent on the HPS core working? | 08:49 |
rah | ok | 08:49 |
Powermaniac | hansfbaier: Actually I might get the DE2 115 instead | 08:49 |
Powermaniac | As that has everything I need without a un needed ARM core | 08:49 |
_franck_ | rah: some of the onboard peripheral are connected to HPS reserved FPGA pins | 08:50 |
Powermaniac | hansfbaier: Still need to wait till Christmas though anyway | 08:50 |
rah | _franck_: what do you mean? | 08:50 |
rah | _franck_: what are "HPS reserved FPGA pins"? | 08:51 |
hansfbaier | Powermaniac: Why the de2? its about 3x the price of SocKit and has the same size. | 08:51 |
_franck_ | the FPGA has pins reserved for the HPS | 08:51 |
hansfbaier | Powermaniac: I still don't see why you want to pay 3x the price of sockit to get something without the ARM cores. Come on they don't bite... | 08:52 |
_franck_ | if you want to access them from your own logic, you need to bridge those from the HPS to your logic | 08:52 |
rah | _franck_: I know | 08:52 |
hansfbaier | Powermaniac: Maybe you can even put them in Powersave / sleep mode, where they consume next to no energy. | 08:52 |
rah | 08:47 < rah> hansfbaier: is it possible to bridge the HPS-connected peripherals to the FPGA with the HPS core disabled? | 08:52 |
rah | Powermaniac: beware that the DE2 only has 128MB RAM | 08:53 |
_franck_ | i would say yes | 08:53 |
Powermaniac | hansfbaier: Well I need a usb or sata or ethernet port for a HDD, a usb port or ps/2 port for keyboard, a ps/2 or usb port for mouse, a hdmi/vga/dvi for monitor, and a usb or ethernet port for wifi. And I already know for a fact I can get a student discount from terasic as I asked about the De0 nano | 08:53 |
hansfbaier | rah: don't know, didn't have enough time to play with it. My goals with the board are different: I want to learn how to write a Linux driver that bridges the HPS and OpenRISC systems | 08:53 |
rah | Powermaniac: the SocKit has 1G | 08:53 |
Powermaniac | rah: Ohh. So many factors I need to consider | 08:54 |
rah | hansfbaier: when you say a "Linux driver that bridges", do you mean a driver for devices on bridged bus(es), or something else? | 08:55 |
rah | hansfbaier: does Linux need to have an awareness of the bus bridge? | 08:55 |
hansfbaier | rah: it's in the linux device tree. | 08:56 |
rah | I grepped for "avalon" in the arch/openrisc/ directory and didn't find anything | 08:56 |
hansfbaier | rah: As for the SocKit the FPGA / HPS systems appear just as a region of memory | 08:56 |
rah | ah | 08:56 |
rah | ok | 08:56 |
rah | so the avalon bridge just acts like a memory map | 08:57 |
rah | I thought it might | 08:57 |
hansfbaier | rah: So I want to do first a char, then a network driver which connects the two systems, and hands over the data to the other via a special reserved region of RAM. | 08:57 |
hansfbaier | rah: It's actually AXI -> avalong -> wishbone | 08:58 |
hansfbaier | avalon | 08:58 |
hansfbaier | But wishbone is very similar to avalon | 08:58 |
rah | ok | 08:58 |
hansfbaier | so the bridge is very small | 08:58 |
hansfbaier | rah: Altera stuff all uses Avalon / OpenRISC/Opencores all use wishbone | 08:59 |
rah | yes, I see that :-) | 09:00 |
rah | I've seen that the orpsoc is all connected with wishbone | 09:00 |
rah | there is an overwhelming absence of I/O pins on the sockit :-/ | 09:03 |
rah | there is a grand total of: 1 | 09:04 |
rah | and it's connected to the HPS :-/ | 09:04 |
hansfbaier | rah: I bought this: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=322 | 09:04 |
rah | hmm | 09:05 |
hansfbaier | rah: Why not the cyclone V starter Kit? Killer price with those features.. | 09:06 |
hansfbaier | and no ARM cores | 09:06 |
hansfbaier | Even HDMI output | 09:06 |
rah | well indeed, why not | 09:07 |
hansfbaier | Arduino and 2x20 GPIO | 09:07 |
hansfbaier | very attractive | 09:07 |
hansfbaier | for only $179 | 09:07 |
rah | the only deal-breaker for me is: no USB | 09:07 |
rah | (or specifically: no general purpose USB) | 09:08 |
rah | plus fewer cells | 09:08 |
rah | but 4G RAM | 09:08 |
rah | choices, choices.. | 09:08 |
stekern | yeah, the sockit's lack of (easily accessible) I/O is a big disadvantage | 09:09 |
stekern | and IMO it's boring that you have all the goody peripherals only available to the HPS | 09:10 |
stekern | accessing the hardcores... sure, but you can't hack on them... | 09:10 |
stekern | I would choose the cyclone v kit over it if I wanted to play with peripherals connected to the fpga | 09:13 |
rah | well, as a newbie, my goal would be to require as little "playing" as possible to get a desktop machine working | 09:14 |
rah | the sockit requires playing with bridging the peripherals from the HPS to the FPGA, but the cyclone v starter kit requires playing with adding a USB host controller | 09:16 |
rah | (or implementing PS/2 connectors) | 09:16 |
rah | again.. choices, choices.. | 09:18 |
stekern | you only need to add an USB phy... but if you think adding PS/2 connectors is too much trouble, I think you'll find the whole experience getting a "desktop machine" working disappointing | 09:19 |
rah | indeed, possibly | 09:20 |
rah | I don't think it would be "too much" trouble | 09:21 |
stekern | the shortest path to get there is to buy the atlys and one of those usb keyboards that has integrated touchpad | 09:23 |
stekern | some of them seems to work with the usb-hid controller on that board (i.e. yyou can get both keyboard and the touchpad working at the same time) | 09:23 |
rah | but too many times I've invested money in something only to find that completing it requires even more, massive investment of time and energy to bring it to completion, because either I underestimated the ease of completing it, or the ease of completing it was misrepresented by others | 09:24 |
rah | this is why I'm wary of the sockit; it sounds like setting up bridged components is very much non-trivial | 09:24 |
stekern | well, I entered this project 3 years ago to use the processor in another project, I've started with the other project last week | 09:25 |
rah | the ideal for me, would be a board with USB and video with an orpsoc image ready to download | 09:25 |
rah | right | 09:25 |
stekern | so, easy choice, buy the atlys | 09:25 |
stekern | I can send you an image right away ;) | 09:26 |
rah | hmm | 09:26 |
rah | that's what I was thinking | 09:26 |
rah | but it's old and expensive and it's only 45k cells :-/ | 09:26 |
stekern | well "only" | 09:27 |
rah | compared to 100k+ on the sockit.. | 09:27 |
stekern | the whole fullblown orpsoc only takes ~50% of that iirc | 09:27 |
stekern | and that's with an ac97 core as well | 09:27 |
rah | hmm | 09:27 |
* rah ponders | 09:28 | |
stekern | oh... and the cyclone v board doesn't have ethernet, does it? | 09:29 |
rah | yes there is that, which is why I'd be keen on adding a USB controller rather than PS/2 | 09:48 |
rah | you can use a USB NIC | 09:48 |
flozn | hello guys! i got some issues using c++ with minsoc. i do not use standard libraries (nostdlib,no-startfiles,no-exceptions) but minsoc reset/interrupt handling. a sigbus error occurs if local variables are passed by reference from c++ to (already proven) c-code. | 09:53 |
flozn | does someone have an idea :) ? maybe there is a stack problem between c and c++ ? | 09:53 |
nvmind | flozn: they should be compatible ;) | 09:54 |
nvmind | function call is done in the same way | 09:55 |
flozn | hm. at the first sight in the disassembly i thought this too ;) . do you have an idea what could be another cause? i used the default linkerscript of | 09:57 |
stekern | flozn: is this with the or1k- toolchain or the or32- one? | 09:58 |
flozn | gcc-Version 4.5.1-or32-1.0rc4 (or32-elf/lib/ldscripts/or32elf.x) | 09:58 |
flozn | i added the stack definition according to minsoc to the linkerscript | 10:00 |
nvmind | flozn: you can reduce your code to a simple test case and try simulate its execution with icarus to see what is going on on the bus. | 10:01 |
flozn | now my workaround is a new c-function which creates the local variables and calls the c-function. it only get parameters by value from c++. this works :/ . | 10:01 |
flozn | nvmind: yes, i can do! | 10:02 |
stekern | can you paste a disasm of the caller and the callee? | 10:02 |
flozn | the sigbus error occurs due to npc=0 (if i dont miss anything). | 10:02 |
stekern | and on what are you running this? | 10:02 |
flozn | minsoc dev | 10:02 |
flozn | stekern: one moment please. i get the disassembly | 10:03 |
stekern | have you tried runing it in or1ksim? | 10:03 |
nvmind | flozn: does it work on or1k-sim? | 10:03 |
stekern | +n | 10:03 |
nvmind | :) | 10:03 |
flozn | actually not the c++ program. | 10:04 |
nvmind | if it works on the simulator the problem should stay in an upper level (more likely) or the simulator is wrong (rare). | 10:06 |
nvmind | if it doesn't work** | 10:06 |
nvmind | sorry. | 10:06 |
flozn | here the disassembly: http://pastebin.com/b8LtdgGz | 10:08 |
stekern | yeah, I'd try to reproduce on or1ksim | 10:09 |
stekern | if you can reproduce there, a lot easier to debug it there, if you can't reproduce there, start hunting hw bugs ;) | 10:09 |
flozn | ah! sry! two essential lines are missing :/ | 10:09 |
flozn | ok. so i will try to simulate the faulty lines. | 10:10 |
nvmind | I missed something... | 10:11 |
nvmind | passing by refernce what does it mean in C? | 10:11 |
flozn | here the the "full" disassambly: http://pastebin.com/b3b8bjrU | 10:12 |
stekern | why not just run the whole program in or1ksim, not just the faulty lines? ;) | 10:12 |
nvmind | C doesn't have referencies it uses pointer for this stuf | 10:12 |
flozn | "by reference" was not exact. "by pointer" it should be | 10:12 |
flozn | sry for that! | 10:12 |
flozn | stekern: ok ;) | 10:13 |
nvmind | you are allocating an obj on the stack and passing its address to a C function, aren't you? | 10:13 |
flozn | yes | 10:14 |
flozn | (local variable) | 10:14 |
flozn | and the problem occurs during "dereferencing" (sry for bad english ... i'm german ) | 10:15 |
stekern | there's still a lot of lines missing... | 10:16 |
flozn | ok, i paste the whole disassembly | 10:16 |
stekern | but it looks right from the ones you can see.. | 10:17 |
nvmind | I bet the error is in the ld script ;) | 10:17 |
stekern | 5478: d7 e2 27 ec l.sw 0xffffffec(r2),r4 <- pData saved | 10:17 |
stekern | 574c: 84 62 ff ec l.lwz r3,0xffffffec(r2) <- pData loaded | 10:17 |
flozn | here the whole disassambly: http://pastebin.com/GiQy87bf | 10:18 |
stekern | 5750: 94 63 00 02 l.lhz r3,0x2(r3) <- load pData->data | 10:19 |
flozn | nvmind: of what did you though especially? | 10:20 |
stekern | flozn: I can't see anything obvious wrong in the disasm, could you go ahead and try in or1ksim to rule out hw problems? | 10:24 |
flozn | hm. i am on the way to simulate. until now i only simulated the whole system with icarus verilog. the or1ksim is building now. | 10:25 |
stekern | ah, ok | 10:26 |
nvmind | flozn: 0xffffffec <- is it the base address for your stack? | 10:28 |
flozn | i dont think so. the stack starts at 0x8000 and has a size of 0x1000 | 10:29 |
nvmind | flozn: what I suspect is that you are accessing an address that is not physically there | 10:32 |
stekern | nvmind: thats an offset of -20 from the frame pointer (r2) | 10:32 |
flozn | nvmind: at first i thought this too. but with the dev version of minsoc i synthesized a soc with 64k (0x1.0000) the software behaves the same. | 10:34 |
olofk | stekern: You're right. wb_intercon_gen should only support 2^n sized address partitions. Forgot to add a check for that | 10:55 |
stekern | heh... I've been adding the ac97 core to orpsoc-cores and sockit, to find out that it doesn't have an ac97 codec, but an i2s... | 11:29 |
olofk | whoops | 11:29 |
stekern | well well, it's not all wasted effort, the ac97.core file can still be of use ;) | 11:30 |
olofk | yep. On the atlys for example | 11:31 |
stekern | mmm | 11:32 |
olofk | I should fire up my LX9 Microboard and start on the ISE backend for ORPSoC | 11:32 |
stekern | I think I'll copy out the instantiation too, for later | 11:33 |
flozn | @stekern,nvmind: after updating manually all build tools or1ksim is running. now i may have to spend some time in it because it seems minsoc doesn't support or1ksim out of the box (no configfile). thanks alot for your help and your time!! :) | 11:35 |
stekern | there should come a sample config file with or1ksim you could start with | 11:38 |
olofk | I usually use the one from Jonas' Linux tree. That one should work too | 11:39 |
stekern | you probably have to alter your program slightly, since there is no i2c simulation in or1ksim | 11:39 |
stekern | but with i2s codec instead of ac97... I start to feel the scope creep crawling up my back | 11:40 |
olofk | :) | 11:41 |
stekern | now I need to write an i2s core... and a Linux driver for that | 11:41 |
olofk | Is i2s similar to i2c? | 11:41 |
stekern | yes... but no | 11:41 |
stekern | I've already written an i2s interface, so the core shouldn't be to much of a big deal | 11:41 |
flozn | olofk: thanks for the tip! hopefully i get some results ;) | 11:41 |
stekern | http://git.chokladfabriken.org/?p=sk-synth/.git;a=blob;f=vhdl/i2s.vhdl;h=e355c3315face807b98b49148962714021422400;hb=d949823ac78e8e58ec857b710a69a2eb15d86222 | 11:42 |
olofk | stekern: Jesus. That's a wide bus for simple audio | 11:45 |
olofk | ah.. sorry. That was the internal bus | 11:46 |
stekern | yes, the data_l and data_r are the parallell data | 11:48 |
stekern | the chip on the sockit is more complex than the one I used there though... it has linout, linein and micin | 11:49 |
stekern | and an i2c configuration interface | 11:49 |
stekern | but the default configuration looks sane enough that I probably can get a proof-of-concept core up and running without touching that | 11:59 |
stekern | ...except that the DAC is muted | 12:05 |
hansfbaier | stekern: The wb_intercon.v(h)? | 13:49 |
hansfbaier | stekern: Are those generated or hand written? | 13:49 |
hansfbaier | stekern: probably not. Otherwise they would be under build/... | 14:06 |
rah | stekern: you said you could send me an image for the Digilent Atlys board right now | 14:07 |
rah | stekern: does that image include an HDMI (or DVI) transmitter? | 14:07 |
stekern | hansfbaier: autogenerated, but "manually" with wb_intercon_gen | 14:12 |
stekern | rah: yes | 14:14 |
rah | stekern: is it the xapp495 core from xilinx? | 14:16 |
stekern | it's a hacked up version of that | 14:18 |
rah | I see | 14:18 |
hansfbaier | stekern: What is the baudrate for serial on de0_nano? I get only garbage at 115200 and grepping got me not much yet | 14:30 |
hansfbaier | ... | 14:30 |
hansfbaier | stekern: Mybe I should find the tutorial from conference again... | 14:31 |
hansfbaier | Maybe | 14:31 |
stekern | the baudrate is what you configure the uart to | 14:31 |
stekern | but the default in libgloss is 115200 | 14:32 |
hansfbaier | stekern: libgloss? | 14:32 |
stekern | yes | 14:32 |
stekern | what sw are you running? | 14:32 |
hansfbaier | stekern: barebox / linux only garbage | 14:33 |
stekern | in linux it's what you set at command line, but it should be 115200 | 14:34 |
hansfbaier | stekern: maybe wrong levels.... But I soldered the bridge on the FT232 to 3.3V. That should be ok. | 14:36 |
hansfbaier | Weird | 14:36 |
hansfbaier | stekern: one of the reasons to hate UARTS. Love them if they work | 14:36 |
stekern | where did you attach the uart? there is a difference between where we had them in the workshop and "where I always had them" | 14:42 |
hansfbaier | stekern: at the bottom header | 14:42 |
hansfbaier | stekern: attached a PL2303 now instead same problem weird | 14:42 |
hansfbaier | stekern: default | 14:43 |
stekern | and you use main orpsoc-cores? I wouldn't expect garbage if you had it wrong though... | 14:43 |
hansfbaier | stekern: 3.3-V LVTTL says tcl. | 14:43 |
hansfbaier | stekern: yes, unmodified from git orpsocv3 | 14:44 |
stekern | weird... | 14:44 |
hansfbaier | stekern: blinky and memory tester run fine barebone | 14:45 |
hansfbaier | de0_nano | 14:45 |
hansfbaier | stekern: Wait a minute... | 14:46 |
hansfbaier | stekern: different clock settings | 14:46 |
hansfbaier | on barebox/linux still had the values from my EP4CE10 | 14:46 |
hansfbaier | Bingo | 14:50 |
hansfbaier | barebox runs | 14:50 |
hansfbaier | stekern: compatible = "opencores,or1200-rtlsvn481"; | 15:18 |
hansfbaier | is this still up-to-date for orpsocv3, or does it use mor1kx by default? | 15:18 |
hansfbaier | stekern: If mor1kx, where do I find a proper dts? | 15:19 |
stekern | it does, but linux doesn't know the difference | 15:25 |
hansfbaier | stekern: Can you give me the device tree for your 'instant' linux kernel image? | 15:33 |
hansfbaier | de0_nano? | 15:33 |
hansfbaier | stekern: linux crashes with my dts.... Bus error after: | 15:34 |
hansfbaier | bio: create slab <bio-0> at 0 | 15:34 |
hansfbaier | KERNEL: Bus error (SIGBUS) 0xbc000002 | 15:34 |
hansfbaier | stekern: The instant kernel runs well | 15:34 |
hansfbaier | stekern: arch/openrisc/boot/dts/de0_nano.dts | 15:35 |
hansfbaier | stekern: that's what mine looks like | 15:36 |
* hansfbaier -> bed | 15:42 | |
-!- larks_ is now known as larks | 15:49 | |
poke53281 | stekern: I managed to compile everything. It is unstable but i could some results. The results are unexpected. | 19:22 |
poke53281 | Yes. gcc is much faster. Around a factor of 4-5. | 19:23 |
poke53281 | But guess the speed improvment of nbench. | 19:23 |
nvmind | Runtime Error: or1k_usb_blaster_adv.tcl:3: invalid command name "usb_blaster" | 19:41 |
nvmind | do you know how to solve ti? | 19:42 |
nvmind | it* | 19:42 |
_franck_ | which OpenOCD repo did you use ? | 19:42 |
nvmind | git://git.code.sf.net/p/openocd/code | 19:43 |
nvmind | I have tried also git@github.com:fjullien/openOCD.git | 19:44 |
nvmind | but the build is broken | 19:44 |
_franck_ | you should use the one from soureforge | 19:44 |
nvmind | ok. | 19:44 |
_franck_ | then openocd -f interface/altera-usb-blaster.cfg -f board/or1k_generic.cfg | 19:45 |
_franck_ | did you select usb-blaster when you ./configure ? | 19:45 |
nvmind | I was using the wrong configuration... | 19:46 |
nvmind | ./src/openocd -f ./tcl/interface/altera-usb-blaster.cfg -f ./tcl/board/or1k_generic.cfg | 19:46 |
nvmind | Runtime Error: embedded:startup.tcl:47: Can't find target/or1k.cfg | 19:46 |
_franck_ | yes becuase you didn't install it. Add a ./tcl/ in front of target/or1k.cfg in ./tcl/board/or1k_generic.cfg | 19:47 |
_franck_ | or just add "-s ./tcl" on the command line | 19:48 |
nvmind | ok now it's not working in another way :) | 19:50 |
nvmind | Warn : Burst read timed out | 19:50 |
nvmind | Warn : Burst read timed out | 19:50 |
nvmind | Error: Burst read failed | 19:50 |
nvmind | Error: Error while calling or1k_save_context | 19:50 |
nvmind | Error: Error while calling or1k_debug_entry | 19:50 |
nvmind | R | 19:50 |
nvmind | now I think that the ball is in my court... | 19:50 |
nvmind | _franck_: thanks a lot. | 19:51 |
nvmind | any idea? | 19:51 |
_franck_ | no, what is your setup ? | 19:51 |
_franck_ | usb blaster + virtual jtag tap + adv_dbg_if ? | 19:52 |
nvmind | now the jtag is working in the simulation with openocd and jtag_vpi and icarus | 19:52 |
nvmind | _franck_: yes | 19:52 |
_franck_ | that should work without any problem | 19:52 |
_franck_ | good to know the jtag_vpi is working for you | 19:53 |
_franck_ | do you have the good TAP selected in or1k_generic.cfg ? (VJTAG) | 19:54 |
_franck_ | you should also change your FPGAID | 19:54 |
nvmind | read "it's working" as I can load a program and break at main ;) | 19:54 |
nvmind | _franck_: slow down ... it's all new stuff for me :) | 19:55 |
nvmind | what should I check? | 19:56 |
nvmind | Info : JTAG tap: or1200.cpu tap/device found: 0x020b30dd (mfg: 0x06e, part: 0x20b3, ver: 0x0) | 19:56 |
nvmind | this? | 19:56 |
_franck_ | 0x020b30dd should be the same as what is specified in or1k_generic.cfg as FPGAID | 19:58 |
nvmind | set FPGATAPID 0x020b30dd | 19:58 |
_franck_ | ok fine | 19:59 |
nvmind | so it is ok. | 19:59 |
_franck_ | you also have a Cyclone II on your board ? (de1 ?) | 20:00 |
nvmind | yes de1 | 20:01 |
_franck_ | I have the same board | 20:01 |
nvmind | can you take a fast look at my soc_top? just to triple check ;) | 20:03 |
nvmind | http://pastie.org/private/uawbq1cutqxfdpdh1tgndg | 20:03 |
_franck_ | you can check mine here: | 20:06 |
_franck_ | https://github.com/openrisc/orpsoc-cores/blob/master/systems/de1/rtl/verilog/orpsoc_top.v | 20:06 |
nvmind | _franck_: have you read about the reason that was causing me the CRC error with simulation? | 20:08 |
nvmind | I wrote it yesterday but I missed the feedbacks.... | 20:08 |
_franck_ | yes I had the same problem: | 20:10 |
_franck_ | https://github.com/openrisc/orpsoc-cores/blob/master/cores/adv_debug_sys/patches/0000-Force-x-to-zero-in-adbg-crc32-during-sim.diff | 20:10 |
_franck_ | are you using orpsocv3 ? | 20:10 |
nvmind | no | 20:13 |
nvmind | I am building my own | 20:13 |
nvmind | I started using as a "template" minsoc | 20:14 |
nvmind | and step by step replacing things | 20:14 |
_franck_ | ok | 20:15 |
nvmind | my target is to generate the soc | 20:15 |
nvmind | with an HLS tool | 20:15 |
nvmind | named panda :) | 20:15 |
nvmind | for your information it can generate accelerators with wishbone 4 interface | 20:16 |
* _franck_ uses google | 20:16 | |
nvmind | http://panda.dei.polimi.it/ | 20:17 |
nvmind | I am the guy behind the wishbone interface generation :) | 20:18 |
_franck_ | ok great and now your are on the other side of the wishbone :) | 20:19 |
nvmind | yes :) | 20:20 |
nvmind | this is my master degree thesis :) | 20:20 |
rfajardo | hehe | 20:21 |
nvmind | if you are interested in HLS... give panda a try | 20:21 |
nvmind | it supports xilinx, altera and recently also lattice FPGA | 20:22 |
nvmind | any feedback is welcome. | 20:23 |
nvmind | by the way was not that the issue :) | 20:23 |
_franck_ | so it generates RTL blocks for you ? | 20:23 |
nvmind | yep. | 20:25 |
nvmind | starting from plain C | 20:25 |
nvmind | the issue was that the register file was not initialized | 20:27 |
_franck_ | do you have a chart with benches results with and without hardware accelaration on some hardware platforms ? | 20:28 |
_franck_ | "register file was not initialized" I know and it what it is in the real life. We get some X because it is undefined | 20:29 |
_franck_ | if we clear the register file during simulation, I could mask some problems | 20:30 |
-!- nvmind` is now known as nvmind | 20:32 | |
_franck_ | s/I/it | 20:33 |
nvmind | ? | 20:34 |
nvmind | I think I missed somthing | 20:34 |
_franck_ | when you run it on your hardware, the RAM is not initialized. This is what we want in simulation | 20:36 |
nvmind | well in the asic world this is true | 20:38 |
nvmind | but block ram are initialized with zeros | 20:38 |
_franck_ | well, we try to be as generic as possible | 20:40 |
nvmind | anyway I solved placing an initial block | 20:41 |
nvmind | well we should consider adding this kind o things only for FPGA target | 20:41 |
nvmind | it has no cost but some lines of verilog | 20:42 |
_franck_ | that was my first move when I had this problem ;) | 20:43 |
rfajardo | nvmind, I'm happy someone is trying to do something good out of minsoc :) | 20:44 |
nvmind | rfajardo: I have used it as a source of inspiration :) and as a learning toy. It is simple enough to be understood by a complete novice :) | 20:46 |
rfajardo | nvmind, The idea was to configure easily and explain well the procedures. Fair enough. Did OpenOCD help? | 20:48 |
nvmind | rfajardo: well then you did a good job... it is fool proven ;) | 20:50 |
rfajardo | nvmind, you would wonder in which ways people can mess things :) | 20:54 |
nvmind | :) I think I am one of those... :) on minsoc I am able to connect to the board with gdb while on my design not yet ;) | 20:55 |
nvmind | btw tomorrow I'll check again my connection looking at _franck_'s top design | 20:57 |
rfajardo | It fails under simulation but works with the board? | 20:57 |
nvmind | the other way around | 20:58 |
rfajardo | hmm, I bet on the Jtag TAP | 20:59 |
nvmind | I have to check connection between altera_virtual_jtag | 20:59 |
nvmind | and debug unit | 21:00 |
nvmind | well if connections are correct | 21:01 |
rfajardo | go for it, it will eventually work out | 21:02 |
rfajardo | but you did switch to openocd after all? | 21:02 |
rfajardo | btw, does anyone know if the linux repository of Jonas is up to date? If the wiki installation description is up to date? I have just tried to install the linux headers and it failed. | 21:02 |
nvmind | may be is something during synthesis... | 21:03 |
nvmind | rfajardo: yes, I did. | 21:04 |
nvmind | mainly becouse openocd is widely used also for other stuff | 21:04 |
rfajardo | great | 21:05 |
rfajardo | I'm glad it works | 21:05 |
rfajardo | well | 21:05 |
rfajardo | I will get going now | 21:05 |
rfajardo | good luck ! | 21:05 |
_franck_ | rfajardo: I using Jonas' tree now | 21:05 |
nvmind | and you know... studends after me will learn something that can be reused | 21:05 |
_franck_ | *'m | 21:05 |
rfajardo | _franck_: headers installation fails because it looks for a non existing include/uapi/linux/netfilter/xt_CONNMARK.h | 21:08 |
rfajardo | related to scripts/Makefile.headersinst:55 | 21:08 |
_franck_ | let me try | 21:11 |
_franck_ | http://pastie.org/8404906 | 21:14 |
_franck_ | it works here | 21:14 |
_franck_ | I do have include/uapi/linux/netfilter/xt_CONNMARK.h in my tree | 21:15 |
rfajardo | I only have xt_CONNSECMARK.h | 21:16 |
rfajardo | but well | 21:16 |
rfajardo | I have to go now. Thanks for the info _franck_. I will let it know how it goes. | 21:16 |
rfajardo | good night everyone! | 21:16 |
_franck_ | me too, good night | 21:17 |
nvmind | night | 21:19 |
poke53281 | stekern: While running nbench I get around 100 tlb refills a second. So the is speed benefit is zero. However gcc speeds up a lot. | 21:40 |
poke53281 | olofk: What is your twitter account doing right now ;) | 22:50 |
--- Log closed Wed Oct 16 00:00:41 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!