| --- Log opened Mon Jan 09 00:00:05 2017 | ||
| wallento | shorne: its P9 | 01:27 |
|---|---|---|
| wallento | and P10 | 01:27 |
| shorne | wallento: thanks, I see do you know if those are implemented anywhere? | 01:39 |
| wallento | IIRC no, it was more a "if anyone wants 64bit this would be very useful" discussion | 01:40 |
| shorne | olofk: stekern: thanks, I will close this pull request then : https://github.com/openrisc/linux/pull/5 | 01:41 |
| shorne | wallento: understood | 01:42 |
| wallento | I remember that address and constant formation made a lot of sense to me | 01:42 |
| wallento | I will draft something for the inter-processor communication | 01:43 |
| wallento | maybe a bit more than the boot flag | 01:43 |
| wallento | it will be a small set of SPRs I think | 01:43 |
| shorne | Alright, that would be good | 01:44 |
| shorne | it would be good to cover everything that is missing that has been implemented for SMP | 01:45 |
| shorne | like SPR_COREID | 01:47 |
| shorne | anyone else think this code looks wrong? https://github.com/openrisc/linux/blob/master/arch/openrisc/kernel/entry.S#L265 | 02:11 |
| shorne | l.andir6,r6,SPR_SR_DSX // check for delay slot exception | 02:11 |
| shorne | l.sfeqir6,0x1 // exception happened in delay slot | 02:11 |
| shorne | shouldn't it be l.sfgeui r6,0x1? | 02:13 |
| shorne | or l.sfeqi r6,SPR_SR_DSX (if thats small enough to fit in immediate) | 02:15 |
| olofk | ZipCPU, shorne: I always assumed l was for long | 02:20 |
| olofk | As in longword | 02:20 |
| olofk | But that could be totally wrong of course | 02:23 |
| olofk | Should perhaps ask Damjan about this | 02:24 |
| wbx | olofk: should i give you my mailadress fo the bitstream (de0 nano) | 02:40 |
| wbx | ? | 02:40 |
| wallento | shorne: yes, I agree | 02:57 |
| wallento | despite I think that l.sfne r6, r0 would be more elegant | 02:58 |
| olofk | wbx: Oh, right. Sorry. Forgot about that. I'll build an image now and give you a link. Ping me in 30 minutes if I haven't done it by then | 03:08 |
| olofk | wbx: Hmm.. we have two options for the bootloader | 03:09 |
| olofk | 1. mor1kx will read instructions from address 0x100 when reset is released. This option requires that you have a JTAG cable that you can use to put a program into the RAM before running | 03:10 |
| olofk | 2. mor1kx will read out an image from the SPI Flash. This option requires that you have a program stored on the SPI Flash | 03:10 |
| olofk | Which do you prefer? | 03:10 |
| shorne | wallento: right I think r0 instead of const is much better | 03:25 |
| wallento | yeah, and also it is more like a set/not set comparison, than using gt | 03:25 |
| wallento | I find that easier to read | 03:26 |
| shorne | yeah, I agree | 03:26 |
| -!- LoneTech_ is now known as LoneTech | 04:37 | |
| olofk | stekern: I'm considering to add a signal to mor1kx to indicate burst length of the transaction, to make it a bit easier to create bridges to other bus interfaces. Do you know where in the design that the burst length is known? Is that in {i,b}bus_bridge? | 06:47 |
| olofk | Or deeper down in the CPU? | 06:47 |
| olofk | ok...this will take more than five minutes to figure out :) | 06:53 |
| olofk | Remind me to never write a CPU | 06:53 |
| ZipCPU|Laptop | olofk: Didn't we have this discussion? I seem to recall we had this discussion back at ORCONF. | 06:57 |
| ZipCPU|Laptop | So, basically, the only things that do bursts within a CPU are typically the caches. | 07:03 |
| ZipCPU|Laptop | The burst length will be equal to the size of a cache line--in MOR1KX this is captured by parameters to the core. | 07:04 |
| ZipCPU|Laptop | Two things will create burst memory reads/writes: the icache (reads only) and the dcache (burst writes depend upon implementation) | 07:05 |
| ZipCPU|Laptop | Looking at line 80 of mor1kx_bus_if_wb32.v, you can see how bursts are determined: | 07:10 |
| ZipCPU|Laptop | On any read request, the CPU automatically declares itself to be bursting. | 07:10 |
| olofk | ZipCPU|Laptop: I think you're right. We talked about this before | 07:29 |
| olofk | And I think I see how it's implemented now | 07:30 |
| olofk | in mor1kx | 07:30 |
| ZipCPU|Laptop | What bus are you bridging to? AXI? | 07:31 |
| olofk | UI | 07:35 |
| ZipCPU|Laptop | Ah ... did you ever get enough of an example that you could work with it? | 07:35 |
| olofk | Well, I have it working just fine when I connect it to my DMA streamers | 07:36 |
| ZipCPU|Laptop | That's a good start. | 07:36 |
| olofk | And I'll probably start out with trying andrzejr's bridge with single accesses | 07:37 |
| ZipCPU|Laptop | Does the UI interface request/require burst lengths? Or just your WB implementation? | 07:38 |
| olofk | It requires burst lengths. There are separate channels for commands, read data and write data. On the command channel you tell the start address and how much to transfer | 07:39 |
| olofk | Basically | 07:40 |
| ZipCPU|Laptop | Just like axi. Got it. | 07:40 |
| olofk | I think Wishbone is the only bus that doesn't have explicit burst lengths | 07:40 |
| ZipCPU|Laptop | When I bridged from wb/b4/p to axi, I just created a *lot* of individual transactions. | 07:41 |
| olofk | (probably wrong about that) | 07:41 |
| ZipCPU|Laptop | Are you able to do that here, or are you choosing not to because it isn't very optimal? | 07:41 |
| olofk | Performance is secondary at this point, so I'll start with single accesses | 07:42 |
| ZipCPU|Laptop | Then the problem is solved: set your burst length to 1. ;) | 07:42 |
| ZipCPU|Laptop | In case you are curious, I'm trying to (re)build the ZipCPU with 8-bit bytewise accesses. | 07:44 |
| olofk | Does it complicate things? | 07:45 |
| olofk | I'm still not sure 8-bit bytes are really that good. Except for that you will have a lot better sw compatibility of course | 07:46 |
| ZipCPU|Laptop | That's sort of why I'm doing it--s/w compatibility has become a *real* hassle. | 07:46 |
| olofk | But for many workloads you don't really need to access on an 8-bit level that often | 07:46 |
| ZipCPU|Laptop | My biggest headache so far is that I need to rebuild binutils and GCC. | 07:47 |
| ZipCPU|Laptop | Turns out the changes were fairly confined to the instruction decoder, and the memory unit. | 07:47 |
| ZipCPU|Laptop | From the standpoint of the items on the bus, only the memory items need to support it. | 07:48 |
| ZipCPU|Laptop | I haven't committed the changes, so that I can accurately sit back and test to see what the impact is. | 07:48 |
| ZipCPU | If I can't run my "O/S" on the Spartan 6/LX4 anymore, I may have to discard the changes. | 07:54 |
| stekern | olofk: as you found out, burst length is always == cache length | 08:04 |
| stekern | line | 08:05 |
| stekern | if you think propagating that info out to the bus translation would be useful, I wouldn't be against such a patch | 08:05 |
| stekern | even though you already can get it from the outside by taking the cache line size | 08:06 |
| olofk | stekern: But the caches are disabled on startup, aren't they? | 08:14 |
| olofk | So that the first acceses are always single accesses | 08:14 |
| olofk | ok, so just as I suspected, the UI bus differs enough between the 7-series and Spartan-6 so that I can't use andrzejr's version without a lot of changes | 08:18 |
| olofk | I'll look at the one in Atlys instead | 08:18 |
| olofk | oh... that one was a bit more complicated than I had anticipated | 08:20 |
| olofk | Aha! wb_to_userport seems to be what I'm looking for | 08:22 |
| olofk | Sneaky inlined module | 08:22 |
| ZipCPU | olofk: Where'd you find that wb_to_userport routine? | 08:41 |
| stekern | olofk: yes, but why does that matter? | 08:45 |
| stekern | olofk: are you looking at the atlys xilinx to wb things? | 08:46 |
| stekern | that was one of the first things I ever wrote in verilog... so expect some madness ;) | 08:46 |
| olofk | ZipCPU: https://github.com/openrisc/orpsoc-cores/blob/master/systems/atlys/rtl/verilog/xilinx_ddr2/xilinx_ddr2_if.v#L731 | 08:49 |
| olofk | stekern: I decided to write my own simple asynchronous version that doesn't use burst at all instead | 08:49 |
| ZipCPU | No wonder I couldn't find it -- I think I was looking in mor1kx-generic. | 08:49 |
| olofk | stekern: Is it correct that mor1kx performs single accesses until caches are explicitly turned on? In that case I don't have enough info from outside the CPU to determine burst lengths | 08:57 |
| stekern | yes | 08:58 |
| stekern | what do you consider "outside" the cpu? | 08:58 |
| stekern | the bus translator knows if the cpu is performing bursts (of cache line length) or none bursts | 08:59 |
| olofk | outside == "not having to make any changes to the mor1kx repo" | 09:01 |
| stekern | mmm, but then you are using wishbone? | 09:01 |
| olofk | Yes | 09:02 |
| stekern | to translate from? | 09:02 |
| olofk | ? | 09:02 |
| stekern | then you know the burst length, no? | 09:02 |
| olofk | ok, my idea is to add an extra burst length indicator to all wishbone masters in my system (likely only mor1kx in many cases), so that it's easier to translate the wb bus to other protocols | 09:03 |
| stekern | wbm_bte_o | 09:04 |
| olofk | Yes and no | 09:04 |
| stekern | 4, 8, 16 (or linear) | 09:04 |
| olofk | ah ok. For mor1kx it's that easy perhaps | 09:04 |
| olofk | But strictly speaking, you can have a wrap-8 burst that is 5 or 37 words long | 09:05 |
| olofk | But if I limit the scope to mor1kx for now, bte would be enough | 09:05 |
| stekern | olofk: sure, but it wouldn't be a problem to support that by issuing 8-wrap bursts outwards | 12:27 |
| wbx | olofk: method two I would like to try | 12:48 |
| olofk | wbx: Done. https://www.dropbox.com/s/pbed6hrs2xlw86o/de0_nano_0.sof?dl=0 | 16:45 |
| olofk | Next step is to create an application that can be put into the SPI Flash | 16:45 |
| olofk | If you have an OpenRISC ELF file, you can convert it to a binf ile and then use this script https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/utils/flash_helper.sh to combine it with the sof and burn it to flash | 16:47 |
| shorne | stekern: I am looking into the todo item for emulation around adjust_pc(). I think I can do it, but interestingly it requires emulating the jmp instruction as well | 23:50 |
| shorne | It would be nice it mor1kx (and or1k spec) had a BTR (branch target regiester) like in microblaze. | 23:51 |
| shorne | When we get an exceeption in a delay slot it seems the only way to finish is to emulate the jump. Agreed? | 23:52 |
| --- Log closed Tue Jan 10 00:00:07 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!