IRC logs for #openrisc Tuesday, 2013-10-29

--- Log opened Tue Oct 29 00:00:00 2013
poke53281stekern: pastie.org/843892502:05
poke53281Took around 1.5 hours.02:05
poke53281But contains my varargs patch.02:07
poke53281The libstdc++ tests are running right now.02:08
poke53281And it's much easier to test than using or1ksim. Almost no configuration.02:20
poke53281 make check RUNTESTFLAGS="--target_board=or1k-sim"02:20
poke53281and a bash script with contains only one line: "qemu-or32 -L /path/to/your/sysroot $@"02:29
poke53281pastie.org/843898902:54
poke53281And here is the rest02:54
poke53281All together 155 minutes.02:55
stekernpoke53281: 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
poke53281I am still waiting for an answer from Lia Liu. The new patches are almost ready to send to the mailing list.04:54
poke53281If you want yaou can directly get the 21 patches.04:55
poke53281git apply *.patch should be enough.04:55
poke53281simulationcorner.net/qemu-patches.tar.gz05:05
poke53281pastie.org/843915905:09
poke53281I will send the patches maybe tomorrow.05:09
poke53281It'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
stekernpoke53281: but aren't they going to?05:49
poke53281Yes, they are going to.05:49
olofk_Which SPI Flash controller do we usually use?05:50
poke53281But they didn't do a year ago.05:50
poke53281But probably they didn't care.05:50
stekernpoke53281: aha, I didn't know about that05:50
stekernolofk_: simple spi05:50
stekernah, no.. now I understand your question05:51
stekernor the depth of the question05:51
stekernthe answer is the same ;)05:51
poke53281No, 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
stekernpoke53281: 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 priorities05:53
stekernof *their* priorities, I mean05:54
stekerndoesn't mean it's not important05:54
stekernbut I need to get better at bugging people too...05:54
stekernmy transparent union fix for clang never got applied, even though it's completely broken in mainline05:55
stekernprobably because I wasn't pushing hard enough05:55
stekernolofk_: or do you mean what SPI flash chips are most used?05:56
poke53281I know what you mean.05:57
olofk_stekern: No, I wondered about the RTL side.06:03
stekernok, then the answer is spi simple, you don't need a special spi flash controller06:04
stekernwhat would be nice though, would be to add quad spi support to the spi controller06: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 controller06:14
olofk_I'm not very good at dogfooding the cores :)06:14
stekernI guess if you want to make a pure hw system, you'd need a "driver" for the SPI core06:19
stekernbut if you have a cpu in the system, don't try to make it smart06:20
stekernsince all drvier frameworks expect the core to not be, so you'd just end up doing hacks to workaround the "smartness"06:21
stekernI 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 be06:25
rahysionneau: my goal is to create a desktop computer08:00
rahysionneau: that would be possible with 128MB but it would be stretching it08:00
ysionneauoh a desktop computer08:22
ysionneauindeed the Milkymist One could be one but it's not the design goal08:22
ysionneauthe design goal was more a visual jockey standalone embedded box08:23
ysionneauI don't remember on which board but the OpenRISC people have Xorg, glxgears and scummvm running on Linux on their System-on-Chip08:24
ysionneauso it's pretty close to a desktop :)08:24
ysionneauon the Milkymist One we don't have Xorg, we only have ucLinux for now08:24
ysionneaumaybe in a few months NetBSD =)08:24
stekernysionneau: porting orpsoc to m1 wouldn't be much of a hassle08:25
ysionneauyes I bet08:25
stekernand it was on an atlys board that I ran the Xorg demo, that's very similar to the m1 board08:26
ysionneauis the M1 "better" than the board that ran Xorg and stuff at OpenRISC project meeting?08:26
ysionneauan Altera board IIRC08:26
ysionneaumore RAM? more Flash?08:27
stekernno, it's a spartan6 board08:27
ysionneauah ok08:27
stekernthe atlys board have 128MB DDR208:27
stekernexactly the same fpga as on m108:27
ysionneauyeah 128 MB but 16 bit wide :(08:27
stekernbut the atlys board doesn't have usb phy on-board08:27
stekernsomething rah wants08:28
ysionneauah, indeed we have the USB phy on the M108:28
stekernand m1 also had sdcard, that's missing from atlys as well08:28
ysionneauyou can connect some usb mice, some usb keyboards and some USB-MIDI devices08:29
stekern(and midi/dmx connectors, but I doubt rah is interested in that)08:29
ysionneauwith our usb host controller08:29
ysionneauoh, there is a Nexys 4 board now!08:30
ysionneauI didn't know that08:30
stekern...or any usb 1 device with another usb host controller08:30
ysionneauyes ;)08:31
ysionneauyou have a host controller in orpsoc?08:31
ysionneauwith a linux driver08:32
stekernit's not integrated into orpsocv2, but there was a couple of orpsocv2 boards that used the opencores usb host controller08:32
ysionneaupretty cool :)08:33
stekernnot integrated into orpsocv3 I mean08:35
stekernit's messy and the linux driver is also messy, but it works (most of the time)08:35
stekernthe u-boot driver is beautiful though08:36
stekern(guess who wrote it?) ;)08:36
ysionneauhehe08:44
ysionneauhttp://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
ysionneauand you don't have any usb host phy13:53
ysionneaubut you can maybe add one as an external board using the Pmods13:53
ysionneauhum 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
ysionneauBut then you need to write your own DDR3 memory controller13:55
ysionneauor use the hard IP which is basically locking your design to one FPGA vendor/family13:56
raharen't there hard DDR3 memory controllers14:07
rahon the FPGA(s)?14:07
rahI thought they all had memory controllers built in14:08
rahoh "hard IP"14:17
rahthat's what you mean14:17
rahysionneau: there are DDR memory controllers on opencores.org14:18
rahincluding a DDR3 controller14:18
ysionneauit seems to support DIMM sticks14:23
ysionneaunot sure how easy it is to modify it to control directly DRAM chips14:24
olofk_Isn't the programmable part of a Zync 7010 quite small?14:33
LoneTechrah: not all14:40
olofkFinally applied the patches from hansfbaier!18:34
olofkHey de0_nano owners. What's this for https://github.com/hansfbaier/orpsoc-cores/commit/991a3e6336e56749b3ad3896a975fd04b9ec7cab18:41
olofk?18:42
poke53281No I am feeling like a spammer.19:05
stekernolofk: no idea19:14
stekernhaven't noticed that before19:14
stekernpoke53281: what do you mean by "the toolchain is missing floating point support"?19:55
stekernthat you didn't enable hard floats when you compiled the tests?19:56
stekerndoes our qemu emulate the fp instructions btw?19:57
poke53281Yes, it does. But you are right. I haven't included it.20:18
poke53281Very often I am writing faster then my brain thinks ;)20:31
stekernfamiliar problem ;)20:35
stekerndon't openrisc@lists.openrisc.net accept postings from non-members? I thought it did20:53
poke53281seems not.20:54
poke53281But I think it is the correct way to CC to the Openrisc mailing lists.20:55
poke53281This patchset is doing some considerable changes and needs to be discussed.20:57
stekernyes, I think so too. I'm not following qemu-devel, but I'm interested in the patches ;)21:01
poke53281Hope 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_laptop21:07
-!- Netsplit over, joins: olofk, jeremybennett, mick_laptop21:14
_franck_I think I'm ready to write an openocd driver for our sockit's USB-Blaster II21: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 pins21:55
_franck_I also disassembled the cypress firmware which is loaded during the usb blaster setup21: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 601021:58
_franck_then you can start to send commands21:58
stekernmmm21:58
stekernbut they are note exactly like the blaster 1 commands21:59
stekerns/note/not21:59
_franck_the only difference is the 5F, it prepares the read buffer to the host21:59
stekernbut if you have the cypress firmware, it should be easy to figure out22:00
_franck_until you send 5F, there is no data back22:00
_franck_well, no :)22:00
stekernyeah, that was what I figured out from the usb logs too22:00
_franck_no firmware does not do usefull things for us22:00
stekernbut there was other differences than that22:01
_franck_endoint 4 and 8 are handled by the cypress hardware and the chip acts like a fifo22:01
stekernah, ok22:01
_franck_the firmware can control the JTAG pins to configure the CPLD22:01
_franck_it can read/write the eeprom in the CPLD22:02
_franck_there is also a serial protocol between the cypress and the CPLD but I don't know what it is for22:02
_franck_anyway, using libusb I can control the JTAG lines using bit bang mode and byte mode like the old blaster22:03
stekernthe bit bang mode never worked like the old blaster for me22:04
_franck_well, I does for me :) or I didn't get how the old one worked22:04
_franck_how did you test it ?22:04
stekernwith openocd and some other test program22:05
stekernwait22:05
stekernI 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 program22:06
stekernhttps://github.com/swetland/jtag.git22:07
poke53281I 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
stekerncould of course be me missing something too, if you get sane stuff on the jtag lines you're probably doing things right22:08
stekernbecause I had to hack in the 0x5f in that, so maybe I messed things up22:10
_franck_I'll look at that22:10
stekernhere's some ramblings about the bitbang mode: http://juliusbaxter.net/openrisc-irc/%23openrisc.2013-07-08.log.html#t18:5222: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 122:20
_franck_I'll remove the 0R resistor on TDI and put a switch here to be sure22:20
_franck_s/TDI/TDO22:23
_franck_blaster input22:23
_franck_stekern: it's almost working with https://github.com/swetland/jtag.git23: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: arokux123: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!