IRC logs for #openrisc Tuesday, 2013-12-31

--- Log opened Tue Dec 31 00:00:32 2013
hikenbootif one is running a virtual machine which is loaded remotely and one was to encypt the memory allocation, would it be difficult or close to impossible for the host system or java itself trace what was going on in the virtual machine?00:07
butcher_I did use binds04:06
maxpalnok, back on this now09:03
maxpalnand it's starting to make a bit more sense09:03
maxpalnseemingly the driver is selected based on the syntax in the .compatible section of the DTS file09:03
maxpalnthis much is what I suspected but it took me a while to confirm this09:03
maxpalnI think there might also be a default somewhere that loads a really generic driver if no matches are found - and I suspect this default is actually the same set of settings as when the device is specified as compatible = "opencores,ethmac-rtlsvn338";09:04
maxpalnalthough I haven't confirmed this so it is speculation and could be wrong09:05
stekernhmm, no, and I think from your earlier comments it sounded like the ethmac driver was loaded09:08
maxpalndo you mean no about the defaults?09:18
maxpalnok, so the 'ethernet' driver doesn't assume a default - I was wrong about this09:30
maxpalnbut i think there may be a default for the PHY driver in case of no match09:30
maxpalnjust looking in drivers/net/phy/phy_device.c09:30
maxpalnok, I think I've got th4ere09:42
maxpalnethoc.c calls phy_connect_direct:
maxpalnthis jumps to phy_device.c which calls phy_attach_direct:
maxpalnThis loads a bunch of stuff into the phy_dev struct then calls phy_init_hw:
maxpalnSo far, this is all generic - and will hapen for any PHY09:45
maxpalnphy_init_hw is where the link to a specific PHY is made - the final call to phydev->drv->config_init is the key:
maxpalnconfig_init is part of the PHY specific struct - in my case contained in marvell.c09:47
maxpalnNow I have a question - how does the or1ksim handle the interrogation of the HW09:51
maxpalni.e. in HW the Kernel can actually probe the MDIO bus and get the ID of the PHY09:51
maxpalnwhat happens in the or1ksim world - there is no PHY and I don't think I've specified a PHY anywhere - the DTS file certainly doesn't appear to contain one09:52
maxpalnI may have just answered this - adding some printouts I can see the phy_id as 0xFFFFFFFF09:52
maxpalnstill, it would be good to know if I can get or1ksim t mirror HW09:53
stekernah, yes, the phy is a different story10:02
stekernso, what phy_id does it find on the hw?10:12
stekernand does it run the marvel config_init?10:12
stekernthat all said - what in the marvell driver do you need?10:12
maxpalnjust run on HW and interestingly the phy_id comes back as the same - 0xFFFFFFFF10:15
maxpalnat least, this is the ID just before the config_init is called:10:15
maxpaln  pr_err("phy_id is %x\n",phydev->drv->phy_id);10:15
maxpalnI was expecting this to contain the ID as read by the Kernel10:15
maxpalnbut now I am wondering if I have misunderstood10:15
stekerntry putting some debug printks at the mdio interface functions in ethoc.c10:16
maxpalnon the pluis side - I have obtained the settings that I need to load into the PHY in order to get it to work as expected in MII mode10:16
maxpalnbut I need to work out how and where to include then in the kernel!10:16
maxpalnyour questoin about te config_init is a good one10:17
maxpalnnow that the phy_id is all Fs I am questioning what has actually been attached to the phy_device struct10:19
stekernI'd be mostly interested to know if there are any data moving on the mdio lines10:22
stekernfirst step towards that is debug prints in mdio interface routines in ethoc.c10:23
maxpalngood point - I could do a build a monitor the mdio lines (I don't have a 'scope at my home office - rubbish, I know!)10:23
stekernif all reads are 0xffff, the lines are probably dead10:23
stekernnext step would indeed be a ILA build10:23
maxpalnok, debug prints first10:24
maxpalncan you clear up my confusion about or1ksim vs HW for this sort of thing - does or1ksim have a way to handle HW (such as PHYs) or can this sort of debug only be done in on the board?10:28
maxpalnhmmm, noticed that there is a Tristate control on the MDIO line - wondering if this never gets released!10:47
stekernmaxpaln: (or1ksim) I would guess that there are no PHY simulation, I would also guess it wouldn't be superhard to add11:03
stekernbut I don't know if the effort is still worth it11:03
maxpalnok, well - I'll assume I need to run on HW to get some sensible data across the MDIO line11:04
maxpalnhmm, making a little more sense - I have noticed that the genphy_driver has a phy_id of 0xffffffff11:10
maxpalnphy_attach_direct seems to assume there is no driver and attaches the generic one anyway11:11
maxpalnI am looking to see  where the actual driver gets attached if it is found11:11
maxpalnI had assumed that the discovery of the correct driver would happen in phy_attach_direct() but now I am wondering if this shoudl all be resolved by then11:17
maxpalnfor example, this function attaches the generic PHY driver - I think this must happen as a result of no driver existing:
maxpalnbut what I can't work out is where the correct driver would get discovered11:19
maxpalnthere isn't much going on before this point that could resolve the correct driver11:19
maxpalnok, ILA shows that MDIO bus is working - activity on outputs and OE goes high to disable tristate11:45
maxpalnso comms between ethmac and PHy is present11:45
maxpalnI am really struggling to work out how anything other than the default genphy driver will get used though - I can't see any hook into a PHYT specific driver anywhere!11:45
maxpalnneed to pop out - will  be back in an hour or so!11:46
stekernok, activity on outputs, but do you see the PHY answering on the mdio line?11:57
stekernto answer the question how anything other than the default, this is the flow for that:12:14
_franck_maxpaln: what a bout your PHY address ?12:41
stekern_franck_: afaict, the code loops over all addresses, so it shouldn't matter12:44
_franck_ah ok, I didn't even look at the code12:47
maxpalnstekern: yep, activity on both output and input lines within the ethmac RTL code12:58
maxpalnso the PHy is responding - I will check through the flow you sent, maybe it will trigger some clues12:58
maxpalnaha - we're back on track!13:17
maxpalnnow I'm looking in the right place - the PHY ID is 1410e8013:17
maxpalnwhich is not one of the supported PHYs in the Marvell list - unsurprisingly13:19
maxpalnbut I should be able to add it easily enough now - I think!13:19
maxpalnThanks stekern - very helpful, you've guided me back on track!13:19
maxpalnnow I just need to work out where the returned PHY ID is compared with the ones the Kernel knows about - shouldn't be too hard13:21
maxpalnExcellent - a quick sanity check yields a successful hook into my new config_init function. Just need to add the necessary register writes now! fingers crossed13:38
stekernmaxpaln: great!14:08
Alpha78Hi All!14:25
Alpha78Anyone knows why I get "(504 Gateway Time-out)" while checking out or1200?14:26
maxpalnok, interesting - so the new phy driver works. I can see the PHY reset, then come up as a 100 Mbps link14:28
maxpalnBut some time shortly after it gets reset again and comes back up as a 1 Gbps link14:29
-!- Netsplit *.net <-> *.split quits: poel, 31NAAG4NU14:29
maxpalncould the Linux Kernel be forcing a reset for some reason?14:29
maxpalnthe timing of the second reset (and wake up as Gbps link) is coincident with the terminal showing the 'Configuring Loopback Device'14:30
stekernnot sure. what kind of reset is it?14:30
stekernsw vs hw14:30
maxpalngood question - the only indicator I have is that the router's light goes off, then the LEDs on the RJ45 go back to the defaults. When it wakes up again its in Gbps mode14:31
maxpalnlet me crack out the ILA and see what it shows14:32
maxpalnin fact, the ethernet reset is connected to the WB reset, this can't be being asserted14:34
maxpalnI thnk it must be a SW reset14:34
-!- Netsplit over, joins: 31NAAG4NU, poel14:36
maxpalnyep, the reset definitely happens after the console gets to 'Press Enter to Activate this console'14:38
maxpalnI think it must be a kernel thing14:39
maxpalnperhaps the kernel is expecting a GMII link and when it only sees an MII link it resets the PJHY, not knowing Linux I don't know if this would be expected behaviour or not14:39
Alpha78Anyone knows why i cant check out or1200. I get a (504 Gateway Time-out)??14:42
maxpalnyep, the resetting is definitely related to the 100 Mbps link - if I go back to a 1Gbps link the reset doesn't happen14:46
maxpalndefinitely a SW reset - I can trigger on the MDIO lines using the ILA,14:57
maxpalnthey kick for a second time (after the PHY has been configured as 100Mbps) when the console is waiting for me to press Enter14:58
maxpalni presume this is some part of the kernel trying to be helpful14:59
maxpalnok, partially solved15:09
maxpalnI noticed that the marvell phy struct entry (the one that defined the .config_init entry point) had a definition for .config_aneg that was pointing to '&genphy_config_aneg'15:10
maxpalnI figured this must be being called by the kernel for some reasons15:10
maxpalncommenting out this entry prevented the reset after the kernel is up and running - so the link remains at 100 MBps now! :-)15:11
maxpalnHowever, when I run an 'ifconfig' on the console I get a stack trace! I guess the .config_aneg is needed as part of the setup of the PHY15:11
maxpalnI wonder how little needs to be in there - I don't want it doing a full auto negotiation otherwise I am back to square 115:12
maxpalnok, so I added a roughly empty function that just prints a message to the console whenever .config_aneg is called then returns 0.15:19
maxpalnIt is indeed getting called right at the start of the kernel free running15:20
maxpalnit also gets called pretty frequently while the prompt is idle. If I try to Ping I don't get any reports at all like 'Request Timed Out' or 'Destination Host Unreachable' I just get the debug message I entered in the .config_aneg function15:22
maxpalnso I am assuming that the kernel is unhappy with the 100 MBps link and is continually trying to autonegotiate a link to get back to a Gbps link - this is an assumption and may be incorrect15:23
maxpalnbut it fits with the evidence15:23
stekernhmm, yes. does it somehow believe that it should be in gbit mode?15:26
maxpalnthat is what I am thinking -15:28
maxpalnI am trying to see where that setting could be stored - or written15:28
maxpalnI thought it might be part of the  kernel config but I can't see anything15:28
maxpalnthe alternative is that the autonegoatiation should set a bit somewhere to say that it has been attempted and ended successfully - my 'empty' function doesn't set any bits so it may be that the kernel keeps trying because it doesn't see the bits getting set15:35
maxpalnbut that wouldn't really explain why the autonegotiation happened in the first place!15:36
maxpalnPerhaps the PHY is advertising Gbp mode and the Kernel sees that the link is slower - this would all be real time so there wouldn't be anywhere in the code to control this.15:38
wkoszekIs Julius often around?23:48
--- Log closed Wed Jan 01 00:00:34 2014

Generated by 2.15.2 by Marius Gedminas - find it at!