| --- Log opened Tue Apr 19 00:00:28 2016 | ||
| olofk | shorne: I would guess that only the commercial implementations run for that long | 02:26 |
|---|---|---|
| olofk | But I'm not actually sure if any of them run mor1kx or if they still run or1200 | 02:26 |
| mithro | anyone heard of the "oldland CPU"? https://jamieiles.github.io/oldland-cpu/ ? | 02:58 |
| olofk | mithro: Nope, missed that one | 03:21 |
| olofk | As usual, a whole new set of JTAG, SPI, UART, SDRAM controllers. I will shoot the next person who does a new SPI or UART | 03:24 |
| olofk | Unless they actually take care to also create documentation, Linux drivers, bare-metal driver, device tree, testbench etc | 03:25 |
| shorne | olofk: thanks, ill leave it to a hardware bug for now, I guess its probably not some bug in the kernel I need to look into | 03:30 |
| shorne | olofk: I did an spi and uart last year for get my verilog chops back up. I just wont share it with anyone since I know there are much better cores than my hacks | 03:31 |
| shorne | dont shoot | 03:31 |
| olofk | :) | 03:33 |
| mithro | olofk: ha | 03:59 |
| mithro | olofk: what about https://github.com/jbush001/NyuziProcessor ? | 04:00 |
| olofk | mithro: Nyuzi has a FuseSoC port | 04:20 |
| olofk | You can run simulations on it and build for a de2 target | 04:20 |
| shorne | this guy James who wrote oldland cpu seems to just have done it for fun. he did it and the toolchain porting as well | 05:19 |
| shorne | quite interesting, not sure if I would try it | 05:20 |
| mithro | Does https://github.com/rdiez hang out in this channel at all? | 07:32 |
| _franck__ | mithro: rdiez used to come here or at least used to work on openrisc and express his strong opinion on the mailing list | 07:45 |
| mithro | I'm playing with his jtag_dpi module - but it seems like he implements a different (possibly older?) protocol to https://github.com/fjullien/jtag_vpi/blob/master/jtag_vpi.v | 07:59 |
| olofk | _franck__: :) | 08:04 |
| olofk | mithro: I don't really know what he did actually. Collaboration didn't seem to be his thing | 08:05 |
| olofk | The benefit of jtag_vpi is that we got a driver in OpenOCD | 08:06 |
| mithro | Looks like it might be "remote_bitbang.c" compatible... | 08:06 |
| _franck__ | mithro: I build this protocol from scratch and rdiez did the same | 08:10 |
| mithro | _franck__: you mean you built the jtag_vpi protocol from scratch? | 08:10 |
| _franck__ | mithro: yes, I mean it :) | 08:21 |
| mithro | It looks pretty trivial to adapt this jtag_dpi to this remote_bitbang protocol | 08:21 |
| _franck__ | what is your use case for jtag_dpi ? Is it for verilator simulations ? | 08:23 |
| mithro | _franck__: yes | 08:23 |
| _franck__ | mithro: https://github.com/openrisc/orpsoc-cores/blob/master/cores/verilator_tb_utils/jtagServer.cpp | 08:23 |
| _franck__ | https://github.com/openrisc/orpsoc-cores/blob/master/systems/mor1kx-generic/bench/verilator/tb.cpp#L108 | 08:24 |
| mithro | _franck__: that impliments the jtag_vpi protocol? | 08:26 |
| _franck__ | yes it is | 08:26 |
| olofk | FYI, the Pulpino guys also have some JTAG protocol https://github.com/pulp-platform/pulpino/blob/master/tb/jtag_dpi.sv | 08:28 |
| olofk | As does another RISC-V CPU author https://github.com/terpstra/opa/tree/master/jtag | 08:29 |
| _franck__ | great ! now I'll start to write a new UART | 08:29 |
| olofk | _franck__: Do you know if I can bring a gun to France or if I need to buy one when I arrive? | 08:30 |
| _franck__ | :) | 08:30 |
| _franck__ | At least as olofk said jtag_vpi has support in OpenOCD | 08:30 |
| mithro | I looked at the Pulpino version but it looked like overkill | 08:31 |
| olofk | Our old JTAG solution was a bit overkill too and tried (poorly) to implement a complete GDB server | 08:31 |
| olofk | Modularity and simplicity rules :) | 08:32 |
| mithro | Does verilator_tb_utils live in it's own repository at all? | 08:34 |
| _franck__ | it does. It's just a collection of helpers | 08:39 |
| olofk | mithro: It's still a part of orpsoc-cores. No one has split it out yet, but it should be done eventually | 09:38 |
| mithro | so the jtag server code seems to make verilator really slow? | 09:45 |
| mithro | well, bed time for me | 10:04 |
| mithro | gnight | 10:04 |
| olofk | mithro: Is it always slow, or just when you connect? | 12:19 |
| olofk | It might make sense to do more in verilog to avoid calling do_jtag so often. Haven't looked at the code really | 12:20 |
| SMDwrk | Hi, guys! Quick question: I'm struggling with reversing blob for one of arm socs which has ar100 inside it. It happens most disasms and even ida can't get any legitimate code out of the blobs. So maybe you could help me somehow? Any advice is appreciated! | 12:48 |
| stekern | SMDwrk: IIRC they have some endian swap on the bus, so you have to massage the binary a bit first | 13:05 |
| SMDwrk | sure, one moment: http://rghost.net/8nPy2L6bs | 13:13 |
| SMDwrk | If hosting is inappropriate, tell me where to put it | 13:13 |
| SMDwrk | stekern: I worry if allwinner has implemented some extentions to or1k core | 13:13 |
| SMDwrk | I've also tried different endianness with online disasm for or1k and or1knd(idk what's that) - no use | 13:16 |
| SMDwrk | And according to https://github.com/skristiansson/ar100-info that core seems like or1k | 13:17 |
| olofk | SMDwrk, stekern : Is it a 16-bit swap? | 14:58 |
| SMD1 | zlog | 15:04 |
| olofk | SMDwrk: or1k-elf-objcopy -I binary -O elf32-or1k -B or1k --reverse-bytes=4 arisc_sun8iw7p1.bin arisc.elf | 15:06 |
| olofk | or1k-elf-objdump -D arisc.elf | less | 15:06 |
| olofk | Works for me | 15:06 |
| SMD1 | olofk: thanks, I'll doublecheck | 15:07 |
| wallento | olofk, mithro: I started with a replacement for the verilator_tb_utils, will add JTAG soon | 15:24 |
| olofk | wallento, _franck__, mithro I guess the best we could do to avoid code duplication is to split out the vpi stuff from jtag_vpi so that we can reuse the logic with vpi, dpi or other wrappers | 15:34 |
| olofk | Like what is done for the elf-loader | 15:34 |
| olofk | Because unfortunately icarus doesn't handle dpi yet, verilator would prefer just ordinary C functions and xsim handles dpi but not vpi | 15:36 |
| olofk | and the vhdl users might want a vhpi wrapper | 15:36 |
| wallento | yeah, but verilator prefers dpi over ordinary C | 16:21 |
| wallento | vpi is dead it seems | 16:21 |
| olofk | vpi is not dead. It's the standard for verilog. dpi is for system verilog | 16:45 |
| olofk | And many tools aren't quite there yet with sv unfortunately | 16:46 |
| olofk | Most design I have come across only build with the tool that was used for development | 16:46 |
| wallento | yeah, but everything moves in the direction of dpi, I would not waste much energy on vpi. | 16:48 |
| wallento | dpi is probably the only thing in SV that is supported sufficiently | 16:49 |
| olofk | wallento: Still, we need it for icarus | 16:52 |
| olofk | And it's not hard to add a VPI wrapper | 16:52 |
| SMD1 | olofk: sorry for interrupting you, but still there are some "unknown" parts: i.e. since 0x8000 offset | 16:54 |
| SMD1 | http://pastebin.com/5E7rdfWj | 16:56 |
| olofk | SMD1: I guess 7e68 and upwards could be data | 16:56 |
| SMD1 | olofk: thanks and sorry for such questions | 16:57 |
| olofk | 7f8c is some kind of string that starts with "ir data full??re" | 16:59 |
| olofk | And no worries. It's always fun with a little reverse engineering :) | 17:00 |
| olofk | Now time to push the FuseSoC icestorm backend! | 17:00 |
| olofk | done | 17:15 |
| mithro | is or1k supported in upstream gdb? | 22:00 |
| --- Log closed Wed Apr 20 00:00:29 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!