| --- Log opened Wed May 15 00:00:59 2013 | ||
| -!- Netsplit *.net <-> *.split quits: Logxen, Amadiro | 05:00 | |
| -!- Netsplit over, joins: Logxen, Amadiro | 05:03 | |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/01f2a14ded13a163dfdd0f0d32c80e51bad3dfd8 | 05:12 |
|---|---|---|
| mor1kx | mor1kx/master 01f2a14 Stefan Kristiansson: cpu: make branch misprediction visible to monitor | 05:12 |
| stekern | juliusb_: you never pulled the pull request on mor1kx-devenv | 05:26 |
| stekern | I piled up some more on it now... | 05:26 |
| stekern | github pull requests are a bit ugly I think | 05:27 |
| stekern | especially the extra merge commit they add | 05:27 |
| stekern | anyways, your mor1kx-devenv is broken without https://github.com/skristiansson/mor1kx-dev-env/commit/28679b04743a47a6be40c61a646ba22917c2a736 so you probably want to pull that in sooner or later :) | 05:28 |
| stekern | s/or/than | 05:29 |
| stekern | looks like there is about a 80% prediction success rate with the the simple static prediction scheme now in place | 05:48 |
| stekern | which is inline with the numbers I've seen floating around the internet for that scheme | 05:52 |
| stekern | hno: was it this firmware blob you were talking about? https://github.com/amery/linux-allwinner/blob/import/lichee-3.3/a31-dev/arch/arm/mach-sun6i/ar100/binary/ar100.code | 07:29 |
| stekern | that at least disassembles nicely into or1k asm ;) | 07:31 |
| hno | stekern, yes. | 08:23 |
| stekern | cool | 08:43 |
| hno | Disassembled copy at https://github.com/hno/Allwinner-Info/tree/master/A31/ar100 | 08:43 |
| stekern | looks like they have a hardware multiplier in there | 08:44 |
| stekern | ah, nice, the strings are in there in your | 08:47 |
| stekern | I was just reading it with: or32-elf-objdump -D -EL --target binary -mor32 ar100.code | 08:47 |
| stekern | I wonder how that debug-uart is connected? | 09:20 |
| hno | stekern, I think it's using the same SoC UARTs as the ARM side. | 09:26 |
| hno | does l.movhi clear the lower bits? | 09:30 |
| stekern | yes | 09:32 |
| stekern | hmm, how do you mean the same uarts as the arm side? the pins are muxed? | 09:33 |
| hno | stekern, I mean the ARM and AR100 is sharing perpherial busses and shares the same set of UARTs. | 09:42 |
| hno | but yes nearly all I/O pins on the SoC is multifunction muxed pins. | 09:43 |
| stekern | hmm, possible | 09:47 |
| hno | I am not yet so good at reading openrisc assembly. Can't even find half ot the string references. | 09:48 |
| stekern | they seem to go to a printf function | 09:48 |
| hno | yes. | 09:49 |
| stekern | or I mean, most of them are referenced and then a printf function is called | 09:49 |
| stekern | haven't followed that in to the uart write yet though | 09:49 |
| hno | ther is one delay slot after l.jr, right? | 09:51 |
| stekern | yes, all branches have delay slots | 09:51 |
| stekern | and one is the number | 09:52 |
| stekern | l.jr r9 is return | 10:07 |
| stekern | you can pretty easily find see the function boundaries by looking at the stack save and restores | 10:08 |
| stekern | -find | 10:09 |
| hno | yes, already done. | 10:09 |
| hno | What is l.rfe? (0x24000000) | 10:53 |
| stekern | retturn from exception | 11:13 |
| hno | Ah, yes guessed so. | 11:16 |
| stekern | I think this is the uart output function: http://pastie.org/7911080 | 12:06 |
| stekern | so the uart write data register address is at 0x1f02800 | 12:10 |
| hno | stekern, ok so there is another UART. Seems to be addressible from the ARM side as well. Slightly unexpected. | 12:29 |
| stekern | so you're saying you can read the registers of that uart from the arm side? | 12:34 |
| stekern | I'm curious, because I'd like to get to see that uart output | 12:36 |
| hno | stekern, 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 |
| stekern | ok, I get the hint, I'll read through the kernel code more carefully ;) | 12:44 |
| stekern | is the tree that I pasted the only one that contains sun6i support? | 12:44 |
| hno | I think that's the only public one at this point. | 12:45 |
| stekern | I couldn't find anything related in the linux-sunxi github repo | 12:45 |
| stekern | ok, "good", then I'm looking at the right place at least | 12:46 |
| hno | In the tree I have (which isn't 100% the same) I found traces in arch/arm/mach-sun6i/include/mach/debug-macro.S | 12:47 |
| stekern | ok, I've only browsed via github web interface so far, too hard to grep there, cloning it now ;) | 12:48 |
| hno | it's there in that tree as well. | 12:49 |
| stekern | the code seems to be touching a lot of stuff in the 0x01f0xxxx range that isn't defined in the kernel | 13:10 |
| hno | stekern, yes, that seems to be an AR100 I/O range. There is some info in platform.h but very limited. | 14:40 |
| hno | bascially only which I/O devices are there and their register range, but no details on registers. | 14:40 |
| stekern | I wonder if it's limited to that range, or if it can access other io registers | 17:45 |
| hno | stekern, it's clearly accessing other io registers as well. For example https://github.com/hno/Allwinner-Info/blob/master/A31/ar100/ar100.or32#L771 | 18:30 |
| hno | there it accesses 0x01c20008, 0x01c20010 | 18:31 |
| hno | which is the main clock controller. | 18:32 |
| stekern | hno: yeah, you're right | 18:45 |
| stekern | that's pretty cool | 18:46 |
| stekern | ah, I see you've annotated the fuctions and the loops as well, nice! | 18:47 |
| stekern | *functions | 18:48 |
| hno | scripted a little grep + sed + printf + ed. | 18:49 |
| hno | static labels are easy to find. It's worse with partial addresses in the code. | 18:50 |
| hno | there 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 |
| stekern | yeah, me too | 18:52 |
| stekern | but I'm also interested in poking a bit at the sprs when it's running | 18:53 |
| stekern | to see which implementation it is (my guess is or1200), and otherwise see what configuration they have | 18:55 |
| stekern | the mul hw support is a bit surprising I think | 18:55 |
| stekern | hno: heh, I just realised you're sedish, I for some reason associated you're nick with asia =P | 19:07 |
| stekern | s/you're/your | 19:07 |
| stekern | and swedish not sedish | 19:08 |
| stekern | not that it matters, just funny how the brain works sometimes | 19:09 |
| hno | stekern, yes. | 19:27 |
| andresjk | what file implements the device driver for simple SPI core under linux? | 19:32 |
| stekern | andresjk: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/spi/spi_opencores.c | 19:34 |
| andresjk | thanks, stekern! | 19:35 |
| andresjk | is written as a module so I guess I have to compile it separately | 19:39 |
| stekern | no, you can compile it as builtin well | 19:42 |
| stekern | as well | 19:42 |
| andresjk | just by enabling spi support in the menuconfig, right? | 19:46 |
| stekern | yes, more specifically by setting: CONFIG_SPI_OCSIMPLE=y | 19:55 |
| stekern | but you'll need CONFIG_SPI=y and CONFIG_SPI_MASTER=y too | 19:56 |
| andresjk | in the .config file, thanks | 20:16 |
| --- Log closed Thu May 16 00:00:00 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!