IRC logs for #openrisc Friday, 2013-06-28

--- Log opened Fri Jun 28 00:00:03 2013
olofkSuccess! It seems like printk only writes to a buffer and nothing happens until the uart is ready, which happens much later.05:29
olofkn't that always 0?07:22
olofk20:24 < olofk> Or does it require a boot loader to set it up for me?07:22
olofk20:27 < olofk> Rereading what stekern said, a few days ago, I see that it's definitely the case07:22
olofk20:28 < olofk> Still... can I fake it somehow, and how does that work in or1ksim?07:22
olofk20:35 < olofk> ahh..ok.. it uses the value from __dtb_start instead. Is the pointer in r3 only for loading device trees that are not compiled into the kernel?07:22
olofk20:36 < olofk> Back to square 1. Haven't got a clue why my printk doesn't try to access the UART07:22
olofk21:52 -!- mboehnert [] has quit [Quit: mboehnert]07:22
olofk22:27 -!- GusBricker [] has quit [Remote host closed the connection]07:22
olofk22:41 -!- GusBricker [] has quit [Remote host closed the connection]07:22
olofkDay changed to 28 Jun 201307:23
olofk03:54 -!- GusBricker [] has quit [Remote host closed the connection]07:23
olofk04:00 -!- GusBricker [] has quit [Ping timeout: 276 seconds]07:23
olofk05:29 < olofk> Success! It seems like printk only writes to a buffer and nothing happens until the uart is ready, which happens much later.  [07:22] [olofk(+i)] [3:freenode07:23
olofk/#openrisc(+cnt)] [Act: 1,2,4,5]07:23
olofk[#openrisc] 07:23
olofkSorry about that07:23
juliusbso you got it going in the end olofk?07:54
LoneTechiirc there is an option for early console printing08:03
hnoconsole=uart,... is quite early.08:04
hnoin x86 and arm it is possible to get uart output a little bit earlier using earlyprintk, but that requires hardcoding uart registers in the code.08:05
LoneTechright, that's what I was thinking of08:05
hnoconsole=uart... is almost as early. Long before /dev/ttyS* is up and running.08:06
hnoand also the only way for me to get any console output at all on FPGA when using Linux-3.9 or later... the /dev/ttyS* driver seems to kill the UART somehow.08:07
juliusbI believe we used to have some early early debugging UART print code in our port's head.S?09:34
juliusbit's probably been taken out though - way hacky09:34
olofkThe boot process is coming along fine. Started it this morning, and the last thing it printed is "RPC: Registered tcp NFSv4.1 backchannel transport module"10:30
olofkMaybe I should have deselected NFS support. I don't think I will use it very much in Icarus10:30
juliusbWhat do people think:
juliusbolofk: nice!12:49
stekernjuliusb: it looks nice, but I know that the oshwa got into some troubles from osi by using a logo to similar to theirs, so I think we should avoid that13:47
stekernmaybe I should put that to the mailing list too13:48
stekernoh, it wasn't mailed to the ml, answered anyways ;)13:51
olofkMy new kernel without NFS and TCP/IP stack is catching up with the first one. Good thing Icarus only uses one core, so I can start another run without any performance hits :)13:53
stekernusing your computer for anything else than opensource stuff would just be insane, I agree13:55
olofkAs soon as the kernel is finished booting, I will start compiling Icarus on it :)14:12
stekerndo you have uart input?14:14
stekernI've ran 'top' in verilated model14:14
stekernbut that's of course blasting fast compared to icarus14:14
stekernit boots in ~10-15 min14:15
olofkNo UART input yet. I will add that later. Probably both line buffered with fgetc, and with VPI via sockets or pipes14:17
olofkI realize now just how much faster verilator is :)14:18
olofkI think there should be a mux in the OpenRISC logo to represent the freedom of choice14:18
stekerncould probably be even faster if a 'fake' uart would be used14:19
olofkYeah, I'm using a fake UART14:21
olofkAhh.. you mean that the verilated model would be faster with a fake UART14:23
stekernI've avoided usin a fake one, because most of the times I have wanted to mimic the reality as much as possible14:24
olofkI prefer my perfect dream world where both instructions and data can share a bus as equals, and the arbiters always grant your requests14:26
larksquestion here, I'm building a small system that's tied to another system via some shared BRAMs.  I was thinking about having two BRAMs, one for the start up code, the text and constants and the other BRAM have the heap and stack18:51
larksfigured since there is a dbus and an ibus this would work well18:52
larksor am I off my rocker18:52
olofklarks: Do you want it like that to separate the read-only stuff from the read-write stuff?19:01
olofkDoes anyone have quick instructions for building barebox? I need something smaller than linux for my icarus experiments19:48
larksolofk: partly yes19:50
olofkIs really insns supposed to be incremented twice in task display_arch_state_except in or1200_monitor? That's not in the regular display_arch_state20:32
olofkAhh. it looks like OR1200_DISPLAY_EXECUTED is never defined, so that piece of code is never used20:51
olofkSent a patch to the mailing lists, but I can never remember which e-mail that is registrered on the lists21:31
--- Log closed Sat Jun 29 00:00:04 2013

Generated by 2.15.2 by Marius Gedminas - find it at!