--- Log opened Wed Jul 03 00:00:10 2013 | ||
-!- Netsplit *.net <-> *.split quits: poke53281, ams | 01:10 | |
stekern | creating a qsys component was really simple | 03:35 |
---|---|---|
stekern | olofk: how's orpsocv3 in this regard, is there some intention for generating socs like that? | 03:36 |
stekern | olofk: (SystemC not compilable) as in the libraries or "our" sysc code? | 04:07 |
stekern | hmm, interesting, the true dprams in mor1kx doesn't get inferred as mem blocks | 04:15 |
stekern | in cyclone iv | 04:15 |
stekern | *cyclone v | 04:16 |
stekern | they do in cyclone iv | 04:16 |
stekern | ah, explicitly describing it as reading out the new value on read-during-write makes it happy | 05:16 |
mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/3e1de595ea8a...164a8707d7b6 | 05:34 |
mor1kx | mor1kx/master aa7744b Stefan Kristiansson: prontoespresso/fetch: add verilator lint_off WIDTH around parameters | 05:34 |
mor1kx | mor1kx/master 164a870 Stefan Kristiansson: true_dpram_sclk: explicitly describe read-new-data on read-during-write... | 05:34 |
stekern | I have a nice little mor1kx dumped into the sockits ref design now | 06:01 |
stekern | just have to think of the best way to test if it works | 06:02 |
stekern | maybe I can just decouple the uart from the hps and route it through the fpga | 06:03 |
stekern | I have to figure out how to communicate with the through a debugger arms without the ds-5 too | 06:05 |
stekern | I guess openocd+gdb is a pretty sure bet | 06:05 |
stekern | s/with the through a debugger arms/with the arms through a debugger | 06:06 |
stekern | hmm, google doesn't give me anything useful in that direction | 06:29 |
stekern | hmm, this golden reference design isn't as golden as one might wish | 11:24 |
stekern | the clock constraints are all wrong | 11:24 |
juliusb | stekern: for what? | 14:29 |
stekern | sockit | 15:26 |
stekern | the clocking is very confusing on the board | 15:27 |
stekern | there is about 4 clock inputs, all go through some "clock synthesis chip" and there are no documentation about the frequencies | 15:28 |
stekern | the golden reference design code says that the completely misnamed clock that is used is 100 MHz, but the schematics says it's 50 | 15:29 |
stekern | or hints that it's 50 I might say | 15:30 |
stekern | the name is OSC_50_B3B | 15:31 |
stekern | ah, actually the user manual calls it OSC_50_B3B(50MHz) | 15:32 |
stekern | the code calls it "input clk_bot1, //1.5V //100 MHz ajustable" | 15:33 |
stekern | and the timing constraints file do: "create_clock -period 20 [get_ports fpga_clk_50]" | 15:37 |
stekern | but there is no fpga_clk_50 signal in the design... | 15:38 |
stekern | nothing but fool's gold... | 15:39 |
hno | stekern, I have ordb2a, and also tested on a Cyclone V based board under development at ORSoC with the same symptom. | 15:52 |
PlumeInterdite | Hello, I just discovered the OpenRISC project and am quite impressed by it. Yet I have a little but complicated question: How far is the project? | 17:41 |
stekern | I guess this is the end for the relationship between me and or_debug_proxy, it no longer works for some reason | 18:16 |
stekern | my guess is the ftdi drivers have got borked | 18:17 |
stekern | hno: ok, I've got physical access to boards now, will run some tests | 18:34 |
hno | stekern, thanks. | 18:41 |
stekern | yup, freezes on my de0_nano right after: 90000000.serial: ttyS0 at MMIO 0x90000000 (irq = 2) is a 16550A | 18:52 |
stekern | that's with or1200, let's see what happens with mor1kx | 18:52 |
hno | same spot. And continues if I remote serial0 from the dts and add keepbootcon to the kernel command line. | 18:54 |
hno | remove serial0... | 18:54 |
hno | not sure how to debug it It does not look like the kernel freezes as such, but seems it stops doing anything useful. | 18:55 |
stekern | same on mor1kx | 18:58 |
stekern | so most likely an soc bug | 18:58 |
stekern | -n | 18:58 |
stekern | and it boots fine in or1ksim and verilated mor1kx and or1200 orpsocs, so something that's different from that | 18:59 |
stekern | and since it happens on several boards, it should be something fairly generic | 19:00 |
stekern | common denominator is of course, all are altera devices | 19:00 |
stekern | lemme try on the atlys board | 19:00 |
stekern | hno: same on atlys board | 19:41 |
stekern | yeah, it's odd, it's not crashed it just doesn't do anything useful, just as you said | 19:54 |
stekern | it always seems to be in the return of arch_local_irq_restore when I break | 19:56 |
stekern | that could just be a coincident, that is called often | 19:56 |
stekern | just a coincident, now it was in arch_local_save_flags and they are called from cpu_idle... | 20:12 |
hno | so the kernel boot process is blocked waiting on something... irq issues? | 20:12 |
stekern | yeah, that has crossed my mind too | 20:13 |
stekern | but why isn't it happening in the verilated model? | 20:13 |
hno | or more likely... something that makes the UART not run, so it never generates an interrupt that it's ready to take more data. | 20:14 |
stekern | hmm, yeah, let's look a bit at the pic sprs and the uart registers | 20:16 |
hno | should try disabling the switch from bootcon to ttyS0 to see if it's the re-initialization of the uart that makes things crash, or the full driver that have I/O problems. | 20:17 |
hno | i.e. make serial8250_find_port_for_earlycon always return -ENODEV and not try activating the "real" console. | 20:19 |
stekern | I'm still really puzzled that it's so reproducable across boards, but not in the verilated model, since that is essentially the same soc as we are running on the boards | 20:21 |
hno | yes that is strange. | 20:21 |
stekern | but maybe I shouldn't stare myself blind at that | 20:21 |
hno | I don't think it's possible to try to stare at that before understanding what is happening. | 20:21 |
stekern | right ;) | 20:22 |
hno | It is even possible it is a software bug triggered by slight timing differences. | 20:22 |
stekern | yeah, but one would assume that the timing differences would be thrown off by the different board setups | 20:23 |
hno | what clock rate is the atlys running at? | 20:24 |
stekern | odder circumstances have happened in the wonderful world of software bugs though ;) | 20:24 |
stekern | all boards are running at 50MHz, including the verilated model | 20:24 |
hno | I don't have a 3.9 build nearby at the moment. Which files gets built in drivers/tty/serial/8250/? | 20:27 |
hno | crap, they moved too much stuff around in there between 3.8 and 3.9. 9 files changed, 4341 insertions(+), 3493 deletions(-) | 20:30 |
stekern | :/ | 20:30 |
stekern | the objects are: 8250_core.o, 8250_early.o, 8250.o and built-in.o | 20:30 |
hno | ok, so only 8260_core and 8250_early. | 20:31 |
hno | and right, the massive changes is from renaming 8250.c to 8250_core.c | 20:32 |
hno | and 8250_early do seem to work. | 20:32 |
hno | but.. can you try booting with console=ttyS0,115200 just to make sure? | 20:33 |
stekern | sure, wait | 20:34 |
hno | Diff narrowed down a bit. 2 files changed, 107 insertions(+), 85 deletions(-) | 20:35 |
hno | http://paste.fedoraproject.org/22858/83759137 | 20:36 |
hno | sorry, mixed up 8250_core.c version slightly, even less changes 3.8->3.9. | 20:38 |
hno | http://paste.fedoraproject.org/22859/72883953 is the diff 3.8 -> 3.9. | 20:39 |
stekern | console=ttyS0,115200 works | 20:39 |
hno | ok. So something in the uart getting confused when reconfigured while already running, most likely busy outputting data even. | 20:44 |
stekern | that sounds likely, yes | 20:46 |
hno | hmm... there is some port config changes in the diff.. port.fifosize, capabilities and tx_loadsz | 20:49 |
hno | if I am not mistaken those will be inherited from the 8250_early config when using earlycon. | 20:53 |
hno | no. | 20:54 |
hno | both uses the same kind of struct, but their own copies. | 20:59 |
stekern | got to hit the sack now, I'll take another look with a fresh mind tomorrow morning | 21:05 |
hno | ok. | 21:05 |
stekern | shout if you figure something out | 21:05 |
hno | been staring at the driver code diffs and out of ideas. | 21:07 |
hno | other than the hypothesis that it's timing related. | 21:08 |
hno | filtering out unrelated crap the diff is down to addition of DMA support, and change in how port.fifosize, capabilities and tx_loadsz is assigned. | 21:10 |
hno | http://paste.fedoraproject.org/22866/13728858 | 21:11 |
hno | stekern, how did you run the verilator simulation? | 23:40 |
--- Log closed Thu Jul 04 00:00:11 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!