| --- Log opened Wed Apr 01 00:00:46 2015 | ||
| Hesham | Hi 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.jpg | 09:14 |
|---|---|---|
| olofk | Hesham: Not really. I was thinking about plugging in a general JTAG adapter to one of the PMOD connectors and expose the jtag_tap pins there | 10:30 |
| olofk | But if OpenOCD can use the Xilinx platform cable, this method would work fine too | 10:30 |
| olofk | But then you probably need to instantiate Xilinx internal JTAG controller (bscan something?) | 10:30 |
| Hesham | olofk: OpenOCD has tcl/interface/usb-jtag.cfg, is this fine? I don't know. | 10:36 |
| olofk | Hesham: For the Altera equivalent of the cable in that picture we're using tcl/interface/altera-usb-blaster.cfg | 10:37 |
| Hesham | Even for Xilinx boards? | 10:38 |
| olofk | No. Just mentioned that for comparasion. I probably just made things more confusing :) | 10:40 |
| olofk | usb-jtag.cfg seems to be a specific USB-jtag adapter | 10:40 |
| Hesham | That's the one I use to configure the FPGA, so it should be fine? | 10:41 |
| olofk | The Xilinx platform cable? | 10:42 |
| Hesham | Nope, the USB-JTAG cable. It's just USB-microUSB cable. | 10:42 |
| Hesham | This one http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_60_4.jpg | 10:44 |
| olofk | But that's not the usb-jtag cable from the openOCD interface config file | 10:44 |
| olofk | There'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 FPGA | 10:45 |
| olofk | Problem is that the protocol sent over USB is proprietary. | 10:45 |
| Hesham | Ah I see | 10:46 |
| olofk | So programming the FPGA is fine, because then you use their proprietary programs, but connecting OpenOCD is a problem | 10:47 |
| olofk | Therefore we need to send JTAG command to the FPGA some other way. A stand-alone JTAG debugger that is supported by OpenOCD would fix this | 10:47 |
| Hesham | I think that should be it http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_27_21.jpg | 10:48 |
| olofk | I don't have a JTAG debugger myself anymore, but something like this would probably do the job http://dangerousprototypes.com/docs/Bus_Blaster | 10:48 |
| Hesham | "ORSoC USB to JTAG debugger" | 10:48 |
| olofk | Yes. Sven-Åke who wrote the blog asked me how to connect the ORSoC debugger | 10:48 |
| olofk | But I think stekern did the pin mapping in the end | 10:49 |
| olofk | But I don't think ORSoC sells that debuger anymore, and I returned mine when I quit there | 10:49 |
| Hesham | So I think we should return back to the hex loader as the only final solution :) | 10:51 |
| olofk | Hesham: Unfortunately, I think that would be the most general solution | 10:51 |
| olofk | Got to run now. Meeting | 10:51 |
| Hesham | Ok thanks you. | 10:52 |
| bandvig | Hesham: Hadn't you resolved your problem with commands to Uboot? | 11:00 |
| Hesham | bandvig: Nope, that's why I was searching for the openocd solution. | 11:04 |
| Hesham | There 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 |
| olofk | Hesham: I still believe that your problem is with the libgloss driver in newlib | 13:48 |
| Hesham | olofk: For the u-boot problem? | 13:49 |
| olofk | If that is the case I guess you would see the same issue if you compile a simple test program that uses scanf or similar | 13:49 |
| olofk | Hesham: Yes. Because that is compiled with newlib and libgloss I presume | 13:49 |
| Hesham | But I guess it was working fine with old orpsocv2 | 13:49 |
| olofk | Hesham: ok. That's strange | 13:50 |
| olofk | With the same u-boot image? | 13:50 |
| Hesham | Has it been broken or something? | 13:50 |
| Hesham | Yes, I didn't even compile it again. | 13:50 |
| olofk | Then I don't know | 13:50 |
| stekern | is it the atlys board in orpsoc-cores that is not working? | 13:52 |
| Hesham | stekern: The UART driver only. I got u-boot working there, but it just emits output. I can't type commands though. | 13:53 |
| stekern | hmm, interesting | 13:55 |
| Hesham | But it was working fine with old orpsocv2 | 13:55 |
| stekern | my atlys board is fried, so I can't test, but afair it did work last I touched it | 13:55 |
| _franck__ | olofk: I don't think uboot uses newlib/libgloss | 13:55 |
| _franck__ | it has its own printf and uart driver | 13:56 |
| stekern | olofk is blaming all uart problems on libgloss nowdays ;) | 13:56 |
| _franck__ | :) | 13:56 |
| Hesham | My guess that the problem maybe with the rtl uart (if it was changed between orpsocv2) or my linux driver. | 13:56 |
| olofk | Well, it's either libgloss' fault or you are holding it wrong. Can't think of any other reasons :) | 13:58 |
| Hesham | Has the uart16550-1.5 changes since orpsocv2? | 13:58 |
| Hesham | changed* | 13:58 |
| olofk | Hesham: Slightly | 13: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 problem | 13:59 |
| _franck__ | I had this when porting barebox | 13:59 |
| _franck__ | don't ask me why it would not count or if it is even possible | 14:00 |
| Hesham | _franck_ Let me run it again, it will take a while since I will burn the flash memory again. | 14:00 |
| olofk | It 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 differences | 14:00 |
| olofk | But I know that the one we're using for FuseSoC is working. I've been using it quite a lot under Linux | 14:01 |
| Hesham | olofk: Is there an easy way to back port the old driver without any modifications to fusesoc? | 14:01 |
| Hesham | It's working but just outputting data. So I guess the problem maybe with the timer also as _franck_ suggested. | 14:02 |
| olofk | Hesham: The libgloss driver you mean? | 14:02 |
| Hesham | No the uart16550 RTL core | 14:03 |
| olofk | Yes. It's not that hard. Do you want the one from orpsocv2 you mean? | 14:04 |
| olofk | But I find it hard to believe that is the problem | 14: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 |
| Hesham | olofk: Yes the one from orpsocv2 | 14:05 |
| Hesham | I'm also considering to use OptimSoC | 14:07 |
| olofk | Yeah, I could have fucked something up when I applied the patches to my github version | 14:07 |
| olofk | You 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 years | 14:08 |
| olofk | Things would be so much easier if we just could have access to the digilent USB protocol | 14:09 |
| Hesham | That would be very easy. | 14:09 |
| Hesham | Let's check the timer issue first... | 14:10 |
| olofk | Hesham: It's a bit more work to get the one from orpsocv2, so I can't help you with that right now | 14:10 |
| olofk | Got to run | 14:10 |
| Hesham | _franck_ I think it's the timer problem, didn't catch any counting down.. http://pastebin.com/5ZgpW37E | 14:24 |
| _franck__ | well, I was expecting you get at least: "Hit any key to stop autoboot:" | 14:33 |
| Hesham | This is a working u-boot quoted from RTS blog http://www.rte.se/sites/default/files/Blog/Modesty/Modesty_22_3.png | 14:35 |
| Hesham | The difference is the existence of interrupt controller | 14:36 |
| Hesham | Why 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 port | 14:43 |
| _franck__ | can't remember how it's called | 14:44 |
| Hesham | maybe there is an ABI change between or1200 and mor1kxx? | 14:44 |
| Hesham | printf(" Interrupt controller: %s\n", | 14:44 |
| Hesham | (upr & SPR_UPR_PICP) ? "yes" : "no"); | 14:44 |
| Hesham | So this can be the problem why I can't type commands ? | 14:45 |
| Hesham | I replaced mor1kxx with or1200 core, u-boot is not working at all. | 15:48 |
| stekern | Hesham: the UPR_PICP bits are wrong in u-boot (and or1200) | 15:49 |
| stekern | but it's not used for anything else than printing that message | 15:50 |
| Hesham | This may cause the interrupt controller problem, or it just sees no interrupt controller although it's there? | 15:50 |
| Hesham | Ah I see. | 15:51 |
| Hesham | Any ideas why or1200 core isn't working with FuseSoC, however mor1kxx is working? I mean u-boot | 15:51 |
| stekern | u-boot is just looking at the wrong bit in upr | 15:53 |
| stekern | to the other question, not really | 15:53 |
| bandvig | olofk: How can I to understand which version of UART I use? | 18:51 |
| Hesham | bandvig: Have you had a look at the .core file? i.e. orpsoc-cores/systems/atlys/atlys.core | 18:53 |
| Hesham | It has uart16550-1.5 for example | 18:53 |
| bandvig | uart16550-1.5 | 18:56 |
| bandvig | Stop! 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 |
| bandvig | olofk: Is it possible to get versrion of uart16550 from verilog sources? | 19:01 |
| bandvig | Hesham: Have you tried old version of uart? | 19:13 |
| Hesham | bandvig: Yeah, but I didn't try it with mor1kxx | 19:13 |
| Hesham | It builds fine | 19:13 |
| Hesham | s/uart16550-1.5/uart16550 | 19:14 |
| bandvig | I 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 |
| bandvig | Hesham: my last idea: competely clean up cached verilog and intermediate files generated by ISE. Reget and re-build. | 19:36 |
| ysionneau | 9 | 20: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!
