IRC logs for #openrisc Wednesday, 2014-10-15

--- Log opened Wed Oct 15 00:00:38 2014
-!- xlro` is now known as xlro01:43
sb0Power management interface provides signals for interfacing RISC core [...] pm_tt_gate Gating of tick timer clock05:01
stekernsb0: where are you reading that?05:18
stekernwhy on earth are you reading that? ;)05:19
sb0I was actually looking for info on the shift instructions...05:19
stekernread the arch spec instead of an implementation spec (of an implementation that you don't use):
sb0yeah, I found it05:21
sb0maybe that should be linked on instead of this document05:21
stekernwallento is working on a better landing page for openrisc05:23
-!- FreezingAlt is now known as FreezingCold06:39
olofk_sb0: is Jonas Bonn's website. He's not very active nowadays, so a lot of the info there is outdated07:39
olofk_And unfortunately gets quite a high page rank07:39
-!- olofk_ is now known as olofk07:40
olofkstekern: stream_reader passes my test bench now. Cleaning up and pushing if you want to try it out09:14
stekernolofk: \o/09:30
stekernI've been extremely tired the last couple of days, conference once a year is definitely sufficient09:31
wallentohey guys10:13
wallentoI try to get the build process with separate newlib and libgloss straight now10:14
wallentodo we plan to maintain or1k-src with git-subtrees for newlib, libgloss and gdb?10:14
stekernyeah, that's at least an option10:18
olofkI think that's a good intermediate solution10:19
stekernbut I think the actual process of seperating them is more important10:19
wallentoyes, I will first leave newlib in or1k-src10:20
wallentoand just build withpuut10:21
olofkwallento: Is it in good enough shape to push to github now?10:36
_franck__stekern: what do you think about this ?12:17
_franck__(the bottom part)12:18
olofkYes. I think I got DMA working for both sending and receiving now. Have no good idea what I should do with the data though12:20
maxpalnHi 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
maxpalnwe're talking 100's byte/s maximum!12:21
olofkmaxpaln: 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 that12:23
stekernis the !mode_option alone good enough?12:24
_franck__it's only if !mode_option12:24
stekernyes, but the CONFIG_OF check doesn't add any extra value12: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
stekernno, I think they just return an error then12: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 check12:27
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_mode12:29
stekern_franck__: yes, but a lot of #ifdef CONFIG_OF has been deprecated, since the functions now have stubs instead12:31
stekernI 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
stekernand 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 driver12:34
stekernmaxpaln: 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_OF12:41
maxpalnThe 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 guess12:41
_franck__I'll grep for of_get_fb_videomode and see if I can find something related to non CONFIG_OF configs12: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 raised12:43
maxpalnThe 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
stekernmaxpaln: is that the 'spi-max-frequency' property of the mtd node in the device-tree?12:44
stekernyeah, 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 fine12: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 anyway12:47
_franck__I mean we can but it's not usefull12:47
stekernfb_find_mode() falls back to the default, no?12:51
stekernif mode_option == 012:52
_franck__then  mode_option = fb_mode_option;12:53
_franck__which is something12:53
_franck__ok, I'll rewrite something when I have time12:54
maxpalnstekern: 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
stekernmaxpaln: if you turn up debugging (or turn that into a printk), what does this say?
maxpalnstekern: good suggestion/question. I'm just rebuilding the HW/kernel - I'll check and see.13:00
olofkAnyone got some ideas what I can do with a bunch of received samples?13:50
olofkI guess that I could calculate a mean value or something13:50
olofkNot terribly exciting, but still something13:51
olofkNow I know! I can calculate a mean value and display on the LEDs13:51
olofkI just invented "The LED pitch". Is your idea good enough to be presented on eight LEDs13: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 chip13:54
_franck__ok, so just do your led thing ;)13:56
maxpalnit's like the 8-minute abs workout :-) It's fine until someone invents the "7-led pitch" :-)14:20
maxpalnstekern: looks like the baudrate is ok: Established baudrate 34090900, wanted 34090900 (i=0)Established baudrate 34090900, wanted 34090900 (i=0)Established baudrate 34090900, wanted 3409090014:30
maxpalnalthough 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
stekernmaxpaln: I would add some instrumentation to this function then, measuring how often it's called and how long it takes etc:
stekernactually, perhaps this would be more interesting:
stekern7 leds are enough to show the ascii-table, who need more?15:09
maxpalnstekern: 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
maxpalnoh, an olofk: stekern has already beaten you with his 7-led pitch - the pace of developments today :-)16:04
maxpalnneed to reboot!16:06
olofkWhen does endianness actually matter btw? Are things like a = b & 0x0000ffff endian-agnostic?16:14
stekernit matters when you read something from memory16:17
stekern...or write16:17
olofkSo if I store everything in the cloud instead of RAM, I should be fine16:18
stekernno, the cloud is big endian16:18
olofkAh crap16:18
stekernso, for a be openrisc implementation, you should be fine16:19
olofkhmm... 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 are16:21
olofkAmazing how much stuff I forgot since I never got to use it since school16:23
stekernyes, that's exactly what happens16:28
olofkok. Cool. Is there any situation where swapping the byte order in HW wouldn't solve issues?16:29
stekernyou can see the effect by executing this on a x86 and or1ksim:
olofkNo way I'm going to run some random piece of code posted on the internet16:37
stekernolofk: depends on to what extent you are swapping the bytes ;)16:37
stekern...and what the problem is16:38
olofkSome 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 it16:41
stekernwell, 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 machine16:42
olofkWhy not?16:43
stekernif 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
olofkHas anyone used verilator with multiple clocks?18:28
olofkstekern: Just thought of something. Will the mor1kx store buffer work with DMA?18:41
olofkI 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
olofkIs the CPU supposed to write stuff to address 0x4?20:24
olofkhmm.. is the data cache getting in the way here?20:47
olofkYes! That's it20:49
olofkSo what's the thing to do here? I could set up a small wb_ram in the uncached area and use that as a buffer20:52
olofkBut I somewhat assumed that a volatile pointer would invalidate the cache20:52
olofkOr do I need snooping here?21:03
--- Log closed Thu Oct 16 00:00:39 2014

Generated by 2.15.2 by Marius Gedminas - find it at!