| --- Log opened Tue Oct 29 00:00:00 2013 | ||
| poke53281 | stekern: pastie.org/8438925 | 02:05 |
|---|---|---|
| poke53281 | Took around 1.5 hours. | 02:05 |
| poke53281 | But contains my varargs patch. | 02:07 |
| poke53281 | The libstdc++ tests are running right now. | 02:08 |
| poke53281 | And it's much easier to test than using or1ksim. Almost no configuration. | 02:20 |
| poke53281 | make check RUNTESTFLAGS="--target_board=or1k-sim" | 02:20 |
| poke53281 | and a bash script with contains only one line: "qemu-or32 -L /path/to/your/sysroot $@" | 02:29 |
| poke53281 | pastie.org/8438989 | 02:54 |
| poke53281 | And here is the rest | 02:54 |
| poke53281 | All together 155 minutes. | 02:55 |
| stekern | poke53281: nice, do you have your patches pushed to some repo or do we have to wait for them to get applied to test them? | 04:32 |
| poke53281 | I am still waiting for an answer from Lia Liu. The new patches are almost ready to send to the mailing list. | 04:54 |
| poke53281 | If you want yaou can directly get the 21 patches. | 04:55 |
| poke53281 | git apply *.patch should be enough. | 04:55 |
| poke53281 | simulationcorner.net/qemu-patches.tar.gz | 05:05 |
| poke53281 | pastie.org/8439159 | 05:09 |
| poke53281 | I will send the patches maybe tomorrow. | 05:09 |
| poke53281 | It's fascinating. They did such a nice job implementing the OpenRISC architecture but then didn't apply a 40 lines patch to increase the speed by a factor of 4-5. | 05:16 |
| stekern | poke53281: but aren't they going to? | 05:49 |
| poke53281 | Yes, they are going to. | 05:49 |
| olofk_ | Which SPI Flash controller do we usually use? | 05:50 |
| poke53281 | But they didn't do a year ago. | 05:50 |
| poke53281 | But probably they didn't care. | 05:50 |
| stekern | poke53281: aha, I didn't know about that | 05:50 |
| stekern | olofk_: simple spi | 05:50 |
| stekern | ah, no.. now I understand your question | 05:51 |
| stekern | or the depth of the question | 05:51 |
| stekern | the answer is the same ;) | 05:51 |
| poke53281 | No, what I want to say: The problem was obvious during that time in my opinion. But none of the developers changed the source. | 05:51 |
| stekern | poke53281: yeah, you have to be persistent and keep bugging people, their concentration might have shifted towards something else, so the thing you're currently working on might not be highest list of priorities | 05:53 |
| stekern | of *their* priorities, I mean | 05:54 |
| stekern | doesn't mean it's not important | 05:54 |
| stekern | but I need to get better at bugging people too... | 05:54 |
| stekern | my transparent union fix for clang never got applied, even though it's completely broken in mainline | 05:55 |
| stekern | probably because I wasn't pushing hard enough | 05:55 |
| stekern | olofk_: or do you mean what SPI flash chips are most used? | 05:56 |
| poke53281 | I know what you mean. | 05:57 |
| olofk_ | stekern: No, I wondered about the RTL side. | 06:03 |
| stekern | ok, then the answer is spi simple, you don't need a special spi flash controller | 06:04 |
| stekern | what would be nice though, would be to add quad spi support to the spi controller | 06:04 |
| olofk_ | Ah ok. Some guys at work wanted to make a SPI Flash Controller. I said, look at opencores, and they found some other controller | 06:14 |
| olofk_ | I'm not very good at dogfooding the cores :) | 06:14 |
| stekern | I guess if you want to make a pure hw system, you'd need a "driver" for the SPI core | 06:19 |
| stekern | but if you have a cpu in the system, don't try to make it smart | 06:20 |
| stekern | since all drvier frameworks expect the core to not be, so you'd just end up doing hacks to workaround the "smartness" | 06:21 |
| stekern | I noticed yesterday that my good old trusty midi keyboard have lost functionality on one of it's keys :( | 06:23 |
| olofk_ | This is a stupid fucking hw only system where everything is ten times a complicated as they really have to be | 06:25 |
| rah | ysionneau: my goal is to create a desktop computer | 08:00 |
| rah | ysionneau: that would be possible with 128MB but it would be stretching it | 08:00 |
| ysionneau | oh a desktop computer | 08:22 |
| ysionneau | indeed the Milkymist One could be one but it's not the design goal | 08:22 |
| ysionneau | the design goal was more a visual jockey standalone embedded box | 08:23 |
| ysionneau | I don't remember on which board but the OpenRISC people have Xorg, glxgears and scummvm running on Linux on their System-on-Chip | 08:24 |
| ysionneau | so it's pretty close to a desktop :) | 08:24 |
| ysionneau | on the Milkymist One we don't have Xorg, we only have ucLinux for now | 08:24 |
| ysionneau | maybe in a few months NetBSD =) | 08:24 |
| stekern | ysionneau: porting orpsoc to m1 wouldn't be much of a hassle | 08:25 |
| ysionneau | yes I bet | 08:25 |
| stekern | and it was on an atlys board that I ran the Xorg demo, that's very similar to the m1 board | 08:26 |
| ysionneau | is the M1 "better" than the board that ran Xorg and stuff at OpenRISC project meeting? | 08:26 |
| ysionneau | an Altera board IIRC | 08:26 |
| ysionneau | more RAM? more Flash? | 08:27 |
| stekern | no, it's a spartan6 board | 08:27 |
| ysionneau | ah ok | 08:27 |
| stekern | the atlys board have 128MB DDR2 | 08:27 |
| stekern | exactly the same fpga as on m1 | 08:27 |
| ysionneau | yeah 128 MB but 16 bit wide :( | 08:27 |
| stekern | but the atlys board doesn't have usb phy on-board | 08:27 |
| stekern | something rah wants | 08:28 |
| ysionneau | ah, indeed we have the USB phy on the M1 | 08:28 |
| stekern | and m1 also had sdcard, that's missing from atlys as well | 08:28 |
| ysionneau | you can connect some usb mice, some usb keyboards and some USB-MIDI devices | 08:29 |
| stekern | (and midi/dmx connectors, but I doubt rah is interested in that) | 08:29 |
| ysionneau | with our usb host controller | 08:29 |
| ysionneau | oh, there is a Nexys 4 board now! | 08:30 |
| ysionneau | I didn't know that | 08:30 |
| stekern | ...or any usb 1 device with another usb host controller | 08:30 |
| ysionneau | yes ;) | 08:31 |
| ysionneau | you have a host controller in orpsoc? | 08:31 |
| ysionneau | with a linux driver | 08:32 |
| stekern | it's not integrated into orpsocv2, but there was a couple of orpsocv2 boards that used the opencores usb host controller | 08:32 |
| ysionneau | pretty cool :) | 08:33 |
| stekern | not integrated into orpsocv3 I mean | 08:35 |
| stekern | it's messy and the linux driver is also messy, but it works (most of the time) | 08:35 |
| stekern | the u-boot driver is beautiful though | 08:36 |
| stekern | (guess who wrote it?) ;) | 08:36 |
| ysionneau | hehe | 08:44 |
| ysionneau | http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1198&Prod=ZYBO < you have a lot more RAM but the board is "closed source" | 13:53 |
| ysionneau | and you don't have any usb host phy | 13:53 |
| ysionneau | but you can maybe add one as an external board using the Pmods | 13:53 |
| ysionneau | hum the usb is said to be OTG so to support host ... I wonder who is doing the usb phy? the FPGA? a microcontroller? | 13:55 |
| ysionneau | But then you need to write your own DDR3 memory controller | 13:55 |
| ysionneau | or use the hard IP which is basically locking your design to one FPGA vendor/family | 13:56 |
| rah | aren't there hard DDR3 memory controllers | 14:07 |
| rah | on the FPGA(s)? | 14:07 |
| rah | I thought they all had memory controllers built in | 14:08 |
| rah | oh "hard IP" | 14:17 |
| rah | that's what you mean | 14:17 |
| rah | ysionneau: there are DDR memory controllers on opencores.org | 14:18 |
| rah | including a DDR3 controller | 14:18 |
| ysionneau | it seems to support DIMM sticks | 14:23 |
| ysionneau | not sure how easy it is to modify it to control directly DRAM chips | 14:24 |
| olofk_ | Isn't the programmable part of a Zync 7010 quite small? | 14:33 |
| LoneTech | rah: not all | 14:40 |
| olofk | Finally applied the patches from hansfbaier! | 18:34 |
| olofk | Hey de0_nano owners. What's this for https://github.com/hansfbaier/orpsoc-cores/commit/991a3e6336e56749b3ad3896a975fd04b9ec7cab | 18:41 |
| olofk | ? | 18:42 |
| poke53281 | No I am feeling like a spammer. | 19:05 |
| stekern | olofk: no idea | 19:14 |
| stekern | haven't noticed that before | 19:14 |
| stekern | poke53281: what do you mean by "the toolchain is missing floating point support"? | 19:55 |
| stekern | that you didn't enable hard floats when you compiled the tests? | 19:56 |
| stekern | does our qemu emulate the fp instructions btw? | 19:57 |
| poke53281 | Yes, it does. But you are right. I haven't included it. | 20:18 |
| poke53281 | Very often I am writing faster then my brain thinks ;) | 20:31 |
| stekern | familiar problem ;) | 20:35 |
| stekern | don't openrisc@lists.openrisc.net accept postings from non-members? I thought it did | 20:53 |
| poke53281 | seems not. | 20:54 |
| poke53281 | But I think it is the correct way to CC to the Openrisc mailing lists. | 20:55 |
| poke53281 | This patchset is doing some considerable changes and needs to be discussed. | 20:57 |
| stekern | yes, I think so too. I'm not following qemu-devel, but I'm interested in the patches ;) | 21:01 |
| poke53281 | Hope so. You will like them in the end. My original motivation was to run the testsuite of libffi. I didn't like the current telnet solution. So I played with QEMU a little bit. | 21:04 |
| -!- Netsplit *.net <-> *.split quits: jeremybennett, olofk, mick_laptop | 21:07 | |
| -!- Netsplit over, joins: olofk, jeremybennett, mick_laptop | 21:14 | |
| _franck_ | I think I'm ready to write an openocd driver for our sockit's USB-Blaster II | 21:29 |
| stekern | _franck_: do you want a bunch of usb logs? | 21:52 |
| _franck_ | I have all I need, I did some tests with the scope connected to the JTAG pins | 21:55 |
| _franck_ | I also disassembled the cypress firmware which is loaded during the usb blaster setup | 21:56 |
| _franck_ | at first the pid is 0x6810 and there is no firmware in the cypress usb chip, then quatus loads the firmware into the chip (using control endpoint) | 21:58 |
| _franck_ | the usb chip renumerate and pid is 6010 | 21:58 |
| _franck_ | then you can start to send commands | 21:58 |
| stekern | mmm | 21:58 |
| stekern | but they are note exactly like the blaster 1 commands | 21:59 |
| stekern | s/note/not | 21:59 |
| _franck_ | the only difference is the 5F, it prepares the read buffer to the host | 21:59 |
| stekern | but if you have the cypress firmware, it should be easy to figure out | 22:00 |
| _franck_ | until you send 5F, there is no data back | 22:00 |
| _franck_ | well, no :) | 22:00 |
| stekern | yeah, that was what I figured out from the usb logs too | 22:00 |
| _franck_ | no firmware does not do usefull things for us | 22:00 |
| stekern | but there was other differences than that | 22:01 |
| _franck_ | endoint 4 and 8 are handled by the cypress hardware and the chip acts like a fifo | 22:01 |
| stekern | ah, ok | 22:01 |
| _franck_ | the firmware can control the JTAG pins to configure the CPLD | 22:01 |
| _franck_ | it can read/write the eeprom in the CPLD | 22:02 |
| _franck_ | there is also a serial protocol between the cypress and the CPLD but I don't know what it is for | 22:02 |
| _franck_ | anyway, using libusb I can control the JTAG lines using bit bang mode and byte mode like the old blaster | 22:03 |
| stekern | the bit bang mode never worked like the old blaster for me | 22:04 |
| _franck_ | well, I does for me :) or I didn't get how the old one worked | 22:04 |
| _franck_ | how did you test it ? | 22:04 |
| stekern | with openocd and some other test program | 22:05 |
| stekern | wait | 22:05 |
| stekern | I never noticed the quartus loading the fw btw, but that was because I always did logs with quartus before running any tests ;) | 22:06 |
| _franck_ | ah ok, I wrote my own test program | 22:06 |
| stekern | https://github.com/swetland/jtag.git | 22:07 |
| poke53281 | I see. I explained my patches too good. :) Instead of being thankful and accept the patches I get tons of suggestions. But I like it. Most of them make sense. | 22:07 |
| stekern | could of course be me missing something too, if you get sane stuff on the jtag lines you're probably doing things right | 22:08 |
| stekern | because I had to hack in the 0x5f in that, so maybe I messed things up | 22:10 |
| _franck_ | I'll look at that | 22:10 |
| stekern | here's some ramblings about the bitbang mode: http://juliusbaxter.net/openrisc-irc/%23openrisc.2013-07-08.log.html#t18:52 | 22:13 |
| _franck_ | about bitbang read, I had the same interrogation. However, I did see the bit move in the byte which is send back to the host (0x10 or 0x11) | 22:19 |
| _franck_ | bit 7 seems always to be 1 | 22:20 |
| _franck_ | I'll remove the 0R resistor on TDI and put a switch here to be sure | 22:20 |
| _franck_ | s/TDI/TDO | 22:23 |
| _franck_ | blaster input | 22:23 |
| _franck_ | stekern: it's almost working with https://github.com/swetland/jtag.git | 23:20 |
| _franck_ | UB_OE has to be set to activate outputs (well, one could say it is normal...) | 23:21 |
| _franck_ | stekern: can you provides me the output of jtagconfig when connected to your sockit ? | 23:32 |
| -!- Netsplit *.net <-> *.split quits: arokux1 | 23:58 | |
| --- Log closed Wed Oct 30 00:00:02 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!