| --- Log opened Thu May 14 00:00:48 2015 | ||
| stekern | olofk: I recall having the same feeling when I did wb_sdram_ctrl | 06:12 |
|---|---|---|
| maxpaln | olofk: the openrisc community portal still references openrisc.net: http://opencores.org/or1k/OR1K:Community_portal | 08:40 |
| olofk | Yeah! The uImage loader works on hardware too | 10:41 |
| olofk | At least on the de0 nano. Next step is to try this on lx9 microboard as well | 10:42 |
| stekern | olofk: nice! | 10:56 |
| bandvig | olofk: as far as I understand, your loader: (1) runes from spi-flash similar to u-boot (2) waits UART (Z-modem?) (3) transfer an image prepared for u-boot and (4) run it. Am I right? | 11:47 |
| olofk | bandvig: I've actually been working with two different boot loaders recently, which might make things more confusing :) | 11:55 |
| olofk | But one of them is almost as you describe, but it's more like this (1) runs from internal boot ROM (without any access to SPI Flash or RAM) (2) waits UART (3) transfer an image converted to intel HEX format and (4) run it | 11:57 |
| olofk | But I stopped working on that one since I realized it would take too much time to transfer a HEX file over UART (~1 hour for a Linux kernel) | 11:58 |
| stekern | olofk: I doubt you'd use that to transfer the Linux kernel though | 11:59 |
| olofk | The other one that I have been working on (which also works now), is a program that is small enough to be put into the internal boot ROM and can boot images prepared for U-boot. This means that we can boot a program (say Linux) directly without having to first load U-boot. It also means that we don't have to use bin2binsizeword anymore for the U-boot image. We can just run mkimage on the U-boot image as well | 12:00 |
| olofk | stekern: I was hoping to do that actually, for boards where it's tricky to get JTAG working | 12:02 |
| stekern | yes, but it could still be useful for that, to load something that's got more intelligence to load the kernel from ethernet/sdcard/usb etc. | 12:05 |
| olofk | stekern: Sure. U-boot for example | 12:05 |
| olofk | The Stream board that I was working on last doesn't have any easily accessible non-volatile memory, so JTAG and UART are the only connections there until ethernet is configured | 12:06 |
| bandvig | olofk: thanks. good job! I think the loaders are also useful things to simplify the road to OpenRISC for newbies. | 12:09 |
| olofk | bandvig: Absolutely. That's why I have spent some time now trying to streamline the process | 12:10 |
| olofk | What I'm looking for now is a decent way to select the boot ROM when building and running simulations. | 12:16 |
| olofk | I could use a `define, and for simulations I could probably use the elf-loader, but I would like something less hackish | 12:17 |
| olofk | A parameter is nicer than a define, but I'm not sure how to pass that to the synthesis tools | 12:19 |
| olofk | Alright! First version (0.9) of or1k_bootloaders is available now | 13:21 |
| olofk | ...and is now used by de0 nano | 13:25 |
| olofk | Is there any clever way to read out the contents of a ROM that is only connected to the instruction bus? | 14:35 |
| olofk | Can I for example connect a debugger, set the pc and read out the current instruction? | 14:35 |
| stekern | olofk: if it's only connected to the processors i-bus, no | 15:18 |
| olofk | I'm trying again to get this DVI thing working. How on earth is anyone supposed to understand this timing stuff? | 17:43 |
| olofk | Are the length of the vsync/hsync strobes important, or is it just edge triggered? | 17:44 |
| olofk | I'm finding tons of tables. Just too bad that not two of them seem to tell the same thing | 17:45 |
| olofk | Quote: "As with RS-232, the standard for VGA video is that there are lots of standards" | 17:46 |
| olofk | Yeah, that sums it up | 17:46 |
| olofk | Doesn't help that my source clock is 30.72MHz. | 17:48 |
| GeneralStupid | i just viewed the vga examples and that was enough for me | 17:49 |
| olofk | GeneralStupid: Enough to understand, or enough to give up? :) | 17:50 |
| GeneralStupid | to give up | 17:50 |
| GeneralStupid | i canceled it. Iam searching for any simpler example. | 17:50 |
| olofk | Everything seems to assume that you have a pixel clock with certain frequencies available | 17:51 |
| olofk | What happens if I'm 0.751% off? | 17:52 |
| GeneralStupid | The T.M.D.S. clock channel carries a character-rate frequency reference from which the | 17:56 |
| GeneralStupid | receiver produces a bit-rate sample clock for the incoming serial streams. Due to the high | 17:56 |
| GeneralStupid | pair-to-pair skew that must be tolerated, the phase of the derived sample clock must be | 17:56 |
| GeneralStupid | adjusted individually for each data channel. The methods of clock generation for data | 17:56 |
| GeneralStupid | recovery are implementation specific and beyond the scope of this document | 17:56 |
| GeneralStupid | Yes... | 17:56 |
| GeneralStupid | Its awful to read :) | 17:56 |
| GeneralStupid | i mean, big document but the implementation isnt in there | 17:56 |
| olofk | Luckily in my case, I have a chip that takes care of the TMDS signalling | 17:58 |
| olofk | But I still need to feed it hsync/vsync | 17:58 |
| olofk | ok, so hsync is supposed to be 3.5-4.0us and vsync 50-300us. That's a start | 18:01 |
| stekern | olofk: usually it's not the end of the world if your clock is slightly off, most monitors can handle that | 18:03 |
| olofk | stekern: Thanks. Good to know | 18:23 |
| olofk | Just discovered that the pixel clock can't be higher than the wb_clk. Now that's a problem | 18:23 |
| GeneralStupid | iam so happy that iam a software guy :) | 18:41 |
| bandvig | stekern: It looks like there is a bug in mor1kx_ctrl_cappuccino. Please have a look on line 418. I think the case id should have one more "?". | 18:43 |
| stekern | bandvig: mhmm, looks like you missed that one (and me too when reviewing your fpu changes) ;) | 18:57 |
| stekern | but good that you cought it now | 18:57 |
| bandvig | yes, my fault :) | 18:59 |
| bandvig | just a minute, I'm going fix it | 19:04 |
| stekern | I already did ;) | 19:05 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/28674cad87aba0e0482c7d2ff2fe63c06cd96a19 | 19:05 |
| mor1kx | mor1kx/master 28674ca Stefan Kristiansson: cappuccino/ctrl: add missing '?' in exception cause decoding | 19:05 |
| bandvig | :) you are so fast | 19:10 |
| olofk | stekern: How off is slighly off? | 20:47 |
| olofk | 7.5% ? | 20:48 |
| stekern | hmm, I don't have any hard numbers, but iirc the pixel clock I used to drive the LCD from de0 nano was pretty off | 20:48 |
| stekern | and on atlys, some resolution was pretty much off, but that worked on my monitor. those guys that did that accelerated 2d graphic stuff had problems with it though. | 20:50 |
| olofk | what the hell.. I find settings that are pretty perfect now. | 20:52 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/6caa7dba90cbe7c51421b542bd7b5ed487c83195 | 20:53 |
| mor1kx | mor1kx/master 6caa7db Stefan Kristiansson: pic: fix OPTION_PIC_TRIGGER="EDGE"... | 20:53 |
| olofk | Perfect = ~2.3% off :) | 20:53 |
| olofk | I've been reading this blog (http://www.filfre.net/) whenever I get the chance. It's awesome | 20:54 |
| olofk | And he has written a ton of articles | 20:55 |
| stekern | nooo, don't give me more distractions!!! ;) | 20:57 |
| olofk | haha | 21:00 |
| stekern | I still have a bunch of unread posts at http://blog.thimbleweedpark.com/ | 21:07 |
| olofk | I chose to avoid that distraction. Still got plenty of others though | 21:07 |
| olofk | Absolutely nothing is happening on the monitor :( | 21:38 |
| stekern | what exactly are you trying with? | 21:52 |
| olofk | The board has a Cyclone IV connected to a TI TFP410 DVI/HDMI Transmitter | 22:01 |
| olofk | Pixel clock is ~40MHz and a standalone simulation seems to generate correct timing | 22:01 |
| olofk | I'm writing the timing registers with OpenOCD | 22:02 |
| olofk | I forgot to connect the master interface though, so I'm rebuilding now with wbm_ack_i = 1 and wbm_dat_i = 32'hffffffff | 22:03 |
| olofk | But it might just as well be some funkiness with the connection to the DVI transmitter | 22:03 |
| olofk | Haven't got an oscilloscope here | 22:03 |
| olofk | wooohooo!!!!! | 22:09 |
| olofk | IT'S WORKING | 22:10 |
| olofk | Well, I got a light grey screen at least. Which is somewhat expected since I tied the data pins high | 22:10 |
| olofk | This is the first time ever that I made something visible more than lighting up LEDs | 22:17 |
| olofk | So what is there to do on the Linux side now? | 22:17 |
| olofk | Do I need the IRQ? | 22:47 |
| olofk | I copied the entry fb0 entry from the neek dts, and it says nothing about irq there | 22:48 |
| olofk | I vaguely recall something about endianness too. Is that relevant? | 22:49 |
| olofk | Can't find anything that looks like an interrupt handler in ocfb.c | 22:51 |
| olofk | Shouldn't linux say something about the fb when I boot? | 22:53 |
| olofk | There's a /dev/fb0 though | 22:53 |
| olofk | Looks like I managed to set the correct mode | 23:06 |
| olofk | The screen is blank though | 23:06 |
| olofk | Shouldn't the terminal show up here? | 23:06 |
| olofk | ahh.. something with bootargs perhaps | 23:07 |
| olofk | Can I set the video mode in the dts, or does that require some extra patches? | 23:08 |
| olofk | Right now I hacked default_mode in ocfb.c | 23:09 |
| olofk | fbset doesn't seem to do much | 23:11 |
| olofk | ok, so setting video mode in the dts seems to work. Still waiting for anything to show up though :( | 23:36 |
| olofk | Where's my penguin? :( | 23:42 |
| --- Log closed Fri May 15 00:00:50 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!