**** BEGIN LOGGING AT Fri Apr 16 03:00:29 2021 Apr 16 14:46:05 hey Apr 16 15:03:19 I have a question on mdio because i am experiencing some issues with my network phy Apr 16 15:03:45 but it's custome board and do not know if this is the right place to ask Apr 16 15:06:48 what phy is connected is the lan8740 and in dmesg i see the following for mdio https://termbin.com/y7o5 Apr 16 15:07:02 it says the driver is unknown and that it is using a generic driver? Apr 16 15:07:31 and i don't know why it can not detect it with phytool i can read the phy id perfectly fine Apr 16 15:22:00 maybe it doesn't have or need a phy-specific driver? are you experiencing any problems? Apr 16 15:22:12 or if it does have one, maybe it's not enabled in the kernel config Apr 16 15:29:47 normally the specific driver is only needed to use interrupts and configure special features like leds Apr 16 15:30:13 not even interrupts I think? Apr 16 15:30:23 not sure Apr 16 15:30:47 you might be right Apr 16 15:31:00 anyway, basic functionality should always be there Apr 16 15:33:21 it does seem like it should have specific driver support: https://lore.kernel.org/patchwork/patch/633960/ Apr 16 15:33:43 so maybe either the kernel theu use is is too ancient, or they forgot to enable it in the kernel config Apr 16 15:36:03 also interesting that it's saying it has detected two PHYs Apr 16 15:36:12 though only one gets a driver attached Apr 16 15:36:30 well we have two phy's connected to the am335x (both lan8740) one works like normal Apr 16 15:36:53 the other one experiences something weird Apr 16 15:37:16 and the lan8740 was added to the smsc driver in kernel 4.5 Apr 16 15:37:28 so I'm guessing you're using 4.4 or older? Apr 16 15:37:38 4.19 Apr 16 15:37:41 or the driver isn't enabled Apr 16 15:37:51 or that yeah Apr 16 15:38:11 and the generic driver should work regardless Apr 16 15:38:17 CONFIG_SMSC_PHY Apr 16 15:38:18 true Apr 16 15:38:46 if one of them works, I'd suspect a problem with the pcb or possibly clock configuration Apr 16 15:39:10 well it looks to me like potentially a DT issue? given one of the two doesn't even get attached Apr 16 15:39:31 are you using it in switch mode or in dual-emac mode? Apr 16 15:39:42 dual-emac Apr 16 15:39:44 or DT, yes Apr 16 15:39:51 i can share my DT Apr 16 15:40:35 SMSC modules is enabled and configured for m Apr 16 15:43:31 devicetree: https://termbin.com/p3bw Apr 16 15:45:27 oh both get attached but i forgot that one line in my copy Apr 16 15:47:32 https://termbin.com/9daz Apr 16 15:49:47 btw dual_emac is a boolean property, which in DT is just indicated by presence or absence of the property, i.e. "dual_emac;" rather than "dual_emac = <1>;" (writing = <1> has no adverse effect, except it may trick a future maintainer into thinking that disabling it is accomplished by changing it to = <0>; which would have no effect) Apr 16 15:51:02 zmatt: thanks i'll edit it :) i am a future maintainer xD and i wouldn't have known Apr 16 15:53:07 your PHYs have no interrupt line connected to the am335x ? Apr 16 16:01:17 so the issue i see is that when i connect it to my netwerk through the first port (shows as eth0 in my logs) is that when i plug in the cable i can't ping anything but unplugging the cable the phy leds stay on Apr 16 16:03:44 btw, on a purely aesthetic note, instead of having one giant &am33xx_pinmux { ... }; block that declares every pinmux block in your entire DT, I personally find it more readable to partition the DT into sections per logical function, with pinmux declaration grouped near the device to which it is attached Apr 16 16:03:56 that sounds like a problem with your phy itself Apr 16 16:04:33 as in, a hardware issue Apr 16 16:05:28 since the leds are directly controlled by the phy based on link status Apr 16 16:05:32 yea it sound like a hardware issue to me too but I have to be pretty sure :) Apr 16 16:06:37 easy way to be sure: test it without booting (e.g. wipe bootloader from emmc, or power on with sysboot pins overridden in a way that removes emmc from the boot order) Apr 16 16:08:05 depending on the design, that might not enable the phy clocks Apr 16 16:16:01 true Apr 16 16:16:18 the bbb just has a crystal attached to the phy Apr 16 16:17:46 Duality: I'm just looking at my own DT to check for interesting differences.... https://pastebin.com/2DppHhTV ... I clearly had some differences in opinion regarding the pull configuration of the pins Apr 16 16:18:13 it definitely seems bogus to configure MDIO as pulldown in sleep, especially if they have external pullup Apr 16 16:21:41 it also seems there's two ways to reference the phy: either using a 'phy_id' property referencing the parent MDIO and phy ID number (e.g. <&davinci_mdio 0> ) or using a 'phy-handle' property referencing a child node of the mdio controller (whose 'reg' is the phy id) Apr 16 16:22:34 probably shouldn't matter unless you have stuff to configure in the phy node Apr 16 16:22:55 e.g. the bbx15 uses it to configure the interrupt line for each phy Apr 16 16:23:33 my DT has smsc,disable-energy-detect; Apr 16 16:24:51 which iirc had to do with disabling some buggy power-saving feature of the phy, mostly because its workaround in the linux driver was ill-behaved iirc Apr 16 16:28:06 anyway, I'm not seeing any obvious problems... also no obvious reason the PHY is being misidentified by the kernel Apr 16 16:28:23 so not sure what's going on Apr 16 16:29:07 honestly, after all the weird issues I've seen with the SMSC phy on the BBB, I would personally never be inclined to use that PHY or any close family member thereof if I had a say in the matter :P Apr 16 16:31:17 I'm afk Apr 16 16:40:24 Question if u-boot does something weird with the phy (we made a newer u-boot version but had to redo a lot of the configuration) like configuring it weirdly would that affect it's function in linux? or does linux reset the phy and reconfigure it? Apr 16 18:00:33 hey guys, I am currently running this overlay-utils thing that zmatt wrote on a beaglebone black Apr 16 18:00:34 https://github.com/mvduin/overlay-utils Apr 16 18:00:54 I modified the gpio-demo.dtsi configuration file, and that seems to be working Apr 16 18:01:13 now I am trying to figure out how to "turn off" two pins that are enabled as UARTs by default Apr 16 18:01:25 do you know if this is possible/where I might look to find an example of doing this? Apr 16 18:01:37 there are no expansion header pins configured as UART by default Apr 16 18:01:52 P9.11 and P9.13, to be specific Apr 16 18:03:26 I think they default to UART4_RX and TXD by default? Apr 16 18:03:28 https://beagleboard.org/support/bone101 Apr 16 18:03:34 they don't Apr 16 18:03:46 I'm looking at the image on this page right below where it says "The expansion headers provide extensive I/O capabitilities." Apr 16 18:04:43 I guess the point is moot though, I'm still trying to figure out how to disable them on boot, if that's possible? Apr 16 18:07:07 all digital I/O on the expansion headers defaults to GPIO mode (hence high-impedance by default) except: 1. the cape i²c bus on P9.19-20, 2. the eMMC pins P8.03-06 + P8.20-25, 3. if HDMI is enabled, the video pins on P8.27-46 4. if HDMI-audio is enabled, this uses P9.25 + P9.28-29 + P9.31 Apr 16 18:07:29 gotcha Apr 16 18:07:43 and is it possible to "disable" a set of pins? Apr 16 18:07:51 define "disable" Apr 16 18:08:46 good question, this is what a coworker is asking me to do Apr 16 18:08:53 I'm trying to figure out what is meant Apr 16 18:09:07 all pins default to GPIO mode unless configured otherwise (by u-boot or by DT), all GPIOs default to high-impedance (output-disabled) unless configured otherwise Apr 16 18:09:16 so all pins are "disabled" unless configured otherwise Apr 16 18:09:26 ok, so maybe I don't have to do anything then Apr 16 18:09:30 other than not put them in the config file Apr 16 18:10:14 apart from the weak internal pull-up/down (direction varies per pin) that all pins have by default Apr 16 18:10:50 (which must be kept enabled for unused pins) Apr 16 18:11:36 for sure Apr 16 18:11:37 use show-pins to inspect the pin configuration Apr 16 18:11:54 (which would have shown that the pins you mentioned are not configured to uart mode) Apr 16 18:12:33 good idea Apr 16 18:12:35 P9.11                             28 fast rx  up  7 gpio 0.30 Apr 16 18:12:43 P9.11                             28 fast rx  up  7 gpio 0.30 Apr 16 18:12:52 yeah you're right Apr 16 18:13:07 that was an unnecessary paste :P Apr 16 18:13:54 oops Apr 16 18:14:01 I meant to show P9.13 for the second ond Apr 16 18:14:03 one Apr 16 18:14:14 but yeah it looks pretty much the same Apr 16 18:16:02 the current internal pull (up/down/disabled) for pins can be seen using show-pins, the default internal pull (as well as external pulls on the BBB) can be found in columns J and M of the P9/P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126 Apr 16 18:16:11 (legend in bottomright corner of the P9 tab) Apr 16 18:19:51 ok great, thanks for the info Apr 16 18:20:06 yeah it looks like they default to the state we want then Apr 16 18:20:09 thanks! Apr 16 18:22:04 note that P8.31-46 should never be configured to have internal pull that opposes the documented default pull (since that default pull is not internal but on the BBB PCB), use no-pull for those pins instead (if you need to custom-configure them that is, which will also require disabling hdmi obviously) Apr 16 22:39:57 Just started up with my old BBB and am trying to load an update image from the latest images.  Apparently I need to hold the boot button down to actually have it boot from the SD.  Is there a way around this other than burning it? Apr 16 22:40:20 that'll be caused by an old incompatible bootloader on eMMC Apr 16 22:40:53 the fixes would be either reflashing eMMC, wiping eMMC, or at least wiping the bootloader from eMMC Apr 16 22:41:22 So I would need to build a new u-boot image and install it? Apr 16 22:41:40 uh no? Apr 16 22:42:54 which part of that is a no?  building a new u-boot, or u-boot itself... Apr 16 22:43:09 "23:40 <@zmatt> the fixes would be either reflashing eMMC, wiping eMMC, or at least wiping the bootloader from eMMC" Apr 16 22:43:54 if you're going to flash to eMMC then u-boot will be automatically installed as part of it Apr 16 22:44:30 if you're not going to flash to eMMC there's no reason to install u-boot onto it (and in fact I'd recommend not to) Apr 16 22:44:46 in no scenario is there any need to build u-boot yourself Apr 16 22:45:30 if no u-boot is present on eMMC, it'll automatically fall back to using the one on SD card Apr 16 22:46:10 (same as what happens when powering on with the boot button (S2), which causes bootrom to ignore eMMC entirely and thus will always load u-boot from SD card instead) Apr 16 22:48:17 note that if your beaglebone is really old (prior to rev C) and has only 2GB of eMMC (instead of 4GB) then the latest IoT image won't really fit on eMMC (though the console image does) Apr 16 22:49:29 wiping eMMC can be done easily with "sudo blkdiscard /dev/mmcblk1" Apr 16 22:50:00 which if what I'd recommend if you want to continue booting from SD card and don't care about the contents of eMMC Apr 16 23:06:25 It's I Apr 16 23:07:23 Sry, keyboard locked up. Apr 16 23:08:20 So, I just need to modify the uEnv.txt file to flash the new image on the SD card, at which point I should be able to boot the image directly? Apr 16 23:08:33 ...w/o holding the boot button Apr 16 23:10:31 if you want to boot from eMMC, flash to eMMC, if you want to boot from SD card, wipe eMMC Apr 16 23:11:14 flashing to eMMC is (generally) done by booting from a flasher SD card. you can either download a pre-made one, or convert your existing SD card to a flasher by uncommenting the last line of its /boot/uEnv.txt Apr 16 23:12:46 the preconfigure images setup to flash don't have the console enabled.  I'd like to have that done, so I'll need to flash a console version Apr 16 23:13:05 what do you mean by "have the console enabled" ? Apr 16 23:14:14 the "console image" is just a small minimalistic image intended for people who want or need the extra free space (or just don't want all the crap preinstalled on the IoT image) and are okay with having to manually install whatever packages they want Apr 16 23:14:26 Sry, I was referring to images that have the GUI enabled Apr 16 23:14:51 All of the flasher images have it disabled Apr 16 23:15:21 yeah because a full desktop environment is kinda too bloated to fit on eMMC, at least when combined with all the stuff already on the IoT image Apr 16 23:16:10 and since it's rarely useful (and doesn't really run very well on a beaglebone anyway, which isn't designed to be used as desktop PC), none of the default images include it Apr 16 23:16:47 Right.  While I wouldn't mind having an IOT image on there, many of the BBB books reference the GUI in their tutorials Apr 16 23:17:05 ew Apr 16 23:17:47 that probably means information in those books is outdated anyway (as happens often with such books) Apr 16 23:18:02 yeah...I'm mostly cmd line user of linux, but I wanted to load an image comparable to what was loaded originally (an Angstrom image) Apr 16 23:19:16 oh god it's *that* old? Apr 16 23:19:23 angstrom is a dead project and has been for many years Apr 16 23:19:42 Yep...I've had it around for years and have just started getting serious about playing with it Apr 16 23:19:58 any book or documentation old enough to be based on the angstrom era is almost certainly mostly useless today Apr 16 23:20:11 I wouldn't suggest trying to recreate it Apr 16 23:20:30 especially if you're comfortable with the linux commandline already Apr 16 23:20:54 there's generally no good reason to run a desktop environment on a BBB, just connect to it via SSH Apr 16 23:20:57 You're probably right. Apr 16 23:22:02 (even if you'd want to create some kind of custom GUI, you wouldn't need a desktop environment for that, often you don't even need X11, e.g. single-window-fullscreen Qt5 prorgams can be run directly on the framebuffer) Apr 16 23:22:32 I booted a new debian version and I saw that it went right into Cloud9, which I found to be very annoying Apr 16 23:22:45 yeah I don't use it either Apr 16 23:23:25 Yeah, why would I want to do the development directly on the BBB, instead of cross-compiling on a powerful desktop...just don't see it Apr 16 23:23:37 the IoT image has a bunch of stuff meant to make it more "newbie-friendly" Apr 16 23:23:41 including for Windows users Apr 16 23:24:09 I'll try booting one and checking it out Apr 16 23:24:40 if you're comfortable with the linux commandline and debian package management you might actually prefer a console image over the IoT image and just use APT to install whatever you want Apr 16 23:26:21 that's what I was thinking, but the console versions don't have a flash version.  I'll need to modify the uEnv.txt file to have it flash Apr 16 23:27:26 and cross-compiling can sometimes be a headache if the build process or something isn't designed for it or it has complicated library dependencies, so what I actually do is build things on the BBB itself but use distcc to distribute the actual compilation to a fast machine via the network Apr 16 23:27:56 yeah I don't know why console flashers are missing on https://beagleboard.org/latest-images .. then again, until recently console images were entirely missing there Apr 16 23:28:17 but changing a non-flasher image to a flasher image is just a matter of uncommenting one line in /boot/uEnv.txt Apr 16 23:28:33 or you can find flashers for the latest testing image: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console Apr 16 23:28:56 Plus, it's not like I can't reflash it with something else if I'm not happy with it Apr 16 23:29:15 indeed Apr 16 23:30:21 jkridner[m]: what's blocking the latest (2020-08-25) testing images from becoming the new release-images? Apr 16 23:30:39 it's like... 6 months past the intended release date? Apr 17 00:00:24 hmm, just installed the latest Debian flasher image, and when I go to login as root it's asking for a password.  Is there an initial password being set now?  I know I can go in through debian/temppwd and change it, but I'd prefer not to. Apr 17 00:01:17 openssh server does not by default allow login as root using password authentication Apr 17 00:01:25 for security reasons Apr 17 00:01:44 dunno if root has a password set up by default actually Apr 17 00:02:05 but unless you change the openssh settings you'd need to use public-key authentication anyway Apr 17 00:02:16 *the sshd settings Apr 17 00:02:48 generally people just use sudo when needed Apr 17 00:03:13 yeah, that's what I normally do to, just notice the change in behavior and was curious about it Apr 17 00:03:14 (if you need a root shell use "sudo -s" to get one in the current directly or "sudo -i" to get one resembling a fresh login) Apr 17 00:03:36 yeah I think ancient images allowed root login using password Apr 17 00:03:42 that hasn't been true for a very long time Apr 17 00:04:29 or did it allow root login without even a password? if so, yikes Apr 17 00:04:38 but I guess that's what you're implying Apr 17 00:04:49 The version I had on there before allowed login to root w/o password Apr 17 00:04:55 nice, lol Apr 17 00:05:14 though to be fair, the current IoT images are terrible from a security point of view too Apr 17 00:05:29 surprised me too...esp since they had a password on the 'debian' account Apr 17 00:05:39 e.g. I'm pretty sure cloud9 lets you open a root shell without authentication Apr 17 00:10:27 and I think bonescript also lets you run code as root (via a websocket), though I'm not particularly familiar with it Apr 17 00:11:45 when I did sudo -i in cloud9 I needed to supply the debian pw Apr 17 00:12:07 oh cloud9 gives you a debian shell? maybe it used to be a root shell, dunno Apr 17 00:12:28 giving you any shell without authentication is already not great Apr 17 00:14:53 yeah, it put me into the debian account by default Apr 17 00:15:20 no password required Apr 17 00:15:21 the debian account has such wide-sweeping privileges that getting root access is unimportant (and not hard anyway) if you already have access to the debian account... the difference between them is mostly that running stuff as root makes it easier to accidently hose your system **** ENDING LOGGING AT Sat Apr 17 02:59:57 2021