| unicos | hello | 05:34 |
|---|---|---|
| unicos | for somebody new to OpenRISC, which is the best way to dive into getting a system running on hardware? orpsoc? minsoc? is one preferred? | 05:40 |
| unicos | I have had success with getting the uart.or32 example running through gdb remote on my terasic de0-nano containing minsoc, but haven't had any success loading u-boot | 05:42 |
| stekern | unicos: what's the problem with u-boot? | 07:06 |
| unicos | stekern: while loading u-boot over remote gdb, I get WB bus error during burst write and a CRC error- I'm confused because while this seems like a common problem on the FAQ, I can actually run the uart.or32 demo correctly | 09:08 |
| unicos | are there any known issues with programming and attaching the jtag bridge through a virtual machine? my development environment is a Fedora 16 VM... | 09:10 |
| unicos | I'll try to test from a real system later to help isolate my problem | 09:12 |
| unicos | I also tried booting the linux kernel with the same results- it transfers a little bit and the jtag bridge fails | 09:17 |
| jonibo_ | juliusb: consider that your pending interrupt is for some realtime process... you shouldn't be delaying it even a single instruction... and it seems strange that a process should be making forward progress, one instruction at a time, during an interrupt storm... I agree with stekern that it's implied, but such is reading between the lines! | 09:38 |
| jonibo_ | If I were to write software relying on such a feature (slow forward progress), then you're free to put me down quietly... :) | 09:39 |
| stekern | unicos: people seem to have all sorts of problems with adv_debug_sys on altera devices, so do I but you can try the orpsocv2 deà nano port at git://openrisc.net/stefan/orpsoc and see if you have better luck with that | 10:09 |
| derRichard | how do i compile openrisc 1200? (i know not much about verilog). is there a compiler which creates a binary blob? how can i program this blob into my fpga? | 13:58 |
| stekern | derRichard: you had that ordb2a board, right? | 14:00 |
| derRichard | yep | 14:01 |
| stekern | so that's an altera device, so you need alteras quartus tool to "compile" it into a bitstream | 14:01 |
| stekern | and then I believe urjtag is to be used to program that into the fpga | 14:02 |
| derRichard | okay. i fear the altera tool is not free, right? | 14:02 |
| stekern | http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html | 14:03 |
| stekern | it's free, but not open | 14:03 |
| derRichard | free as free beer :( | 14:03 |
| stekern | free of charge | 14:03 |
| stekern | yeah ;) | 14:03 |
| derRichard | okay. and what about ork1sim? let's say i change openrisc (like adding a new opcode...) how can i get this into ork1sim? | 14:04 |
| stekern | I can't say I'm all to familiar with the inner workings of or1ksim, so I guess my advice there is to dig around in the code, or ask Jeremy Bennett about it | 14:08 |
| stekern | but for adding op-codes, there are a small set of "custom" instructions that are designed to used for that | 14:09 |
| stekern | *to be | 14:09 |
| stekern | l.cust1 - l.cust8 | 14:11 |
| derRichard | cool! | 14:12 |
| stekern | iirc there is even an example l.custX implementation in or1200 | 14:15 |
| derRichard | thx a lot :) | 14:15 |
| derRichard | openrisc is really cool stuff | 14:15 |
| derRichard | contains r0 always zero? | 18:59 |
| stekern | it's implementation specific, but sw should never write anything else than 0 to it | 19:05 |
| stekern | so the short answer is: yes ;) | 19:05 |
| derRichard | hmm, | 19:11 |
| derRichard | i'm reading http://openrisc.net/or1200-spec.html but it does not say anything about r0 | 19:12 |
| stekern | take a look at the arch spec instead | 19:13 |
| derRichard | the or1000 spec? | 19:15 |
| stekern | yes | 19:15 |
| stekern | but for or1200, it is a normal register just like any other | 19:17 |
| derRichard | but it's also on or1200 always 0? | 19:20 |
| stekern | as long as you don't write anything else than zero to it, yes | 19:20 |
| derRichard | otherwise t #define CLEAR_GPR(gpr) l.or gpr,r0,r0 | 19:22 |
| derRichard | ups | 19:22 |
| derRichard | otherwise this would be wrong: #define CLEAR_GPR(gpr) l.or gpr,r0,r0 | 19:22 |
| derRichard | i found this in the linux port and got confused | 19:22 |
| stekern | yeah, as a programmer, you can safely assume that r0 is always zero | 19:23 |
| stekern | i'm just pointing out that it's technically nothing special about r0 in or1200 | 19:24 |
| stekern | it's not hardwired to zero | 19:24 |
| derRichard | and where is it set to zero? | 19:32 |
| juliusb | the arch spec says it shpuld always be read as zero and you should never wrote it | 19:38 |
| derRichard | if it's not wired to zero who takes care of it? | 19:39 |
| juliusb | but on or1200 it should br written as 0 at the beginning | 19:40 |
| derRichard | at the beginning of what? does the assembler create such an instruction? | 19:43 |
| jt_eaton | what beginning? does the hardware clear it in reset or does the boot code have to write it? If I implement the registers as a bank or ram then it can be real hard to make sure r0 is never non zero | 19:43 |
| stekern | no, as the first instruction in reset vector | 19:44 |
| juliusb | hw doesnt clear ot, its isually in a register file whoch is a RAM which you cant reset | 19:45 |
| juliusb | so ypu must l.movhi r0, 0 as first insn | 19:45 |
| jt_eaton | no but I can force the ram address and data to zeros during reset with a active write so that r0 will be cleared by hardware coming out of reset. You still have the problem of someone writing a nonzero value with code | 19:47 |
| juliusb | you could mask that easily enough bit i arfue its unecessary | 19:48 |
| juliusb | argue | 19:48 |
| jt_eaton | Do you want a robust design or a house of cards? This is the type of thing that can easily create havoc in a large design team. All you have to do is forget to initialize r0 or overwrite it and you have a disaster. | 19:52 |
| juliusb | yeah well surely you understand the design ypure using | 19:54 |
| jt_eaton | I would argue that if the arch spec says always zero then it should be enforced by hardware. You dont want to have any more failure opportunities if you can prevent it | 19:55 |
| juliusb | i dont accept that you csnt introduce things like this to avoid hw complexity | 19:55 |
| stekern | the arch spec doesn't say it is always zero | 19:56 |
| jt_eaton | what does it say? | 19:56 |
| juliusb | i cantget it right now (on phone) | 19:57 |
| stekern | R0 is used as a constant zero. Whether or not R0 is actually hardwired to zero is implementation dependent. R0 should never be used as a destination register. | 19:57 |
| jt_eaton | OK, Ill do some research | 19:58 |
| juliusb | but iys basically some gates you can save by doing something simple in sw and wou;d be eyasy to denug | 19:58 |
| stekern | "R0 is used as a constant zero. Whether or not R0 is actually hardwired to zero is implementation dependent. R0 should never be used as a destination register." | 20:00 |
| jt_eaton | Dont worry about saving gates, they are really cheap. Designer time is expensive. It may only take 15 minutes to debug but that is how schedules slip | 20:00 |
| stekern | forgot the quotes around that, it's from the arch spec | 20:01 |
| unicos | stekern: thanks for the advice | 20:38 |
| olofk | We talked about this before, and I really think we should update the implementation so that r0 is wired to zero. jeremybennett said that it could break legacy code, and that is true, but for me it seems like a bad thing from a security perspective to have it the way it is. What happens if some code reads from r0 and compares it to the current uid to check if root is logged in? Any process could just write something to r0 and we s | 20:50 |
| olofk | uddenly have a root escalation problem. | 20:50 |
| olofk | Not sure if that example would really work, but it still seems like a potential problem to me | 20:53 |
| unicos | suppose it helps if I'm in the right directory! I was trying to compile from orpsoc/boards/altera/de0_nano/syn/quartus/bin instead of .../run and getting all kinds of errors | 21:23 |
| unicos | stekern: using stefan's orpsoc for de0-nano, I can successfully program the device, but adv_jtag_bridge reports a lot of CRC errors and gdb fails to attach to the remote target with "Remote failure reply: E01" | 21:42 |
| stekern | people have succesfully commented out the CRC checking code in adv_jtag_bridge and got it working reliably | 21:43 |
| stekern | ... | 21:43 |
| stekern | when I tested it I got the behaviour you are describing in about 33% of the cases | 21:45 |
| unicos | stekern: do you also use de0-nano? | 21:45 |
| stekern | yes I have a de0-nano | 21:47 |
| stekern | <- stefan | 21:47 |
| unicos | I've been using `./adv_jtag_bridge -b ./ ft245` with some success under minsoc, but the usbblaster cable option has never worked for me | 21:47 |
| unicos | ah, hello! | 21:47 |
| stekern | yup, that's the same thing I have experienced | 21:48 |
| stekern | I think the ft245 option superseeds the usb-blaster one | 21:48 |
| unicos | good to know- I have next to no experience with FPGAs and running things on them, so I've been assuming all problems are just my lack of understanding | 21:50 |
| stekern | I'd like to get those adv_debug_sys problems sorted out, I'm mostly using an external jtag-adapter whn connecting to the de0-nano (the "legacy" debug if), but using the builtin jtag-port really lowers the entry threshold for people | 21:53 |
| unicos | I see | 21:59 |
| unicos | maybe I should study verilog and the quartus toolchain in the mean time | 22:01 |
| unicos | I have no idea how to extend the project once I manage to get it running :) | 22:04 |
| derRichard | can r0 be written in unprivileged mode? (i know changing r0 is bad) | 23:40 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!