| --- Log opened Tue Dec 31 00:00:32 2013 | ||
| hikenboot | if 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 binds | 04:06 |
| maxpaln | ok, back on this now | 09:03 |
| maxpaln | and it's starting to make a bit more sense | 09:03 |
| maxpaln | seemingly the driver is selected based on the syntax in the .compatible section of the DTS file | 09:03 |
| maxpaln | this much is what I suspected but it took me a while to confirm this | 09:03 |
| maxpaln | I 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 |
| maxpaln | although I haven't confirmed this so it is speculation and could be wrong | 09:05 |
| stekern | hmm, no, and I think from your earlier comments it sounded like the ethmac driver was loaded | 09:08 |
| maxpaln | do you mean no about the defaults? | 09:18 |
| maxpaln | ok, so the 'ethernet' driver doesn't assume a default - I was wrong about this | 09:30 |
| maxpaln | but i think there may be a default for the PHY driver in case of no match | 09:30 |
| maxpaln | just looking in drivers/net/phy/phy_device.c | 09:30 |
| maxpaln | ok, I think I've got th4ere | 09:42 |
| maxpaln | ethoc.c calls phy_connect_direct: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/ethernet/ethoc.c#n691 | 09:43 |
| maxpaln | this jumps to phy_device.c which calls phy_attach_direct: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/phy/phy_device.c#n430 | 09:44 |
| maxpaln | This loads a bunch of stuff into the phy_dev struct then calls phy_init_hw: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/phy/phy_device.c#n569 | 09:45 |
| maxpaln | So far, this is all generic - and will hapen for any PHY | 09:45 |
| maxpaln | phy_init_hw is where the link to a specific PHY is made - the final call to phydev->drv->config_init is the key: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/phy/phy_device.c#n511 | 09:46 |
| maxpaln | config_init is part of the PHY specific struct - in my case contained in marvell.c | 09:47 |
| maxpaln | Now I have a question - how does the or1ksim handle the interrogation of the HW | 09:51 |
| maxpaln | i.e. in HW the Kernel can actually probe the MDIO bus and get the ID of the PHY | 09:51 |
| maxpaln | what 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 one | 09:52 |
| maxpaln | I may have just answered this - adding some printouts I can see the phy_id as 0xFFFFFFFF | 09:52 |
| maxpaln | still, it would be good to know if I can get or1ksim t mirror HW | 09:53 |
| stekern | ah, yes, the phy is a different story | 10:02 |
| stekern | so, what phy_id does it find on the hw? | 10:12 |
| stekern | and does it run the marvel config_init? | 10:12 |
| stekern | that all said - what in the marvell driver do you need? | 10:12 |
| maxpaln | just run on HW and interestingly the phy_id comes back as the same - 0xFFFFFFFF | 10:15 |
| maxpaln | at 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 |
| maxpaln | I was expecting this to contain the ID as read by the Kernel | 10:15 |
| stekern | interesting | 10:15 |
| maxpaln | but now I am wondering if I have misunderstood | 10:15 |
| stekern | try putting some debug printks at the mdio interface functions in ethoc.c | 10:16 |
| maxpaln | on 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 mode | 10:16 |
| maxpaln | but I need to work out how and where to include then in the kernel! | 10:16 |
| maxpaln | your questoin about te config_init is a good one | 10:17 |
| maxpaln | now that the phy_id is all Fs I am questioning what has actually been attached to the phy_device struct | 10:19 |
| stekern | I'd be mostly interested to know if there are any data moving on the mdio lines | 10:22 |
| stekern | first step towards that is debug prints in mdio interface routines in ethoc.c | 10:23 |
| maxpaln | good 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 |
| stekern | if all reads are 0xffff, the lines are probably dead | 10:23 |
| stekern | next step would indeed be a ILA build | 10:23 |
| maxpaln | ok, debug prints first | 10:24 |
| maxpaln | can 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 |
| maxpaln | hmmm, noticed that there is a Tristate control on the MDIO line - wondering if this never gets released! | 10:47 |
| stekern | maxpaln: (or1ksim) I would guess that there are no PHY simulation, I would also guess it wouldn't be superhard to add | 11:03 |
| stekern | but I don't know if the effort is still worth it | 11:03 |
| maxpaln | ok, well - I'll assume I need to run on HW to get some sensible data across the MDIO line | 11:04 |
| maxpaln | hmm, making a little more sense - I have noticed that the genphy_driver has a phy_id of 0xffffffff | 11:10 |
| maxpaln | phy_attach_direct seems to assume there is no driver and attaches the generic one anyway | 11:11 |
| maxpaln | I am looking to see where the actual driver gets attached if it is found | 11:11 |
| maxpaln | I 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 then | 11:17 |
| maxpaln | for example, this function attaches the generic PHY driver - I think this must happen as a result of no driver existing: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/phy/phy_device.c#n536 | 11:18 |
| maxpaln | but what I can't work out is where the correct driver would get discovered | 11:19 |
| maxpaln | there isn't much going on before this point that could resolve the correct driver | 11:19 |
| maxpaln | ok, ILA shows that MDIO bus is working - activity on outputs and OE goes high to disable tristate | 11:45 |
| maxpaln | so comms between ethmac and PHy is present | 11:45 |
| maxpaln | I 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 |
| maxpaln | need to pop out - will be back in an hour or so! | 11:46 |
| stekern | ok, activity on outputs, but do you see the PHY answering on the mdio line? | 11:57 |
| stekern | to answer the question how anything other than the default, this is the flow for that: | 12:14 |
| stekern | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/ethernet/ethoc.c#n1109 | 12:14 |
| stekern | http://lxr.free-electrons.com/source/drivers/net/phy/mdio_bus.c#L169 | 12:14 |
| stekern | http://lxr.free-electrons.com/source/drivers/net/phy/mdio_bus.c#L237 | 12:15 |
| stekern | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/net/phy/phy_device.c#n338 | 12:15 |
| _franck_ | maxpaln: what a bout your PHY address ? | 12:41 |
| stekern | _franck_: afaict, the code loops over all addresses, so it shouldn't matter | 12:44 |
| _franck_ | ah ok, I didn't even look at the code | 12:47 |
| maxpaln | stekern: yep, activity on both output and input lines within the ethmac RTL code | 12:58 |
| maxpaln | so the PHy is responding - I will check through the flow you sent, maybe it will trigger some clues | 12:58 |
| maxpaln | aha - we're back on track! | 13:17 |
| maxpaln | now I'm looking in the right place - the PHY ID is 1410e80 | 13:17 |
| maxpaln | which is not one of the supported PHYs in the Marvell list - unsurprisingly | 13:19 |
| maxpaln | but I should be able to add it easily enough now - I think! | 13:19 |
| maxpaln | Thanks stekern - very helpful, you've guided me back on track! | 13:19 |
| maxpaln | now I just need to work out where the returned PHY ID is compared with the ones the Kernel knows about - shouldn't be too hard | 13:21 |
| maxpaln | Excellent - a quick sanity check yields a successful hook into my new config_init function. Just need to add the necessary register writes now! fingers crossed | 13:38 |
| stekern | maxpaln: great! | 14:08 |
| Alpha78 | Hi All! | 14:25 |
| Alpha78 | Anyone knows why I get "(504 Gateway Time-out)" while checking out or1200? | 14:26 |
| maxpaln | ok, interesting - so the new phy driver works. I can see the PHY reset, then come up as a 100 Mbps link | 14:28 |
| maxpaln | But some time shortly after it gets reset again and comes back up as a 1 Gbps link | 14:29 |
| -!- Netsplit *.net <-> *.split quits: poel, 31NAAG4NU | 14:29 | |
| maxpaln | could the Linux Kernel be forcing a reset for some reason? | 14:29 |
| maxpaln | the timing of the second reset (and wake up as Gbps link) is coincident with the terminal showing the 'Configuring Loopback Device' | 14:30 |
| stekern | not sure. what kind of reset is it? | 14:30 |
| stekern | sw vs hw | 14:30 |
| maxpaln | good 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 mode | 14:31 |
| maxpaln | let me crack out the ILA and see what it shows | 14:32 |
| maxpaln | in fact, the ethernet reset is connected to the WB reset, this can't be being asserted | 14:34 |
| maxpaln | I thnk it must be a SW reset | 14:34 |
| -!- Netsplit over, joins: 31NAAG4NU, poel | 14:36 | |
| maxpaln | yep, the reset definitely happens after the console gets to 'Press Enter to Activate this console' | 14:38 |
| maxpaln | I think it must be a kernel thing | 14:39 |
| maxpaln | perhaps 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 not | 14:39 |
| Alpha78 | Anyone knows why i cant check out or1200. I get a (504 Gateway Time-out)?? | 14:42 |
| maxpaln | yep, the resetting is definitely related to the 100 Mbps link - if I go back to a 1Gbps link the reset doesn't happen | 14:46 |
| maxpaln | definitely a SW reset - I can trigger on the MDIO lines using the ILA, | 14:57 |
| maxpaln | they kick for a second time (after the PHY has been configured as 100Mbps) when the console is waiting for me to press Enter | 14:58 |
| maxpaln | i presume this is some part of the kernel trying to be helpful | 14:59 |
| maxpaln | ok, partially solved | 15:09 |
| maxpaln | I 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 |
| maxpaln | I figured this must be being called by the kernel for some reasons | 15:10 |
| maxpaln | commenting out this entry prevented the reset after the kernel is up and running - so the link remains at 100 MBps now! :-) | 15:11 |
| maxpaln | However, 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 PHY | 15:11 |
| maxpaln | I wonder how little needs to be in there - I don't want it doing a full auto negotiation otherwise I am back to square 1 | 15:12 |
| maxpaln | ok, 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 |
| maxpaln | It is indeed getting called right at the start of the kernel free running | 15:20 |
| maxpaln | it 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 function | 15:22 |
| maxpaln | so 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 incorrect | 15:23 |
| maxpaln | but it fits with the evidence | 15:23 |
| stekern | hmm, yes. does it somehow believe that it should be in gbit mode? | 15:26 |
| maxpaln | that is what I am thinking - | 15:28 |
| maxpaln | I am trying to see where that setting could be stored - or written | 15:28 |
| maxpaln | I thought it might be part of the kernel config but I can't see anything | 15:28 |
| maxpaln | the 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 set | 15:35 |
| maxpaln | but that wouldn't really explain why the autonegotiation happened in the first place! | 15:36 |
| maxpaln | Perhaps 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 |
| wkoszek | Is Julius often around? | 23:48 |
| --- Log closed Wed Jan 01 00:00:34 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!