memaher
Forum Replies Created
-
AuthorPosts
-
Resolved: needed to change the external pullups (2k2 now) on the I2C line.
To conclude this thread (as I’m now giving up)…
in Debian 9, dtb= and/or fdtfile= statements are overwritten by the findfdt= macro during boot. This makes it almost impossible to insert a custom device tree using uEnv.txt. The options are therefore:
1. modify/rebuild u-boot
2. use Debian 8
3. implement changes as overlays (however this limits the changes that are possible)I think its a more deep-seated problem. Looking at the startup logs
95: Using: dtb=emanip-arm-ctrl.dtb
105: uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtbLooking into the u-boot source it seems that dtb= (and therefore fdtfile=) can be set to whatever in uEnv.txt, but is then automatically overridden during the i2c EEPROM check.
Everything is pointing at the moment to needing a custom u-boot build, which I’ve been trying to avoid
u-boot is loading a LOT of device trees in addition to my custom one! Is there any way to shut these down other than customising u-boot?
U-Boot SPL 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500) Trying to boot from MMC2 Loading Environment from EXT4... ** Unable to use mmc 0:1 for loading the env ** U-Boot 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500), Build: jenkins-github_Bootloader-Builder-128 CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found Reset Source: Power-on reset has occurred. RTC 32KCLK Source: External. MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from EXT4... ** Unable to use mmc 0:1 for loading the env ** Board: BeagleBone Black Model: Octavo Systems OSD3358-SM-RED not set. Validating first E-fuse MAC BeagleBone Black: Model: Octavo Systems OSD3358-SM-RED: Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus are properly configured BeagleBone: cape eeprom: i2c_probe: 0x54: Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus are properly configured BeagleBone: cape eeprom: i2c_probe: 0x55: Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus are properly configured BeagleBone: cape eeprom: i2c_probe: 0x56: Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus are properly configured BeagleBone: cape eeprom: i2c_probe: 0x57: Net: eth0: MII MODE cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds board_name=[OS00] ... switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 gpio: pin 56 (gpio 56) value is 0 gpio: pin 55 (gpio 55) value is 0 gpio: pin 54 (gpio 54) value is 0 gpio: pin 53 (gpio 53) value is 1 starting USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found gpio: pin 54 (gpio 54) value is 1 Checking for: /boot/uEnv.txt ... switch to partitions #0, OK mmc0 is current device gpio: pin 56 (gpio 56) value is 0 gpio: pin 55 (gpio 55) value is 0 gpio: pin 54 (gpio 54) value is 0 gpio: pin 53 (gpio 53) value is 1 switch to partitions #0, OK mmc0 is current device gpio: pin 54 (gpio 54) value is 1 Checking for: /uEnv.txt ... 2344 bytes read in 4 ms (572.3 KiB/s) gpio: pin 55 (gpio 55) value is 1 Loaded environment from /uEnv.txt Importing environment from mmc ... Checking if uenvcmd is set ... Checking if client_ip is set ... Checking for: /boot.scr ... Checking for: /boot/boot.scr ... Checking for: /boot/uEnv.txt ... ** Invalid partition 3 ** ** Invalid partition 4 ** ** Invalid partition 5 ** ** Invalid partition 6 ** ** Invalid partition 7 ** switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... gpio: pin 56 (gpio 56) value is 0 gpio: pin 55 (gpio 55) value is 0 gpio: pin 54 (gpio 54) value is 0 gpio: pin 53 (gpio 53) value is 1 switch to partitions #0, OK mmc1(part 0) is current device gpio: pin 54 (gpio 54) value is 1 Checking for: /uEnv.txt ... Checking for: /boot.scr ... Checking for: /boot/boot.scr ... Checking for: /boot/uEnv.txt ... gpio: pin 55 (gpio 55) value is 1 2310 bytes read in 15 ms (150.4 KiB/s) Loaded environment from /boot/uEnv.txt debug: [dtb=emanip-arm-ctrl.dtb] ... Using: dtb=emanip-arm-ctrl.dtb ... Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot ... loading /boot/vmlinuz-4.14.108-ti-r113 ... 9929216 bytes read in 644 ms (14.7 MiB/s) debug: [enable_uboot_overlays=0] ... debug: [enable_uboot_cape_universal=0] ... debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] ... uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ... uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb ... loading /boot/dtbs/4.14.108-ti-r113/am335x-boneblack-uboot-univ.dtb ... 163003 bytes read in 46 ms (3.4 MiB/s) uboot_overlays: [fdt_buffer=0x60000] ... uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ... 951 bytes read in 162 ms (4.9 KiB/s) uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ... 1606 bytes read in 128 ms (11.7 KiB/s) uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]... uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ... 867 bytes read in 313 ms (2 KiB/s) uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ... 3675 bytes read in 117 ms (30.3 KiB/s) loading /boot/initrd.img-4.14.108-ti-r113 ... 4696458 bytes read in 314 ms (14.3 MiB/s) debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet] ... debug: [bootz 0x82000000 0x88080000:47a98a 88000000] ... ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8fb85000, end 8ffff98a ... OK Loading Device Tree to 8faf9000, end 8fb84fff ... OK Starting kernel ... [ 0.002139] timer_probe: no matching timers found [ 0.973924] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle [ 1.334822] omap_voltage_late_init: Voltage driver support not added [ 1.342197] PM: Cannot get wkup_m3_ipc handle rootfs: clean, 83819/477664 files, 607632/1907712 blocks [[0m[0;31m* [0m] (1 of 3) A start job is running for…network interfaces (19s / 5min 2s) [K[[0;1;31m*[0m[0;31m* [0m] (1 of 3) A start job is running for…network interfaces (20s / 5min 2s) [K[[0;31m*[0;1;31m*[0m[0;31m* [0m] (1 of 3) A start job is running for…network interfaces (20s / 5min 2s) [K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (2 of 3) A start job is running for…ric Board Startup (21s / no limit) [K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (2 of 3) A start job is running for…ric Board Startup (21s / no limit) [K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] (2 of 3) A start job is running for…ric Board Startup (22s / no limit) [K[ [0;31m*[0;1;31m*[0m] (3 of 3) A start job is running for dev-ttyGS0.device (22s / 1min 30s) [K[ [0;31m*[0m] (3 of 3) A start job is running for dev-ttyGS0.device (23s / 1min 30s) [K[ [0;31m*[0;1;31m*[0m] (3 of 3) A start job is running for dev-ttyGS0.device (23s / 1min 30s) [K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] (1 of 3) A start job is running for…network interfaces (24s / 5min 2s) [K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (1 of 3) A start job is running for…network interfaces (24s / 5min 2s) [K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (1 of 3) A start job is running for…network interfaces (25s / 5min 2s) [K[[0;31m*[0;1;31m*[0m[0;31m* [0m] (5 of 5) A start job is running for dev-ttyGS0.device (25s / 1min 30s) [K[[0;32m OK [0m] Found device /sys/subsystem/net/devices/can0. [[0;32m OK [0m] Started ifup for can0. [[0;32m OK [0m] Found device /sys/subsystem/net/devices/can1. [[0;32m OK [0m] Started ifup for can1. [[0;32m OK [0m] Found device /sys/subsystem/net/devices/eth0. [[0;32m OK [0m] Started ifup for eth0. [[0;32m OK [0m] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. [[0;32m OK [0m] Found device /dev/ttyGS0. [[0;32m OK [0m] Started Raise network interfaces. [[0;32m OK [0m] Reached target Network. [[0;32m OK [0m] Reached target Network is Online. Starting LSB: Advanced IEEE 802.11 management daemon... Starting A high performance web server and a reverse proxy server... Starting OpenBSD Secure Shell server... Starting dnsmasq - A lightweight DHCP and caching DNS server... Starting Permit User Sessions... [[0;32m OK [0m] Started LSB: Advanced IEEE 802.11 management daemon. [[0;32m OK [0m] Started Permit User Sessions. [[0;32m OK [0m] Started Serial Getty on ttyS0. [[0;32m OK [0m] Started Getty on tty1. [[0;32m OK [0m] Started Serial Getty on ttyGS0. [[0;32m OK [0m] Reached target Login Prompts. [[0;32m OK [0m] Started OpenBSD Secure Shell server. [[0;32m OK [0m] Started dnsmasq - A lightweight DHCP and caching DNS server. [[0;32m OK [0m] Reached target Host and Network Name Lookups. [[0;32m OK [0m] Started Generic Board Startup. Starting BB WL18xx Bluetooth Service... [[0;32m OK [0m] Started BB WL18xx Bluetooth Service. [[0;32m OK [0m] Started A high performance web server and a reverse proxy server. [[0;32m OK [0m] Reached target Multi-User System. [[0;32m OK [0m] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [[0;32m OK [0m] Started Update UTMP about System Runlevel Changes. Debian GNU/Linux 9 beaglebone ttyS0 BeagleBoard.org Debian Image 2019-08-03 Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian default username:password is [debian:temppwd] beaglebone login: debianand finally…
PHY ADDRESS = 4 is hard-coded somewhere in the system: it is NOT being read from the custom device tree.
I can say that now, as…
1. Changing my hardware 2nd PHY address away from 4 to 0 (with changing the device tree to match) results in
[ 18.311930] libphy: PHY 4a101000.mdio:04 not found
[ 18.353779] net eth0: phy “4a101000.mdio:04” not found on slave 0, err -19So something, somewhere, is hard-coding this address and it was just coincidence that I chose adr=4 for my second phy.
2. changing my hardware 1st PHY address to 4 (leaving 2nd phy at 0) results in the ethernet port now working (regardless of device tree setting).
So, I now have a working ethernet port. However, it doesn’t explain the root cause of the problem: maybe its the original suspicion of beaglebone overlays still being loaded on top of the custom overlay?
ok, so my theory about the highest address doesn’t stack up. But, I can confirm that changing the PHYID within the cpsw {} device tree sections doesn’t make the slightest bit of difference to the PHYID allocation.
I can also confirm that the extra 1.5k pullup isn’t the issue (now removed).
I’ve modified the board as follows
ethernet#1 = PHYID 5 (this is my eth0 port)
ethernet#2 = PHYID 41. setting the device tree to addresses 0 & 1 respectively results in ethtool detecting PHYID=4 as eth0 (aka it doesn’t work)
2. setting the device tree to addresses 5 & 4 respectively results in ethtool detecting PHYID=4 on eth0 (ditto)
3. setting the device tree backwards to 4 & 5 respectively results in exactly the same PHYID=4.Something is finding address 4 and prioritising it over everything, but I’ve no idea what. It still remains the same problem: eth0 works brilliantly, but only when a cable is plugged into eth1 – otherwise it doesn’t detect a valid link.
Two logs attached.
Later today I’ll attempt to physically change the phy address on eth0 to be higher than eth1 phy. Should confirm whether or not it’s just picking the highest number.
Attachments:
I made all the changes except for the allocation of MII vs GMII. Not sure where to go here, as the options are GMII, RGMII or RMII. As I’m using the full MII I didn’t want to head to RMII. Despite the MDIO problems, using GMII works fine: I get a very stable link up (but of course only when I’ve got both ethernet cables connected).
Interestingly, I tried breaking the cpsw_emac definitions by allocating PHY2 to the wrong address:
&cpsw_emac0
{
phy_id = <&davinci_mdio>, <0>;
phy-mode = “mii”;
dual_emac_res_vlan = <1>;
ifname = “eth0”;
};
&cpsw_emac1
{
phy_id = <&davinci_mdio>, <1>;
phy-mode = “mii”;
dual_emac_res_vlan = <2>;
ifname = “eth1”;
};The end result was the same, it still allocated the eth0 PHY to address 4 (ethtool printout below).
This to me indicates one thing: the eth0 PHY address is being picked up as the last-found address from an automatic scan of the MDIO bus, NOT the device tree.
Still lost how to fix it though!
Mat
——————————————–Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 4
Transceiver: internal
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000000 (0)Link detected: yes
Thanks for the comments. I’ll make the amendments but I don’t think they are the route cause of this problem.
dmesg reattached, from what I can ascertain:
1. Both PHYs are detected correctly on MDIO ([1.171191] + [1.171200])
2. eth0 clearly gets brought up with MDIO:04 [17.571013].MAt
Attachments:
Final bit of useful information. Both dmesg log and EthTool both list the PHY as being at address 4. So, what I think is happening is that the kernel is mis-configured between MII port and MDIO address. What should be:
MII0 == MDIO Addr 0
MII1 == MDIO Addr 4is actually reading
MII0 == MDIO Addr 4
MII1 == MDIO Addr 0This would explain why MII0 port fails if MDIO<4> says the port is disconnected.
However, this being the case, you would think that just swapping the cpsw {} entries for phy addesses would resolve the problem. Alas not: it doesn’t actually make the slightest difference: EthTool STILL reports address 4!
—————————————————————————————————-
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 4
Transceiver: internal
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000000 (0)Link detected: yes
Some progress since, but even more confusing now…
The good news is that its now working. However, to get it working, I had to connect both ethernet ports to a valid target (including the one which isn’t actually being used)! If either Ethernet port is disconnected, then both fail to operate. Is this something you’ve come across before?
I’ll re-upload my files (with .txt extension): please let me know if you spot anything or can shed some light on why its operating in this manner?
My ultimate aim is to have the 3 ethernet ports operating as a switch (CPU as the 3rd). However, I’d settle for just one ethernet port operating (with the other disconnected) for now!
I appreciate your support!
Mat
Thanks Eshtaartha,
I’ve implemented the changes for dual ethernet as suggested but I think it highlights a more fundamental problem with my system! I’ll post in a new thread…
good suggestions. I followed them by putting an MSP430 as power/reset supervisor coupling to a supercap bank. Calculations show this should provide enough power to keep the system alive long enough to perform shutdown.
However, one problem I’ve got is knowing when the processor is actually shutdown. Of course the default response would be to wait for PMIC_PGOOD to fall, but this may be a very long time after the processor has departed. Reading a GPIO is the next best thing, but any application driving this will get removed before shutdown.
Can you think of any way to detect the moment of powerdown?
-
AuthorPosts
