IRC logs for #openrisc Friday, 2014-01-17

--- Log opened Fri Jan 17 00:00:57 2014
olofk_Linkedin recommended me to join the group "Interior Design Professionals". They apparently have more confidence in my skills than my girlfriend has :)06:27
olofk_oh.. or perhaps the mean I should join the group to learn a few things :(06:28
stekernfor some reason, my wife was logged in as me on youtube, so now it suggests all sorts of odd things for me to watch...06:35
olofk_I'm not using youtube that much, so after I watched a demo of the Jolla phone in Finnish a while ago I'm only getting suggestions from Google for Finnish stuff (haven't got a clue what it's about, guessing ice hockey)07:05
blueCmd_olofk: try
blueCmd_it usually tells you who it thinks you are08:39
jonibostekern: the "generic" syscall stuff should all be in uClibc... but openrisc hasn't been adapted to it yet09:34
jonibovfork should not be needed... bug if it is as it's behind a DEPRECATED define in the kernel header09:34
jonibowhile you're at it, can you make the syscall interface in the openrisc port clobber "memory"...?09:34
joniboi'm seeing strange behaviour on syscall return where the arg registers are being handled as call-saved... at least it appears that way, but I wonder if it's not just a matter of addnig the "memory" clobber09:35
joniboi need to push my syscall handling rework to you for testing, since you seem to be looking at the linux code far more than me these days... sigh, need more time09:36
joniboanyway, it would be good if you (or anybody) could finish off moving uClibc to the generic syscalls so that we can drop supporting the legacy syscalls from our tree... they're not upstream so it's just an annoying diff that causes confusion09:42
jonibofrom the Linux kernel tree, I mean09:42
joniboanyway, did I ansewr your question?09:43
stekernjonibo: yes, and I think most became clear already yesterday, I posted this:
stekernI'll take a look at the memory clobber09:52
stekernbut what I'm really doing is that I've undertaken a "small" hobbyproject of writing a Linux port to a cpu called eco32 from scratch09:53
jonibothanks for posting that patch09:54
joniboyeah, I heard about your eco32 port... awesome09:54
joniboglad you're using openrisc as a template and happy if you can fix up some openrisc cruft along the way09:55
stekernI'm using the openrisc port a lot as reference though, so anything I found that doesn't seem right I step into openrisc mode and look it up ;)09:55
joniboi know upstream Linux wants more "generic" arch code so anything you find that looks essentially the same across a bunch of archs is a candidate for moving to generic headers/libs09:56
joniboand if you figure out how memblock is supposed to work in place of bootmem, let me know... we need to move openrisc to memblock but I don't quite grok the interface... bootmem is deprecated09:59
maxpalntrying to debug a basic ethernet issue - the Linux kernel won't respond to pings09:59
maxpalnfrom the Linux kernel I can ping a machine connected directly via cross over cable10:00
maxpalnI don't get a response but I can see the Rx packet count increasing on the machine being pinged as the pings are sent10:01
maxpalnusing ifconfig I can see the Tx and Rx packet counters increasing on the ORSOC board as well10:02
maxpalnBut Ping just responds with 0 packets received (on the ORSOC board)10:03
stekernjonibo: sure, I'll take a look at that too10:03
maxpalnI haven't completely ruled out that there maybe a HW problem but the fact that packets are Tx'ing and Rx'ing is giving me confidence. I am currently thinking this is a Linux issue10:03
maxpalnhmmm, odd - I am not seeing any of my posts appear in the stream10:08
maxpalnah. that one appeared!10:08
maxpalnI was trying to say "/proc/sys/net/ipv4/icmp_echo_ignore_all" is set to 010:08
stekernmaxpaln: you quit/joined a couple of times there, network issues perhaps10:08
maxpalnyeah, maybe10:08
maxpalnThe IP addresses look correct to me (not an expert but I think they *should* be able to talk to one another10:09
maxpalnThe ORSOC board can ping it's own address (
maxpalnand the loopback address (
stekernhave you tried inspecting the traffic with wireshark or similar?10:15
maxpalnnope - not used wireshark before10:16
maxpalnlet me look into it10:16
maxpalnok, so I can see thee ping requests arriving from the ORSOC board10:30
maxpalnI can't see a way to repeat that test on the ORSOC board though10:30
_franck_web_can you see the ARP reply from your machine ?10:35
_franck_web_I mean ICMP (ping) reply10:35
jonibomaxpain: this is a longshot, especially since things seem to work for you with pings arriving from the board, but do you have the WISHBONE_BUS_BIG_ENDIAN (something like that) config option set in your kernel config?  upstream kernel is missing this altogether and probably won't work... are you using kerne lfrom
maxpalnok, two questions -10:36
maxpalnjonibo: will check - I am using the openrisc kernel (can't remember the link)10:36
_franck_web_maxpaln: of course you can see it because you RX count increments10:37
jonibokernel from should work...10:37
joniboupstream kernel driver for ethernet mac is missing endianess fix10:37
jonibobut like I said, if you can see packets going out then it's probably fine... i'm just guess here10:38
maxpaln_franck_web_: On my PC (which is a Windows-7 laptop) I can see the Rx packet count increasing with each ping sent from the ORSOC board10:39
maxpalnunfortunately, on the ORSOC board the Rx packet count increases regardless of what is happening on the Windows machine - I am guessing windows is constantly sending traffic out over the link to assess the network etc.10:39
maxpalnso it is difficult to say for certain that the ORSOC board is 'receiving' any ping packets10:40
maxpalnjonibo: cat marvell_phy_and_spi.config | grep ENDIAN10:41
_franck_web_in wireshark, you should see ping reply after you received ping request10:41
jonibook, and your drivers/net/ethernet/ethoc.c uses that config option?10:42
joniboethoc.c, not sure path is correct there10:42
joniboif yes, you're fine10:42
maxpalnjonibo: there are several #ifdef CONFIG_WISHBONE_BUS_BIG_ENDIAN in ethoc.c (you had the path right)10:43
jonibook, perfect10:43
_franck_web_maxpaln: in wireshark/filter type: "icmp || arp" and apply10:44
_franck_web_you should see arp and ping request reply10:44
maxpaln_franck_web_: checking that now10:45
maxpalnok, gettting somewhere10:47
maxpalnso the request comes through (fromt he ORSOC board) but no reply is sent10:48
maxpalnrepeating the same test using another laptop (windows XP) with the IP address configured the same yields the expected reply after the request10:49
maxpalnI shoudl say the XP laptop replaces the ORSOC board10:50
maxpalnalso, very interesting - once I plug in the ORSOC board Wireshark shows a steady stream of ARPs with the destination of Braodcast requesting "WHo is"10:51
maxpalngoing to recheck IP settings on the ORSOC board10:52
_franck_web_you should inspect the ping request content10:54
maxpalnok, [should highlight that I'm not an expert here!]10:55
_franck_web_look at mac addresses10:56
maxpalnI was just checking those10:56
_franck_web_and IPs10:56
maxpalnwell, the MAC addresses and IP addresses for the destination and source look correct10:57
maxpalnbut Wireshark is telling me that the 'Header checksum' is incorrect10:57
maxpalnnot really sure if that would prevent the reply though10:58
_franck_web_well I thin k that would10:59
maxpalnok, I trust you :-)11:00
_franck_web_you could save the wireshark log session and share it11:01
_franck_web_I can take a look11:02
maxpalngood suggestion11:02
maxpalnok, you should be able to get it here11:05
_franck_web_the CRC problem is definitely bad11:10
_franck_web_plus I can't see ARP reply11:11
_franck_web_you should put your board the same ip mask: 192.168.254.x11:12
maxpalneverything is at 192.168.1.X at the moment11:12
_franck_web_ah ok, so the ARP request is not coming from the ping11:13
_franck_web_at some point you should have "Who has Tell"11:14
_franck_web_and then Dell_38... is at
maxpalnthe IP address of the ORSOC is the defaul at the moment - I am just setting to static with equivalent values11:15
_franck_web_do you have "arp" command on your board ?11:16
maxpalngood question - you're going to ask one I know the answer to soon :-)11:17
maxpaln# arp11:17
maxpaln? ( at <incomplete>  on eth011:17
_franck_web_(anyway, the ARP is not the problem since your ping has correct MACs)11:18
_franck_web_<incomplete> ?11:18
maxpalnok, so now I've set the ip address statically11:19
maxpalneach ping request is followed by an ARP request "who has tell"11:20
maxpalnand arp now returns11:20
maxpaln# arp11:21
maxpaln? ( at 5c:26:0a:38:57:d2 [ether]  on eth011:21
blueCmd_192.168.1.254 sounds like it's trying to route something11:21
_franck_web_lunch time11:22
maxpaln<agreed - well, elevenses here but still agreed>11:22
maxpalnonce last thing - here is the static IP details11:22
maxpaln# cat /etc/network/interfaces11:22
maxpalnauto lo11:22
maxpalniface lo inet loopback11:22
maxpalnauto eth011:22
maxpaln#iface eth0 inet dhcp11:22
maxpalniface eth0 inet static11:22
maxpaln(in case I have made a mistake)11:22
blueCmd_hah, you should use or something11:22
blueCmd_can you paste output of 'ip ro' ?11:23
maxpalnah, yeah - I was shown that yesterday (probably by _frank_web_ - very cool, must use more often!)11:23
blueCmd_also 'ip ro get <the other ip>'11:23
maxpalnonly 3 lines - will paste straight here:11:23
maxpaln# ip ro11:23
maxpalndefault via dev eth011:23
maxpaln192.168.1.0/24 dev eth0  src
maxpaln# ip ro get
maxpaln192.168.1.81 dev eth0  src
maxpalninterestingly, when I set the static IP I changed the address of the ORSOC board to - but the two pastes above reference!11:26
maxpalnnothing is at .100 now11:26
maxpalnhmmm, none of this really explains why the packets have incorrect header checksum!11:28
maxpalntime for a cuppa - be back in 511:28
blueCmd_checksums can be offloaded so don't assume that's a problem11:28
maxpalnok, back in the room11:34
maxpalnunderstood re checksums - will mark that for follow-up11:34
maxpalnok, so after each ping request I can see an ARP from the PC to find out "Who has" the default gateway address11:44
maxpalnI guess this means that the PC doesn't know how to find the ORSOC board11:44
maxpalnthere is no router - laptop and ORSOC board are connected directly via crossover cable11:45
blueCmd_maxpaln: you have to desribe your setup better. what is the configuration on your computer which I assume you are trying to ping from the board?11:47
maxpalnok, no worries11:48
maxpalnby configuration do you mean IP address config?11:48
blueCmd_idealy "ip ro" output of both machines11:48
maxpalnok, here is the paste from the ipconfig output for the Local Area Connection11:49
blueCmd_is that your ONLY connection?11:49
maxpalnthere are plenty of connections from the ipconfig output - I'll paste them all11:49
blueCmd_yes so that's your problem11:50
maxpalnah, ok11:50
blueCmd_you are using the same network for both connections11:50
blueCmd_so when the packet arrives to your computer it does not know where to send it11:51
blueCmd_it will probably default to send the answer out on your wifi11:51
maxpalnbut if I disable the wifi the problem still exists11:51
blueCmd_but ARP are link local so that is still correct11:51
blueCmd_just change the network to and
maxpalnok, will give it a go11:51
blueCmd_100 for your computer and 101 for the board for example11:51
maxpalnno worries11:52
maxpalnok, so now my limited understanding of netmasks means I am not confident that I have set the IP addresses correctly! [rubbish I know - really should have more attention at uni]12:00
maxpalnhere are the settings on the ORSOC board:12:01
maxpalnsimilarly for the PC:12:02
maxpalnThese look correct to me - but ping still doesn't work12:02
maxpalnbut I am no longer seeing the ARP requests for 'who has' - so perhaps we are one step closer!12:03
joniboyour broadcast address should be but that's certainly not your problem12:14
joniboyou had several NIC's on your PC?  what addresses/netmasks are set for hte other NICs?12:15
maxpalnupdated paste of the ipconfig /all output here:12:16
joniboi'm not familiar with the "network" field that you're setting on the Linux side, but it doesn't match the netmask you're setting12:16
jonibook, you have overlapping network between the NIC and wifi12:18
maxpalnah, of course12:18
maxpalnnetmask should be .253.012:18
maxpaln(I think)12:18
jonibowhy not make life easy for yourself and use everywhere?12:18
jonibonetmask should be .254.0...12:18
jonibobut .255.0 _everywhere_ is problably the way to go12:19
maxpalnreally? now I know I don't understand this -12:19
maxpalnthe Wifi uses 192.168.1.X12:19
maxpalnso I shifted the LAN to 192.168.2.X -12:20
jonibobut you set LAN network size to 22 bits and wifi net to 24 bits12:20
joniboif you set LAN netmask to then you'll actually have separate networks12:20
maxpalnyep - you've just confirmed it, I REALLY don't understand how that works (what is it they say about a little knowledge...)12:21
maxpalnso I am going to trust you :-)12:21
maxpalnand do some reading offline12:21
maxpalnok, I have set the netmask to on both PC and board and set IP addresses to and .101 on PC and board respectively12:27
maxpalnand now I can see the ping request on the PC12:28
maxpalnI can see thw ARP for "who has" from the PC12:28
maxpalnand I can (for the first time) see the board respond with an ARP to say that is at <MAC address>12:29
maxpalnthis is progress - but still no Ping reply!12:29
joniboping from PC to board of board to PC?12:30
joniboneither works?12:30
maxpalncorrect - neither works12:30
maxpalnI get more useful info from board to PC - because I can use Wireshark (thanks _franck_web_) to view the packets12:31
joniboyour sniffing the PC side... do you see the ping request coming in?12:32
maxpalnyep, definitely12:32
jonibook, and the pong giong out?12:33
maxpalnnope - no ping reply is sent12:33
jonibowindows firewall?12:33
maxpalnif I replace the board with another laptop I can ping successfully12:33
jonibothe problem would be on the windows side if you're seeing the ping request but no pong is sent as a response...12:33
maxpalnbut it's a good point - mayeb the firewall treats the board different to another laptop, worth a quick try12:34
maxpalnnope - no success12:35
maxpalnone point worth making - when I ping from the board, wireshark shows a LOT of ARPs from thge board for random IP addresses within 192.168.12:36
maxpalnfpor example or
maxpalnmight not be relevant but it happens as part of the ping process which seems weird12:36
_franck_web_on your PC machine "arp -a"12:36
_franck_web_and check is is here12:37
maxpalnwelll, we've switched to 192.168.2.X (jonibo highlighted a conflict with the wifi)12:38
maxpalnbut it isn't there:12:38
_franck_web_it is, line 512:39
maxpalnah, ok - wasn't reading it corrtcely - I see it now12:39
_franck_web_so the ping know where to send the reply....12:39
blueCmd_did you have an ipconfig /all somewhere?12:40
maxpalnthis is new progress - freshly achieved thanks for jonibo and the resolution of the ip conflict with wifi12:40
maxpalnblueCmd: here is a fresh paste:12:41
blueCmd_as well as an 'ip addr', 'ip ro' and 'ip ro get' from the board12:41
blueCmd_also 'arp -n'12:41
maxpalnthe commands output from the board:
blueCmd_that's not the MAC the WIndows machine has seen
_franck_web_good catch blueCmd_12:44
maxpalnoooh, you're right12:45
maxpalnip addr12:45
blueCmd__franck_web_: thanks,12:45
blueCmd_but it's weird12:45
maxpalnooops, wrong window in focus!12:45
blueCmd_I would reboot the Windows machine. Beause of reasons, and it's Windows12:46
_franck_web_maxpaln: double check the ARP reply from your board to see it's MAC address12:46
maxpalnthe ARP reply?12:47
maxpalnah, you mean in Wireshark12:47
_franck_web_in wireshark12:47
maxpalnok - yeah - it's the same as the board12:47
maxpalnI just checked that12:47
blueCmd_did you reboot the board recently?12:47
_franck_web_or you can clear the windows arp cache12:47
maxpalnnope - not in a while12:47
maxpalnlet me do that - give me an hour (only joking)12:48
maxpalnbe back online in 5 mins or so12:48
blueCmd_ok. I know the kernel randomly generates MAC for ethoc, but if you haven't rebooted that should be fine12:48
maxpalnyeah - a new MAC gets assigned to the ETH interface each time12:49
_franck_web_arp -d
maxpalnI was just thinking the same12:49
maxpalndenied: The ARP entry deletion failed: The requested operation requires elevation.12:49
maxpaln[frickin windows]12:49
maxpalnok - done12:50
maxpalnso a fresh arp -a shows no entry for (as expected)12:50
_franck_web_if you ping from the board you should have a new ARP request/reply12:50
_franck_web_and arp -a should show you the good MAC12:51
maxpalnok, this is wierd - now the ping request isn't arriving at the PC12:52
maxpalnI am getting a lot of 'Broadcast' ARPs for random IP addresses within 192.168. by the Board12:53
maxpalnand NO entry in the ARP table on the PC12:56
maxpalnok, I am going to reboot the PC - because its windows12:59
maxpalnI'll be back online shortly - the sudden lack of requests is odd, maybe a cold reboot will help13:00
maxpalnyou're help is very appreciated BTW - hopefully I can repay later13:01
maxpalnright - finally closed everything down13:04
maxpalnbe back online shortly13:04
maxpalnok ,back online13:25
maxpalnback with some sensible behaviour now13:34
maxpalnpings are still not working13:35
maxpalnbut the requests from the board are arriving at the PC now13:35
maxpalnbut I am still very confused about the constant stream of ARPs from the board for random IP addresses13:35
maxpalnhere is a log from Wireshark - you can see the steady stream of ARPs:13:36
maxpalnjust spotted that on the PC the ARP entry for the board is still wrong13:38
maxpalnI didn't make a note of the settings before but the way in which it is wrong looks very similar to last time (first 2 bytes correct then the remaining 4 incorrect):13:40
maxpalnsomewhat predictably - the MAC address in the packet sent by the Board is also incorrect13:42
maxpaln(maybe it was before too - with the first few bytes being correct perhaps I gave it a cursory glance rather than a good comparisoin13:43
_franck_web_indeed this ARP requests are weird13:44
maxpalnok, a correction13:45
maxpalnhaving looked at the log further I can see there is a mixture of pings from the PC and from the Board (I tried both)13:46
maxpalnthe ping fromthe board is correct - it contains the correct MAC address13:46
_franck_web_look at that, your board mac address in the PC arp table: 8e-2e-c0-a8-02-6613:46
_franck_web_c0-a8-02-66 =
maxpalnyep, I saw that13:47
maxpalnI think I can reliably cause that to happen13:47
maxpalnby removing the entry from the ARP table than pinging the board from the PC13:48
maxpalnlet me try13:48
maxpalni'll capture the log in wireshark13:48
_franck_web_who is .102 ?13:49
maxpalnok, here is log - it happened exactly as I expected13:50
maxpaln.102 is the board13:50
maxpalnthe ARP request for returns an incorrect MAC address13:50
maxpalnI presume this is the board responding -13:50
maxpalnmore specifically it is the hardware in the board13:51
maxpalnrather than the kernel (If I understand how the ARP is handled)13:51
maxpalnso the Ping from the PC has an incorrect MAC address so it never arrives at the board13:52
maxpalnthe ping from board makes it to the PC but the PC has an incorrect arp entry for that MAC address13:52
maxpalnI would have thought we'd still see a Ping reply but with the wrong mac address but maybe I'm wrong13:53
_franck_web_me too13:53
_franck_web_but still, there is a problem here in the ARP13:53
maxpalnthe question is where is the incorrect mac address response being generated when the arp request is sent out13:54
_franck_web_now you need to dive into the Kernel13:54
maxpalnok, you think its a kernel issue rather than ORSOC HW?13:55
_franck_web_I would print the arp packet in the driver tx routine13:56
olofk__franck_web_: Thanks for the CPP patch for or1k-elf-loader btw.13:56
maxpalnI guess it must be in the kernel thinking about it - ARP isn't part of the HW laye13:56
_franck_web_no it's not13:57
maxpalnok, in I dive13:57
maxpalni'll come up for air periodically13:57
_franck_web_but who knows, my be some fifo over/underrun somewhere....13:57
_franck_web_olofk_: when you have time, please comment:
_franck_web_maxpaln: me be hardware; if you look at ICMP with bad crc, you can see that CRC = last two bytes of src address :)14:00
maxpalnand interestingly, I decided to reboot the linux kernel a few times and get a few sets of mac addresses (good from board and bad from PC for comparison)14:03
_franck_web_maxpaln: print skb->data in ethoc_start_xmit14:05
maxpalnI have two sets and in both cases the upper four bytes are almost identical in the PC arp table: C0-A8-02-66 and C0-A8-02-6714:05
olofk_olofk: Yeah, I have looked at it briefly and it seems fine, but I will look at it more closely when I have time14:11
olofk_I mean _franck_web_  of course14:13
olofk_That wasn't meant to be a note to self :)14:13
maxpaln_franck_web_: hmmm, might need a little guidance here - I tried looking for the definition of sk_buff to see what type to print14:29
maxpalnall I found was an empty definition in phy.h - and trying to trace the call to ethoc_start_xmit didn't get me anywhere.14:30
maxpalnI took a guess at type char * and did a print with %s as the type and it results in this:14:30
maxpaln# net eth0: skb->data is \&14:30
_franck_web_print for (i = 0 ; i < skb->len; i++)14:32
maxpaln:-) thanks14:32
juliusb_looks like the irc logs are down (and my high-impact home page)14:32
_franck_web_juliusb_: hello14:32
juliusb_hmm actually, no, it's fine from my phone. OK something up with my web browser at work14:33
juliusb__franck_web_: salut! :) how are you?14:33
juliusb_happy new year all, by the way14:33
_franck_web_right, happy new year :)14:35
juliusb_what's been going down?14:36
juliusb_... aside from the number lines contributed to OpenRISC-related projects and IRC lately :(14:37
_franck_web_well, we are still spending your time on thing that nobody cares and won't make us rich :)14:38
olofk_Hi juliusb_ Good to see you14:38
olofk_Are the logs down? That's not good... .it's where I usually go to find out the syntax for git fetch14:39
maxpaln(pretty new to this but I've been adding more than my fair share of lines to the log I think :-) )14:41
maxpaln_franck_web_: here is the output - not sure if the format is helpful or not but I wasn't sure what to expect (I captured the HW address too for reference):14:42
_franck_web_maxpaln: this is frame, compare with wireshark14:46
maxpalnah, ok14:46
_franck_web_ would be easier to read14:46
maxpalnwell, crucially bytes 24-27 are different14:49
_franck_web_you can filter ARP frames with skb->data[12] == 8 && skb->data[13] == 614:49
_franck_web_so there are good in the printk and not good in wireshark ?14:50
olofk_juliusb_: Lots of stuff going on. From the top of my head: maxpaln running ORPSoCv2 on Lattice, blueCmd_ working on glibc and making debs for the toolchain, _franck_web_ and I are improving orpsocv3, jonibo and stekern are fixing linux stuff14:50
olofk_Probabyl a lot more that I forgot right now14:50
maxpalnrealised I might have been looking at an old wireshark log14:50
maxpalnlet me doubel check and confirm14:50
maxpalnbut I think that is correct14:50
maxpalnok, confirmed - the printk contains the correct MAC address (or at least a MAC address consistent with that reported by ifconfig) and wireshark contains incorrect data14:55
_franck_web_ok, so now you can close the Linux source files :)14:56
maxpalninterestingly, the ethernet frame has the correct MAC address but the ARP section of the packet contains the wrong MAC address14:57
maxpalnok, closing the source files :-)14:57
_franck_web_the ARP and ICMP frame are corrupted the same way14:57
maxpalnwell, the ethernet frame contains the correct HW address in both ARP and ICMP packets15:04
maxpalnI see what you are saying - the checksum bytes in the ICMP (which are incorrect) are in bytes 24 and 25, which is also where the HW address is sent in the ARP packet15:09
maxpalnoooh, tricky one - over the to Verilog...15:12
maxpalnso the most likely culprit is probably the memories - according to our tools the rest of the ETHMAC block is just implemented via straightforward logic (i.e. no distributed memory and so on).15:17
maxpalnthe ETHMAC instantiates 4 block RAMs, 3 as FIFOs (two Rx and 1 Tx) and 1 as a BD_RAM15:18
maxpalnok, I can see there are some technology specific mappings in the BD_RAM, I'll take a look and see if I can see what sort of memories are used in the Xilinx or Altera versions - maybe there's a latency issue or something similar15:22
_franck_web_yeah, might be15:22
maxpalnhmmm, might be onto something here -15:31
juliusb_olofk_: nah website is actually OK, fortunately. It is a rich mine of git-related commands, I agree :)15:32
juliusb_sounds good15:33
juliusb_I was contacted about running another chiphack at some point, so I'll still be active spreading the OpenRISC gospel15:33
maxpalnthe BD_RAM has been inferred as a dual port RAM by Synplify - not sure why. But it should be a single port - there is a likely conflict with both ports accessing the same memory space simultaneously15:33
maxpalnI'll modify and rebuild the HW15:34
olofkjuliusb_: Sounds like fun. Give me a shout if you want an extra hand. It would be fun to come over if I can make the time18:15
olofk_franck_: I'm starting reviewing your patch now and writing down what I find18:22
olofkInstead of using Launcher with bash as the first argument, you can set shell=True as a parameter18:22
olofkin there's a new import subprocess that's not needed18:27
olofkOther than that, it looks all good. I could make the changes and apply the patch if you like18:29
olofkok, I've amended the changes. Should I push it?18:42
_franck_olofk: did you do something about the VERILATOR_ROOT variable ?18:58
_franck_olofk: we should have a "next" branch in the orpsoc repo18:59
_franck_so we could push new feature and test it before we push to master19:00
_franck_I did not test a core simulation with verilator. I only worked on or1200-generic system19:02
_franck_olofk: ok, you were talking about the script patches....20:13
_franck_so yes you can apply this one20:13
--- Log closed Sat Jan 18 00:00:59 2014

Generated by 2.15.2 by Marius Gedminas - find it at!