IRC logs for #openrisc Wednesday, 2015-04-01

--- Log opened Wed Apr 01 00:00:46 2015
HeshamHi olofk: Is this the cable you refer to (for loading ELF files to Atlys)? http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_60_3.jpg09:14
olofkHesham: Not really. I was thinking about plugging in a general JTAG adapter to one of the PMOD connectors and expose the jtag_tap pins there10:30
olofkBut if OpenOCD can use the Xilinx platform cable, this method would work fine too10:30
olofkBut then you probably need to instantiate Xilinx internal JTAG controller (bscan something?)10:30
Heshamolofk: OpenOCD has tcl/interface/usb-jtag.cfg, is this fine? I don't know.10:36
olofkHesham: For the Altera equivalent of the cable in that picture we're using tcl/interface/altera-usb-blaster.cfg10:37
HeshamEven for Xilinx boards?10:38
olofkNo. Just mentioned that for comparasion. I probably just made things more confusing :)10:40
olofkusb-jtag.cfg seems to be a specific USB-jtag adapter10:40
HeshamThat's the one I use to configure the FPGA, so it should be fine?10:41
olofkThe Xilinx platform cable?10:42
HeshamNope, the USB-JTAG cable. It's just USB-microUSB cable.10:42
HeshamThis one http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_60_4.jpg10:44
olofkBut that's not the usb-jtag cable from the openOCD interface config file10:44
olofkThere's an MCU on the Atlys board that takes the commands sent over USB and translates them to JTAG commands that are forwarded to the FPGA10:45
olofkProblem is that the protocol sent over USB is proprietary.10:45
HeshamAh I see10:46
olofkSo programming the FPGA is fine, because then you use their proprietary programs, but connecting OpenOCD is a problem10:47
olofkTherefore we need to send JTAG command to the FPGA some other way. A stand-alone JTAG debugger that is supported by OpenOCD would fix this10:47
HeshamI think that should be it http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_27_21.jpg10:48
olofkI don't have a JTAG debugger myself anymore, but something like this would probably do the job http://dangerousprototypes.com/docs/Bus_Blaster10:48
Hesham"ORSoC USB to JTAG debugger"10:48
olofkYes. Sven-Åke who wrote the blog asked me how to connect the ORSoC debugger10:48
olofkBut I think stekern did the pin mapping in the end10:49
olofkBut I don't think ORSoC sells that debuger anymore, and I returned mine when I quit there10:49
HeshamSo I think we should return back to the hex loader as the only final solution :)10:51
olofkHesham: Unfortunately, I think that would be the most general solution10:51
olofkGot to run now. Meeting10:51
HeshamOk thanks you.10:52
bandvigHesham: Hadn't you resolved your problem with commands to Uboot?11:00
Heshambandvig: Nope, that's why I was searching for the openocd solution.11:04
HeshamThere maybe something wrong with the Linux driver I use for this USB-UART chip. In that case I don't have time to find out how to solve it.11:05
olofkHesham: I still believe that your problem is with the libgloss driver in newlib13:48
Heshamolofk: For the u-boot problem?13:49
olofkIf that is the case I guess you would see the same issue if you compile a simple test program that uses scanf or similar13:49
olofkHesham: Yes. Because that is compiled with newlib and libgloss I presume13:49
HeshamBut I guess it was working fine with old orpsocv213:49
olofkHesham: ok. That's strange13:50
olofkWith the same u-boot image?13:50
HeshamHas it been broken or something?13:50
HeshamYes, I didn't even compile it again.13:50
olofkThen I don't know13:50
stekernis it the atlys board in orpsoc-cores that is not working?13:52
Heshamstekern: The UART driver only. I got u-boot working there, but it just emits output. I can't type commands though.13:53
stekernhmm, interesting13:55
HeshamBut it was working fine with old orpsocv213:55
stekernmy atlys board is fried, so I can't test, but afair it did work last I touched it13:55
_franck__olofk: I don't think uboot uses newlib/libgloss13:55
_franck__it has its own printf and uart driver13:56
stekernolofk is blaming all uart problems on libgloss nowdays ;)13:56
_franck__:)13:56
HeshamMy guess that the problem maybe with the rtl uart (if it was changed between orpsocv2) or my linux driver.13:56
olofkWell, it's either libgloss' fault or you are holding it wrong. Can't think of any other reasons :)13:58
HeshamHas the uart16550-1.5 changes since orpsocv2?13:58
Heshamchanged*13:58
olofkHesham: Slightly13:58
_franck__Hesham: does your u-boot down count 3..2..1..0 ? u-boot uses polling for everything so if your timer doesn't count it may be the problem13:59
_franck__I had this when porting barebox13:59
_franck__don't ask me why it would not count or if it is even possible14:00
Hesham_franck_ Let me run it again, it will take a while since I will burn the flash memory again.14:00
olofkIt goes like this. The uart was copied into orpsocv2 at some point and there were some patches added. For FuseSoC I used the upstream uart16550 and tried to feed back all the relevant patches from orpsocv2, but there might still be differences14:00
olofkBut I know that the one we're using for FuseSoC is working. I've been using it quite a lot under Linux14:01
Heshamolofk: Is there an easy way to back port the old driver without any modifications to fusesoc?14:01
HeshamIt's working but just outputting data. So I guess the problem maybe with the timer also as _franck_ suggested.14:02
olofkHesham: The libgloss driver you mean?14:02
HeshamNo the uart16550 RTL core14:03
olofkYes. It's not that hard. Do you want the one from orpsocv2 you mean?14:04
olofkBut I find it hard to believe that is the problem14:04
_franck__Hesham: as olofk said we use this RTL a lot. So if olofk didn't broke it while including patches it should be ok ;)14:04
Heshamolofk: Yes the one from orpsocv214:05
HeshamI'm also considering to use OptimSoC14:07
olofkYeah, I could have fucked something up when I applied the patches to my github version14:07
olofkYou could start by changing atlys.core and change uart16550-1.5 to just uart16550. That would give you back the version that we have used in FuseSoC for the last few years14:08
olofkThings would be so much easier if we just could have access to the digilent USB protocol14:09
HeshamThat would be very easy.14:09
HeshamLet's check the timer issue first...14:10
olofkHesham: It's a bit more work to get the one from orpsocv2, so I can't help you with that right now14:10
olofkGot to run14:10
Hesham_franck_ I think it's the timer problem, didn't catch any counting down.. http://pastebin.com/5ZgpW37E14:24
_franck__well, I was expecting you get at least: "Hit any key to stop autoboot:"14:33
HeshamThis is a working u-boot quoted from RTS blog http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_22_3.png14:35
HeshamThe difference is the existence of interrupt controller14:36
HeshamWhy do I have "Interrupt controller: no" on my FuseSoC build?14:36
_franck__maybe stekern used his brand new external interrupt controller on this board port14:43
_franck__can't remember how it's called14:44
Heshammaybe there is an ABI change between or1200 and mor1kxx?14:44
Heshamprintf("       Interrupt controller: %s\n",14:44
Hesham    (upr & SPR_UPR_PICP) ? "yes" : "no");14:44
HeshamSo this can be the problem why I can't type commands ?14:45
HeshamI replaced mor1kxx with or1200 core, u-boot is not working at all.15:48
stekernHesham: the UPR_PICP bits are wrong in u-boot (and or1200)15:49
stekernbut it's not used for anything else than printing that message15:50
HeshamThis may cause the interrupt controller problem, or it just sees no interrupt controller although it's there?15:50
HeshamAh I see.15:51
HeshamAny ideas why or1200 core isn't working with FuseSoC, however mor1kxx is working? I mean u-boot15:51
stekernu-boot is just looking at the wrong bit in upr15:53
stekernto the other question, not really15:53
bandvigolofk: How can I to understand which version of UART I use?18:51
Heshambandvig: Have you had a look at the .core file? i.e. orpsoc-cores/systems/atlys/atlys.core18:53
HeshamIt has uart16550-1.5 for example18:53
bandviguart16550-1.518:56
bandvigStop! really. I'm not sure!!! I collected source files for atlys almost 9 monthes ago! Since that I have updated working copies of fusesoc and orpsoc_cores but I haven't updated verilog files!19:00
bandvigolofk: Is it possible to get versrion of uart16550 from verilog sources?19:01
bandvigHesham: Have you tried old version of uart?19:13
Heshambandvig: Yeah, but I didn't try it with mor1kxx19:13
HeshamIt builds fine19:13
Heshams/uart16550-1.5/uart1655019:14
bandvigI looked at date of my verilog source tree for atlys. Except mor1kx all other are very old (about begining of june 2014). It means that I use just uart16550.19:27
bandvigHesham: my last idea: competely clean up cached verilog and intermediate files generated by ISE. Reget and re-build.19:36
ysionneau920:04
--- Log closed Thu Apr 02 00:00:48 2015

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!