Ethernet port failure on 2nd stage u-boot
Forums › Devices › OSD335x-SM › Ethernet port failure on 2nd stage u-boot
- This topic has 17 replies, 3 voices, and was last updated 5 years, 7 months ago by
Neeraj Kumar Reddy Dantu.
- AuthorPosts
- October 16, 2019 at 9:55 am #9241
memaherParticipantSorry, this might be quite a large post. Its the strangest problem I’ve dealt with in a long while and I’m lost for ideas…
We’ve got a custom designed board with dual 100mbit Ethernets: MII interfaced ports connected through LAN8710A devices.
1. Running a standard Beaglebone Debian image with custom device-tree, eth0 is alive from the O/S side but unresponsive to data throughput.
2. Pinging the devices from the Ethernet shows activity on the PHY activity lights, showing the PHY is receiving *something*.
3. Performing the MII loopback tests as described in the app notes works perfectly: the PHY’s are online on the MII port.
4. breaking u-boot on the keyboard halt shows ethernet as working (it performs active DHCP requests back to my host computer).So, I can pretty much confirm that the the hardware working, and stage-1 uboot configuration is happy with it. However, the moment the 2nd-stage u-boot and Linux kernel takes over, it breaks the configuration and ethernet fails to work.
There are three possibilities as I see it:
1. my device-tree is wrong
– its had a lot of changes and been validated against EVM device trees so unlikely.2. u-boot is applying beaglebone device trees on top of my device tree.
– the boot messages suggest this is happening3. there is some weird configuration of Linux at work
Option 2 is currently my best guess. The boot messages show a lot of unwanted beaglebone device trees being applied.
Apart from the simple question of “have you ever seen this before or have any suggests where to start looking?”, my main question is
“how can I shut-down the beaglebone overlays so they aren’t overwriting my device tree?
Any ideas?
Mat
————————————————————————————————————
U-Boot SPL 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500) Trying to boot from MMC2 Loading Environment from EXT4... ** File not found /boot/uboot.env ** ** Unable to read "/boot/uboot.env" from mmc0:1 ** 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... ** File not found /boot/uboot.env ** ** Unable to read "/boot/uboot.env" from mmc0:1 ** 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 ... Checking for: /boot.scr ... Checking for: /boot/boot.scr ... Checking for: /boot/uEnv.txt ... gpio: pin 55 (gpio 55) value is 1 2344 bytes read in 65 ms (35.2 KiB/s) Loaded environment from /boot/uEnv.txt Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot ... ** Invalid partition 2 ** ** 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 2340 bytes read in 14 ms (163.1 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 43 ms (3.6 MiB/s) uboot_overlays: [fdt_buffer=0x60000] ... uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ... 951 bytes read in 72 ms (12.7 KiB/s) uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ... 1606 bytes read in 322 ms (3.9 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 246 ms (2.9 KiB/s) uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ... 3675 bytes read in 365 ms (9.8 KiB/s) loading /boot/initrd.img-4.14.108-ti-r113 ... 4696458 bytes read in 313 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 ------------------------------------------------------------------------So,
1. Anyone any ideas what might be going wrong?
2. Anyone any ideas how to shut-down the beaglebone overlays?
Attachments:
- October 18, 2019 at 12:52 pm #9251
Eshtaartha BasuModeratorHello memaher,
Looks like emanip-arm-ctrl.dts was not successfully uploaded due to security issues. Please zip all your files and re-upload them so that we can access it.
1. Please share complete dmesg or boot log. In the current partial boot log, we cannot see any messages related to Eth PHY.
2. Please re-upload all device tree files so that we can review it.
3. If possible, share schematics of Eth PHY circuitry.
4. Have you tried using the official Octavo RED image instead of latest BeagleBoard image? If yes, did you face similar issues on RED image as well?Meanwhile, we’d also recommend taking a look at our Ethernet app note (https://octavosystems.com/app_notes/ethernet-am335x-system-in-package/) and other Dual Ethernet discussions on our forum.
- October 21, 2019 at 8:11 am #9252memaherParticipant
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
- October 21, 2019 at 9:39 am #9255memaherParticipant
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
- October 21, 2019 at 11:17 am #9256
Neeraj Kumar Reddy DantuModeratorHey Memaher,
A couple of changes are suggested for the device tree attached: emanip-arm-ctrl.txt.
1. pinctrl-names ‘default’ and ‘sleep’ are defined but ‘sleep’ pin mux definitions are not linked in the @mac node.
2. The pin mux definitions in ‘mii_pins_default‘ set the pins for GMII and RGMII modes instead of the MII mode that they need to be set to
3. This is more of a clean up action, but please get rid of the pinmux nodes that are not being used for clarity.
These changes might fix the issues you are having. In case they do not, please attach a complete log output of dmesg(failed upload in your last post) so that we can examine how the processor is probing the PHYs and initializing the interfaces
In addition, note that only 1 1.5K pull-up is enough on MDIO_DATA and 2 pull-ups in parallel could be stronger than necessary,
Hope this helps. Please let us know how your debug goes.
Neeraj
- October 22, 2019 at 3:05 am #9272memaherParticipant
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:
- October 23, 2019 at 3:54 pm #9281Neeraj Kumar Reddy DantuModerator
Memaher,
As you pointed out, the MDIO probe is finding 2 PHYs, but only 1 PHY is being initialized after. This could be related to the pinmux declaration. Please let us know how the system behaves after the device tree updates.
Best,
Neeraj
- October 24, 2019 at 6:21 am #9282memaherParticipant
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
- October 24, 2019 at 10:13 am #9283Neeraj Kumar Reddy DantuModerator
Mat,
Can you please attach the dmesg logs for 1. when both ports come up and work and 2. Both ports do not work. You are right that the processor scans the MDIO bus to see where the PHYs are located. But, in our experience, having a wrong address in the device tree still results in the ethernet port not working.
Best,
Neeraj
- October 25, 2019 at 3:00 am #9285memaherParticipant
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:
- October 25, 2019 at 5:06 am #9289memaherParticipant
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.
- October 25, 2019 at 7:29 am #9290memaherParticipant
and 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?
- October 25, 2019 at 3:07 pm #9291Neeraj Kumar Reddy DantuModerator
Mat,
It would be good to verify that the correct device tree and no overlays are being loaded while booting. For this, we will have to look at logs before the kernel starts on UART0. The bootloader log will show whether any overlays are being loaded.
The logs both working and not working only show 1 Ethernet port, while you should see eth0 and eth1 come up.
Note that the PHY address for Beaglebone Black is set to 0. PHY address for the RED board is set to 4. I suspect that the device tree is not loading correctly? See model in the boot logs “[ 0.000000] OF: fdt: Machine model: Octavo Systems OSD3358-SM-RED” while the string you have in your device tree is “model = “Seaeye eManip Arm controller”;”
You can also check the model name in command line: “cat /proc/device-tree/model”
Hope this helps.
Neeraj
- October 29, 2019 at 10:21 am #9328memaherParticipant
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: debian - October 31, 2019 at 3:37 pm #9337Neeraj Kumar Reddy DantuModerator
Memaher,
From the logs it looks like the following is happening:
1. Processor recognizes MMC0 interface, presumably with the SD card as boot source
2. Check for uEnv.txt in /boot/ folder
3. Check for uEnv.txt in /(root) folder
4. Loading environment from /uEnv.txt
5. Checking for uEnv.txt again??
6. Switching to MMC1, presumable eMMC
7. Checking for /boot/uEnv.txt
8. Loaded environment from /boot/uEnv.txt on eMMC
Is ’emanip-arm-ctrl.dtb’ file present in /boot/dtbs/[Kernel Version]/ folder of eMMC?
9. Device tree is switching to dtb=am335x-boneblack-uboot-univ.dtb (line 105)
10. Loading several overlays
The questions are the following:
1. Which boot source are you intending to boot from? (SD card/eMMC) If you are booting from the eMMC, please remove the SD card
2. Which uEnv.txt file are you intending for the processor to read? Is the board reading the correct uEnv.txt file?
3. Is the Device tree file present in the correct location on the desired boot source?
You have both the values debug: ‘[enable_uboot_overlays=0] ...’ and ‘[enable_uboot_cape_universal-0] …’. You can remove all the other variables from your uEnv.txt file to remove any confusion for the processor.
Hope this helps.
Neeraj
- November 1, 2019 at 3:48 am #9338memaherParticipant
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
- November 1, 2019 at 7:27 am #9339memaherParticipant
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) - November 1, 2019 at 10:33 am #9340Neeraj Kumar Reddy DantuModerator
Memaher,
The default behavior of Beagle u-boot is to check the EEPROM first, select the device tree based on the ID and then over ride that selection based on the variable set in uEnv.txt. You can see this behavior in the OSD3358-SM-RED image we host on the website.
We believe that the multiple boot sources and uEnv.txt files that are being sourced could be causing the overrides. We have verified that modifying /boot/uEnv.txt with the correct ‘dtb’ variable name(and corresponding dtb file sitting in /boot/dtbs/[kernel version]) and commenting out everything else in the file did not load any device tree overlays on the latest Beagle image (9.9).
Please let us know if you need further assistance.
Best,
Neeraj
- AuthorPosts
- You must be logged in to reply to this topic.