IRC logs for #openrisc Tuesday, 2016-04-19

--- Log opened Tue Apr 19 00:00:28 2016
olofkshorne: I would guess that only the commercial implementations run for that long02:26
olofkBut I'm not actually sure if any of them run mor1kx or if they still run or120002:26
mithroanyone heard of the "oldland CPU"? https://jamieiles.github.io/oldland-cpu/ ?02:58
olofkmithro: Nope, missed that one03:21
olofkAs usual, a whole new set of JTAG, SPI, UART, SDRAM controllers. I will shoot the next person who does a new SPI or UART03:24
olofkUnless they actually take care to also create documentation, Linux drivers, bare-metal driver, device tree, testbench etc03:25
shorneolofk: thanks, ill leave it to a hardware bug for now, I guess its probably not some bug in the kernel I need to look into03:30
shorneolofk: 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 hacks03:31
shornedont shoot03:31
olofk:)03:33
mithroolofk: ha03:59
mithroolofk: what about https://github.com/jbush001/NyuziProcessor ?04:00
olofkmithro: Nyuzi has a FuseSoC port04:20
olofkYou can run simulations on it and build for a de2 target04:20
shornethis guy James who wrote oldland cpu seems to just have done it for fun. he did it and the toolchain porting as well05:19
shornequite interesting, not sure if I would try it05:20
mithroDoes 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 list07:45
mithroI'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.v07:59
olofk_franck__: :)08:04
olofkmithro: I don't really know what he did actually. Collaboration didn't seem to be his thing08:05
olofkThe benefit of jtag_vpi is that we got a driver in OpenOCD08:06
mithroLooks like it might be "remote_bitbang.c" compatible...08:06
_franck__mithro: I build this protocol from scratch and rdiez did the same08:10
mithro_franck__: you mean you built the jtag_vpi protocol from scratch?08:10
_franck__mithro: yes, I mean it :)08:21
mithroIt looks pretty trivial to adapt this jtag_dpi to this remote_bitbang protocol08:21
_franck__what is your use case for jtag_dpi ? Is it for verilator simulations ?08:23
mithro_franck__: yes08:23
_franck__mithro: https://github.com/openrisc/orpsoc-cores/blob/master/cores/verilator_tb_utils/jtagServer.cpp08:23
_franck__https://github.com/openrisc/orpsoc-cores/blob/master/systems/mor1kx-generic/bench/verilator/tb.cpp#L10808:24
mithro_franck__: that impliments the jtag_vpi protocol?08:26
_franck__yes it is08:26
olofkFYI, the Pulpino guys also have some JTAG protocol https://github.com/pulp-platform/pulpino/blob/master/tb/jtag_dpi.sv08:28
olofkAs does another RISC-V CPU author https://github.com/terpstra/opa/tree/master/jtag08:29
_franck__great ! now I'll start to write a new UART08: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 OpenOCD08:30
mithroI looked at the Pulpino version but it looked like overkill08:31
olofkOur old JTAG solution was a bit overkill too and tried (poorly) to implement a complete GDB server08:31
olofkModularity and simplicity rules :)08:32
mithroDoes verilator_tb_utils live in it's own repository at all?08:34
_franck__it does. It's just a collection of helpers08:39
olofkmithro: It's still a part of orpsoc-cores. No one has split it out yet, but it should be done eventually09:38
mithroso the jtag server code seems to make verilator really slow?09:45
mithrowell, bed time for me10:04
mithrognight10:04
olofkmithro: Is it always slow, or just when you connect?12:19
olofkIt might make sense to do more in verilog to avoid calling do_jtag so often. Haven't looked at the code really12:20
SMDwrkHi, 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
stekernSMDwrk: IIRC they have some endian swap on the bus, so you have to massage the binary a bit first13:05
SMDwrksure, one moment: http://rghost.net/8nPy2L6bs13:13
SMDwrkIf hosting is inappropriate, tell me where to put it13:13
SMDwrkstekern: I worry if allwinner has implemented some extentions to or1k core13:13
SMDwrkI've also tried different endianness with online disasm for or1k and or1knd(idk what's that) - no use13:16
SMDwrkAnd according to https://github.com/skristiansson/ar100-info that core seems like or1k13:17
olofkSMDwrk, stekern : Is it a 16-bit swap?14:58
SMD1zlog15:04
olofkSMDwrk: or1k-elf-objcopy -I binary -O elf32-or1k -B or1k --reverse-bytes=4 arisc_sun8iw7p1.bin arisc.elf15:06
olofkor1k-elf-objdump -D arisc.elf | less15:06
olofkWorks for me15:06
SMD1olofk: thanks, I'll doublecheck15:07
wallentoolofk, mithro: I started with a replacement for the verilator_tb_utils, will add JTAG soon15:24
olofkwallento, _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 wrappers15:34
olofkLike what is done for the elf-loader15:34
olofkBecause unfortunately icarus doesn't handle dpi yet, verilator would prefer just ordinary C functions and xsim handles dpi but not vpi15:36
olofkand the vhdl users might want a vhpi wrapper15:36
wallentoyeah, but verilator prefers dpi over ordinary C16:21
wallentovpi is dead it seems16:21
olofkvpi is not dead. It's the standard for verilog. dpi is for system verilog16:45
olofkAnd many tools aren't quite there yet with sv unfortunately16:46
olofkMost design I have come across only build with the tool that was used for development16:46
wallentoyeah, but everything moves in the direction of dpi, I would not waste much energy on vpi.16:48
wallentodpi is probably the only thing in SV that is supported sufficiently16:49
olofkwallento: Still, we need it for icarus16:52
olofkAnd it's not hard to add a VPI wrapper16:52
SMD1olofk: sorry for interrupting you, but still there are some "unknown" parts: i.e. since 0x8000 offset16:54
SMD1http://pastebin.com/5E7rdfWj16:56
olofkSMD1: I guess 7e68 and upwards could be data16:56
SMD1olofk: thanks and sorry for such questions16:57
olofk7f8c is some kind of string that starts with "ir data full??re"16:59
olofkAnd no worries. It's always fun with a little reverse engineering :)17:00
olofkNow time to push the FuseSoC icestorm backend!17:00
olofkdone17:15
mithrois 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!