--- Log opened Fri Jun 28 00:00:03 2013 | ||
olofk | Success! It seems like printk only writes to a buffer and nothing happens until the uart is ready, which happens much later. | 05:29 |
---|---|---|
olofk | n't that always 0? | 07:22 |
olofk | 20:24 < olofk> Or does it require a boot loader to set it up for me? | 07:22 |
olofk | 20:27 < olofk> Rereading what stekern said, a few days ago, I see that it's definitely the case | 07:22 |
olofk | 20:28 < olofk> Still... can I fake it somehow, and how does that work in or1ksim? | 07:22 |
olofk | 20: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 |
olofk | 20:36 < olofk> Back to square 1. Haven't got a clue why my printk doesn't try to access the UART | 07:22 |
olofk | 21:52 -!- mboehnert [[email protected]] has quit [Quit: mboehnert] | 07:22 |
olofk | 22:27 -!- GusBricker [[email protected]] has quit [Remote host closed the connection] | 07:22 |
olofk | 22:41 -!- GusBricker [[email protected]] has quit [Remote host closed the connection] | 07:22 |
olofk | Day changed to 28 Jun 2013 | 07:23 |
olofk | 03:54 -!- GusBricker [[email protected]] has quit [Remote host closed the connection] | 07:23 |
olofk | 04:00 -!- GusBricker [[email protected]] has quit [Ping timeout: 276 seconds] | 07:23 |
olofk | 05: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:freenode | 07:23 |
olofk | /#openrisc(+cnt)] [Act: 1,2,4,5] | 07:23 |
olofk | [#openrisc] | 07:23 |
olofk | Sorry about that | 07:23 |
juliusb | so you got it going in the end olofk? | 07:54 |
LoneTech | iirc there is an option for early console printing | 08:03 |
hno | console=uart,... is quite early. | 08:04 |
hno | in 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 |
LoneTech | right, that's what I was thinking of | 08:05 |
hno | console=uart... is almost as early. Long before /dev/ttyS* is up and running. | 08:06 |
LoneTech | ok | 08:07 |
hno | and 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 |
juliusb | I believe we used to have some early early debugging UART print code in our port's head.S? | 09:34 |
juliusb | it's probably been taken out though - way hacky | 09:34 |
juliusb | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/arch/openrisc/kernel/head.S?h=junk#n2113 | 09:35 |
olofk | The 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 |
olofk | Maybe I should have deselected NFS support. I don't think I will use it very much in Icarus | 10:30 |
juliusb | What do people think: http://juliusbaxter.net/OPENRISC.jpg | 12:48 |
juliusb | olofk: nice! | 12:49 |
stekern | juliusb: 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 that | 13:47 |
stekern | maybe I should put that to the mailing list too | 13:48 |
stekern | oh, it wasn't mailed to the ml, answered anyways ;) | 13:51 |
olofk | My 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 |
stekern | using your computer for anything else than opensource stuff would just be insane, I agree | 13:55 |
stekern | s/opensource/openrisc | 13:55 |
olofk | As soon as the kernel is finished booting, I will start compiling Icarus on it :) | 14:12 |
stekern | do you have uart input? | 14:14 |
stekern | I've ran 'top' in verilated model | 14:14 |
stekern | but that's of course blasting fast compared to icarus | 14:14 |
stekern | it boots in ~10-15 min | 14:15 |
olofk | No UART input yet. I will add that later. Probably both line buffered with fgetc, and with VPI via sockets or pipes | 14:17 |
olofk | I realize now just how much faster verilator is :) | 14:18 |
olofk | I think there should be a mux in the OpenRISC logo to represent the freedom of choice | 14:18 |
stekern | could probably be even faster if a 'fake' uart would be used | 14:19 |
olofk | Yeah, I'm using a fake UART | 14:21 |
olofk | Ahh.. you mean that the verilated model would be faster with a fake UART | 14:23 |
stekern | yes | 14:23 |
stekern | I've avoided usin a fake one, because most of the times I have wanted to mimic the reality as much as possible | 14:24 |
olofk | I prefer my perfect dream world where both instructions and data can share a bus as equals, and the arbiters always grant your requests | 14:26 |
stekern | utopia | 14:35 |
juliusb | rofl | 15:19 |
larks | question 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 stack | 18:51 |
larks | figured since there is a dbus and an ibus this would work well | 18:52 |
larks | or am I off my rocker | 18:52 |
olofk | larks: Do you want it like that to separate the read-only stuff from the read-write stuff? | 19:01 |
olofk | Does anyone have quick instructions for building barebox? I need something smaller than linux for my icarus experiments | 19:48 |
larks | olofk: partly yes | 19:50 |
olofk | Is really insns supposed to be incremented twice in task display_arch_state_except in or1200_monitor? That's not in the regular display_arch_state | 20:32 |
olofk | Ahh. it looks like OR1200_DISPLAY_EXECUTED is never defined, so that piece of code is never used | 20:51 |
olofk | Sent a patch to the mailing lists, but I can never remember which e-mail that is registrered on the lists | 21:31 |
--- Log closed Sat Jun 29 00:00:04 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!