| --- Log opened Wed Oct 15 00:00:38 2014 | ||
| -!- xlro` is now known as xlro | 01:43 | |
| sb0 | Power management interface provides signals for interfacing RISC core [...] pm_tt_gate Gating of tick timer clock | 05:01 |
|---|---|---|
| sb0 | seriously? | 05:01 |
| stekern | sb0: where are you reading that? | 05:18 |
| sb0 | http://www.openrisc.net/or1200-spec.html | 05:19 |
| stekern | why on earth are you reading that? ;) | 05:19 |
| sb0 | I was actually looking for info on the shift instructions... | 05:19 |
| stekern | read the arch spec instead of an implementation spec (of an implementation that you don't use): https://github.com/openrisc/doc/blob/master/openrisc-arch-1.1-rev0.pdf?raw=true | 05:20 |
| sb0 | yeah, I found it | 05:21 |
| sb0 | maybe that should be linked on openrisc.net instead of this document | 05:21 |
| stekern | wallento is working on a better landing page for openrisc | 05:23 |
| -!- FreezingAlt is now known as FreezingCold | 06:39 | |
| olofk_ | sb0: openrisc.net is Jonas Bonn's website. He's not very active nowadays, so a lot of the info there is outdated | 07:39 |
| olofk_ | And unfortunately openrisc.net gets quite a high page rank | 07:39 |
| -!- olofk_ is now known as olofk | 07:40 | |
| olofk | stekern: stream_reader passes my test bench now. Cleaning up and pushing if you want to try it out | 09:14 |
| olofk | done | 09:20 |
| stekern | olofk: \o/ | 09:30 |
| stekern | I've been extremely tired the last couple of days, conference once a year is definitely sufficient | 09:31 |
| wallento | hey guys | 10:13 |
| wallento | I try to get the build process with separate newlib and libgloss straight now | 10:14 |
| wallento | do we plan to maintain or1k-src with git-subtrees for newlib, libgloss and gdb? | 10:14 |
| stekern | yeah, that's at least an option | 10:18 |
| olofk | I think that's a good intermediate solution | 10:19 |
| stekern | but I think the actual process of seperating them is more important | 10:19 |
| wallento | yes, I will first leave newlib in or1k-src | 10:20 |
| wallento | and just build withpuut | 10:21 |
| olofk | wallento: Is it in good enough shape to push to github now? | 10:36 |
| _franck__ | stekern: what do you think about this https://lkml.org/lkml/2014/6/23/336 ? | 12:17 |
| _franck__ | (the bottom part) | 12:18 |
| olofk | Yes. I think I got DMA working for both sending and receiving now. Have no good idea what I should do with the data though | 12:20 |
| maxpaln | Hi All, We are seeing some seriously low performance accessing SPI flashes via Linux (standard Linux Kernel and simple_spi ORPSOC peripheral). Has anyone else come across this issue? | 12:20 |
| maxpaln | we're talking 100's byte/s maximum! | 12:21 |
| olofk | maxpaln: Can't help you there, but maybe you need a kickass DMA component? | 12:22 |
| _franck__ | maxpaln: did you check your SPI speed with a scope ? | 12:22 |
| _franck__ | I only trust scopes ;) | 12:23 |
| stekern | _franck__: I agree with his argument, the fact that the CONFIG_OF option is enabled is not a good reason to try to get the mode from that | 12:23 |
| stekern | is the !mode_option alone good enough? | 12:24 |
| _franck__ | it's only if !mode_option | 12:24 |
| stekern | yes, but the CONFIG_OF check doesn't add any extra value | 12:24 |
| _franck__ | if CONFIG_OF is not enabled then I guess of_get_fb_videomode will be undefined (I should if #if CONFIG_OF may be) | 12:25 |
| stekern | no, I think they just return an error then | 12:26 |
| maxpaln | _frank__: I'll suggest that (I don't have the HW on my desk) - my thoughts are that it is a Linux driver issue, the scope should offer-up how the Linux kernel is driving the pins - my guess is slowly! | 12:26 |
| _franck__ | stekern: humm, need to check | 12:27 |
| _franck__ | http://lxr.free-electrons.com/source/drivers/video/fbdev/core/fbmon.c#L1435 | 12:28 |
| stekern | _franck__: either case, I think the right way is to: if (!mode_option) { try to get the stuff from OF } fallback to fb_find_mode | 12:29 |
| stekern | _franck__: yes, but a lot of #ifdef CONFIG_OF has been deprecated, since the functions now have stubs instead | 12:31 |
| stekern | I don't know if that's the case for these particular functions, but the fact that you found them somewhere doesn't mean that it's correct ;) | 12:32 |
| stekern | and this has really nothing to do with what the original comment was about, that the fact that OF is enabled doesn't mean that OF stuff is available for the driver | 12:34 |
| stekern | maxpaln: what frequency are you running the spi at? | 12:39 |
| _franck__ | stekern: in the piece of code linked above, of_get_fb_videomode is undefined when CONFIG_OF is not set (I couldn't find any stubs) that's why I think I should use #ifdef CONFIG_OF | 12:41 |
| maxpaln | The linux device tree has it listed as 68 MHz or so (the wishbone clock rate) - the datasheet max of the Flash is around 80 MHz so this is fine. But the real answer is 'as fast as linux is driving it' I guess | 12:41 |
| _franck__ | I'll grep for of_get_fb_videomode and see if I can find something related to non CONFIG_OF configs | 12:42 |
| stekern | _franck__: ah, ok. fair enough. but my other point was, just wrapping it inside a #ifdef CONFIG_OF will not address the issue Tomi raised | 12:43 |
| maxpaln | The bootrom code accesses the SPI flash much faster - not sure of the actual rate but quick enough to boot linux in a few seconds. So I am pretty confident the HW is not causing the problem. My feeling is that this is a Linux driver/configuration issue. | 12:43 |
| stekern | maxpaln: is that the 'spi-max-frequency' property of the mtd node in the device-tree? | 12:44 |
| stekern | yeah, 100 B/s doesn't sound right... | 12:44 |
| _franck__ | stekern: if kernel has CONFIG_OF but we didn't register the driver from the device tree then of_get_fb_videomode will fail and that's fine | 12:44 |
| stekern | _franck__: yes, but it's not fine in your current code, since it does not fall back to fb_find_mode() | 12:45 |
| _franck__ | we can't fall back to fb_find_mode() because !mode_options anyway | 12:47 |
| _franck__ | I mean we can but it's not usefull | 12:47 |
| _franck__ | s/can/could | 12:47 |
| stekern | fb_find_mode() falls back to the default, no? | 12:51 |
| stekern | if mode_option == 0 | 12:52 |
| _franck__ | then mode_option = fb_mode_option; | 12:53 |
| _franck__ | which is something | 12:53 |
| _franck__ | ok, I'll rewrite something when I have time | 12:54 |
| maxpaln | stekern: yes, I have this: | 12:56 |
| maxpaln | flash0: mtd@0 { | 12:56 |
| maxpaln | compatible = "stm,m25p64"; | 12:56 |
| maxpaln | reg = <0>; | 12:56 |
| maxpaln | spi-max-frequency = <68181800>; | 12:56 |
| stekern | maxpaln: if you turn up debugging (or turn that into a printk), what does this say? http://git.openrisc.net/cgit.cgi/stefan/linux/tree/drivers/spi/spi-oc-simple.c?h=smp#n99 | 12:58 |
| maxpaln | stekern: good suggestion/question. I'm just rebuilding the HW/kernel - I'll check and see. | 13:00 |
| olofk | Anyone got some ideas what I can do with a bunch of received samples? | 13:50 |
| olofk | I guess that I could calculate a mean value or something | 13:50 |
| olofk | Not terribly exciting, but still something | 13:51 |
| olofk | Now I know! I can calculate a mean value and display on the LEDs | 13:51 |
| olofk | I just invented "The LED pitch". Is your idea good enough to be presented on eight LEDs | 13:52 |
| _franck__ | they are samples of what ? | 13:53 |
| olofk | _franck__: Right now it's just a pregenerated sinus wave, but it's supposed to be I/Q data received from an SDR chip | 13:54 |
| _franck__ | ok, so just do your led thing ;) | 13:56 |
| maxpaln | it's like the 8-minute abs workout :-) It's fine until someone invents the "7-led pitch" :-) | 14:20 |
| maxpaln | stekern: looks like the baudrate is ok: Established baudrate 34090900, wanted 34090900 (i=0)Established baudrate 34090900, wanted 34090900 (i=0)Established baudrate 34090900, wanted 34090900 | 14:30 |
| maxpaln | although Linux appears to have halfed the baud rate from that selected in the device tree (I think there is a SPI config option for this!). But at ~35 Mb/s we should be able to get a sensible throughput! | 14:31 |
| stekern | maxpaln: I would add some instrumentation to this function then, measuring how often it's called and how long it takes etc: http://git.openrisc.net/cgit.cgi/stefan/linux/tree/drivers/spi/spi-oc-simple.c?h=smp#n223 | 15:03 |
| stekern | actually, perhaps this would be more interesting: http://git.openrisc.net/cgit.cgi/stefan/linux/tree/drivers/spi/spi-oc-simple.c?h=smp#n248 | 15:05 |
| stekern | 7 leds are enough to show the ascii-table, who need more? | 15:09 |
| maxpaln | stekern: thankfully this project now has a linux developer who knows what they are doing :-) it seems the problem is being resolved by a reimplementation of the MTD driver. I will try and get more details - although it it likely the actual code won't be published as this is a 3rd party SW house. | 16:04 |
| maxpaln | oh, an olofk: stekern has already beaten you with his 7-led pitch - the pace of developments today :-) | 16:04 |
| maxpaln | need to reboot! | 16:06 |
| olofk | When does endianness actually matter btw? Are things like a = b & 0x0000ffff endian-agnostic? | 16:14 |
| stekern | yes | 16:16 |
| stekern | it matters when you read something from memory | 16:17 |
| stekern | ...or write | 16:17 |
| olofk | So if I store everything in the cloud instead of RAM, I should be fine | 16:18 |
| stekern | no, the cloud is big endian | 16:18 |
| olofk | Ah crap | 16:18 |
| stekern | so, for a be openrisc implementation, you should be fine | 16:19 |
| olofk | hmm... say that I write 0x12345678 to address 0x1000 as a word to RAM, and read back 0x1000 as a byte, is that when I will get 0x12 or 0x78 depending on how large my endians are | 16:21 |
| olofk | ? | 16:21 |
| olofk | Amazing how much stuff I forgot since I never got to use it since school | 16:23 |
| stekern | yes, that's exactly what happens | 16:28 |
| olofk | ok. Cool. Is there any situation where swapping the byte order in HW wouldn't solve issues? | 16:29 |
| stekern | you can see the effect by executing this on a x86 and or1ksim: http://pastie.org/9650239 | 16:33 |
| olofk | No way I'm going to run some random piece of code posted on the internet | 16:37 |
| stekern | olofk: depends on to what extent you are swapping the bytes ;) | 16:37 |
| stekern | ...and what the problem is | 16:38 |
| olofk | Some people seem to put a lot of effort into creating an OpenRISC LE. Just seems like a stupid idea if you can easily get around it | 16:41 |
| stekern | well, just swapping the bytes at the memory interface is not going to help a lot if you try to run code that assumes LE on a BE machine | 16:42 |
| olofk | Why not? | 16:43 |
| stekern | if you swap both the bytes you write and the bytes you read, the read result is the same as if you wouldn't have done any swapping, isn't it? | 16:58 |
| olofk | oh... | 17:49 |
| olofk | Has anyone used verilator with multiple clocks? | 18:28 |
| olofk | stekern: Just thought of something. Will the mor1kx store buffer work with DMA? | 18:41 |
| olofk | I do a calculation for all values received in the DMA buffer, but I'm getting the same result every time. I suspect I need to mark something as volatile.. but what? | 19:35 |
| olofk | Is the CPU supposed to write stuff to address 0x4? | 20:24 |
| olofk | hmm.. is the data cache getting in the way here? | 20:47 |
| olofk | Yes! That's it | 20:49 |
| olofk | So what's the thing to do here? I could set up a small wb_ram in the uncached area and use that as a buffer | 20:52 |
| olofk | But I somewhat assumed that a volatile pointer would invalidate the cache | 20:52 |
| olofk | Or do I need snooping here? | 21:03 |
| --- Log closed Thu Oct 16 00:00:39 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!