| --- Log opened Thu Aug 28 00:00:26 2014 | ||
| poke53281 | X and wayland I haven't tried yet. They compile at least. | 00:12 |
|---|---|---|
| poke53281 | scummvm is 1.6.0 | 01:52 |
| stekern | I tried 1.7.0, but it crashes with an unaligned access | 02:38 |
| stekern | don't now if it's related to that version | 02:39 |
| stekern | *know | 02:39 |
| poke53281 | I checked for unaligned access. No problem while running monkey island 1 amiga demo | 02:45 |
| poke53281 | without sound | 02:45 |
| stekern | I'll give 1.6.0 a go | 02:51 |
| stekern | but whatever the outcome of that is, I'll investigate this crash later | 02:52 |
| poke53281 | By the way. Interesting article. http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient | 03:00 |
| stekern | 1.6.0 doesn't crash | 03:04 |
| poke53281 | Hmm, then it's probably nothing severe | 03:10 |
| stekern | could be a scummvm bug | 03:11 |
| stekern | running mouse events over the network didn't work too well | 03:11 |
| stekern | maybe I should have said, running them over my hack over the network | 03:12 |
| poke53281 | Didn't even know that there is a driver for this. Or do you use vnc? | 03:12 |
| stekern | it works but is slow as hell | 03:12 |
| stekern | not a specific driver, I use a hacked-up hack I found on internet to write uinput events from stdin | 03:14 |
| stekern | and then on or1k: nc -l -p 12345 | uinput | 03:14 |
| stekern | and on my ws: cat /dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse | nc 192.168.255.142 12345 | 03:15 |
| stekern | ...or the keyboard | 03:15 |
| stekern | keyboard works fairly well | 03:15 |
| poke53281 | Ahh, Ok. I expect a speed which is good. If you do cat /dev/input/eventX the amount of data is not that much. | 03:15 |
| poke53281 | even for a mouse | 03:16 |
| stekern | actually it does, there was a brainless 1ms sleep between each event in the hack | 03:18 |
| stekern | http://code.google.com/p/nethid/ | 03:18 |
| poke53281 | :) | 03:19 |
| stekern | http://pastie.org/9508835 | 03:20 |
| stekern | my version to make events from a 64-bit little-endian machine work on a 32-bit big-endian | 03:20 |
| poke53281 | looks easy. But in the long term an vnc server would be better I would say. | 03:21 |
| stekern | a vnc connection isn't really what I want though | 03:24 |
| stekern | unless you mean to write a vnc-server that mimics that functionality, and without transferring any display data | 03:25 |
| stekern | but if you need to do that, it's probably easier to improve the hack I'm using | 03:27 |
| stekern | and write a small server/client, where the client would grab the mouse and keyboard and direct them to the server | 03:28 |
| poke53281 | no, I mean a fully functional server. Transfer just the mouse is kind of senseless. If you run out of usb plugs or ps2 connectors you should use a hub. | 03:28 |
| stekern | well, if you want that, just run a vnc-server... but that's not what I need | 03:29 |
| poke53281 | I emulate the simplest touchscreen driver I could find and which I can use with the dts file. | 03:29 |
| stekern | and this isn't related to running out of usb plugs or ps2 connectors, I don't have usb nor ps2 connected to the or1k core at all | 03:31 |
| stekern | so, I need something that gives me mouse and keyboard that functions exactly like if they were attached to the or1k soc | 03:35 |
| poke53281 | Ok, I thought, that you already a sort of emulation for the mouse | 03:36 |
| poke53281 | is the framebuffer implemented in the same way? | 03:37 |
| poke53281 | cat /dev/fb0 | nc ....... ;) | 03:40 |
| stekern | no, why would I do that? ;) | 03:49 |
| stekern | I have access to the vga dac from the fpga | 03:50 |
| stekern | I actually *don't* have access to a eth phy from the fpga, so I get network via the ARM hps | 03:52 |
| poke53281 | I don't know the options you have with an FPGA. I suppose you can also define some mmio areas where you can write an emulation if this area is accessed. | 04:16 |
| stekern | yes, that would work, but I opted for an easy/generic solution | 04:30 |
| stekern | where I crossconnect 2 macs | 04:31 |
| -!- NegativeForty is now known as FreezingCold | 05:43 | |
| poke53281 | blueCmd: I make significant progress with asynchronous loading of files for my emulator. Tried to use it to boot Debian. http://jor1k.com/debian/jor1k-master/ | 06:45 |
| poke53281 | I come pretty far | 06:46 |
| poke53281 | Maybe you have an idea of the current error. Or is this already the udev error? | 06:47 |
| poke53281 | I cannot start stage2 of the debootstrap yet. (Kernel too old) | 06:47 |
| poke53281 | blueCmd: Do you have a bootstrapped tar.xxx file on the server which is already patched? | 07:17 |
| olofk | There should be a led blinker for de0_nano somewhere... | 09:38 |
| olofk | I assumed writing directly to 0x91000000 should light up the LEDs, but that doesn't seem to work | 09:39 |
| blueCmd | poke53281: patched in what way? | 09:45 |
| stekern | olofk: you need to set the direction to output too | 09:51 |
| stekern | *((uint8_t *)0x91000000) = 0xff; *((uint8_t *)0x91000001) = 0xff; | 09:52 |
| olofk | aha. That saved med som googling | 09:52 |
| olofk | Undefined command? | 09:53 |
| olofk | ahh. forgot the set :) | 09:53 |
| olofk | "No symbol table is loaded". What's this..? | 09:54 |
| stekern | what are you doing? setting from gdb? | 09:55 |
| olofk | yes | 09:55 |
| stekern | s/uint8_t/char | 09:55 |
| olofk | Ah.. forgot to mention that :) | 09:55 |
| olofk | woohoo!!! | 09:56 |
| olofk | Why doesn't writing an int work? | 09:58 |
| LoneTech | presumably the 8-bit device decodes which register to access based on the bus address | 09:58 |
| LoneTech | and the bus width translator doesn't convert multiple byte enables to multiple accesses | 10:00 |
| LoneTech | when going from 32-bit bus to 8-bit | 10:00 |
| LoneTech | though if it did work, you'd probably need to set 0xffff0000 or 0x0000ffff anyway | 10:01 |
| olofk | Yes, I tried both those combinations | 10:01 |
| olofk | But you're right. The arbiter is a bit too stupid here | 10:01 |
| olofk | I wonder if this should be considered a bug | 10:02 |
| olofk | Or how is this handled on other SoCs? | 10:02 |
| LoneTech | it's not unusual to have SFRs that must be accessed in specific modes | 10:02 |
| olofk | ah ok. Then I probably won't do anything about it | 10:03 |
| olofk | At least not now | 10:03 |
| olofk | maxpaln: I'm here today to hold your hand through the land of FuseSoC (also known as the Swamp of Sadness) | 10:04 |
| olofk | So if you need to blink some LEDs, just ask me | 10:05 |
| stekern | olofk, the LED maestro | 10:08 |
| maxpaln | :-) I would LOVE to be at the stage of blinking LEDs!! | 10:09 |
| maxpaln | olofk: thanks - I may well call on your expertise. | 10:09 |
| olofk | How do I set the npc from gdb? spr npc is deprecated, right? | 10:41 |
| stekern | olofk: set $pc= | 10:50 |
| olofk | c00l | 10:50 |
| maxpaln | These are good tips :-) I haven't used GDB very much before and have never actually tried to use it on any HW until now. It is nearing the top of the todo list (after the shift to the newest code) - out of interest, what cable connection would work best I was planning on getting one of these http://www.ftdichip.com/Products/Cables/USBMPSSE.htm to allow USB to JTAG comms. | 11:00 |
| olofk | maxpaln: I think it's basically a question if OpenOCD supports it (which I suspect it will), so search through the openocd docs | 11:04 |
| maxpaln | cool - thanks. | 11:04 |
| olofk | Or consult altavista | 11:04 |
| LoneTech | ftdi mpsse jtag comms is fairly common; you can use it directly with urjtag or openocd. the wiring is in figure 3-1 in the datasheet for that cable, and you'll likely want the 3.3V. note that some FPGAs run lower voltages still | 11:05 |
| maxpaln | LoneTech: thanks, ours is still 3.3V - I'll read through the openocd docs anyway but it sounds as though this is a good option. | 11:06 |
| stekern | maxpaln: to what extent does lattice support hooking up user logic to the (native) jtag chain | 11:50 |
| stekern | ? | 11:50 |
| stekern | and what kind of programming solutions do you usually use? | 11:50 |
| maxpaln | stekern: two questions there, i'll answer the last one first as its the easiest: | 12:08 |
| maxpaln | We have a broad range of programming tools and utilities that work via JTAG using one of our standard JTAG programming cables. | 12:09 |
| maxpaln | The DIamond Programmer is the latest incarnation but if any of you have used our devices before you may have used ispVM System. Both of these can be used as a generaic JTAG programming utility for any device - I have anumber of customers using our tools for Xilinx devices for example. | 12:10 |
| stekern | ok, you should check if those are supported in openocd, they might be ;) | 12:11 |
| maxpaln | Good point - worth checking! | 12:11 |
| maxpaln | As for the methods provided for hooking user logic to the JTAG chain, we provide a primitive that can be instantiated in the design. This primitive has a set of JTAG ports that mimic the incoming data - but due to the way this works it is necessary to shift in some custom instructions to enable the additional ports. Or put another way, by default you wouldn't see the JTAG activity in the | 12:12 |
| maxpaln | design until you first send some specific coammands to the FPGA. | 12:12 |
| maxpaln | It is for this reason that I was planning on using a simpler approach - I will just route the JTAG wires from a USB to JTAG cable to some GPIO on the FPGA and hook up the JTAG ports from the JTAG TAP Controller to these same GPIO ports. Is there any reason why this won't work? | 12:13 |
| stekern | no, that will work fine | 12:13 |
| stekern | I'm just asking out of curiousity ;) | 12:14 |
| maxpaln | It is for this reason that I was planning on using a simpler approach - I will just route the JTAG wires from a USB to JTAG cable to some GPIO on the FPGA and hook up the JTAG ports from the JTAG TAP Controller to these same GPIO ports. Is there any reason why this won't work? | 12:14 |
| maxpaln | :-) | 12:14 |
| maxpaln | This will allow me to get something working - then I can look into making things more seamless with our JTAG primitive | 12:15 |
| maxpaln | On the subject of the new wb_intercon arbiter. From what I can see, I should be able to remove the old arbiter from my orpsocv2 orpsoc_top and replace it with the new wb_intercon module. This would allow me to make one small change that I can validate in Simulation and HW. It would also get me almost all the way to the latest code - I would just need to upgrade use the latest versions of the | 12:17 |
| maxpaln | peripherals, if any have changed. | 12:17 |
| maxpaln | This would make the process of adding support into fusesoc for our tool flow a lot easier since I will have a known working starting piont. | 12:18 |
| maxpaln | Let me know if I have missed any fundamental problems that will prevent this from working :-) | 12:19 |
| stekern | right, and swapping the arbiters are basically just ripping out the old code, add the `include and change signal names | 12:20 |
| maxpaln | yep, that was my conclusion - great, this should be straight forward, | 12:20 |
| maxpaln | On a related note, one of my background tasks is to get the clock speed as fast as possible. I am expecting comparable rates to something like the Spartan 6 on the Atyls board | 12:22 |
| maxpaln | Do you know what Fmax the wishbone clock can ran at on these boards? | 12:22 |
| stekern | it depends on the peripherals | 12:24 |
| maxpaln | fair enough - I am keeping things basic, SPI, UART and my memory controller. Tha latter can run quick so I am expecting the rest of the system to be the limiting factor. With little effort I have got to 75 MHz. | 12:25 |
| stekern | ok, on a similar SoC setup on a cyclone iv, I've got around 85 MHz with the mmu enabled | 12:26 |
| maxpaln | Ok, well that is comparable. | 12:27 |
| stekern | 100MHz with the mmu disabled | 12:27 |
| maxpaln | ok. The longest paths appear to be from the MMU, through the cache and back to the MMU - so that fits with your variation due to the MMU enabled/disabled. | 12:28 |
| stekern | yes, and it's not really possible to cut that path away, so to optimize it you'll need to optimize the surrounding logic | 12:29 |
| stekern | well, of course it's *possible*, but not without taking a toll on performance | 12:31 |
| maxpaln | Yeah, when I saw the longest path I figured that reducing the logic levels here would be tricky. Might be worth looking a little later - I get roughly 14 logic levels at the moment. Reducing this by a few would make a significant difference. It might be possible to tweak how the code is written a little - I'll mark it down as a job for later. | 12:31 |
| maxpaln | there may even be scope to floorplan some of this logic to keep it closer together - it's not the most portable solution but some of the routing delays are pretty big so keeping things closer may have a significant impact. | 12:33 |
| stekern | yeah, I have never went down that route, since I've been mostly interested in generic optimizations that will be beneficial across platforms | 12:36 |
| maxpaln | yeah, that is the better approach - but for a specific FPGA/PCB there can be significant gains by helping out PAR. I'll look into it and let you know if I make any progress. | 12:38 |
| stekern | sounds good | 13:03 |
| maxpaln | Putting together a wb_intercon.conf file | 14:15 |
| maxpaln | I am using the atlys version as a guide | 14:15 |
| maxpaln | I can see some slaves have the datawidth set and others don't - is there a rule for this? | 14:16 |
| stekern | 32-bit is default, so it might be omitted on slaves that are 32-bit | 14:52 |
| poke53281 | blueCmd: Just the three patches in the README. inittab, noswap, ... | 15:48 |
| poke53281 | And if you know a one-liner to let the boot process ignore the udev-related bug you told me, this would be great as well. | 15:51 |
| poke53281 | but not necessary. For now it is enough if I come in the boot process to the same state as you are. | 15:52 |
| blueCmd | poke53281: no and no sadly, I never got it pas the udev thing | 15:58 |
| poke53281 | no problem. I will ask you in approx 0.0016 centuries again. ;) | 16:09 |
| poke53281 | But it would be great to have a online bootable Debian. | 16:10 |
| olofk | maxpaln: Are there any documentation for how to use the Lattice JTAG primitive, or is that a proprietary interface? | 16:10 |
| poke53281 | I have worked hard to implement a very efficient filesystem to make even Debian usable on a website without downloading 200MB. | 16:11 |
| olofk | I think that both the Xilinx and Altera protocols were reverse-engineered, but it would be nice to not have to go down that route | 16:11 |
| olofk | _franck_: Which port does openocd use for uart? | 17:01 |
| olofk | And where the hell can I read about this? I found the gdb, tcl and telnet ports by trying a few ports | 17:04 |
| olofk | Yes! 7777 | 17:19 |
| olofk | Fuckin' A! It works. Got a hello world | 17:21 |
| olofk | And linux is booting | 17:23 |
| olofk | Got some garbled output though | 17:23 |
| stekern | olofk: yes, me and _franck_ got that too, so it's 'normal'. We never got to the bottom of it, but the guess is that it's something in adv_debug sys | 18:08 |
| olofk | stekern: Something like this? ^@-/bin/?: not f/ # ? | 18:18 |
| stekern | yes | 18:19 |
| olofk | The kernel output looks all ok, but it looks like it's starting to mess up when busybox is started | 18:19 |
| olofk | Freeing unused kernel memory: 1656K (c030a000 - c04a8000) | 18:19 |
| olofk | init stusyBox vit (20147:52:52 Configurback dev | 18:19 |
| olofk | Pleaseer to achis consifconfigFADDR: Nevice | 18:19 |
| stekern | yes, more precisely when the irq is turned on | 18:20 |
| olofk | aha | 18:20 |
| olofk | Can I cut the IRQ line and use polling instead? | 18:21 |
| stekern | wait, I'll dig up the old conversation | 18:21 |
| stekern | but, yes, I think you can | 18:21 |
| olofk | great x 2 | 18:21 |
| olofk | I should try to simulate this with openocd connected to icarus too | 18:24 |
| olofk | Might be crazy slow though :) | 18:24 |
| stekern | ok, here's about where the old conversation me and _franck_ had: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-06-17.log.html#t05:39 | 18:26 |
| olofk | Thanks | 18:26 |
| olofk | weird. If I press Ctrl-c, I get a good prompt | 18:56 |
| stekern | I think that is consistent with what I saw too | 19:11 |
| olofk | Reading through the quite comprehensive adv_debug_sys docs, it looks like there are a lot of potential differences from a true uart16550 | 19:29 |
| olofk | Maybe this is the time to finally try out signaltap | 19:30 |
| olofk | Or is that included in the web edition? | 19:30 |
| olofk | Or perhaps diila | 19:44 |
| stekern | signaltap is included in the web edition | 19:46 |
| olofk | What's the binary called? | 19:47 |
| olofk | Only used the Xilinx equivalent before | 19:48 |
| olofk | nevermind. used the gui instead | 19:49 |
| stekern | for future reference, it's quartus_st | 19:51 |
| olofk | cool | 19:58 |
| olofk | Finding signals wasn't that easy | 20:04 |
| olofk | Might be a better idea to use the pre-synthesis netlist | 20:17 |
| olofk | fuck it. OpenOCD steals the JTAG connection | 20:25 |
| olofk | and why isn't my fancy USB-UART adapter showing up in /dev? | 20:52 |
| olofk | lsusb finds it | 20:53 |
| olofk | Aha. I have disabled the kernel driver. Who would have thought | 20:55 |
| olofk | Cool. I could use enable it, build the kernel and run make modules_install without rebooting | 20:59 |
| olofk | no UART output | 21:05 |
| olofk | Was there a special pinout for the de0_nano image in last year's workshop? | 21:05 |
| olofk | and the answer is yes! | 21:06 |
| olofk | Finally! | 21:16 |
| hesham1 | olofk: Please check the latest opened issue at github for Atyls board | 21:17 |
| olofk | hesham1: Hard to tell without the full log, but I know that there is some problems with the HDMI output on later ISE versions | 21:21 |
| olofk | Ironically it's in code that stekern copied straight away from a Xilinx white paper | 21:21 |
| olofk | Could you check if it's the same issue as https://github.com/olofk/fusesoc/issues/45 ? | 21:22 |
| hesham1 | olofk: Ah I came across this issue when I searched for a solution for this error, but it was not of help. stekern suggested to comment out some lines regarding timing constraints, but unfortunately the same problem exists. I will paste a full log to pastebin and give you a link. | 21:25 |
| olofk | Thanks | 21:29 |
| olofk | Unfortunately I no longer own an atlys board, so I'm a bit in the dark here, but I'll see what I can do | 21:29 |
| olofk | As a sidenote, please open issues related to the cores and systems in openrisc/orpsoc-cores instead | 21:29 |
| hesham1 | Sure | 21:31 |
| hesham1 | Another (side) issue, is that when I comment out morkx and use or1200 cpu instead, I got xst error. But that's not related to the main problem for now. | 21:32 |
| olofk | I really wish there was a nicer way to switch between the CPU implementations, but or1200 is starting to become a second class citizen in our board ports now | 21:38 |
| olofk | But it's good to know and feel free to open an issue for it so we can fix it | 21:38 |
| hesham1 | olofk: The log is too big for pastebin, so I created a google doc for it, please find it https://docs.google.com/document/d/1XKbPo4vVf4xJpCQ_8cXemwDKrv0fC_7svZ8bVZwfhec/edit | 21:58 |
| olofk | Might have another speaker for orconf now | 22:03 |
| olofk | hesham1: C00l. I'll take a look | 22:03 |
| hesham1 | Thank! | 22:03 |
| --- Log closed Fri Aug 29 00:00:28 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!