IRC logs for #openrisc Wednesday, 2013-05-15

--- Log opened Wed May 15 00:00:59 2013
-!- Netsplit *.net <-> *.split quits: Logxen, Amadiro05:00
-!- Netsplit over, joins: Logxen, Amadiro05:03
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master 01f2a14 Stefan Kristiansson: cpu: make branch misprediction visible to monitor05:12
stekernjuliusb_: you never pulled the pull request on mor1kx-devenv05:26
stekernI piled up some more on it now...05:26
stekerngithub pull requests are a bit ugly I think05:27
stekernespecially the extra merge commit they add05:27
stekernanyways, your mor1kx-devenv is broken without so you probably want to pull that in sooner or later :)05:28
stekernlooks like there is about a 80% prediction success rate with the the simple static prediction scheme now in place05:48
stekernwhich is inline with the numbers I've seen floating around the internet for that scheme05:52
stekernhno: was it this firmware blob you were talking about?
stekernthat at least disassembles nicely into or1k asm ;)07:31
hnostekern, yes.08:23
hnoDisassembled copy at
stekernlooks like they have a hardware multiplier in there08:44
stekernah, nice, the strings are in there in your08:47
stekernI was just reading it with:  or32-elf-objdump -D -EL --target binary -mor32 ar100.code08:47
stekernI wonder how that debug-uart is connected?09:20
hnostekern, I think it's using the same SoC UARTs as the ARM side.09:26
hnodoes l.movhi clear the lower bits?09:30
stekernhmm, how do you mean the same uarts as the arm side? the pins are muxed?09:33
hnostekern, I mean the ARM and AR100 is sharing perpherial busses and shares the same set of UARTs.09:42
hnobut yes nearly all I/O pins on the SoC is multifunction muxed pins.09:43
stekernhmm, possible09:47
hnoI am not yet so good at reading openrisc assembly. Can't even find half ot the string references.09:48
stekernthey seem to go to a printf function09:48
stekernor I mean, most of them are referenced and then a printf function is called09:49
stekernhaven't followed that in to the uart write yet though09:49
hnother is one delay slot after l.jr, right?09:51
stekernyes, all branches have delay slots09:51
stekernand one is the number09:52
stekernl.jr r9 is return10:07
stekernyou can pretty easily find see the function boundaries by looking at the stack save and restores10:08
hnoyes, already done.10:09
hnoWhat is l.rfe? (0x24000000)10:53
stekernretturn from exception11:13
hnoAh, yes guessed so.11:16
stekernI think this is the uart output function:
stekernso the uart write data register address is at 0x1f0280012:10
hnostekern, ok so there is another UART. Seems to be addressible from the ARM side as well. Slightly unexpected.12:29
stekernso you're saying you can read the registers of that uart from the arm side?12:34
stekernI'm curious, because I'd like to get to see that uart output12:36
hnostekern, I don't have a device to test anything on. But the kernel code do have traces of using that UART as debug UART.12:43
stekernok, I get the hint, I'll read through the kernel code more carefully ;)12:44
stekernis the tree that I pasted the only one that contains sun6i support?12:44
hnoI think that's the only public one at this point.12:45
stekernI couldn't find anything related in the linux-sunxi github repo12:45
stekernok, "good", then I'm looking at the right place at least12:46
hnoIn the tree I have (which isn't 100% the same) I found traces in arch/arm/mach-sun6i/include/mach/debug-macro.S12:47
stekernok, I've only browsed via github web interface so far, too hard to grep there, cloning it now ;)12:48
hnoit's there in that tree as well.12:49
stekernthe code seems to be touching a lot of stuff in the 0x01f0xxxx range that isn't defined in the kernel13:10
hnostekern, yes, that seems to be an AR100 I/O range. There is some info in platform.h but very limited.14:40
hnobascially only which I/O devices are there and their register range, but no details on registers.14:40
stekernI wonder if it's limited to that range, or if it can access other io registers17:45
hnostekern, it's clearly accessing other io registers as well. For example
hnothere it accesses 0x01c20008, 0x01c2001018:31
hnowhich is the main clock controller.18:32
stekernhno: yeah, you're right18:45
stekernthat's pretty cool18:46
stekernah, I see you've annotated the fuctions and the loops as well, nice!18:47
hnoscripted a little grep + sed + printf + ed.18:49
hnostatic labels are easy to find. It's worse with partial addresses in the code.18:50
hnothere is likely still some functions misdetected with an l label. but not planning on doing a full reverse engineering of this, just curious in what it's doing.18:51
stekernyeah, me too18:52
stekernbut I'm also interested in poking a bit at the sprs when it's running18:53
stekernto see which implementation it is (my guess is or1200), and otherwise see what configuration they have18:55
stekernthe mul hw support is a bit surprising I think18:55
stekernhno: heh, I just realised you're sedish, I for some reason associated you're nick with asia =P19:07
stekernand swedish not sedish19:08
stekernnot that it matters, just funny how the brain works sometimes19:09
hnostekern, yes.19:27
andresjkwhat file implements the device driver for simple SPI core under linux?19:32
andresjkthanks, stekern!19:35
andresjkis written as a module so I guess I have to compile it separately19:39
stekernno, you can compile it as builtin well19:42
stekernas well19:42
andresjkjust by enabling spi support in the menuconfig, right?19:46
stekernyes, more specifically by setting: CONFIG_SPI_OCSIMPLE=y19:55
stekernbut you'll need CONFIG_SPI=y and CONFIG_SPI_MASTER=y too19:56
andresjkin the .config file, thanks20:16
--- Log closed Thu May 16 00:00:00 2013

Generated by 2.15.2 by Marius Gedminas - find it at!