IRC logs for #openrisc Wednesday, 2013-07-03

--- Log opened Wed Jul 03 00:00:10 2013
-!- Netsplit *.net <-> *.split quits: poke53281, ams01:10
stekerncreating a qsys component was really simple03:35
stekernolofk: how's orpsocv3 in this regard, is there some intention for generating socs like that?03:36
stekernolofk: (SystemC not compilable) as in the libraries or "our" sysc code?04:07
stekernhmm, interesting, the true dprams in mor1kx doesn't get inferred as mem blocks04:15
stekernin cyclone iv04:15
stekern*cyclone v04:16
stekernthey do in cyclone iv04:16
stekernah, explicitly describing it as reading out the new value on read-during-write makes it happy05:16
mor1kx[mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/3e1de595ea8a...164a8707d7b605:34
mor1kxmor1kx/master aa7744b Stefan Kristiansson: prontoespresso/fetch: add verilator lint_off WIDTH around parameters05:34
mor1kxmor1kx/master 164a870 Stefan Kristiansson: true_dpram_sclk: explicitly describe read-new-data on read-during-write...05:34
stekernI have a nice little mor1kx dumped into the sockits ref design now06:01
stekernjust have to think of the best way to test if it works06:02
stekernmaybe I can just decouple the uart from the hps and route it through the fpga06:03
stekernI have to figure out how to communicate with the through a debugger arms without the ds-5 too06:05
stekernI guess openocd+gdb is a pretty sure bet06:05
stekerns/with the through a debugger arms/with the arms through a debugger06:06
stekernhmm, google doesn't give me anything useful in that direction06:29
stekernhmm, this golden reference design isn't as golden as one might wish11:24
stekernthe clock constraints are all wrong11:24
juliusbstekern: for what?14:29
stekernsockit15:26
stekernthe clocking is very confusing on the board15:27
stekernthere is about 4 clock inputs, all go through some "clock synthesis chip" and there are no documentation about the frequencies15:28
stekernthe golden reference design code says that the completely misnamed clock that is used is 100 MHz, but the schematics says it's 5015:29
stekernor hints that it's 50 I might say15:30
stekernthe name is OSC_50_B3B15:31
stekernah, actually the user manual calls it OSC_50_B3B(50MHz)15:32
stekernthe code calls it "input          clk_bot1,            //1.5V    //100 MHz ajustable"15:33
stekernand the timing constraints file do: "create_clock -period 20 [get_ports fpga_clk_50]"15:37
stekernbut there is no fpga_clk_50 signal in the design...15:38
stekernnothing but fool's gold...15:39
hnostekern, I have ordb2a, and also tested on a Cyclone V based board under development at ORSoC with the same symptom.15:52
PlumeInterditeHello, 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
stekernI guess this is the end for the relationship between me and or_debug_proxy, it no longer works for some reason18:16
stekernmy guess is the ftdi drivers have got borked18:17
stekernhno: ok, I've got physical access to boards now, will run some tests18:34
hnostekern, thanks.18:41
stekernyup, freezes on my de0_nano right after: 90000000.serial: ttyS0 at MMIO 0x90000000 (irq = 2) is a 16550A18:52
stekernthat's with or1200, let's see what happens with mor1kx18:52
hnosame spot. And continues if I remote serial0 from the dts and add keepbootcon to the kernel command line.18:54
hnoremove serial0...18:54
hnonot sure how to debug it It does not look like the kernel freezes as such, but seems it stops doing anything useful.18:55
stekernsame on mor1kx18:58
stekernso most likely an soc bug18:58
stekern-n18:58
stekernand it boots fine in or1ksim and verilated mor1kx and or1200 orpsocs, so something that's different from that18:59
stekernand since it happens on several boards, it should be something fairly generic19:00
stekerncommon denominator is of course, all are altera devices19:00
stekernlemme try on the atlys board19:00
stekernhno: same on atlys board19:41
stekernyeah, it's odd, it's not crashed it just doesn't do anything useful, just as you said19:54
stekernit always seems to be in the return of arch_local_irq_restore when I break19:56
stekernthat could just be a coincident, that is called often19:56
stekernjust a coincident, now it was in arch_local_save_flags and they are called from cpu_idle...20:12
hnoso the kernel boot process is blocked waiting on something... irq issues?20:12
stekernyeah, that has crossed my mind too20:13
stekernbut why isn't it happening in the verilated model?20:13
hnoor 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
stekernhmm, yeah, let's look a bit at the pic sprs and the uart registers20:16
hnoshould 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
hnoi.e. make serial8250_find_port_for_earlycon always return -ENODEV and not try activating the "real" console.20:19
stekernI'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 boards20:21
hnoyes that is strange.20:21
stekernbut maybe I shouldn't stare myself blind at that20:21
hnoI don't think it's possible to try to stare at that before understanding what is happening.20:21
stekernright ;)20:22
hnoIt is even possible it is a software bug triggered by slight timing differences.20:22
stekernyeah, but one would assume that the timing differences would be thrown off by the different board setups20:23
hnowhat clock rate is the atlys running at?20:24
stekernodder circumstances have happened in the wonderful world of software bugs though ;)20:24
stekernall boards are running at 50MHz, including the verilated model20:24
hnoI don't have a 3.9 build nearby at the moment. Which files gets built in drivers/tty/serial/8250/?20:27
hnocrap, 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
stekernthe objects are: 8250_core.o, 8250_early.o, 8250.o and built-in.o20:30
hnook, so only 8260_core and 8250_early.20:31
hnoand right, the massive changes is from renaming 8250.c to 8250_core.c20:32
hnoand 8250_early do seem to work.20:32
hnobut.. can you try booting with console=ttyS0,115200 just to make sure?20:33
stekernsure, wait20:34
hnoDiff narrowed down a bit. 2 files changed, 107 insertions(+), 85 deletions(-)20:35
hnohttp://paste.fedoraproject.org/22858/8375913720:36
hnosorry, mixed up 8250_core.c version slightly, even less changes 3.8->3.9.20:38
hnohttp://paste.fedoraproject.org/22859/72883953 is the diff 3.8 -> 3.9.20:39
stekernconsole=ttyS0,115200 works20:39
hnook. So something in the uart getting confused when reconfigured while already running, most likely busy outputting data even.20:44
stekernthat sounds likely, yes20:46
hnohmm... there is some port config changes in the diff.. port.fifosize, capabilities and tx_loadsz20:49
hnoif I am not mistaken those will be inherited from the 8250_early config when using earlycon.20:53
hnono.20:54
hnoboth uses the same kind of struct, but their own copies.20:59
stekerngot to hit the sack now, I'll take another look with a fresh mind tomorrow morning21:05
hnook.21:05
stekernshout if you figure something out21:05
hnobeen staring at the driver code diffs and out of ideas.21:07
hnoother than the hypothesis that it's timing related.21:08
hnofiltering 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
hnohttp://paste.fedoraproject.org/22866/1372885821:11
hnostekern, 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!